[RPRWG] [Fwd: BOUNCE stds-802-17@xxxxxxxxxxxxxxxxxx: Non-member submission from ["Devendra Tripathi" <tripathi@xxxxxxxxxxxxx>]]
owner-stds-802-17@xxxxxxxxxxxxxxxxxx wrote:
>
> From owner-stds-802-17@xxxxxxxx Wed Jul 3 02:03:32 2002
> Received: from mail.covisible.com (gemini3.ieee.org [140.98.193.25])
> by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) with ESMTP id g6363V815955
> for <stds-802-17@xxxxxxxx>; Wed, 3 Jul 2002 02:03:31 -0400 (EDT)
> Received: from pdciis [61.11.16.133] by mail.covisible.com with ESMTP
> (SMTPD32-6.00) id A2224D402EC; Tue, 02 Jul 2002 22:56:50 -0700
> From: "Devendra Tripathi" <tripathi@xxxxxxxxxxxxx>
> To: "Anoop Ghanwani" <anoop@xxxxxxxxxxxxxx>,
> "'John Lemon'" <JLemon@xxxxxxxxxxxx>,
> "'Prasad Modali'" <prasad_modali@xxxxxxxxxxxxxxx>
> Cc: <stds-802-17@xxxxxxxx>
> Subject: RE: [RPRWG] Question on ClassB client traffic
> Date: Wed, 3 Jul 2002 11:34:58 +0530
> Message-ID: <MBBBLOAELGJAINHCHKADOEDECGAA.tripathi@xxxxxxxxxxxxx>
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
> Importance: Normal
> In-Reply-To: <58BE468BAC66D511AFE6000347251A2D012D7969@xxxxxxxxxxxxxxxxxxxxxxx>
>
> Since it is Packet based, my thought would be at least one packet buffer,
> which means ~2KB for Ethernet.
>
> Regards,
> Devendra Tripathi
> CoVisible Solutions (India) Pvt Ltd.
> (Subsidiary of CoVisible Solutions Inc.)
> Pune, India
> Tel: +91-20-433-1362
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Anoop Ghanwani
> Sent: Wednesday, July 03, 2002 5:38 AM
> 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
> > > >
> > >
> >
>
> **************************************************************
> Scanned by MailScan Content-Security and Anti-Virus Software.
> Visit http://www.mwti.net for more info on eScan and MailScan.
> **************************************************************
>
> ---
> [This E-mail scanned for viruses by Declude Virus]
>
> **************************************************************
> Scanned by MailScan Content-Security and Anti-Virus Software.
> Visit http://www.mwti.net for more info on eScan and MailScan.
> **************************************************************
>
> ---
> [This E-mail scanned for viruses by Declude Virus]
--
Michael Takefman tak@xxxxxxxxx
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 fax: 613-254-4867