RE: Proposal for accomodating 10.0000 and 9.58464 line rates
Agreed.
I did not mean to confuse anybody, it was as deliberate as mixing
fruits to make a salad. You stated your preference based on the
architectural impact on the spec. I tried to contrast that with an
implementation based preference.
Eventually the group should decide if they are more sympathetic to the
hardships of spec writers or implementers.
And you are right, with such a large group, bouncers might not help...
Ariel
> From: "Mick Seaman" <mick@xxxxxxxxxxx>
> To: <stds-802-3-hssg@xxxxxxxx>
> Subject: RE: Proposal for accomodating 10.0000 and 9.58464 line rates
> Date: Wed, 18 Aug 1999 18:54:26 -0500
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> X-Listname: stds-802-3-hssg
> X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
>
>
> Ariel,
>
> You seem to have an apples and oranges comparison below:
>
> 1) A hard implementation reality, an extra PIN
>
> 2) A specification fiction, the absence of queuing
>
> The latter is really going to have to be cleaned up if it is going to
> underpin a real practical choice.
> Driving 'subtlety' isn't in it.
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Ariel
> Hendel
> Sent: Wednesday, August 18, 1999 7:20 PM
> To: stds-802-3-hssg@xxxxxxxx; mick@xxxxxxxxxxx
> Subject: RE: Proposal for accomodating 10.0000 and 9.58464 line rates
>
>
>
>
> Mick,
> Was it Socrates or Confucius that taught us that any function can be
> architected into IEEE 802 with an additional sub-layer?
>
> Now seriously, neither scheme has an impact on the 802.1D forwarding
> implementation. The variable rate IPG is a lowly counter or two doing
> its thing at a very low level, as invisible to the forwarding function
> as the deferral process of 802.3.
>
> The choice of spec'ing this at the MAC Client level is a convenience
> derived from the fact that the MAC layer has no queuing. We have
> already exploited that convenience for 802.3x, for example, to avoid
> having to source/sink XOFF frames at the heart of the MAC layer. I
> believe that Brad and Shimon will drive this subtlety again at the next
> meeting with the appropriate audiovisuals, and hopefully convince the
> group. (If that doesn't do it, we'll hire a couple of bouncers to drive
> the point beyond audiovisuals :) ).
>
>
> Jumping back to implementation, the HOLD signal presents two long term
> headaches:
>
> 1) The most scarce resource is pins, not gates. Do we really want to
> increase the number of per port pins?
>
> 2) As soon as technology permits, implementations integrate the PCS
> coding layer, and eventually the clock recovery and transceiver. The
> MII ceases to be an exposed interface. For the mainstream MII functions
> like COLLISION (R.I.P.) and CARRIER SENSE, the event/encoding that
> defines the function is well defined at the PCS layer and there is no
> loss of functionality.
>
> How do I preserve the HOLD functionality for a hypothetical 10GbE
> MAC-PCS ASIC (with no MII) that I'll buy three years from now?
>
>
> Ariel Hendel
> Sun Microsystems
>
> >
> > 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
> >
> >
> >
> >
>
>