From: Gadi Lahat
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
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: Hugh Barrass
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: Jonathan Thatcher
Sent: Monday, May 17, 2004 8:49 AM
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: Brad Booth
Sent: Sunday, May 16, 2004 6:50 PM
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: Norman Finn
Sent: Sunday, May 16, 2004 11:11 AM
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