Subject: RE: The problem with tagging packets

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Tue, 11 Nov 1997 15:17:34 +0200

On 11 Nov 97 at 7:28 AM, Roch Guerin wrote:

>Kalevi,
>I would not implement support for real-time service, or any delay
>differentiation for that purpose, using drop precedence.....
>A delay precedence semantic seems much more appropriate and natural.
>Roch

Roch,

My intention is to combine drop preference and delay precedence, so that   
all combinations are possible: (high,high), (high,low), (low,high),   
(low,low), where for instance (high,low) means high drop preference and   
low delay precedence.

So we need both semantics, and drop preference must work both with normal   
delay and low delay services. My opinion is (I know, there also are   
different opinions) that drop preference shall work independent of the   
delay precedence of the packet. That is, if one low delay and one normal   
delay packet with the same drop preference come into a node at the same   
time, they both will either be discarded or accepted.

The technical issue is that a proper drop preference scheme is more   
difficult to implement in case of small buffers used with low delay   
services.

.. Kalevi

---

From: Roch Guerin <[email-masked]>
Date: Tue, 11 Nov 97 08:30:48 -0500

Kalevi,

>So we need both semantics, 
Yes.

>and drop preference must work both with normal   
>delay and low delay services. 
Agreed too.

>My opinion is (I know, there also are   
>delay precedence of the packet. 
I think I agree with that, but not with the next statement.

>That is, if one low delay and one normal   
No.  Dropping for one delay class should be based on whatever state
information is relevant to that class.  In some implementations, the
outcome may be as you indicate but in many (most?) it wont.  For
example, if I support delay differentiation through different queues,
then dropping in one queue is likely to depend on the current
occupancy of that queue and not necessarily of the occupancy of other
queues.  

In any case, I don't think these are things we need to specify as part
of the semantics definition as they are essentially implementation
dependent. 

Roch

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 11 Nov 1997 22:09:58 +0200

i agree with roch here and in fact i have exchanged several email with
kalevi about the issue.

and we too came to the above conclusion.

-- juha