Re: [8023-CMSG] Problem statement
David,
The MAC Clients I was referring to is the local device MAC Client and
the link partner MAC Client. IMHO, as far as CMSG should be concerned,
the 802.3 MAC should not have to know what MAC Client is above it, only
that they have an agreed upon interface to use for the movement of data
(as currently exists now) and an agreed upon interface for the exchange
of congestion control information (CMSG's charter?). I believe that
CMSG is focused on 802.3's point-to-point links; therefore, any
end-to-end exchanges would have to be handled by the MAC Clients
involved.
Thanks,
Brad
-----Original Message-----
From: David V James [mailto:dvj@alum.mit.edu]
Sent: Tuesday, September 14, 2004 12:36 PM
To: Booth, Bradley
Cc: STDS-802-3-CM@listserv.ieee.org
Subject: RE: [8023-CMSG] Problem statement
Bradley,
Thanks for your timely clarification email; much appreciated.
But, now I'm really confused. I don't know if you miss-spoke
or I miss-read, so please bear with me.
>> My interpretation is that 802.3 could provide a means to
>> exchange congestion information. 802.3 would create a
>> message exchange protocol that would pass control information
>> between the MAC Clients.
^^^^^^^^^^^^^^^^^^^^^^^
The way that I read this (possibly not what was intended) is that
a TCP/IP client could send control information on a UDP client on
the same station.
Or, did you mean (in the case of a file transfer, for example)
the file receiver could send control information back
to the file transmitter?
Or, did you mean an intermediate switch
could send information back to contributing clients?
Its not that I'm arguing in favor of one or the other (or all),
simply that its hard to understand with an uncertain context.
>> A proactive response would permit the MAC Client to determine
>> if the system is going to have issues, pass information control
>> information outside of the data flow, and make the necessary
>> adjustments to decrease the packet loss by preventing
oversubscription.
>>
>> I believe that is a little bit different than what 802.17 is
performing.
Actually, this sounds a bit similar. The 802.17 RPR client-to-MAC
interface
includes flow-control information that flows from the MAC to the client,
for the purpose of limiting transmissions. Distinct control information
(sendA, sendB, and sendC) is provided for classA, classB, and classC,
traffic, respectively, so that each can be independently controlled.
Of course, there are also lower-level indications that allow the
MAC to determine when sendA, sendB, and sendC should be asserted.
While the specific RPR frames and content is a bit ringlet centric,
the concept of these three independently throttled QOS-related
flows might be interesting to review for possible 802.3 CM
applicability.
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: Tuesday, September 14, 2004 11:04 AM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Problem statement
My interpretation is that 802.3 could provide a means to exchange
congestion
information. 802.3 would create a message exchange protocol that would
pass
control information between the MAC Clients. In my mind, the primary
reason
to create congestion control message exchanges is to permit any MAC
Client
(802.1, TCP/IP, UDP, etc.) to pass information outside the data flow to
provide a proactive rather than reactive response to possible congestion
scenarios. A reactive response relies on loss of data, and if
congestion
control information passes across the MAC Client service interface as
data,
then that control information could be lost. A proactive response would
permit the MAC Client to determine if the system is going to have
issues,
pass information control information outside of the data flow, and make
the
necessary adjustments to decrease the packet loss by preventing
oversubscription.
I believe that is a little bit different than what 802.17 is performing.
Thanks,
Brad
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