Re: [RPRWG] Question on ClassB client traffic
With regard to the class of question that Anoop has raised:
This information is strictly outside of the definition of the MAC. However,
it is really important information to serve as guidance to implementers.
What the Token Ring Working Group did with this type of information was to
provide informative "exemplary information" both to serve as guidance for
implementers, and as clarification to everyone in the Working Group, as to
the implications of what is specified and how we should be interpreting the
impact of those specifications.
I strongly recommend that we take the same approach with the RPR standard
and include descriptions of this "additional" information as informative
examples of "exemplary" implimentations.
Best regards,
Robert D. Love
President, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 208 978-1187
----- Original Message -----
From: "Anoop Ghanwani" <anoop@xxxxxxxxxxxxxx>
To: "'John Lemon'" <JLemon@xxxxxxxxxxxx>; "Anoop Ghanwani"
<anoop@xxxxxxxxxxxxxx>; "'Prasad Modali'" <prasad_modali@xxxxxxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Tuesday, July 02, 2002 8:08 PM
Subject: RE: [RPRWG] Question on ClassB client traffic
>
>
> John,
>
> Ok, I now understand the function of the state queue. I
> tend to think that this is an implementation issue and
> doesn't need to specified in the standard.
>
> In any case, maybe you can help by answering the following
> question: How big does the stage buffer need to be
> so that I can guarantee that a packet from the client
> can be accepted into the stage queue if SendX is
> asserted? For a MAC to work as described below,
> where the stage buffer is considered part of the medium,
> one would need to know that number. Otherwise,
> you will reach a point where SendX is asserted
> and yet the MAC cannot accept the packet from the
> client. In that case, SendX is redundant.
>
> -Anoop
>
> > -----Original Message-----
> > From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
> > Sent: Tuesday, July 02, 2002 5:00 PM
> > To: 'Anoop Ghanwani'; 'Prasad Modali'
> > Cc: stds-802-17@xxxxxxxx
> > Subject: RE: [RPRWG] Question on ClassB client traffic
> >
> >
> > Anoop,
> >
> > The SendX signal is asserted when it is okay to add a packet.
> > The staging
> > queue merely provides a place to hold the frame until the
> > transit path is
> > clear. If the reaction time of the client were 0, there would
> > be no need for
> > the staging queue. But since there is a non 0 reaction time,
> > a small buffer
> > is needed to keep the pipeline full. Your statement that "the
> > MAC is telling
> > the client it's OK to send, but yet it can't put the packet on to the
> > medium" is incorrect. As I mentioned in my earlier message,
> > the staging
> > queue is to be viewed as part of the medium.
> >
> > jl
> >
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> > Sent: Tuesday, July 02, 2002 1:28 PM
> > To: 'John Lemon'; 'Prasad Modali'
> > Cc: stds-802-17@xxxxxxxx
> > Subject: RE: [RPRWG] Question on ClassB client traffic
> >
> >
> >
> > John,
> >
> > The way things are specified right now, there
> > is nothing about space in the staging queue that
> > controls when SendX is asserted. Basically, if even
> > one credit is available, the SendX for that class
> > is asserted. When the client indicates a desire
> > to send a frame to the MAC, the MAC then tries
> > to put the frame on to the medium. With a single
> > transit buffer, or a full STQ, the MAC won't be
> > able to put the packet on the medium instantly.
> > That's where the whole SendX concept breaks down.
> > Basically, the MAC is telling the client it's OK
> > to send, but yet it can't put the packet on to the
> > medium.
> >
> > Instead, as I said in an earlier email responding
> > to the same query, we need to just specify how
> > the client indicates a desire to transmit. How
> > and when the MAC puts the packet on to the medium
> > is what the rest of 802.17 spec will decide. But
> > it doesn't need to send any signals back to the
> > client.
> >
> > -Anoop
> >
> >
> > > -----Original Message-----
> > > From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
> > > Sent: Tuesday, July 02, 2002 1:22 PM
> > > To: 'Prasad Modali'
> > > Cc: stds-802-17@xxxxxxxx
> > > Subject: RE: [RPRWG] Question on ClassB client traffic
> > >
> > >
> > >
> > > Prasad,
> > >
> > > You are correct. I was being overly simplistic. There is a
> > > minimal amount of
> > > buffering in the MAC for specifically this purpose. We call
> > > it the staging
> > > queue. Its purpose is solely to accept a packet from the client with
> > > sufficient timeliness to keep the staging queue ready to
> > > transmit a frame at
> > > any time with no delay in fetching it from the client. One
> > > could think of it
> > > as a prefetch. It is not a general purpose buffer that has a
> > > buffer full or
> > > empty state conveyed to the client. Instead, the MAC, when it
> > > has room in
> > > the staging queue, raises the appropriate sendX signal. One
> > > the packet has
> > > been received from the client, it should be viewed as being
> > > on the wire.
> > >
> > > jl
> > >
> > > -----Original Message-----
> > > From: Prasad Modali [mailto:prasad_modali@xxxxxxxxxxxxxxx]
> > > Sent: Tuesday, July 02, 2002 12:26 PM
> > > To: John Lemon
> > > Cc: stds-802-17@xxxxxxxx
> > > Subject: RE: [RPRWG] Question on ClassB client traffic
> > >
> > >
> > > John,
> > >
> > > If we do not have any buffering in the MAC, we'd bring down
> > > the peformance of the client interface. For example, scheduler
> > > could decide to accept an insert packet if there is no class A
> > > transit packet at that moment. The client could take few clock
> > > cycles to respond to the send signal. Meanwhile, we could have
> > > a class A transit packet available. This will require us to
> > > buffer the client packet in the MAC or throttle the class A
> > > transit traffic until client responds and completes the packet
> > > transfer. How do we address this scenario?
> > >
> > > prasad
> > >
> > > > -----Original Message-----
> > > > From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
> > > > Sent: Monday, July 01, 2002 2:52 PM
> > > > To: 'Prasad Modali'
> > > > Cc: Anil Nangunoori; stds-802-17@xxxxxxxx
> > > > Subject: RE: [RPRWG] Question on ClassB client traffic
> > > >
> > > >
> > > > Prasad,
> > > >
> > > > There is no buffer-full type of back pressure because the
> > > add queues (or
> > > > buffers) are maintained by the client, not the MAC.
> > > Depending upon the
> > > > implementation, the client may push a packet out of an add
> > > queue when the
> > > > associated Send signal is active, or the MAC may pull a packet
> > > > out of an add
> > > > queue when the associated Send signal is active. In the
> > > former case, the
> > > > client would need to use the Send signals to figure out
> > > when to send and
> > > > what to send. In the latter case, the client could ignore
> > > the signals and
> > > > just keep stuffing its queues. It's an implementation decision.
> > > >
> > > > jl
> > > >
> > > > -----Original Message-----
> > > > From: Prasad Modali [mailto:prasad_modali@xxxxxxxxxxxxxxx]
> > > > Sent: Thursday, June 27, 2002 6:11 PM
> > > > To: Stds-802-17
> > > > Cc: Anil Nangunoori
> > > > Subject: [RPRWG] Question on ClassB client traffic
> > > >
> > > >
> > > >
> > > > Hi All,
> > > >
> > > > Annex I in D0.3 describes the MAC client behavior. The
> > > > packet forwarding logic in the MAC has to give priority to
> > > > the ClassA transit traffic. So a client inserting ClassB
> > > > packets into the MAC could be back pressured by a burst
> > > > of ClassA transit traffic.
> > > >
> > > > How does the client distinguish between buffer-full type
> > > > of back pressure vs. ClassB rate shaping(tokens expiry)
> > > > related back pressure? When classB tokens expire, client
> > > > can still send classB packets if SendC is asserted.
> > > >
> > > > thanks
> > > >
> > > > --
> > > > Prasad Modali
> > > > Chip Engines Inc
> > > > (408)991-9800 x116
> > > >
> > >
> >