Re: [8023-CMSG] 802.1 presentation
Ben,
1) I find the timing knowledge an interesting one.
For some applications (video, audio), this information
might already be there, or would be useful if it were
to be there.
It would be interesting to compare queue depth to delay,
possibly with simulations, to better understand which
might be better.
I suspect that queue depth is a more effective measure,
but is harder to normalize and communicate.
2) What is a "network power product"? My first reaction
was nanowatts-per-pit-transferred, but I suspect that's
not the case.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
>> -----Original Message-----
>> From: owner-stds-802-3-cm@listserv.ieee.org
>> [mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of Benjamin
>> Brown
>> Sent: Monday, October 04, 2004 12:59 PM
>> To: STDS-802-3-CM@listserv.ieee.org
>> Subject: [8023-CMSG] 802.1 presentation
>>
>>
>> All,
>>
>> I gave the presentation to 802.1 this afternoon in Ottawa.
>> It went well. They agreed to continue hearing proposals on
>> the subject. Bob and Tony will discuss how the meeting
>> logistics will work out.
>>
>> Layer 2/3 switches do this today, though it is not specified
>> within 802.1.
>>
>> There were questions regarding the usefulness of using the
>> intermediate bridges to indicate this information. It has already
>> been shown that this is useful over smaller networks and less
>> useful over larger networks. If the network is small (relative
>> to the number of packets in flight), why not just have the receiving
>> station flag congestion when it receives a packet that took longer
>> to arrive than expected.
>>
>> To me, this means some kind of timing knowledge between
>> end stations. First, a receiving station must know how long a
>> packet should take to arrive from each destination. Second,
>> stations must have a common time base in order to determine
>> when that received packet has exceeded its expected flight
>> time. Mick Seaman is pushing this idea so it would be interesting
>> to pick his brain regarding where this is coming from.
>>
>> Mick wants us to specify the network power product for the
>> networks that we feel are the most interesting. Bob told him that
>> our major interest was with reducing discards and increasing
>> throughput. A reduction in memory usage is merely a bonus.
>> He said the power product is useful information since different
>> values can point us in different directions. I don't understand
>> this much. Thoughts and comments from those who do would
>> be a useful discussion topic on this reflector (at least for me).
>>
>> We were apparently successful in bringing examples of possible
>> solutions to show feasibility without trying to shove a solution
>> down their throat. We apparently passed several litmus tests
>> by not mentioning QOS and not suggesting a hop-by-hop
>> solution. Several people told me after the presentation that they
>> didn't know what to expect but didn't expect they were going to
>> like it and instead were pleasantly surprised that we just want
>> to solve a problem and don't really care how its done. We found
>> one way but we're not married to it.
>>
>> Anyway, Bob might have other thoughts regarding the outcome
>> of this meeting. If there are questions or comments on any of the
>> above, please air them so we can talk about them.
>>
>> Thanks,
>> Ben
>>
>> --
>> -----------------------------------------
>> Benjamin Brown
>> 178 Bear Hill Road
>> Chichester, NH 03258
>> 603-491-0296 - Cell
>> 603-798-4115 - Office
>> benjamin-dot-brown-at-ieee-dot-org
>> (Will this cut down on my spam???)
>> -----------------------------------------
>>