Re: [8023-CMSG] Purpose
Gadi,
Please see my recent note (addressed to Glen).
Implicit in said note is that congestion is a bigger problem that seen at
two ends of a link. It ***MAY*** be the case that we (802.3) can come up
with something so genius, that the designer/implementers of the paths
between links unambiguously know what to do with traffic such that there is
consistent operation across equipment from a variety of manufacturers. The
only difference between BP and longer links should be the size of the
buffers.
For, even in the case of BP, users will want to know that the manufacturers
of blades play with each other nicely. There are some blades that will be
sources or destinations. If all were, this would be trivial. But, we must
presume that some blades will be bridges, switches, routers, etc, and
intermediate points within larger networks. With this model, we are using BP
(CM) as a fabric between blades.
To this degree, we are turning the fabric inside out (a nice mathematical
trick that reminds one of the joke about the engineer, physicist, and
mathematician fencing in sheep). The "bridge" between ports is now the 802.3
links and the links between ports is now the bridge. This may sound
facetious. It isn't. This is exactly why flow control has been the bane of
PCI-Express Advanced Switching and other similar activities.
jonathan
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of Gadi Lahat
Sent: Monday, May 03, 2004 11:31 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Purpose
Jonathan
I think that we should start with trying to see if there is merit in just
link level 802.3 .
We can then have a better understanding of what 802.1 support is required (
as in 802.p and Q which where pushed by 802.3 and been closed with 802.3ac
by changing the frame format)
End to End solution does look like the "right" thing, and probably yields
best performance.
However End-to-End solution sounds like an ATM initiative, and I'm not sure
..... we want to get there.
Again - Lets first understand why Ethernet customers, want CM in Ethernet,
if they all ready have perfectly good mechanisms in ATM.
Or is the CM merit is just in supporting the BP Ethernet solution ?
Thanks
Gadi
_____
From: Jonathan Thatcher [mailto:jonathan.thatcher@IEEE.ORG]
Sent: Monday, May 03, 2004 8:06 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Purpose
Ben, Gadi,
I think I may have introduced some ambiguity. There are three types of
behavior, generally, that might be considered. We may be using
"edge-to-edge" to include two of these. So, let me attempt to distinguish
these and see if it makes sense.
1. Link-level CM: this is done one link, or one hop at a time. It is
independent of source, destination, edge, bridge, switch, and the like.
2. L2-end-to-end CM: this is done from entry to L2 until exit from L2. It
includes consistent "Link-level-CM" as well as consistent bridge CM.
3. LN-end-to-end CM: this includes consistent "L2-end-to-end CM" as well as
something that "backs up" into the higher layer where injection rates are
ramped (or otherwise controlled).
Presuming that we only do link-level CM, then there is no way to ensure that
a user can expect consistent behavior across the entire "L2 network"
integrated with systems/components from multiple suppliers.
Presuming that we do L2-end-to-end CM, the user can ensure consistent
behavior across the entire "L2 network," but this does ensure that these
features are used by upper layers in any optimal way.
LN-en-to-end CM may provide both consistent behavior and more optimal use.
But...
Link-level CM might be done within 802.3.
L2-end-to-end CM would be difficult, if not impossible, without some, if not
much, 802.1 interaction.
LN-end-to-end would be difficult, if not impossible, without some, if not
much, IETF (or other) interaction.
The potential value is significantly greater with greater interaction (read
that greater complexity). Least interaction (802.3 alone) has the potential
of providing a feature with little additional value to PAUSE.
jonathan
-----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, May 03, 2004 7:33 AM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Purpose
Gadi,
While it may be interesting to talk about what it means to make
congestion management a layer 2 edge-to-edge service, this isn't
really what we're set up to do. We may decide there are pieces
of this effort that need to work edge-to-edge but it isn't the job
of this 802.3 study group to figure that out. We're here to figure
out if there is anything that 802.3 wants to do about this issue.
This implies a clear understanding of what the problem is that
802.3 wants to do something about and then what that something
is (in general terms at this point). A suggestion for an 802.1 project
may very well come out of this study group but that's about as far
as this particular study group can go.
This does, however, bring up another interesting discussion. Both
802.3x MAC Control Frames (PAUSE) and 802.3ad Link
Aggregation didn't have an accompanying 802.1 project. 802.3
provided a service that MAC Client implementations could use
to differentiate themselves for customers. This may be a similar
project if 802.1 doesn't find a component of this they want to
standardize.
Regards,
Ben
Gadi Lahat wrote:
Glen
I wanted to thank you for pointing to the important issues first, before
we dive into the details devil.
I would like to make it bolder
Is CM supposed to control the link only ? Just the local link (hop) ?
Be aware of the end to end path ?
OR
CM is supposed to be more network oriented, that is more like
standardizing a switch ( multiport bridge ...) core load management ?
We can then consider if 802.1 is more appropriate than 802.3, and how
speed matters.
Thanks
Gadi
-----Original Message-----
From: Glen Kramer [ mailto:glen.kramer@TEKNOVUS.COM
<mailto:glen.kramer@TEKNOVUS.COM> ]
Sent: Friday, 30 April, 2004 22:29
To: STDS-802-3-CM@listserv.ieee.org
<mailto:STDS-802-3-CM@listserv.ieee.org>
Subject: Re: [8023-CMSG] Purpose
Jonathan,
Improving performance is good, but how would one know if this is
achieved.
Very good point. This brings even more fundamental question: how do we
know that there is a congestion in the first place. After all, 802.3
scope ends at MAC service interface. MAC is given one frame at a time,
and while transmitting a frame, at best, it will know that another frame
is waiting.
Except for, perhaps, "Shall provide predictable, consistent
network-wide operation" :-)
Another related point: what is "network-wide" operation in the context
of 802.3? Is it a station-to-station within a single access domain?
Regarding 802.1 v 802.3, I am working on a presentation on this topic.
So, in the end, what objectives would you recommend adding?
I would be happy to collaborate on objectives and possible solutions.
But I have difficulty understanding what can be done within 802.3. It
would be more prudent to wait for your presentation explaining why this
job should be done under 802.3 and not 802.1.
Glen
Congratulations! Without making any changes to 802.3 you may claim
that all the CMSG objectives were already met.
Except for, perhaps, "Shall provide predictable, consistent
network-wide operation" :-)
Yes, you are correct about my list being primarily about constraints.
Your points are all worthy of study and discussion. Improving
performance is good, but how would one know if this is achieved
Implicit in your comment is that there are aspects of CM that are not
defined. I would be surprised if any disagree there. One thing that is
implicit to me is that unlike PAUSE, CM will manage traffic flow to
finer granularity than the link.
On your second point, I thought that MPCP avoided specifying the
method of doing rate control. I would love to see a presentation about
how said simplification might be useful.
Regarding 802.1 v 802.3, I am working on a presentation on this topic.
So, in the end, what objectives would you recommend adding?
jonathan
-----Original Message-----
From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
<mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG>
[ mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG
<mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG> ]On Behalf Of Glen
Kramer
Sent: Thursday, April 29, 2004 3:35 PM
To: STDS-802-3-CM@LISTSERV.IEEE.ORG
<mailto:STDS-802-3-CM@LISTSERV.IEEE.ORG>
Subject: Re: [8023-CMSG] Purpose
Jonathan,
Congratulations! Without making any changes to 802.3 you may claim
that all the CMSG objectives were already met.
Indeed, current 802.3 (with upcoming additions) already supports
copper and optical media, 100 Mb/s, 1 Gb/s, and 10 Gb/s rates,
consistent with 802 architecture, provides predictable operation,
and supports OAM. Anything else we should do?
Seriously, I think your list of objectives is really just a set of
constraints that should be observed. But what this study group wants
to achieve? What is missing?
I am not certain that QoS should not be an objective. The very
reasons to use congestion management are to get better performance
than afforded by the best-effort operation. I agree that the term
QoS is overloaded. So, let's talk about specific parameters: delay,
jitter, frame loss, and may be bandwidth utilization as well. An
attention should be given to decoupling of bandwidth and delay.
Many time-division systems suffer from this.
This group may do some interesting things that would improve
performance. I will just list some general ideas and let the group
decide if these are the worthy of studying further:
1. PAUSE frame provides ON/OFF control. It is known that such
control methods do not easily achieve steady state behavior,
especially is control loop delay is high. On the opposite, they tend
to amplify traffic oscillation throughout the network, as a result
increasing jitter and packet loss. One way to improve the
performance is to change the rate control from ON/OFF paradigm to
"adjust by delta" paradigm. (Add a new MAC Control
message?)
2. 802.3ah P2MP STF introduced Multi-Point Control Protocol that
performed explicit rate control for multiple devices. It can be
extended (actually
simplified) to be used on P2P links.
One question that is not completely clear to me is why 802.3 and not
802.1?
Cheers,
Glen
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org
<mailto:owner-stds-802-3-cm@listserv.ieee.org>
[ mailto:owner-stds-802-3 <mailto:owner-stds-802-3> -
cm@listserv.ieee.org <mailto:cm@listserv.ieee.org> ] On Behalf Of Jonathan
Thatcher
Sent: Thursday, April 29, 2004 3:35 PM
To: STDS-802-3-CM@listserv.ieee.org
<mailto:STDS-802-3-CM@listserv.ieee.org>
Subject: Re: [8023-CMSG] Purpose
Okay, I'll take a shot at the objectives:
First, my list of anti-objectives:
-- No support for half-duplex
-- No changes to PCSs / PMAs / PMDs
-- No simultaneous support for PAUSE and CM
-- Not end-to-end flow control (no transaction layer)
-- No traffic classification (e.g. looking at L3/L4/L5...)***
-- No reordering within class (e.g. by priority within class)
-- Not QoS****
Objectives:
-- Shall support up to 100 m of media (copper or optical)*****
-- Shall support 100 Mb/s, 1 Gb/s, and 10 Gb/s
-- Shall be consistent with IEEE 802.3 and IEEE 802.1 layer
architecture
-- Shall provide predictable, consistent network-wide operation
-- Shall be consistent with slow protocols (e.g. OAM)
Questions:
-- Maximum supported latency across link (MAC to MAC)?
-- Support of FEC?
*** this does not mean that there isn't some traffic class
identifier
provided by L2 and used within L2. It means that L2 does
not classify the
flow and associate it with the identifier.
**** QoS is an ambiguous, overloaded term. In most cases,
it is associated
with a contract with a user rather than a feature or
function provided to
a
higher layer. Frequently it includes policies, shaping,
rate limits, etc.
Congestion management has little to nothing to do with this.
***** not necessarily all media!
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org
<mailto:owner-stds-802-3-cm@listserv.ieee.org>
[ mailto:owner-stds-802-3-cm@listserv.ieee.org
<mailto:owner-stds-802-3-cm@listserv.ieee.org> ]On Behalf
Of Benjamin
Brown
Sent: Thursday, April 22, 2004 8:09 AM
To: STDS-802-3-CM@listserv.ieee.org
<mailto:STDS-802-3-CM@listserv.ieee.org>
Subject: [8023-CMSG] Purpose
Hi,
I thought I'd try to kick start some discussions around the
Congestion Management Study Group's purpose for existence.
We have 3 tasks to accomplish between now and the May interim.
We need to develop a PAR, 5 Criteria and a list of objectives.
Ideally we can accomplish this in May in order to pre-circulate
the PAR and 5 Criteria so that we can formally request Standards
Board approval in the July meeting. During the July meeting,
we'll refine the objectives and hopefully not change the PAR and
5 Criteria so the Standards Board is approving the same thing we
pre-circulated. If we miss this May deadline, things get ugly.
I'd rather not go into those details, mostly because I don't
know them well enough to talk to but also because it sidetracks
the discussion.
The bottom line is that we need to work on those 3 items.
The PAR and 5 Criteria are used to get support from the
Standards Board. The objectives are used by WG 802.3 in order to
validate the 5 Criteria. I intend to begin working on the 5
Criteria and posting them to this reflector, probably using
individual threads. I would really appreciate some discussion
around them now since we've only got about a day and a half at
the May meeting. If we wait until then to even see them, we may
not be able to make the progress we'd like to make.
The implication of the above is that now is not the time to
propose solutions. That is the work for the task force. If we
can't get the above 3 items completed in order to become a task
force, the best solution in the world doesn't help us.
There will be time for solution proposals.
If anyone has ideas or suggestions for objectives or any of the
5 Criteria, please don't hesitate to start a thread on them.
Remember, I'm just the moderator of this process. I need all of
you participants to show that you're sufficiently
interested
to actually participate. In fact, this is one of the
Criteria - Broad
Market Potential - Multiple vendors, multiple users!
Regards,
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???)
-----------------------------------------