Re: [8023-CMSG] Problem statement
Ben,
Some belated replies. Hopefully still of some use.
jl
> 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.
The 802.17 MAC is not that different from the 802.3 MAC in this regard. No queues of frames waiting to be sent exist in the MAC. The client maintains any queues and decides (hopefully intelligently) which frames to request be transmitted next. The MA_DATA.request service primitives of each MAC contain the same required parameters, including a service_class parameter (along with destination_address, source_address [not really required in either MAC], and m_sdu). The difference is that the 802.17 MAC does not ignore the service_class parameter, and allows some additional information to be optionally passed.
> 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.
Again, there is a great deal of similarity here too. The 802.17 MAC also provides no acknowledgement of the MA_DATA.request. One could also view the function call as handing control over to the MAC, although 802.17 does not have any such statement. Maybe we should add some such statement as you say 802.3 has. Could you point me to where I can find this statement in 802.3? No such statement is made in 2.3.1, which is where I would expect such a statement to be.
> 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.
As noted above, addition of queues is neither required nor desired.
> 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?
As mentioned above, the MA_DATA.request primitive in 802.17 functions pretty much the same way as the same primitive in 802.3. (I purposely cribbed as much as made sense from 802.3 when writing this part of 802.17.)