Re: [8023-CMSG] Problem statement
To add a little clarification (or confusion, as the case may be), I'd like to point out that the only client fed transmit queue explicitly defined to exist in the 802.17 MAC is the stage queue.
"A single entry stage queue is provided for client and control transmissions without access delay. The stage
queue can hold at most one frame at any time. As soon as it empties, the next highest priority frame is
selected to be the next add frame to be transmitted."
There is also some wishy washy text that tries to address the issue of preloading frames by positing the possibility of some elastic buffer or queue. This has nothing to do with sendX signals or any other aspect of MAC functionality. It was added mostly because it eased the modeling task by allowing the MAC to pull a frame when ready even though the MA_DATA.request is a push operation, and partly because some felt it was useful to describe in abstract the issue of non-instantaneous transfers. ("Any such logical or physical structure is recommended to be sufficiently large to allow for full rate transmissions, including the latencies inherent in signaling flow control information across the MAC-to-client interface.") The client's frame transmission requests are pulled from this theoretical queue with the client knowing magically when to provide another frame and when not to.
-----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: Wednesday, September 15, 2004 2:36 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Problem statement
Benjamin,
>> There is nothing explicit keeping the MAC Client from generating
>> one MA_DATA.request after another, at least until the sendX
>> signals are negated in the case of 802.17.
>>
>> Has there been any discussion around this issue in 802.17? We
>> immediately came up against this when we started thinking about
>> real solutions to the congestion management issue.
The sendX indication is withdrawn when the client exceeds
its allowed limit, which prevents the client from an
infinite number of MA_DATA.request submissions.
After the shaper credits have accumulated to a positive
value, the corresponding sendX indication is reasserted.
>> 1) There need be no queues in the MAC. sendX can be merely
>> an indication that the shapers say it is okay to transmit.
Having said this, but admitting my recollection is fuzzy,
I may have to eat my words.
We did have the question of how many queues are there, what
is there structure, etc. However, we didn't want to be overly
specific, since the queue sizes could depend on the design:
a shared queue with reserved allocations, dedicated queues,
handshake turn-around delays, MAC interface bandwidth, etc.
could influence any such specification.
The MAC specification picks the first frame of the desired
type (priority first, up to certain BW limits) by using
a procedure. The English-phrased definition of that procedure
then states its behavior, using words like "selects the
first frame of the class-parameter class, if any" to
avoid any specific implementation details.
There were questions as to whether the MAC-specified queues
were in the physical MAC or in the physical client. There
are several distinct possibilities:
1) All queues could be in the physical client, assuming
the MAC/client signaling is fast enough to pipeline
the frame to the MAC when an opening appears.
2) One queue of each type could be in the physical MAC.
This would relieve the interface of tight timing
constraints.
3) One "staging" queue could be in the physical MAC.
This relaxes the interface timing, but requires
a pre-commitment before the opening appears.
The abstract specification was intended to isolate the
standard from such implementation details.
Having reviewed those details, I believe that some
queues are implied in the MAC behavior specification,
but these queues could be physically present in silicon
that contains mostly client functionality.
I hope that helps more than confuses.
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 Benjamin Brown
Sent: Wednesday, September 15, 2004 1:13 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Problem statement
David,
Your email said 2 things in particular that interest me.
1) There need be no queues in the MAC. sendX can be merely
an indication that the shapers say it is okay to transmit.
2) There is only a single MA_DATA.request service primitive
from the MAC Client with a parameter that indicates its class.
It appears that 802.17 has the same "problem" that 802.3 has.
There is no explicit handshake back to the MAC Client (802.1
or otherwise) to indicate when the requested packet transmission
has completed. There is no explicit mechanism for the MAC
Client to know when to generate the next MA_DATA.request.
There is nothing explicit keeping the MAC Client from generating
one MA_DATA.request after another, at least until the sendX
signals are negated in the case of 802.17.
Has there been any discussion around this issue in 802.17? We
immediately came up against this when we started thinking about
real solutions to the congestion management issue.
Thanks,
Ben
David V James wrote:
Benjamin,
Some answers to your questions. I always get a bit fuzzy
on these abstract interfaces, so I hope John Lemon will
correct any of my errors.
According to my (extremely limited) knowledge of 802.17,
these signals are used to tell the MAC Client that the
respective queues are full and cannot accept additional frames.
A perhaps better way of thinking is the signal indicates
whether the rate-limiting shapers indicate a frame can be sent.
There is not necessarily a queue associated with the permissions,
in concept, although there is most likely such a queue in reality.
I suppose the Congestion Management Study Group could
choose to take on such a monumental task as adding queues
I can't judge how hard that is within your group, so no
recommendation is provided. However, I suspect that
QOS issues (particularly within Residential Ethernet) may
require something like what is provided by the 802.17
MAC service interface.
Are there 3 different MA_DATA.request primitives or simply a
common primitive with a "service class"-like parameter that
directs the frame to the appropriate queue?
A common primitive with a parameter that indicates its class.
This effects its ranking (in terms of what is serviced first)
as well as bits included in the header. The queue structure
is somewhat abstract, from a specification perspective.
I think that answered your questions. If not, poke me again.
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 Benjamin Brown
Sent: Tuesday, September 14, 2004 2:40 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Problem statement
David,
You bring up an interesting point. You talk about the sendA,
sendB and sendC signals. According to my (extremely limited)
knowledge of 802.17, these signals are used to tell the MAC
Client that the respective queues are full and cannot accept
additional frames. I'm sure you could correct this potential
misinterpretation if it is indeed incorrect. If it is correct then
there is no corresponding signal used by 802.3. In fact, 802.3
doesn't have the explicit queues that are described by 802.17.
The MAC Service Interface described by 802.3 is a bit more
vague than that.
There is no explicit acknowledge of the MA_DATA.request
service primitive by 802.3. Within the MAC Control sublayer
(or magically if the optional MAC Control sublayer doesn't
exist), the MA_DATA.request is converted to a TransmitFrame
function call, which is effectively a request to the MAC to
transmit a frame. This function call hands control over to the
MAC, where that control stays until control is handed back
when the function returns with the TransmitStatus (the result
of the transmission attempt). This process makes it clear that
multiple TransmitFrame function calls cannot be generated
simultaneously. It is a well accepted understanding between
802.3 and 802.1 that multiple MA_DATA.request service
primitives will also not be called simultaneously. This is an
area that will likely see some discussion by the joint work
being done by members of all the 802 working groups when
they meet on Sunday's before Plenary week.
I suppose the Congestion Management Study Group could
choose to take on such a monumental task as adding queues
to 802.3 and creating an explicit handshake with the MAC
Client. I, for one, would probably not be in favor of this
project taking on that much work. I don't think that is within
the charter of what we are studying, though I could be wrong,
nor do I think there is currently enough interest in the group
for such a task.
One thing that does interest me, to some degree, is the fact
that there are 3 explicit paths into the 802.17 MAC: the A, B,
and C queues (though these may not be the appropriate labels).
Perhaps I could pick your brain about how this works. Are
there 3 different MA_DATA.request primitives or simply a
common primitive with a "service class"-like parameter that
directs the frame to the appropriate queue? If the former,
are multiple MA_DATA.request primitives allowed to be
generated/received simultaneously?
Regards,
Ben
David V James wrote:
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
--
-----------------------------------------
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???)
-----------------------------------------