Subject: [Diffserv] avoiding packet reordering

From: "Ronaldo Moreira Salles" <[email-masked]>
Date: Fri, 23 Jun 2000 12:34:23 +0100

Hello everybody,

I have read several diffserv rfcs and drafts and it is still not clear for me "how" the diffserv network could avoid packet reordering, since outprofile packets may be demoted to a lower AF class (or BE class). Does the ingress node need to keep track of the demoted microflow? Sorry, if this issue has already been discussed and answered. Am I missing something?

Best regards,

Ronaldo.

---

From: John Schnizlein <[email-masked]>
Date: Fri, 23 Jun 2000 08:02:55 -0400

The WG has chosen not to define how to accomplish avoiding reordering
packets within a microflow of an AF class. Note that this is the only
place that this requirement is specified, and demoting to default (BE)
is not specified. 

One fairly obvious way to avoid reordering AF traffic within a 
microflow would be to keep all the drop threshold alternatives 
for that class in the same queue. This approach would avoid keeping
state information about microflows. This is not the only approach,
and the reason the WG does not specify how to do it is to encourage
a variety of methods to compete. The principle being followed here
is to avoid standardizing before experience identifies a requirement 
that everybody do the same thing.

John

At 12:34 PM 06/23/2000 +0100, Ronaldo Moreira Salles wrote:
> 
>I have read several diffserv rfcs and drafts and it is still not clear 
>for me "how" the diffserv network could avoid packet reordering, since 
>outprofile packets may be demoted to a lower AF class (or BE class). 
>Does the ingress node need to keep track of the demoted microflow? 
>Sorry, if this issue has already been discussed and answered. 
>Am I missing something?

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 23 Jun 2000 08:11:59 -0700

> Ronaldo Moreira Salles wrote:
> 
> Hello everybody,
> 
> I have read several diffserv rfcs and drafts and it is still not clear for me
> "how" the diffserv network could avoid packet reordering, since outprofile
> packets may be demoted to a lower AF class (or BE class).

I dont believe it is acceptable to move packets from one
scheduling class to another simply because they violate
a temporal profile at ingress. AF1x represents a different
scheduling class to AF2x, etc.  But it certainly is likely
that violating a temporal profile on ingress will have
a packet demoted from AFn1 to AFn2 or AFn3 - different
drop precedence of the same scheduling class, and ergo
no reordering is likely (at least within that flow of
packets being classified into AFn)

cheers,
gja

---

From: Carlos Alberto Kamienski <[email-masked]>
Date: Fri, 23 Jun 2000 13:16:05 -0300 (EST)

Ronaldo

To avoid packet reordering one would expect packet demotion to a higher
drop probability DSCP within the same AF class. Then, all packtes of a
flow enter the same queue (a RIO-like queue, for example).

Carlos

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Jun 2000 13:17:52 -0500

The simple answer is that it's an implementation detail and that in the
standards discussion we don't care how it's achieved.

The complicated answer is that the only form of "demotion" currently
defined is remarking an AFx1 packet to AFx2, or AFx2 to AFx3. This only
changes its drop precedence, which has nothing to do with queuing and
therefore cannot cause reordering.

There is no precedence relationship between different AF classes so there
is no such thing as demotion to another AF class. And if you are foolish
enough to demote part of a Class Selector aggregate to a lower Class
Selector, yes there may be reordering, because you've done the wrong thing.

  Brian

> I have read several diffserv rfcs and drafts and it is still not clear for me "how" the diffserv network could avoid packet
> reordering, since outprofile packets may be demoted to a lower AF class (or BE class). Does the ingress node need to keep
> track of the demoted microflow? Sorry, if this issue has already been discussed and answered. Am I missing something?
> 
> Best regards,
> 
> Ronaldo.
>

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 24 Jun 2000 11:55:10 +0300 (EEST)

> I have read several diffserv rfcs and drafts and it is still not clear for me "how" the diffserv network could avoid packet reordering, since outprofile packets may be demoted to a lower AF class…

yes you are.  the af spec says:

"However, the traffic conditioning actions MUST NOT cause reordering of
packets of the same microflow."

since each af class is treated independently, this means that if you
reassign ONE packet to another af class, you must reassign ALL packets of
the microflow to which the packet belongs to.  if you don't want to keep
track of the microflows, you better not to reassign packets to other af
classes.

-- juha