RE: Proposal for accomodating 10.0000 and 9.58464 line rates

["Mick Seaman" <mick@xxxxxxxxxxx>]

Title: RE: Proposal for accomodating 10.0000 and 9.58464 line rates

No it doesn't bypass internal buffering. That's sort of the point and it is why the HOLD function is going to do what I need while the client based alternatives are not. The HOLD function solves the problem without exporting it. 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 4:05 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: RE: Proposal for accomodating 10.0000 and 9.58464 line rates

Mick,

I don't know what the 802.1D forwarding function is, but I'm assuming that it is a means of receiving on one port and bypassing internal buffering for transmission on another port.  If this is the case, I don't see how the HOLD signal is going to do it for you.  If the receive port is getting data at 10 Gb/s and the transmitting port can only handle 9.58464 Gb/s, then the HOLD signal will not prevent the loss of data.  The only way to guarantee that would be some form of buffering or a re-architecture.

Did I interpret the forwarding function correctly?  If not, then you can let me know what the forwarding function is without telling the whole reflector.

Thanks,
Brad

Brad Booth
bbooth@xxxxxxxxxx
Level One Communications, Austin Design Center
(512) 407-2135 office
(512) 589-4438 cellular

-----Original Message-----
From:   Mick Seaman [SMTP:mick@xxxxxxxxxxx]
Sent:   Wednesday, August 18, 1999 1:24 PM
To:     stds-802-3-hssg@xxxxxxxx
Subject:        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

-----Original Message-----
From:   pbottorf@xxxxxxxxxxxxxxxxxx [SMTP:pbottorf@xxxxxxxxxxxxxxxxxx]
Sent:   Wednesday, August 18, 1999 12:17 PM
To:     Booth, Brad; stds-802-3-hssg@xxxxxxxx
Subject:        RE: Proposal for accomodating 10.0000 and 9.58464 line rates

Brad, Dan:

I agree with Dan. The HOLD solution is the simplest and most general. If the PHY doesn't rate control the MAC then the MAC will need a pacing mechanism.

Paul