RE: [RPRWG] Frame reordering for medium priority traffic in Gandalf?
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