RE: [RPRWG] Question on ClassB client traffic
Here is a bounced message from Devendra.
Please make sure any email address that you can mail
from is subscribed to the reflector.
In order to reduce spam we did force posters to the
reflector to be members.
thanks
mike
owner-stds-802-17@xxxxxxxxxxxxxxxxxx wrote:
>
> From owner-stds-802-17@xxxxxxxx Wed Jul 3 02:06:52 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 g6366p816867
> for <stds-802-17@xxxxxxxx>; Wed, 3 Jul 2002 02:06:51 -0400 (EDT)
> Received: from pdciis [61.11.16.133] by mail.covisible.com with ESMTP
> (SMTPD32-6.00) id A2FB13903C8; Tue, 02 Jul 2002 23:00:27 -0700
> From: "Devendra Tripathi" <tripathi@xxxxxxxxxxxxx>
> To: "Anoop Ghanwani" <anoop@xxxxxxxxxxxxxx>,
> "'John Lemon'" <JLemon@xxxxxxxxxxxx>
> Cc: <stds-802-17@xxxxxxxx>
> Subject: RE: [RPRWG] Question on ClassB client traffic
> Date: Wed, 3 Jul 2002 11:38:35 +0530
> Message-ID: <MBBBLOAELGJAINHCHKADAEDFCGAA.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: <58BE468BAC66D511AFE6000347251A2D012D796C@xxxxxxxxxxxxxxxxxxxxxxx>
>
> Hi Anoop,
>
> May be I am missing something, but if SendX is giving the MAC a control to
> accept the packet from host, why should it depend upon the length of stream
> on input line side ? A related question is if sendX behaviour is pulse
> type(one pulse one packet/ segment) or level (one clock- one word) ?
>
> 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 7:25 AM
> To: 'John Lemon'; Anoop Ghanwani
> Cc: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] Question on ClassB client traffic
>
> John,
>
> I would have assumed it depends, at least to some extent,
> on the longest train of packets that one can receive
> on the transit path that would prevent the MAC from
> inserting the packet on to the ring immediately.
>
> -Anoop
>
> > -----Original Message-----
> > From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
> > Sent: Tuesday, July 02, 2002 5:31 PM
> > To: 'Anoop Ghanwani'
> > Cc: stds-802-17@xxxxxxxx
> > Subject: 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
> > > > >
> > > >
> > >
> >
>
> **************************************************************
> 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