RE: [RPRWG] Question on ClassB client traffic
Prasad,
> I'd think stage buffer needs to be atleast 1 MTU
> (9216 bytes) plus the MAC <-> Client response time
> for the SendX signal. We'd need per class staging
> buffers to avoid HOL blocking. So doesn't it make
> sense for the MAC to provide per class Send signals?
It doesn't make sense because even though the MAC has
credits, it may not be able to accept a packet from
the client because it was unable to put the packet
in its "stage buffer" on the ring. In that case
what purpose is the signal serving? The signal
may well have implementation value, but it doesn't
have any value as far as the standard is concerned,
and the standard shouldn't be specifying implementation.
> Now I'm not clear if RPR defines a mechanism to the
> client to differentiate between SendX de-assertion
> for buffer/tokens vs. rate limiting due to
> TTL_to_congestion?
You've lost me here. The rate limiting for the
node at TTL_to_congestion is done using a token bucket.
What's the buffer/tokens scenario that you think should be
handled by SendX? Is it the lack of space in the
"stage buffer"? If so, SendX doesn't handle that
case. Does it make sense for SendX to handle that?
Probably for an implementation, but I'd question the
need for it in the standard.
-Anoop