Re: [Diffserv] issues with RFC 2598

Jean-Yves Le Boudec <leboudec@epfl.ch> Wed, 03 May 2000 20:14 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10519 for <diffserv-archive@odin.ietf.org>; Wed, 3 May 2000 16:14:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12951; Wed, 3 May 2000 16:00:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12840 for <diffserv@ns.ietf.org>; Wed, 3 May 2000 16:00:45 -0400 (EDT)
Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10207 for <diffserv@ietf.org>; Wed, 3 May 2000 16:00:44 -0400 (EDT)
Received: from icanoteb14 (ra-epfl-007.epfl.ch [128.178.84.207]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with SMTP id WAA27471; Wed, 3 May 2000 22:00:38 +0200 (MET DST)
Message-Id: <4.1.20000503205301.017d45c0@icamail1.epfl.ch>
Message-Id: <4.1.20000503205301.017d45c0@icamail1.epfl.ch>
Message-Id: <4.1.20000503205301.017d45c0@icamail1.epfl.ch>
X-Sender: leboudec@icamail1.epfl.ch
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 03 May 2000 22:01:24 +0200
To: diffserv@ietf.org
From: Jean-Yves Le Boudec <leboudec@epfl.ch>
Subject: Re: [Diffserv] issues with RFC 2598
Cc: Anna Charny <acharny@cisco.com>
In-Reply-To: <39103119.2B3A0FEB@hursley.ibm.com>
References: <7F4AC78738EAD2119D86009027626C6D07EE98@PACKETBDC>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_30676129==_.ALT"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Diffserv Discussion List <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

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


At 5/3/00, Brian E Carpenter wrote:
>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.