Re: [RPRWG] How does ExamineQueue() search, when no queues are present?
John,
I think this wording still remains confusing.
>> Well, it might be examining client queues
That does not seem to fit the service interface model.
>> examining some pre-storage buffers in the MAC.
Recent emails claimed there were no such buffers.
>> ready even though the MA_DATA.request is a push operation,
I can see value with the abstracting the
MA_DATA.request to have an "instantaneous" response to
the sendA, sendB, and sendC indications, which make this
conceptually possible.
However, I think its not phrased that way now.
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: Wednesday, September 22, 2004 10:09 AM
>> To: David V James
>> Cc: Steve Wood; Mike Takefman; Peter Jones
>> Subject: RE: How does ExamineQueue() search, when no queues are present?
>>
>>
>> Well, it might be examining client queues, or it might be
>> examining some pre-storage buffers in the MAC. We don't know, or
>> care. As stated below, this "queue" 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". As further noted
>> below and in the standard "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". In other words, with zero latency, a zero length
>> buffer is fine.
>>
>> -----Original Message-----
>> From: David V James [mailto:dvj@alum.mit.edu]
>> Sent: Tuesday, September 21, 2004 3:51 PM
>> To: John Lemon
>> Cc: Steve Wood; Mike Takefman; Peter Jones
>> Subject: How does ExamineQueue() search, when no queues are present?
>>
>>
>> John,
>>
>> I'm a bit confused on this topic, as noted in my voicemail.
>> If there are not queues in the MAC, then how does
>> ExamineQueue(quque,frameType,serviceClass) page 107
>> work in the described manner of
>> "Looks inside the specified queue within the datapath..."
>>
>> Unless its examining client queues, I think we have
>> defined queues inside the MAC, although their structure
>> remains abstracted by the ExamineQueue() routine interface.
>>
>> I didn't really want to fling this over the reflector,
>> but after we converge in our discussions, sending the
>> result to the CMSG reflector might be helpful.
>>
>> 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 John Lemon
>> >> Sent: Monday, September 20, 2004 6:07 PM
>> >> To: STDS-802-3-CM@listserv.ieee.org
>> >> Subject: 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???)
>> >> -----------------------------------------
>> >>
>>
>>