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
> >
>