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

RE: Proposal for accomodating 10.0000 and 9.58464 line rates

Title: RE: Proposal for accomodating 10.0000 and 9.58464 line rates
As someone who is deeply involved in standardizing one kind of MAC Client (the forwarding function of an 802.1D bridge/ switch) I don't see how the 'pacing function' gets put in the 'client' without a massive revision of architecture, MAC service interface, definition of what a MAC is etc. From my vantage point the HOLD solution is much the simplest, and the most general. If this is to go in the direction of 'pacing mechanisms' I would suggest that this whole speed matching area gets split off so that the campus benefits of 10G can be enjoyed while the historic discussions of pacing are replayed.
 
Mick
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Booth, Brad
Sent: Wednesday, August 18, 1999 1:00 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: RE: Proposal for accomodating 10.0000 and 9.58464 line rates

I think I'd prefer to have a pacing mechanism either in the MAC or in the MAC Client.  This would keep the rate control at a higher layer in the stack, and also keep it located with the current rate control function.  The MAC already performs a rate control by inserting IPG between packets.  A pacing mechanism could be added to this IPG insertion, which would result in a change in the standard.  Or, the pacing mechanism could be implemented in the MAC Client (Ariel Hendel's proposal), which would not result in a change to the standard other than maybe an addition of an informative annex.

This would eliminate the need for the HOLD signal, and leave the pacing mechanism (and its granularity) up to the implementer. J

Thanks,
Brad