Subject: RE: [Diffserv] issues with RFC 2598

From: Jon Bennett <[email-masked]>
Date: Wed, 3 May 2000 00:15:23 -0400

Brian,

> Kent reminded us of the key definition of the EF PHB:
> 
> > "The EF PHB is defined as a forwarding treatment for 
> > a particular diffserv aggregate where the departure rate of
> > the aggregate's packets from any diffserv node must equal 
> > or exceed a configurable rate.  The EF traffic SHOULD receive 
> > this rate independent of the intensity of any other traffic 
> > attempting to transit the node."
>
> When we finalized RFC 2598 this wording seemed to be 
> unambiguous, necessary, and sufficient, otherwise it 
> would not have gained WG consensus.

Regardless of any previous consensus it has been demonstrated
that the definition in RFC 2598 can not be implemented by any 
known scheduler. It has also been shown by several people that 
the definition can not be implemented in principle by any known 
or unknown work conserving scheduler. As a consequence it is not 
implementable by a strict priority scheduler or by any of the 
implementation examples presented in RFC 2598. 

Do you have any technical arguments to counter these statements?

Unless you can present such arguments if would seem that the 
definition in RFC 2598 can not be "necessary and sufficient".

> Would anyone like to propose a specific, 
> simple change to this wording? 

A number of proposals have been put forward, all of which are 
substantial improvements over RFC 2598 in that they can actually 
be implemented by a number of schedulers such as strict priority 
or weighted fair queueing unlike RFC 2598 which has been repeatedly 
shown to be unimplementable.

> On the other hand, discussion of implementation details belongs
> on the diffserv implementation list 
> (see http://www.tip.csiro.au/dsimplementation )

The discussion of implementation details has been solely 
for the purpose of determining that there exist reasonable 
implementations of the definitions that have been proposed. 
Are you suggesting that determining whether or not a 
proposed standard can be successfully implemented is 
not a relevant topic for discussion by an IETF WG?

jon

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 May 2000 09:00:57 -0500

Jon,

I'm not claiming technical expertise and I'm not going to enter the
technical argument. I'm asking that the people who assert that
there is a problem with the EF definition cited below come up with
a specific, simple proposed rewrite that we can then discuss with 
the EF authors. 

     Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]

---

From: Jean-Yves Le Boudec <[email-masked]>
Date: Wed, 03 May 2000 22:01:24 +0200

Anna Charny and I support the last proposal by Bill and Kent, namely, replace
the definition in RFC 2598 by

The departure time d(k) for the kth packet of an EF aggregate must satisfy d(k)
<= f(k) + L

where f(k) is defined recursively by

f(0)=0
f(k) = max (a(k), min(f(k-1), d(k-1)) + l(k) / R

In the above, a(k) is the arrival time, l(k) is the length of packet in bits, R
is the configured rate and L is the latency (or error term) of the node. 

The reasons are the following.

1. This definition is implementable (WF2Q+ is an example), yet does not tie the
servive into any specific implementation
2. It is close to the spirit of the initial definition in RFC2598 (which was
not implementable).
3. We can compute end-to-end delays in a diff-serv context.

Points 1 and 2 have been discussed in this mailing list already. About point 3,
consider that the initial proposition by Kent, namely f(k) = max (a(k), f(k-1))
+ l(k) / R, is called "Guaranteed Rate Scheduling" by Goyal, Lam and Vin in
1995 [1]. One can show [2] that it is equivalent to the so called "rate-latency
service curve property" of Cruz and others. Now we have shown in [3] that
end-to-end delay bounds can be computed in a diffserv context with an
assumption that can be essentially stated as: the nodes have the rate-latency
service curve property. The new definition is stronger than the initial
proposition by Kent, thus the results in [3] still hold with the new
definition.

Note that this new definition has an impact of the volkswagen (VW) service
definition in draft-ietf-diffserv-ba-vw-00. Indeed, the delay computations in
draft-ietf-diffserv-ba-vw-00 are overly optimistic. See reference [3] for
proven end-to-end delay bounds. 

JY

References:
----------

[1] P. Goyal, S. S. Lam, and H. Vin, “Determining end-to-end delay bounds in
heterogeneous networks,” in 5th Int. Workshop on Network and Operational System
Support for Digital Audio and Video (Durham, NH, Apr. 1995).

[2] J.Y. Le Boudec, "Application of Network Calculus To Guaranteed Service
Networks", IEEE Trans on Information theory, (44) 3, May 1998 

[3] A. Charny and J.Y. Le Boudec "Delay Bounds in a Network with Aggregate
Scheduling", http://dscwww.epfl.ch./EN/publications/ps_files/tr00_022.ps

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 May 2000 08:28:57 -0500

Just a comment from a co-chair: Van is going to give his comments
on the whole thread as soon as he can, but external circumstances
have delayed this. When we get his comments we can move forward
in this discussion.

  Brian