RE: [8023-CMSG] 802.1 presentation
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???)
>> -----------------------------------------
>>