[8023-CMSG] Confirmation of RBR distinctions
All,
So sorry for continuing on this thread, but (as John Lemon noted)
I have miss-spoken and hope to correct any false impressions that
may have occurred as a result.
I had intended to use the non-802.3 references as examples of
several congestion-management strategies. With these examples
in mind, the goals of 802.3 CM could be better understood.
>> P1796 (RBR) certainly is borrowing very heavily from RPR (P802.17)
The RBR Working Group is _very_ thankful for the good
work done in P802.17, which pioneered the transport of
802 frames over point-to-point links connected in a
ring topology.
>> but it is in no way to be considered an extension to it.
I appologize for unintentionally implying otherwise.
Simplifications (option elimination) and new features
(classA guarantees, request/response transactions,
and destination-asserted flow control) that conflict
with possible goals of plug compatibility with P802.17.
Some of these RBR features only make sense in the low
latency environment, where the distances are less than
or comparable to the span of in-flight frames. Such
features would therefore be much less useful over RPR
distances, regardless of commonality of other features.
The PHY layers of RBR are likely to differ from RPR, given the
distinct requirements of a backplane (vs Metro) environment.
Commonality with P802.3ap, Backplane Ethernet Task Force
is more likely.
>> Any and all extensions to RPR will be done by 802.17.
And I will continue to support these 802.17 RPR extensions,
as best I can, as an 802.17 participant with a limited budget.
The 802.17 Working Group is clearly _the_ right place for
RPR extensions, with its well versed leaders and applicable
talent pool of engineers.
The current (formulation stages) 802.17 work on enhanced
bridging is _very_ interesting/fundamental, and applicable
to many networking standards (perhaps wireless, as well as
wired).
In the future, I will try to better differentiate RBR from
related (but not plug compatible) cousins, such as 1394,
1596, or 802.17 RPR.
Sorry for any/all possible confusions.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
-----Original Message-----
From: John Lemon [mailto:JLemon@luminous.com]
Sent: Tuesday, September 14, 2004 10:56 AM
To: STDS-802-3-CM@listserv.ieee.org
Cc: David V James; Mike Takefman (E-mail)
Subject: RBR/RPR Clarification (was Problem statement)
I'm sure David didn't mean the wording that he used, but I need to clarify
that RBR is not "extensions to RPR". Any and all extensions to RPR will be
done by 802.17. P1796 (RBR) certainly is borrowing very heavily from RPR
(P802.17), but it is in no way to be considered an extension to it.
_______________________
John Lemon
Vice Chair, IEEE 802.17
_______________________
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of David V James
Sent: Monday, September 13, 2004 7:48 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Problem statement
Manoj,
Just trying to understand, with a few questions.
1) 802.17 has a classC, which allocated bandwidth in a weighted fashion
among the applicants, so that (after feedback settles) applicantions
with near-constant rate inputs will eventually be provided with their
weighted fair shared of the available bandwidth.
From you email response, I assume this is what CMSG desires.
2) 802.17 also has classA (real time) and classB (preferential), which
may be similar to differentiation and priorities. To make them work,
access controls are also required, which (I believe) is not currently
included in 802.3. I think, however, that you think this handles the
transient
issues, but I am highly skeptical. However, no point is arguing,
since its not the scope of the CMSG project.
3) Another problem, that often occurs in clusters, is the transient overload
problem. With computer backplanes, this is the classical every processor
reads from one memory. Doesn't happen all that happen, cannot be
characterized by an average load, and isn't helped by priority
(all processors tend to have the same priority).
Problem (3) is being addresses by RBR, extensions to RPR, with
appropriate extensions of computer-backplane like flow destination-asserted
flow control, where the "destination" can also be an intermediate
bridge. This can be found at:
http://grouper.ieee.org/groups/msc/MSC_RBR/info.html
I was hoping the RBR Working Group could leverage some of the CMSG
advances. However, given the differences between (3) and (1), with the
apparent CMSG leaning towards (1), I guess not.
I think (1) is an even harder problem, so I admire your initiative.
Best of luck!
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of Wadekar, Manoj K
Sent: Monday, September 13, 2004 4:56 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Problem statement
No, CMSG focused primarily on "oversubscription" issue.
["Transient" being addressed by "differentiation" or "priorities"].
Thanks,
- Manoj
From: owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of David V James
Sent: Monday, September 13, 2004 2:41 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Problem statement
Hmm,...
1) I had thought the primary reason for congestion management was to avoid
the short-term problem of loss of traffic during coincidental peaks in
traffic.
The term "oversubscription" seems to imply a long-term flow control
solution.
I suppose that's OK if the original intent of (1) was misperceived or has
changed.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org
[mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of Booth, Bradley
Sent: Monday, September 13, 2004 1:59 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: [8023-CMSG] Problem statement
Greetings,
I wasn't able to attend the CMSG meeting in July, due to being a little busy
in 802.3an, but I was looking at the problem statement that I believe was
adopted by the SG. I was a little concerned that the statement only
mentioned 802.3 MAC Clients and nothing about the 802.3 MAC itself. I was
wondering if the following problem statement would still be palatable to
everyone:
"802.3 MAC Clients need the ability to communicate, via 802.3 MACs,
congestion information to avoid oversubscription."
Thoughts? Feedback?
Thanks,
Brad