RE: [RPRWG] Question on ClassB client traffic
Anoop,
Yes it probably borders on implementation. As for the size needed, it
depends upon the lag between asserting SendX and receiving a packet from the
client.
jl
-----Original Message-----
From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
Sent: Tuesday, July 02, 2002 5:08 PM
To: 'John Lemon'; Anoop Ghanwani; 'Prasad Modali'
Cc: stds-802-17@xxxxxxxx
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
> > >
> >
>