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