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.
- RE: [Diffserv] issues with RFC 2598 Kent Benson
- RE: [Diffserv] issues with RFC 2598 Anna Charny
- RE: [Diffserv] issues with RFC 2598 Kent Benson
- Re: [Diffserv] issues with RFC 2598 Bill Courtney
- Re: [Diffserv] issues with RFC 2598 Pawan Goyal
- Re: [Diffserv] issues with RFC 2598 Bill Courtney
- Re: [Diffserv] issues with RFC 2598 Anna Charny
- RE: [Diffserv] issues with RFC 2598 Shahram Davari
- RE: [Diffserv] issues with RFC 2598 Jon Bennett
- Re: [Diffserv] issues with RFC 2598 Jon Bennett
- RE: [Diffserv] issues with RFC 2598 Kent Benson
- Re: [Diffserv] issues with RFC 2598 Brian E Carpenter
- RE: [Diffserv] issues with RFC 2598 Jon Bennett
- Re: [Diffserv] issues with RFC 2598 Brian E Carpenter
- RE: [Diffserv] issues with RFC 2598 Shahram Davari
- RE: [Diffserv] issues with RFC 2598 Bill Courtney
- Re: [Diffserv] issues with RFC 2598 Jean-Yves Le Boudec
- Re: [Diffserv] issues with RFC 2598 Brian E Carpenter
- FW: [Diffserv] issues with RFC 2598 Shahram Davari
- Re: FW: [Diffserv] issues with RFC 2598 Brian E Carpenter
- Re: FW: [Diffserv] issues with RFC 2598 Lloyd Wood
- Re: FW: [Diffserv] issues with RFC 2598 Van Jacobson