Re: [8023-CMSG] Purpose
Ben and Jonathan,
You are getting a lot of opposition simply for using terms that are neither
relevant nor correct (in some cases). Based on what I hear from you and
Jonathan, I believe congestion management is not an appropriate term here.
More often than not, congestion is detected in queues and "congestion
management" refers to queue management and smart scheduling algorithms.
For example, the following excerpt is taken from Cisco website: "Congestion
management features allow you to control congestion by determining the order
in which packets are sent out an interface based on priorities assigned to
those packets. Congestion management entails the creation of queues,
assignment of packets to those queues based on the classification of the
packet, and scheduling of the packets in a queue for transmission. The
congestion management QoS feature offers four types of queueing protocols,
each of which allows you to specify creation of a different number of
queues, affording greater or lesser degrees of differentiation of traffic,
and to specify the order in which that traffic is sent."
There is no congestion on a full-duplex link. Full duplex MAC can transmit
anytime if it is not already transmitting. So, for 802.3 it is really
difficult to talk about congestion. This is not to say that 802.3 cannot add
a supporting mechanism for CM at higher layers.
Perhaps required is a mechanism that would allow some flows to have better
performance than other flows on the same link. If such physical link can be
presented to higher layers as multiple parallel links (or multiple MAC
service interfaces) with different performance, the higher layer can decide
which interface to use, based on some conditions known to this higher layer
(conditions like congestion or QoS, for example). Note, that in this
example, higher layer decides what constitutes a flow and what performance
is required for each flow.
In effect, what we want is a mechanism opposite to link aggregation. Whereas
the link aggregation presents several physical links as one logical link, we
want a mechanism where one physical link will be presented as multiple
logical links.
An example of such link segregation mechanism used for congestion management
can be found every day: a single freeway stretch is segregated into a
carpool lane and best-effort lanes.
So, if the idea of Link Segregation Study Group (LSSG) is not too resentful
for you, here is a crack at objectives:
1. Specify a mechanism to bind multiple MAC service interfaces to one
physical layer.
2. Specify a mechanism to guarantee performance such as medium access delay
differentiated for each MAC service interface. (Here we would talk about
allowing frames sent on one MAC port to preempt frames sent on another MAC
port. This preemption mechanism should be transparent to all clients using
MAC service interfaces.)
3. The proposed link segregation mechanism is to remain compatible with 802
architecture, including 802.1D bridging and STP.
I avoided talking about end-to-end control, yet one can see that with a
proper client behavior, high-performance links can be concatenated to build
end-to-end high performance tunnels through the entire L2 network.
Glen
-----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 8: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]
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???)
-----------------------------------------