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

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

-----------------------------------------