Re: [8023-CMSG] Questions
Gadi,
Could you point to the document where such a change
would be placed?
Then, the next problem is how to provide a similar
priority-based pause from the MAC to the client
and (perhaps) the client to the MAC.
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: Gadi Lahat [mailto:Gadi@TERA-CHIP.COM]
>> Sent: Wednesday, May 19, 2004 5:04 AM
>> To: David V James; STDS-802-3-CM@listserv.ieee.org
>> Subject: RE: [8023-CMSG] Questions
>>
>>
>> All
>> Continuing on the line David started below
>> The current frame structure of PAUSE, allows the congested, to signal
>> the congested, stop any traffic to Xn destination.
>> One can even go finer, and request stop any traffic from Xn and CoS
>> lower than B.
>> This can be referred to as Distinctive Backpressure, different than the
>> current Link Level Backpressure.
>> The CSIX standard enables such signaling.
>>
>> Gadi
>>
>>
>> ________________________________
>>
>> From: David V James [mailto:dvj@ALUM.MIT.EDU]
>> Sent: Tuesday, May 18, 2004 22:15
>> To: STDS-802-3-CM@listserv.ieee.org
>> Subject: Re: [8023-CMSG] Questions
>>
>>
>> All,
>>
>> A few thoughts.
>>
>> In the local (backplane or computer room) environment, the latency is
>> small enough
>> that congested traffic doesn't have to be dropped--feedback to the
>> sources can stiffle
>> the traffic to supportable rates. As such, I'm not very interested in
>> using priorities
>> to determine the drop rate: if one cares, this should be zero in the
>> local interconnect.
>>
>> However, rate restrictions _do_ depend on what type of traffic is being
>> sent.
>> I tend to like the simplistic p802.17 model for classes of service:
>> A (TDM like, telephony),
>> B (longer latencies, but BW still guaranteed)
>> C (best effort)
>>
>> For the classA, there should be no restrictions on bandwidth, as devices
>> should
>> only use what was prenegotiated.
>>
>> For the classB and classC, things get more interesting.
>>
>> From the perspective of a PAUSE, the generalization to support a
>> level-based
>> PAUSE is more important than a send-this-amount-of-bandwidth parameter.
>> Instead, a pause-everything-less-than-this-priority feature would seem
>> to be more
>> valuable.
>>
>> 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 Hugh Barrass
>> Sent: Tuesday, May 18, 2004 11:41 AM
>> To: STDS-802-3-CM@listserv.ieee.org
>> Subject: Re: [8023-CMSG] Questions
>>
>>
>> Brad,
>>
>> If you step back & think about it - what PAUSE does is reduced
>> the net bandwidth used on a link. If the devices at both ends of the
>> link were smart, they would somehow negotiate what that net rate should
>> be (so that the output of one drains at a rate that doesn't mess up the
>> input of the other). Making this work using an XOFF/XON mechanism
>> operating across an (potentially very long) link is far from optimal.
>> Perhaps there is scope to change the PAUSE definition to say "send me no
>> more than X % of bandwidth on this link."
>>
>> From the perspective of a higher layer, setting the effective
>> width of a pipe should be perfectly acceptable; other changes that
>> increase the "intelligence" of the MAC layer would require much more
>> scrutiny.
>>
>> Hugh.
>>
>> Booth, Bradley wrote:
>>
>>
>> JT,
>>
>> I got the answer I needed, which is that there is a base
>> assumption that
>> an 802.1 layer needs to exist above the 802.3 MAC if
>> there is going to
>> be any use of priorities. It was the interaction
>> between the MAC's
>> queues and 802.1 queues that I didn't understand as I
>> spend most of my
>> time at the physical layer.
>>
>> I'm still mulling over the statement by Matt that PAUSE
>> makes a bigger
>> pipe into a smaller pipe. Over a long period of time
>> and if it was
>> implemented correctly, I could understand that analogy.
>> The trouble I'm
>> having with that statement is that it seems to me that
>> PAUSE is
>> performed because of back pressure from upper layers
>> (memory has passed
>> a watermark). If upper layers can handle QoS/CoS, then
>> surely they'd be
>> able to handle making a big pipe run like a small pipe.
>> If they cannot,
>> then it seems that PAUSE would want some finer
>> granularity rather than
>> XON/XOFF.
>>
>> Thanks,
>> Brad
>>
>> -----Original Message-----
>> From: owner-stds-802-3-cm@listserv.ieee.org
>> [mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf
>> Of Jonathan
>> Thatcher
>> Sent: Monday, May 17, 2004 8:49 AM
>> To: STDS-802-3-CM@listserv.ieee.org
>> Subject: Re: [8023-CMSG] Questions
>>
>>
>> Brad,
>>
>> The way you choose to ask the question sends the
>> response in a
>> particular
>> direction that you may, or may not be intending.
>>
>> If I were to ask you if 10GBASE-T knows how to forward
>> packets from the
>> MAC-Client interface one could respond in two different
>> ways where both,
>> depending on perspective, are technically correct:
>>
>> 1. 10GBASE-T does not know anything about the MAC-Client
>> interface as
>> that
>> is exposed only in layers above 10GBASE-T.
>> 2. Of course it does. By definition, 10GBASE-T
>> references the upper
>> layers.
>> These are, therefore, explicitly included in the
>> 10GBASE-T
>> specification.
>>
>> Now someone might argue with each of these. For
>> instance, the argument
>> to
>> the second might be, "you don't understand, the MAC is
>> common across
>> multiple port types." This argument is true, but misses
>> the point. The
>> fact
>> is, that is the beauty of the layered architecture.
>>
>> Ethernet is not just the PMD. Ethernet is the PMD and
>> all layers above
>> the
>> PMD that provide a complete solution, whether those
>> layers are shared or
>> not.
>>
>> Just because 802.1 is shared with other 802 "dots" does
>> not mean that
>> when
>> it is integrated with Ethernet that it isn't part of
>> Ethernet.
>>
>> Some in 802.1 would argue that all of 802.1 is part of
>> the MAC. 802.1 is
>> part of Layer 2. 802.1 is part of an Ethernet solution.
>>
>> There are any number of ways that you could modify your
>> question to get
>> opposite responses.
>>
>> Example: Is it understood or implied that 802.3 knows
>> how to direct to
>> and
>> from multiple queues? Answer: Absolutely. See EPON. But,
>> even without
>> EPON,
>> MAC-Control knows how to deal with packets to/from
>> control and data
>> queues.
>>
>> Etc.
>>
>> My response to 1) would therefore be: 802.1 knows.
>> Therefore, by
>> definition
>> Ethernet knows.**
>>
>> jonathan
>>
>> ** Exception: if there is no 802.1, then there are no
>> queues and
>> Ethernet
>> doesn't know because there is nothing to know. In this
>> case, the
>> question is
>> moot. :-)
>>
>>
>>
>> -----Original Message-----
>> From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
>> [mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]On
>> Behalf Of Booth,
>> Bradley
>> Sent: Sunday, May 16, 2004 6:50 PM
>> To: STDS-802-3-CM@LISTSERV.IEEE.ORG
>> Subject: Re: [8023-CMSG] Questions
>>
>>
>> Norm,
>>
>> Thanks for the response. Two follow-up
>> questions:
>> 1) Is it understood or implied that Ethernet
>> knows how to
>> direct frames
>> to and from these 8 queues?
>> 2) What if the device does not use a bridge as
>> in an adapter?
>>
>> Thanks,
>> Brad
>>
>> -----Original Message-----
>> From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
>> [mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]
>> On Behalf Of
>> Norman Finn
>> Sent: Sunday, May 16, 2004 11:11 AM
>> To: STDS-802-3-CM@LISTSERV.IEEE.ORG
>> Subject: Re: [8023-CMSG] Questions
>>
>>
>> Brad,
>>
>> I think you did miss the mark, particularly
>> with:
>>
>> "Considering that Ethernet doesn't know in
>> advance about the
>> provisioning
>> of the network and does not care about which
>> packets it delays or
>> drops,
>> then it is likely that 802.1 and the upper
>> layers can do all the
>> priorities or differentiated services that
>> they want but will see
>> diminishing returns as the load on the
>> network increases."
>>
>> I would agree with, "Ethernet doesn't know in
>> advance about the
>> provisioning
>> of the network", but 802.1D bridges certainly do
>> care about
>> which frames
>> are
>> delayed or dropped. Bridges define the use of 8
>> queues per
>> output port,
>> and
>> frames are marked with 8 levels of priority.
>> Although strict priority
>> scheduling is the only queue draining algorithm
>> specified in the
>> standard,
>> others are explicitly allowed, and most vendors
>> implement
>> varieties that
>> provide very good latency and bandwidth
>> guarantees. Furthermore, a
>> great
>> many bridges are able to assign priorities to
>> 802.3 frames based on
>> criteria
>> such as IP DSCP code points.
>>
>> In short, ethernet is *far* from "best effort".
>>
>> -- Norm
>>
>> Booth, Bradley wrote:
>>
>>
>> My apologies in advanced if the answers
>> are obvious, but
>>
>>
>> I've been so
>>
>>
>> focused on cabling and physical layer
>> the last couple of
>>
>>
>> weeks, so I'm
>> a
>>
>>
>> bit brain dead to upper layer stuff.
>>
>> There has been some talk about
>> differentiated services and
>>
>>
>> priorities
>>
>>
>> associated with 802.1 and the upper
>> layers. Here are my questions:
>> 1) If the network is overprovisioned
>> (available bandwidth >= maximum
>>
>>
>> instantaneous throughput), then am I correct in
>> assuming that
>>
>>
>> these differentiated services and
>> priorities operate just
>>
>>
>> fine because
>>
>>
>> the upper layer protocols within the
>> switches have sufficient
>> bandwidth? Should I also assume that
>> the available
>>
>>
>> bandwidth is based
>>
>>
>> upon what the end stations (adapters,
>> servers, etc.) can handle?
>> 2) If the network is not overprovisioned
>> (either in the switches or
>> adapters), then is it fair to assume
>> that these differentiated
>>
>>
>> services
>>
>>
>> and priorities will provide diminishing
>> returns as throughput
>>
>>
>> increases
>>
>>
>> over the available bandwidth?
>>
>> I keep coming back to the statement
>> others have made that
>>
>>
>> 802.1 or the
>>
>>
>> upper layers can handle this, but I
>> cannot help think that
>>
>>
>> would only
>> be
>>
>>
>> true for an overprovisioned network.
>> Considering that Ethernet
>>
>>
>> doesn't
>>
>>
>> know in advance about the provisioning
>> of the network and does not
>>
>>
>> care
>>
>>
>> about which packets it delays or drops,
>> then it is likely that 802.1
>>
>>
>> and
>>
>>
>> the upper layers can do all the
>> priorities or
>>
>>
>> differentiated services
>>
>>
>> that they want but will see diminishing
>> returns as the load on the
>> network increases.
>>
>> This would seem to me like going out and
>> buying a Formula 1 race car
>>
>>
>> to
>>
>>
>> use to drive to work in Silicon Valley.
>> A lot of money in fuel and
>> equipment only to sit on 101 during rush
>> hour(s).
>>
>> Am I off the mark here?
>>
>> Thanks,
>> Brad
>>
>>
>>
>>
>>
>>