|
OOPS
Should be:
but this does **NOT*** ensure that these features are used by upper layers in
any optimal way.
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
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]
Sent: Friday, 30 April, 2004 22:29
To: 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]On Behalf Of Glen
Kramer
Sent: Thursday, April 29, 2004 3:35 PM
To: 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] On Behalf Of Jonathan Thatcher
Sent: Thursday, April 29, 2004 3:35 PM
To: 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]On Behalf
Of Benjamin
Brown
Sent: Thursday, April 22, 2004 8:09 AM
To: 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???)
-----------------------------------------
|