RE: [RPRWG] Frame reordering for medium priority traffic in Ganda lf?
First, this is not a single station that we're talking about here.
Second, the out-of-profile traffic was admitted because the
network thought it could deliver it. Reordering the traffic might
actually make things worse. It's like getting a freebie that might
make your life worse without telling you about it.
-Anoop
> -----Original Message-----
> From: Dawkins, Spencer [mailto:Spencer.DAWKINS@xxxxxxxxxxxxxxx]
> Sent: Friday, December 07, 2001 7:58 AM
> To: stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] Frame reordering for medium priority
> traffic in Ganda lf?
>
>
>
> My question still remains - the station is sending
> out-of-profile medium-class traffic onto the network; why is
> preserving order, which allows the station to continue
> sending out-of-profile medium class traffic, an important
> design constraint?
>
> Spencer
>
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> Sent: Friday, December 07, 2001 9:36 AM
> To: 'Dawkins, Spencer'; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] Frame reordering for medium priority
> traffic in Ganda lf?
>
>
>
> Spencer,
>
> You are right about the description of TCP behavior.
>
> However, the policing operates on aggregate
> flows between nodes so its not inconceivable for many individual TCP
> connections get affected by the reordering. And there's no way to
> distinguish between which of the individual TCP flows was non-
> conformant. It's also the reason for DiffServ's notion of PSC (PHB
> service class).
>
> -Anoop
>
> > -----Original Message-----
> > From: Dawkins, Spencer [mailto:Spencer.DAWKINS@xxxxxxxxxxxxxxx]
> > Sent: Friday, December 07, 2001 6:46 AM
> > To: stds-802-17@xxxxxxxx
> > Subject: RE: [RPRWG] Frame reordering for medium priority
> > traffic in Ganda lf?
> >
> >
> >
> > I hope this isn't a silly question, but -
> >
> > Single-packet reordering won't slow TCP down at ALL. It takes
> > three duplicate acknowledgements in a row to trigger fast
> > retransmit/fast recovery, right?
> >
> > We're not talking about slowing all traffic down, only one
> > TCP connection, right?
> >
> > If one TCP connection is sending out-of-profile traffic into
> > the network, why is slowing it down an error?
> >
> > Spencer
> >
> > -----Original Message-----
> > From: Mike Takefman [mailto:tak@xxxxxxxxx]
> > Sent: Thursday, December 06, 2001 10:25 PM
> > To: Anoop Ghanwani
> > Cc: stds-802-17@xxxxxxxx
> > Subject: Re: [RPRWG] Frame reordering for medium priority
> > traffic in Gandalf?
> >
> >
> >
> > Anoop,
> >
> > We discovered this error in the document soon after the meeting.
> > Our presentations have consistently stated that the medium
> > priority class is treated as high priority only from the
> > perspective of admission, not transit. Clearly, we missed it
> > in our review of the document prior to the meeting.
> >
> > thank you for raising the issue,
> >
> > mike
> >
> > Anoop Ghanwani wrote:
> > >
> > > In Section 2.2.2 of the Gandalf proposal, we have the following
> > > statement:
> > > "However the priority class on the ring transit path will be
> > > different depending on whether the particular frame is in or
> > > out of its agreed CIR/EIR/BIR profile. In-profile frame will
> > > be delivered on the high priority low-delay transit path while
> > > out-of-profile traffic will transit on the low-priority,
> > > best-effort path."
> > >
> > > This seems to suggest that frames belonging to the medium
> > > priority class of traffic can get reordered since a later
> > > frame that is determined to be in-profile may get to
> > > the destination node before an earlier one that was
> > > determined to be out-of-profile.
> > >
> > > It's well known that protocols such as TCP will suffer
> > > throughput degradation if packets are reordered, and
> > > therefore most protocols (such as, for example, 802.3ad
> > > link aggregation) make every effort to ensure that frames
> > > are delivered to the destination in order. Is there a
> > > reason why re-ordering has been considered acceptable in
> > > this case?
> > >
> > > This issue may have already been brought up at the meeting,
> > > but if it was then I missed it. (I must've been at one
> > > of them bridging sessions. :-)).
> > >
> > > -Anoop
> >
> > --
> > 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
> >
>