Ben, All,
Some elaboration on Mick's points
from a hallway chat today.
Re the [bandwidth*delay] network product.
He was suggesting that work on the general topic area of congestion management
from the past decade or two could be leveraged by considering the
[bandwidth*delay] value range of interest. For example, in work on Frame Relay
congestion management, although the bit rate (bandwidth) was lower (say DS-1 or
NxDS-1 rates) the distances were MAN-WAN scale, so perhaps the [bandwidth*delay]
value range would be similar to higher rate Ethernet (say 1/10Gig) over short
data center distances. So maybe solutions for FR CM could be re-applied in some
manner to Ethernet data center applications.
Re the timestamping of Ethernet frames
idea. A source MAC control (or some sublayer above the MAC) could incorporate a
timestamp field. The sink MAC control could send back a frame with the
source's timestamp field and a received timestamp field. Didn't get
into the frequency of this exchange. The source MAC then knows the flight time
to all DAs and can determine when a path to a DA is entering congestion. This
would likely involve either expected delay provisioning or some long term
averaging / learning. Didn't get into that either. So the source MAC
control could apply backpressure to its MAC client under detected congestion
periods.
Note that I've interpolated somewhat
on the timestamping explanation here. Hopefully it's enough though to
spark further thinking.
...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 Benjamin
Brown
Sent: Tuesday, October 05, 2004
9:06 AM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] 802.1
presentation
David,
Thanks very much for interpreting what I heard yesterday. I
heard pretty much the same thing but could not have repeated
it nearly as clear. Please do contact Mick to try to understand
more about his thoughts. They might have (okay, probably)
lead me in a completely different direction than he intended.
Thanks,
Ben
David Martin wrote:
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???)
>>
-----------------------------------------
>>
--
-----------------------------------------
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???)
-----------------------------------------