Subject: Re: differential services tos octet

From: Indra Widjaja <[email-masked]>
Date: Fri, 17 Oct 1997 10:07:59 -0400

At 09:16 PM 10/16/97 +0300, Juha Heinanen wrote:
>   Whiile connections in RED experience the same packet
>   loss rate, FRED makes different dropping decisions over connections
>   with different bandwidth usages by use of per-active-connection
>   accounting. 
>
>i wonder how the connections are identified when people are encrypting
>their ip packet payloads before sending the packets to the isp, i.e., is
>per connection anything practical in the current world of secure
>intranets?

In the case layer-2 ATM switching with VC merging is used, the connections
can not be identified as well.
Also, since GFC field may not be used, I'd like to hear how the TOS and DP
are encoded in ATM cells? 
(1 bit DP can be encoded in the CLP?)

indra

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 17 Oct 1997 19:36:07 +0300

each tos needs its own vc and clp can be used to implement two level
dp scheme.

-- juha

---

From: [email-masked] (Hyogon Kim)
Date: Fri, 17 Oct 1997 14:10:26 -0400 (EDT)

In case we allow applications to set delay priority bit(s), 
how do we charge for the low-delay packets? Has anybody thought
about metering device for delay-differentiated traffic? For
instance we have leaky bucket-like meter in Clark's scheme
where the profile is installed, for which a subscriber pays money. 
But I think there metering was done against the rate, not the delay.
I guess it is obvious that one would be tempted to mark all
his/her packets low-priority if metering is not done (properly).

Hyogon
------------------------------------------------------------------------------
Hyogon Kim ([email-masked])	       		       |        (201) 829-4728
Research Scientist				       |           MCC 1B-225B
Internet Architecture Research Laboratory	       |      445 South Street 
Bell Communications Research			       |  Morristown, NJ 07960
------------------------------------------------------------------------------

---

From: [email-masked] (Hyogon Kim)
Date: Fri, 17 Oct 1997 14:43:19 -0400 (EDT)

>his/her packets low-priority if metering is not done (properly).
                 ^^^^^^^^^^^^

Sorry, it should be "low-delay".

-- Hyogon

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 18 Oct 1997 10:15:50 +0300

you need as many meters as you have different profiles, e.g., levels of
delay.

-- juha

---

From: Zheng Wang <[email-masked]>
Date: Sun, 19 Oct 1997 21:43:07 -0400

It is fine to have both delay priority and dropping priority but I
believe that we have to define the precedence between them, i.e.,
what bit should be looked/acted at first.

If we do not have precedence between delay and dropping, the
scheduling and buffer management may have difficulty in deciding 
what to do. If a packet has both low delay bit and dropping priority
bit set, the scheduler may want to put the packet in the front of 
the queue while the buffer management may want to drop the packet
because the queue length reaches some threshold.

It is an interesting question as to which (delay priority or dropping
priority) is more important.

Cheers
Zheng

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 20 Oct 1997 07:54:54 +0300

neither is more important.  when you exceed the threshold in either
of the two queues (one for low delay and the other for normal delay),
you start dropping packets that have high dp.

-- juha

---

From: "Alessio Casati" <[email-masked]>
Date: Mon, 20 Oct 1997 11:08:59 +0100

> priority) is more important.

At the Munich meeting David Clark and John Wroclawski proposed a single queue based,
namely RIO (look at the draft draft-clark-diff-svc-alloc-00.txt for details). With 
a Delay priority in place one queue per Delay Priority can be envisioned. So just 
classify your packets per Delay Priority and drop Packets following the RIO or a RIO like 
algorithm within each queue, acting on the DP bit(s). Scheduling and buffer management are 
orthogonal processes.

Bye 

Alessio Casati

---

From: "Alessio Casati" <[email-masked]>
Date: Mon, 20 Oct 1997 14:39:50 +0100

> At the Munich meeting David Clark and John Wroclawski proposed a single queue based ,

should read as

>At the Munich meeting David Clark and John Wroclawski proposed a single queue based dropper,

...sorry.

Bye

Alessio

---

From: Zheng Wang <[email-masked]>
Date: Mon, 20 Oct 1997 11:43:31 -0400

> you start dropping packets that have high dp.
 
Well, you have an implicit precedence here (i.e., DP over delay priority).
The packets with DP bit set are dropped once the overall buffer threshold
is reached.

However, if I use the delay priority to differentiate two types of services
(premium service and best-effort service), what you described above is not
desirable. I would like the DP bit to be significant only within its delay
class. So that the packets with low delay and DP bit set are only discarded
when the queue for low delay packet exceeds some threshold. In another words,
I dont want to the low delay class dropping to be affected by the best-effort
queue length.

Cheers
Zheng

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 20 Oct 1997 18:53:45 +0300

>    It is an interesting question as to which (delay priority or
   >    dropping priority) is more important.
   >  neither is more important.  when you exceed the threshold in
   > either of the two queues (one for low delay and the other for
   > normal delay), you start dropping packets that have high dp.

   Well, you have an implicit precedence here (i.e., DP over delay
   priority).  The packets with DP bit set are dropped once the overall
   buffer threshold is reached.

may be i didn't wrote the above clearly enough.  there is two
thresholds: one for low delay queue (that needs to be small in size) and
another one for normal delay queue (that can be very large).

when a packet arrives, the router determines, which of the queues it
would belong to according to its d bit.  if the target queue is already
above its thresholds and the packet has dp bit on, the packet is made
eligible for discard, e.g., xred is applied to it.

   However, if I use the delay priority to differentiate two types of
   services (premium service and best-effort service), what you
   described above is not desirable. I would like the DP bit to be
   significant only within its delay class. So that the packets with low
   delay and DP bit set are only discarded when the queue for low delay
   packet exceeds some threshold. In another words, I dont want to the
   low delay class dropping to be affected by the best-effort queue
   length.

so to me it appears that we agree.

-- juha

---

From: "Alessio Casati" <[email-masked]>
Date: Tue, 21 Oct 1997 17:51:41 +0100

Zheng Wang wrote:

> I would like the DP bit to be significant only within its delay

Perfect, Zheng.

...now some humour.
After what Fred said some message ago, in case of name clash between Delay Priority and Drop 
Precedence bit(s), that is in case the WG will deem as necessary to have both of them in the IP
Header (whereas two DP fiels would have to be defined), why don't we call the Drop Precedence 
bit(s) the H bit(s) (where H stands for hammer)?

Bye

Alessio Casati