Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] Frame reordering for medium priority traffic in Gandalf?




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
>