RE: [RPRWG] Question on ClassB client traffic
Anoop,
We could use the same SendX signalling to convey to the
client to either send or not send the next packet. This
could be due to running out of tokens or buffer fill
conditions. Either way, client has to stop, right?
TTL_to_congestion is controlled by the incoming fair rate
messages from downstream nodes. So insert traffic would
have to be rate limited based on the TTL value of the
client packets. Right now in the draft, I not see a way
defined to indicate to the client not to send packets
beyond a certain TTL value. And SendX de-assertion
cannot be used in this case, since packets with a TTL
value less than TTL_to_congestion may still have tokens
to enter the ring.
pm
PS: how come i see your reply posted even before i see
my mail posted on the group? ;-)
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> Sent: Tuesday, July 02, 2002 7:44 PM
> To: 'Prasad Modali'; stds-802-17@xxxxxxxx
> Subject: 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
>