| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Brad, Manoj, Dr.James,
I'll take a stab at answering your questions.
The discussion about L2-3 switches was that they often mark (non-802.1-std) the IP ECN bit under congestion situations. So the problem has already been solved (albeit proprietarily) for any IP client protocol.
As far as end stations, the 802.1 folks admitted they haven't done the due diligence at describing DTE VLAN processing (they've focused on bridges), and also indicated they don't plan to. Re handling CI in DTEs (e.g., IP ECN bit), I would imagine they would say that's covered by IETF - although that wouldn't cover all protocols.
I think Mick's comments about "network product" were in the context of the network [bandwidth*delay] product required by the application. Meaning that different applications' requirements for [bandwidth*delay] values may lead to different network solutions. I'm at the 802.1 interims for the duration, so I'll try and corner Mick for more insight.
About the "small network and let the end station detect a slow frame" approach: If the network is small, then the typical prop delay is small (say 100usec?), so the delay variation is really small (say 10usec?). Is the timing precision required by the end station to detect a slow frame within practical limits? Not sure about that.
...Dave
David W. Martin
Nortel Networks
dwmartin@ieee.org
+1 613 765-2901 (esn 395)
~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org [mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of David V James
Sent: Monday, October 04, 2004 4:24 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: 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???)
>> -----------------------------------------
>>