Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
>>
>>
>>
>>
>>
>>