Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] Question on ClassB client traffic






> -----Original Message-----
> From: Prasad Modali [mailto:prasad_modali@xxxxxxxxxxxxxxx]
> Sent: Tuesday, July 02, 2002 8:06 PM
> To: Anoop Ghanwani; stds-802-17@xxxxxxxx
> Subject: 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?

Right.  But that doesn't belong in the standard, because
regardless of whether or not the MAC client reacts to the 
SendX being de-asserted, the MAC has to be able to
handle it...and the MAC doesn't throw packets away.

> 
> 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.

Well, you can always supply the hop distance or 
something like that to the client along with the
SendX signal.  But working the details just doesn't
seem worth it because of the issue stated above.

-Anoop