Matt,
Thanks for the reply.
I'm trying to stay
away from the organizational "where to do it" angle of .3 vs .1 and consider
whether there is some backpressure that could be done at a finer granularity
like per-VLAN ID or per-CoS.
WG locale aside, are
you saying you're not a fan of either a per-VLAN ID or per-CoS backpressure
mechanism?
...Dave
David W.
Martin
Nortel Networks
dwmartin@ieee.org
+1 613 765-2901 (esn
395)
~~~~~~~~~~~~~~~~~~~~
-----Original
Message-----
From:
Matt Squire
[mailto:MSquire@HATTERASNETWORKS.COM]
Sent: Thursday, May 20, 2004 3:43
PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Proposed Upper
Layer Compatibility Objective
In my
head, the bottom line is that this is an unsupportable problem at the Etherent
layer. Congestion is an end-to-end problem - telling someone to slow
down transmissions is an application/host level issue, not a link layer
issue.
Within a
system as Hugh pointed out, congestion starts by having too much traffic going
out at the egress ports, which is then fed back somehow to ingress ports
which then do intelligent discard based on some parameter (p-bits, dscp,
something). Every device I've ever worked on hits the same problems and
follows the same basic paradigms, and seems like Hugh has run into the same
thing. This is not specific to a given bridge
implementation. For feedback to work properly, you have to know where
that traffic is going. It isn't based on the classification algorithms
allowed by the switch (e.g. doesn't matter if they're using different
classification algorithms), but is based on what they do to each
packet. For example, in a bridge, you'd want to know which
packets are destined to which egress ports on the bridge to which you're
forwarding so that you could selectively pause traffic for the congested
egress port. Thats just not a problem .3 can or should solve.
IMHO, .3
helps best by maintaining a reliable pipe for some higher layer QoS mechanism
to use in the manner it is configured to do so. Creating multiple,
different class channels within a single .3 link is not a good direction
for us to go.
-----Original
Message-----
From: David
Martin [mailto:dwmartin@NORTELNETWORKS.COM]
Sent: Thursday, May 20, 2004 2:31
PM
To:
STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: Re: [8023-CMSG] Proposed Upper
Layer Compatibility Objective
Hugh,
For sake of discussion, if you take as a given that
all bridges have 8 output queues per port, where frames are classified based
on CoS (MEF terminology) aka user_priority (802.1 terminology), then if a
downstream bridge could send a Pause_CoS_n (where n=0..7) backwards /
upstream, wouldn't that alleviate the scalability issue you
mentioned?
In arithmetic terms, Device 1 would need 8*P queues,
where P is the number of ports it has.
Doesn't the scalability issue you mentioned only
arise when different bridges use different output queue classification
approaches? Then I could imagine a squared-type of
relationship.
Just trying to follow the line of reasoning here.
Thanks.
...Dave
David W. Martin
Nortel Networks
dwmartin@ieee.org
+1 613 765-2901 (esn 395)
~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: Hugh Barrass [mailto:hbarrass@CISCO.COM]
Sent: Thursday,
May 20, 2004 9:23 AM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG]
Proposed Upper Layer Compatibility Objective
Brad,
I've answered below:
Booth, Bradley wrote:
>Hugh,
>
>I want to lock in on one paragraph you
mentioned. It is listed below:
>
>"The only use of PAUSE that would (might) work
would be if device 2
>could
>signal to device 1 that only frames destined for
port K should be
>paused. This would require that device 1 must
understand how device 2 is
>going to classify and direct the traffic and
device 1 must maintain
>separate queues on its output port corresponding
to the output ports of
>device 2. This means that device 1 will wind up
with a total number of
>queues equal to the sum of all the queues on all
of the devices
>connected to it. Scaling for more than 2 devices
is left as an exercise
>for the reader."
>
>You said that this would require
device 1 to understand how device 2
>classify and directs traffic. When you say
that are you referring to
>the 802.3 portion of device 1? If you are,
then I would agree that we
>have an issue of adding "intelligence" to the
802.3 MAC. If not, would
>not 802.1 know how to classify this
traffic? Maybe this has to do with
>the definition of port, priority
and queue. It might help if you could
>explain your use of the terminology
to a layman.
>
>
>
If device 2 wants to send a message that says,
"pause the traffic that
will be directed to my output queue K" then device 1
must understand the
criteria that device 2 will use to forward traffic
to its output K. That
may be MAC address, that may be IP address, or
something else entirely.
Note that the "output queues" of device 2 may be
physical ports, virtual
ports or even s/w queues for an edge
device.
Hugh.