From owner-issll@mercury.lcs.mit.edu  Mon Mar  6 05:53:30 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01848
	for <issll-archive@odin.ietf.org>; Mon, 6 Mar 2000 05:53:27 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id EAA11747
	for issll-outgoing; Mon, 6 Mar 2000 04:38:30 -0500 (EST)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id EAA16190
	for <issll@mercury.lcs.mit.edu>; Mon, 6 Mar 2000 04:38:28 -0500 (EST)
Received: from oleane  (dyn-1-1-215.Vin.dialup.oleane.fr [195.25.4.215])  by smtp2.cluster.oleane.net  with SMTP id KAA76974; Mon, 6 Mar 2000 10:38:08 +0100 (CET)
Message-ID: <00e101bf874f$1e26f920$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp2.cluster.oleane.net;>
Subject: SIP 2000 International Conference 
Date: Mon, 6 Mar 2000 10:33:45 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00DE_01BF8757.73594D00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00DE_01BF8757.73594D00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unknown and even rejected by many vendors and operators only a few =
months ago, SIP is on the brink of making a definitive name for itself.=20
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.htm


------=_NextPart_000_00DE_01BF8757.73594D00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV>Unknown and even rejected by many vendors and operators only a few =
months=20
ago, SIP is on the brink of making a definitive name for itself. </DIV>
<DIV>Visit the SIP 2000 International Conference programme:</DIV>
<DIV><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></DIV>
<DIV></FONT>&nbsp;</DIV></DIV></BODY></HTML>

------=_NextPart_000_00DE_01BF8757.73594D00--



From owner-issll@mercury.lcs.mit.edu  Tue Mar 14 07:46:05 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23081
	for <issll-archive@odin.ietf.org>; Tue, 14 Mar 2000 07:46:05 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA10519
	for issll-outgoing; Tue, 14 Mar 2000 06:20:21 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id GAA13428
	for <issll@mercury.lcs.mit.edu>; Tue, 14 Mar 2000 06:20:20 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19769;
	Tue, 14 Mar 2000 06:20:19 -0500 (EST)
Message-Id: <200003141120.GAA19769@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: issll@mercury.lcs.mit.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-issll-diffserv-rsvp-04.txt
Date: Tue, 14 Mar 2000 06:20:19 -0500
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Integrated Services over Specific Link Layers Working Group of the IETF.

	Title		: A Framework For Integrated Services Operation Over 
                          Diffserv Networks	
       Author(s)	: Y. Bernet, R. Yavatkar, F. Baker, B. Davie, P. Ford, 
                          B. Braden, J. Wroclawski, M. Speer,  E. Felstaine,
                          L. Zhang
	Filename	: draft-ietf-issll-diffserv-rsvp-04.txt
	Pages		: 27
	Date		: 13-Mar-00
	
The Integrated Services architecture provides a means for the
delivery of end-to-end QoS to applications over heterogeneous
networks. To support this end-to-end model, the Intserv architecture
must be supported over a wide variety of different types of network
elements. In this context, a network that supports Differentiated
Services (Diffserv) may be viewed as a network element in the total
end-to-end path. This document describes a framework by which
Integrated Services may be supported over Diffserv networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-issll-diffserv-rsvp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-issll-diffserv-rsvp-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000313135834.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-issll-diffserv-rsvp-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-issll-diffserv-rsvp-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000313135834.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-issll@mercury.lcs.mit.edu  Tue Mar 14 07:47:03 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23442
	for <issll-archive@odin.ietf.org>; Tue, 14 Mar 2000 07:47:02 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA12336
	for issll-outgoing; Tue, 14 Mar 2000 06:20:26 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id GAA11873
	for <issll@mercury.lcs.mit.edu>; Tue, 14 Mar 2000 06:20:25 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19810;
	Tue, 14 Mar 2000 06:20:24 -0500 (EST)
Message-Id: <200003141120.GAA19810@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: issll@mercury.lcs.mit.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-issll-rsvp-aggr-02.txt
Date: Tue, 14 Mar 2000 06:20:23 -0500
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Integrated Services over Specific Link Layers Working Group of the IETF.

	Title		: RSVP  Reservations Aggregation
	Author(s)	: F. Baker, B. Davie, F. Le Faucheur, C. Iturralde
	Filename	: draft-ietf-issll-rsvp-aggr-02.txt
	Pages		: 40
	Date		: 13-Mar-00
	
A key	problem	in the design of RSVP version 1	is, as noted in
its applicability statement, that it lacks facilities	for
aggregation of individual reserved sessions into a common
class. The use of such aggregation is	required for
scalability.
This document	describes the use of a single RSVP reservation
to aggregate other RSVP reservations across a	transit	routing
region, in a manner conceptually similar to the use of Virtual
Paths	in an ATM network. It proposes a way to	dynamically
create the aggregate reservation, classify the traffic for
which	the aggregate reservation applies, determine how much
bandwidth is needed to achieve the requirement, and recover
the bandwidth	when the sub-reservations are no longer
required. It also contains recommendations concerning
algorithms and policies for predictive reservations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-aggr-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-issll-rsvp-aggr-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-issll-rsvp-aggr-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000313135845.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-issll-rsvp-aggr-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-issll-rsvp-aggr-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000313135845.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-issll@mercury.lcs.mit.edu  Wed Mar 15 16:56:10 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18822
	for <issll-archive@odin.ietf.org>; Wed, 15 Mar 2000 16:55:53 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id PAA13629
	for issll-outgoing; Wed, 15 Mar 2000 15:36:10 -0500 (EST)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id PAA23097
	for <issll@mercury.lcs.mit.edu>; Wed, 15 Mar 2000 15:36:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <v04210104b4f57db6dd7b@[18.26.0.167]>
Date: Wed, 15 Mar 2000 15:35:53 -0500
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Meeting reminder and status of drafts
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Hi,

Just a quick reminder that the ISSLL meeting at the Adelaide IETF is 
scheduled for 9:30 Monday morning, March 27. The agenda is presently 
fairly short, and will focus on the intserv-diffserv integration work 
presently in progress in the group. I'll send a more detailed agenda 
note shortly.

Here is a status report on the old-business open drafts. As a 
reminder, all of the group's open drafts are available at:

  http://ana.lcs.mit.edu/ISSLL/drafts/<name-of-draft>

as well as at the usual repositories.

The following three drafts are complete and will be submitted 
together for publication as RFC's:

- A new version of the intserv-diffserv framework document, 
draft-ietf-issll-diffserv-rsvp-04.txt, was recently submitted to 
incorporate last call comments. We will submit the current version 
for publication.

- The DCLASS RSVP object spec, draft-ietf-issll-dclass-01.txt, was 
finished some time ago. We will submit the current version for 
publication.

- The NULL Service spec, draft-ietf-issll-nullservice-00.txt, has 
received no comments since we asked for a WG last call at the 
previous meeting. We'll send this to the IESG after a quick final 
review by the chairs.


The RSVP aggregation spec, draft-ietf-issll-rsvp-aggr-02.txt, has 
been revised twice since the last meeting. -01 was submitted in 
December to resolve some minor comments raised at the November IETF. 
We intended to publish it at that time, but some outside comments and 
more work by the authors led to further additions to the text. The 
-02 version was submitted last week. There have been enough changes 
to warrant reopening the discussion briefly.

Please read this draft and provide any comments you may have *between 
now and the ISSLL meeting March 27*. We'll also have a slot for 
comments on this draft at the meeting. Pending the outcome of this 
discussion we would like to resolve any issues raised and submit this 
draft for publication immediately after that.

Thanks,
Eric and John



From owner-issll@mercury.lcs.mit.edu  Wed Mar 15 17:33:23 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03351
	for <issll-archive@odin.ietf.org>; Wed, 15 Mar 2000 17:33:20 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA20500
	for issll-outgoing; Wed, 15 Mar 2000 16:32:12 -0500 (EST)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA19211
	for <issll@mercury.lcs.mit.edu>; Wed, 15 Mar 2000 16:32:10 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <v04210104b4f57db6dd7b@[18.26.0.167]>
Date: Wed, 15 Mar 2000 15:35:53 -0500
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Meeting reminder and status of drafts
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Hi,

Just a quick reminder that the ISSLL meeting at the Adelaide IETF is 
scheduled for 9:30 Monday morning, March 27. The agenda is presently 
fairly short, and will focus on the intserv-diffserv integration work 
presently in progress in the group. I'll send a more detailed agenda 
note shortly.

Here is a status report on the old-business open drafts. As a 
reminder, all of the group's open drafts are available at:

  http://ana.lcs.mit.edu/ISSLL/drafts/<name-of-draft>

as well as at the usual repositories.

The following three drafts are complete and will be submitted 
together for publication as RFC's:

- A new version of the intserv-diffserv framework document, 
draft-ietf-issll-diffserv-rsvp-04.txt, was recently submitted to 
incorporate last call comments. We will submit the current version 
for publication.

- The DCLASS RSVP object spec, draft-ietf-issll-dclass-01.txt, was 
finished some time ago. We will submit the current version for 
publication.

- The NULL Service spec, draft-ietf-issll-nullservice-00.txt, has 
received no comments since we asked for a WG last call at the 
previous meeting. We'll send this to the IESG after a quick final 
review by the chairs.


The RSVP aggregation spec, draft-ietf-issll-rsvp-aggr-02.txt, has 
been revised twice since the last meeting. -01 was submitted in 
December to resolve some minor comments raised at the November IETF. 
We intended to publish it at that time, but some outside comments and 
more work by the authors led to further additions to the text. The 
-02 version was submitted last week. There have been enough changes 
to warrant reopening the discussion briefly.

Please read this draft and provide any comments you may have *between 
now and the ISSLL meeting March 27*. We'll also have a slot for 
comments on this draft at the meeting. Pending the outcome of this 
discussion we would like to resolve any issues raised and submit this 
draft for publication immediately after that.

Thanks,
Eric and John



From owner-issll@mercury.lcs.mit.edu  Wed Mar 15 17:33:27 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03352
	for <issll-archive@odin.ietf.org>; Wed, 15 Mar 2000 17:33:20 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA22025
	for issll-outgoing; Wed, 15 Mar 2000 16:38:47 -0500 (EST)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA21604
	for <issll@mercury.lcs.mit.edu>; Wed, 15 Mar 2000 16:38:45 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <v04210103b4f5b2cb4924@[18.26.0.167]>
Date: Wed, 15 Mar 2000 16:38:29 -0500
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Drafts, try 2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Following up on my own msg:

>As a reminder, all of the group's open drafts are available at:
>
> http://ana.lcs.mit.edu/ISSLL/drafts/<name-of-draft>

oops, wrong protocol. Really

ftp://ana.lcs.mit.edu/ISSLL/drafts/<name-of-draft>


From owner-issll@mercury.lcs.mit.edu  Wed Mar 15 18:01:03 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13242
	for <issll-archive@odin.ietf.org>; Wed, 15 Mar 2000 18:01:03 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA19234
	for issll-outgoing; Wed, 15 Mar 2000 17:05:29 -0500 (EST)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA24376
	for <issll@mercury.lcs.mit.edu>; Wed, 15 Mar 2000 17:05:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <v04210102b4f5b1e1121a@[18.26.0.167]>
Date: Wed, 15 Mar 2000 17:05:09 -0500
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: New draft: draft-ietf-issll-ds-map-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Folks,

Anna Charny and I have written a very drafty first draft of a 
"service mapping" document for diffserv. The purpose of this document 
is to describe the specifics of using diffserv clouds as part of a 
path that provides end-to-end intserv-style QoS.

I haven't seen the IETF announcement of this draft go by the list 
yet, but I assume it will soon. In the meantime it is available at

http://ana.lcs.mit.edu/ISSLL/drafts/draft-ietf-issll-ds-map-00.txt
ftp://ana.lcs.mit.edu/ISSLL/drafts/draft-ietf-issll-ds-map-00.txt

Completing this document is the last big thing in the group's current charter.
However, it needs quite a bit of work still, including the writing of 
at least one or two sections that are entirely missing at this point. 
All help from quick comments to additional authors would be welcome.

We've allocated a good chunk of the Adelaide meeting to presenting 
and discussing this draft. We hope to spin a new version very shortly 
after the meeting based on discussion there and on the list, so 
please take a look now if you're interested in this.

Thanks,
John


From owner-issll@mercury.lcs.mit.edu  Wed Mar 15 18:03:10 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13987
	for <issll-archive@odin.ietf.org>; Wed, 15 Mar 2000 18:03:09 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA14658
	for issll-outgoing; Wed, 15 Mar 2000 17:09:13 -0500 (EST)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA23704
	for <issll@mercury.lcs.mit.edu>; Wed, 15 Mar 2000 17:09:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <v04210104b4f5b9ace716@[18.26.0.167]>
Date: Wed, 15 Mar 2000 17:08:55 -0500
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Mailing list cleanup
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Hi,

Over time we've accumulated a number of dead addresses on the ISSLL 
list. I'm about to clean up a bit.

If you get this, wish to be on the list, and don't get a followup 
note from me within 48 hours, please send mail to me directly 
(jtw@lcs.mit.edu); I may have accidentally deleted you.

Thanks, -john


From owner-issll@mercury.lcs.mit.edu  Thu Mar 16 17:32:22 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21361
	for <issll-archive@odin.ietf.org>; Thu, 16 Mar 2000 17:32:20 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA26947
	for issll-outgoing; Thu, 16 Mar 2000 16:19:40 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA19305
	for <issll@mercury.lcs.mit.edu>; Thu, 16 Mar 2000 16:19:37 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23373;
	Thu, 16 Mar 2000 16:19:23 -0500 (EST)
Message-Id: <200003162119.QAA23373@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: issll@mercury.lcs.mit.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-issll-ds-map-00.txt
Date: Thu, 16 Mar 2000 16:19:22 -0500
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Integrated Services over Specific Link Layers Working Group of the IETF.

	Title		: Integrated Service Mappings for Differentiated 
                          Services Networks
	Author(s)	: J. Wroclawski, A. Charny
	Filename	: draft-ietf-issll-ds-map-00.txt
	Pages		: 
	Date		: 15-Mar-00
	
This document describes mappings of IETF Integrated Services onto IETF
differentiated services networks.  These mappings allow appropriately
engineered and configured differentiated service network clouds to play
the role of 'network elements' in the Integrated Services framework, and
thus to be used as components of an overall end-to-end Integrated
Services QoS solution.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-issll-ds-map-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-issll-ds-map-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-issll-ds-map-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000315132813.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-issll-ds-map-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-issll-ds-map-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000315132813.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-issll@mercury.lcs.mit.edu  Fri Mar 17 11:22:24 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03866
	for <issll-archive@odin.ietf.org>; Fri, 17 Mar 2000 11:22:23 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA25557
	for issll-outgoing; Fri, 17 Mar 2000 09:47:57 -0500 (EST)
Received: from ultra5.unile.it (ultra5.unile.it [193.204.77.251])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA26862
	for <issll@mercury.lcs.mit.edu>; Fri, 17 Mar 2000 09:44:52 -0500 (EST)
Received: from jack (drum.unile.it [193.204.77.151])
	by ultra5.unile.it (8.9.1b+Sun/8.9.1) with SMTP id PAA02990;
	Fri, 17 Mar 2000 15:41:22 GMT
Message-ID: <00c601bf901e$db64d3e0$974dccc1@unile.it>
From: "Simone Molendini" <molendin@ultra5.unile.it>
To: <fred@cisco.com>, <cei@cisco.com>, <flefauch@cisco.com>,
        <bdavie@cisco.com>
Cc: <issll@mercury.lcs.mit.edu>
Subject: Re: I-D ACTION:draft-ietf-issll-rsvp-aggr-02.txt
Date: Fri, 17 Mar 2000 15:41:03 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I have a question about E2E Resv messages' management in an  aggregation
domain

Let suppose that the deaggregator router receives through an external
interface an E2E Resv message.
Let suppose that it has already received the proper Aggregate Path message
by the aggregating router.

If the existing reservation has insufficient bandwith, the deaggregator
sends to the aggregator a new Aggregate Resv message.

But, it also sends the E2E Resv messages with IP protocol number RSVP:
do interior routers process both aggregate and E2E Resv message?

If this is true, it confuses me: why don't mark these E2E Resv messages with
RSVP-E2E-IGNORE?

Best regards,
Simone





From owner-issll@mercury.lcs.mit.edu  Fri Mar 17 11:40:46 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03865
	for <issll-archive@odin.ietf.org>; Fri, 17 Mar 2000 11:22:23 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA26667
	for issll-outgoing; Fri, 17 Mar 2000 10:24:42 -0500 (EST)
Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA27068
	for <issll@mercury.lcs.mit.edu>; Fri, 17 Mar 2000 10:24:39 -0500 (EST)
Received: from cisco.com (cei-ultra.cisco.com [161.44.134.45])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA02157;
	Fri, 17 Mar 2000 10:23:57 -0500 (EST)
Message-ID: <38D24E0D.5BC513A3@cisco.com>
Date: Fri, 17 Mar 2000 10:23:57 -0500
From: Carol Iturralde <cei@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Simone Molendini <molendin@ultra5.unile.it>
CC: fred@cisco.com, flefauch@cisco.com, bdavie@cisco.com,
        issll@mercury.lcs.mit.edu
Subject: Re: I-D ACTION:draft-ietf-issll-rsvp-aggr-02.txt
References: <00c601bf901e$db64d3e0$974dccc1@unile.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Simone Molendini wrote:
> 
> Hi,
> 
> I have a question about E2E Resv messages' management in an  aggregation
> domain
> 
> Let suppose that the deaggregator router receives through an external
> interface an E2E Resv message.
> Let suppose that it has already received the proper Aggregate Path message
> by the aggregating router.
> 
> If the existing reservation has insufficient bandwith, the deaggregator
> sends to the aggregator a new Aggregate Resv message.
> 
> But, it also sends the E2E Resv messages with IP protocol number RSVP:
> do interior routers process both aggregate and E2E Resv message?

The e2e Resv message is sent directly to the Aggregator (the PHOP
learned by deaggregator when e2e Path was received), and since
the Resv messages do not contain router alert option, interior
routers imply forward them as they would any IP data packet.  
Interior routers do not process e2e Resv messages.  They just
forward them.

> 
> If this is true, it confuses me: why don't mark these E2E Resv messages with
> RSVP-E2E-IGNORE?
> 
> Best regards,
> Simone


From owner-issll@mercury.lcs.mit.edu  Fri Mar 17 17:30:01 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04395
	for <issll-archive@odin.ietf.org>; Fri, 17 Mar 2000 17:29:59 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA04750
	for issll-outgoing; Fri, 17 Mar 2000 16:26:52 -0500 (EST)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA29790;
	Fri, 17 Mar 2000 16:26:39 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <v0421010fb4f84e39469f@[18.26.0.167]>
In-Reply-To: <10797.953197776@cs.ucl.ac.uk>
References: <10797.953197776@cs.ucl.ac.uk>
Date: Fri, 17 Mar 2000 16:26:21 -0500
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, acharny@cisco.com
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Re: New draft: draft-ietf-issll-ds-map-00.txt
Cc: issll@mercury.lcs.mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

(issll@mercury.lcs.mit.edu added to the reply list)

Jon,

At 9:09 AM +0000 3/16/00, Jon Crowcroft wrote:
>In message <v04210102b4f5b1e1121a@[18.26.0.167]>, John Wroclawski typed:
>
> >>Anna Charny and I have written a very drafty first draft of a
> >>"service mapping" document for diffserv. The purpose of this document
> >>is to describe the specifics of using diffserv clouds as part of a
> >>path that provides end-to-end intserv-style QoS.
>
>yes - i wonder if
>ftp://ftp.ee.lbl.gov/papers/vw_ba.pdf
>isnt relevant.....
>
>there's an assretion in kathy's paper that the jitter preopbability
>decreases as negative exponential of the number of the hops (as well
>as increasing linearly) due to the number of different ways you can
>combine DE packets to get infront of VW packets.....its a bit
>simplistic but clearly in the right spirit of working out what we
>actually care about, which (imho) is not worst bounds but 90centiles
>or first couple of moments of the delay distribution

This all is the intent of (the unwritten, only a title there at the 
moment) Section 5. We are definitely in need of contributions in this 
area.

What we wanted to accomplish with Section 4 was to lay out the 
performance of a "real" guaranteed service, and particularly give 
some intution about how it varies with changes in topology and so on.

Of course, we have a service (CL) that is specifically intended to 
support and be implemented with 99.99% strategies. So probably we've 
got the structure of the draft a bit wrong; a discussion of this 
could be broken out as service independent and then the applicability 
of it to both CL and G discussed separately.

>so the straight negative exponential assumes poisson (independant)
>phases of the seperate flows merging at an egress bottleneck. i you
>put in other distributions, and even put in a feedback loop that tends
>to synch the flows, its still quite hard to get a system that spends
>much of its time at the worst case.....but i think someone with some
>fancy stats background should look at these - feedin some fractional
>arima, and some renewal process stuff, and see what happens...

John


From owner-issll@mercury.lcs.mit.edu  Fri Mar 17 19:44:48 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22639
	for <issll-archive@odin.ietf.org>; Fri, 17 Mar 2000 19:44:48 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA19922
	for issll-outgoing; Fri, 17 Mar 2000 18:58:38 -0500 (EST)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA04269
	for <issll@mercury.lcs.mit.edu>; Fri, 17 Mar 2000 18:58:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <v04210101b4f876ceb4a0@[18.26.0.167]>
Date: Fri, 17 Mar 2000 18:58:20 -0500
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: List cleanup complete
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Hi,
The cleanup of the mailing list that I mentioned recently is 
complete. Hopefully you're all still here...

John


From owner-issll@mercury.lcs.mit.edu  Sat Mar 18 08:31:47 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13830
	for <issll-archive@odin.ietf.org>; Sat, 18 Mar 2000 08:31:47 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id HAA07032
	for issll-outgoing; Sat, 18 Mar 2000 07:40:57 -0500 (EST)
Received: from magic.kuis.kyoto-u.ac.jp (leeza.kuis.kyoto-u.ac.jp [130.54.22.126])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id HAA03453
	for <issll@mercury.lcs.mit.edu>; Sat, 18 Mar 2000 07:40:55 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by magic.kuis.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id VAA03803
	for <issll@mercury.lcs.mit.edu>; Sat, 18 Mar 2000 21:39:00 +0900 (JST)
	(envelope-from fujikawa@real-internet.org)
To: issll@mercury.lcs.mit.edu
Subject: Re: Meeting reminder and status of drafts
References: <v04210104b4f57db6dd7b@[18.26.0.167]>
X-Mailer: Mew version 1.93 on XEmacs 20.4 (Emerald)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000318213859S.fujikawa@real-internet.org>
Date: Sat, 18 Mar 2000 21:38:59 +0900
From: FUJIKAWA Kenji <fujikawa@real-internet.org>
X-Dispatcher: imput version 990731(IM118)
Lines: 18
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'd like to talk about an idea for guaranteeing 
per-flow QoS using a simpler method than WFQ.

ISSLL WG seems to be the best WG for making a presentation
in the coming IETF meeting.

Just three minutes are enough.

The title is: 
	A simple method of guaranteeing per-flow QoS

Thanks in advance.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
 WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                              E-mail fujikawa@real-internet.org



From owner-issll@mercury.lcs.mit.edu  Sat Mar 18 11:42:16 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23705
	for <issll-archive@odin.ietf.org>; Sat, 18 Mar 2000 11:42:15 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA04574
	for issll-outgoing; Sat, 18 Mar 2000 10:54:28 -0500 (EST)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA02651
	for <issll@mercury.lcs.mit.edu>; Sat, 18 Mar 2000 10:54:26 -0500 (EST)
Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA28373;
	Sat, 18 Mar 2000 16:53:05 +0100 (MET)
From: Mikhail Smirnov <smirnow@fokus.gmd.de>
Received: (mis@localhost) by dumbo.fokus.gmd.de  (SMI-8.6/8.6.12) id QAA05091; Sat, 18 Mar 2000 16:54:16 +0100
Date: Sat, 18 Mar 2000 16:54:16 +0100
Message-Id: <200003181554.QAA05091@dumbo.fokus.gmd.de >
To: issll@mercury.lcs.mit.edu
Subject: QofIS'2000
Cc: smirnow@fokus.gmd.de
X-Sun-Charset: US-ASCII
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Hi,
please find below a short information on a relevant 
to the list workshop:

----
title:        Quality of future Internet Services (QofIS'2000)
start date:   25 September 2000  
end date:     26 September 2000
submission:   29 March 2000
city:         Berlin
country:      Germany 
URL:          http://www.fokus.gmd.de/events/qofis2000/
description:  The workshop focuses on end-to-end  services 
              over QoS assured Internet, on service creation, 
              configuration and deployment.
chairs:       Jon Crowcroft, Jim Roberts
publication:  Proceedings will be published by Springer in LNCS
contact:      qofis2000@fokus.gmd.de or smirnow@fokus.gmd.de
              tel.: +49 30 34637113 fax.: +49 30 34638000
sponsors:     T-Nova (Deutsche Telekom), Cisco Systems, Nokia, 
              IST Programme of the European Union, GMD FOKUS,
              ERCIM
----

Regards

Michael


From owner-issll@mercury.lcs.mit.edu  Wed Mar 22 06:56:09 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14403
	for <issll-archive@odin.ietf.org>; Wed, 22 Mar 2000 06:56:08 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id FAA18534
	for issll-outgoing; Wed, 22 Mar 2000 05:28:32 -0500 (EST)
Received: from magic.kuis.kyoto-u.ac.jp (leeza.kuis.kyoto-u.ac.jp [130.54.22.126])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id FAA23117
	for <issll@mercury.lcs.mit.edu>; Wed, 22 Mar 2000 05:27:48 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by magic.kuis.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id TAA01337
	for <issll@mercury.lcs.mit.edu>; Wed, 22 Mar 2000 19:25:34 +0900 (JST)
	(envelope-from fujikawa@real-internet.org)
To: issll@mercury.lcs.mit.edu
Subject: Re: Meeting reminder and status of drafts
In-Reply-To: Your message of "Sat, 18 Mar 2000 21:38:59 +0900"
	<20000318213859S.fujikawa@real-internet.org>
References: <20000318213859S.fujikawa@real-internet.org>
X-Mailer: Mew version 1.93 on XEmacs 20.4 (Emerald)
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
	boundary="--Next_Part(Wed_Mar_22_17:14:54_2000_809)--"
Content-Transfer-Encoding: 7bit
Message-Id: <20000322192533B.fujikawa@real-internet.org>
Date: Wed, 22 Mar 2000 19:25:33 +0900
From: FUJIKAWA Kenji <fujikawa@real-internet.org>
X-Dispatcher: imput version 990731(IM118)
Lines: 515
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

----Next_Part(Wed_Mar_22_17:14:54_2000_809)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From: FUJIKAWA Kenji <fujikawa@real-internet.org>
Subject: Re: Meeting reminder and status of drafts
Date: Sat, 18 Mar 2000 21:38:59 +0900

> The title is: 
> 	A simple method of guaranteeing per-flow QoS
> 
> Thanks in advance.

Please accept our apology for sending our ID directly 
to this ML.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
 WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                              E-mail fujikawa@real-internet.org


----Next_Part(Wed_Mar_22_17:14:54_2000_809)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit







INTERNET DRAFT                                              FUJIKAWA Kenji
                                                          FUJIMOTO Yoshito
                                                              IKEDA Katsuo
                                                          Kyoto University
                                                           MATSUFURU Norio
                                                      Hiroshima University
                                                             OHTA Masataka
                                             Tokyo Institute of Technology

                                                  Real Internet Consortium
                                                             10 March 2000


              A Simple Method of Guaranteeing Per-Flow QoS


Status of this Memo

    This document is an Internet-Draft and is in full conformance
    with all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as
    "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.


Abstract

    This draft defines a simple method of guaranteeing per-flow 
    QoS. For this, Comfortable Service (CS) is defined, which realizes 
    statistical end-to-end QoS guarantee in the Internet. CS is 
    based on Policed Priority Queuing (PPQ) which processes packets 
    in a constant time, and statistically guarantee the maximum 
    time of queuing delay.


   



FUJIKAWA Kenji              Expires on 10 September              [Page 1]






INTERNET DRAFT                      CS                         March 2000


1. Introduction

   Guaranteed service[RFC2212] based on Weighted Fair Queuing
   (WFQ)[WFQ1992] is proposed as a type of Integrated Services (IntServ).
   In guaranteed service, it takes O(log(n)) time to insert each input
   packet into an output queue, or to pick it up from the queue because
   of sorting, where n is the number of flows that should be treated
   individually. WFQ strictly guarantees the maximum delay time, however
   this does not mean all the packets will actually reach the end in the
   maximum delay time, because the network cannot completely be free from
   bit errors or packet loss.
   
   We define a queuing method, Policed Priority Queuing (PPQ) , in which
   the time to insert each input packet to an output queue and the time
   to pick it up from the output queue are constant, and the maximum
   delay time is guaranteed statistically. We then define a new type of
   IntServ, Comfortable Service (CS) , which is based on PPQ and realizes
   statistical end-to-end QoS guarantee in the Internet.

   
2. Definition of QoS Guarantee

   In this article, Quality of Services (QoS) guarantee is defined as
   follows:
   when transmitting packets
     * with the defined traffic pattern,
     * with a specified average bandwidth,
       
   they reach the end
     * at the defined probability (at the defined packet loss ratio),
     * in a specified maximum delay time.
       
   This QoS guarantee is necessary and sufficient for multimedia
   applications such as audio and video transmission.

   
3. Structure of Router Based on PPQ for QoS Guarantee

   A router based on Policed Priority Queuing (PPQ) for QoS guarantee is
   shown in Figure I1.
   










FUJIKAWA Kenji              Expires on 10 September              [Page 2]






INTERNET DRAFT                      CS                         March 2000


 Input      +----------------------------------------------------+ Output
 Interfaces |          Flow1  +--+                     ----+     | Interfaces
            |           /---> |P1| ------------------>  QQ |     |
            |          /      +--+ \ /--------------->     |     |
            |     +-+ /Flow2  +--+  X                  ----+ --> | ------>
    ------> | --> |C| ------> |P2| / \--------> -----------+ --> |
            |     +-+ \Flow3  +--+ ----------->         BQ |     |
            |      \ \ \----> +--+    /------->            |     |
            |       \ \       |P3| \ / /------> -----------+     |
            |        \ \      +--+ \X /                          |
            |         \ \----------/\X                 ----+     |
            |          \            /\\-------------->  QQ |     |
            |           ----------\/  X-------------->     |     |
            |                     /\ / \               ----+ --> | ------->
            |      +-+ ----------/  X   \-----> -----------+ --> |
    ------> | -->  |C| Flow4  +--+ / \-------->         BQ |     |
            |      +-+ -----> |P4| ----------->            |     |
            |        \        +--+  /---------> -----------+     |
            |         \------------/                             |
            +----------------------------------------------------+

            C:     Classifier             QQ: QoS Queue
            P1-P4: Policer                BQ: Best-Effort Queue

                        Figure I1: Router based on PPQ

   The process of packets is as follows:
    1. Packets of multiple flows are input into a router from input
       interfaces.
    2. By classifiers, each packet is classified into a QoS-guaranteed
       type (from Flow1 to Flow4 in Figure I1 ) or a best-effort type.
    3. An output interface is determined.
         1. A packet of best-effort flows is queued in the best-effort
            queue at the output interface determined by packet analysis.
         2. In terms of packets of a QoS-guaranteed flow, the policer
            associated with the flow checks if the packets violates the
            bandwidth the flow has requested in advance. Legal packets
            are queued in the QoS queue at the output interface, and
            illegal ones are queued in the best-effort queue at the same
            output interface.
    4. Packets are transmitted.
       
   The following rules are used when transmitting packets:
     * A QoS queue has an absolutely high priority.
     * The process is executed in First Come First Serve (FCFS) manner.
     * A router transmits packets in a best-effort queue when the
       corresponding QoS queue becomes empty.
     * A packet transmission is not preempted until it is over, when it



FUJIKAWA Kenji              Expires on 10 September              [Page 3]






INTERNET DRAFT                      CS                         March 2000


       is once started.
       
   These processes can be executed in a constant time except the process
   at classifiers. By means of hashing or using Content Addressable
   Memory (CAM), the process at classifiers can also be executed in a
   constant time. Note that sice a policer does not configure a queue,
   the queuing delay does not occur at the policer.

   
4. Queuing Model and Its Analysis

  4.1 Queuing Model M/D/1/K
  
   In PPQ, QoS-guaranteed flows are being processed, almost whenever
   packets exist in a QoS queue. Thus, QoS-guaranteed flows are
   considered to be independent of best-effort flows. Only the QoS queue
   is discussed hereafter.
   
   The length of a QoS queue at an output interface is influenced by all
   the QoS-guaranteed flows directed to the interface. Assuming that each
   flow is transmitted from the upstream node at exponential distribution
   intervals, the arrival intervals of mixed flows at the queue in the
   router also becomes exponential distribution.
   
   We regard the processing time of each packet constant, considering the
   processing time of the longest packet. We also let the MTU be 1280
   bytes, with taking into account IPv6.
   
   As a result, when let the maximum queue length be K , the behavior of
   a QoS queue can be treated as M/D/1/K.
   
  4.2 Analysis of Delay and Packet Loss Ratio
  
   Using an M/D/1/K queuing model, we analyze the behavior of a QoS queue
   and clarify the delay and packet loss ratio.
   
   We let the processing time of one packet be constant in the above
   discussion. Then, we use packet per second (pps) instead of bit per
   second (bps) for majoring both router's processing capacity and the
   rate of arriving packets of QoS-guaranteed flows.
   
   Let the processing capacity of a certain output interface be u (stands
   for mu in Greek characters) pps, the packet arrival rate of all the
   flows arriving at a certain QoS queue be l (stands for lambda) pps,
   and the maximum length of the queue be K. Here l equals to the total
   sum of l_i , where the arrival rate of flow i is l_i. The availability
   of the interface is given by p (stands for rho) = l/u.
   



FUJIKAWA Kenji              Expires on 10 September              [Page 4]






INTERNET DRAFT                      CS                         March 2000


   Generally, it is well known that a probability of queue overflow
   becomes very low, when p is less than 1.
   
   Though the detailed analysis is omitted here, the packet loss ratio
   for each p and each K is given by numerical analysis. This shows that
   in the case of the maximum queue length of 20, the packet loss ratio
   of 10^-5 is achieved even when 75% of the bandwidth is reserved.
   
   In other words, under the conditions that the maximum length of the
   queue is set to 20, and that only the reservations that consume 75% of
   the bandwidth are admitted, the packet loss ratio of 10^-5 can be
   guaranteed for every flow.
   
   Considering use in the Internet, even if only 75% of an output
   interface is utilized for QoS-guaranteed flows, the rest 25% is
   consumed by best-effort flows. This means the interface is fully
   utilized at any time.
   
   The maximum delay time is given by K/u , independent of the arrival
   time of each flow. For example, in the case of 100 Mbps, the queuing
   delay is 2 msec, while in the case of 10 Gbps, the queuing delay is no
   more than 20 usec. That is, at high-speed links, the queuing delay can
   be ignored against the transmission delay.
   
   According to PPQ, QoS guarantee can be easily achieved, where the
   packet loss ratio and the queuing delay are easily estimated.

   
5. ``Comfortable'' Service

   We define Comfortable Service (CS) as a new service for QoS guarantee.
   Here, comfortable means not completely guaranteed but statistically
   guaranteed, and comfortable for actual applications.
   
   First, we aim at the packet loss ratio of less than 10^-5 at a single
   router. Then, assuming that there is a case that at most 100 routers
   reside on the path, the end-to-end packet loss ratio becomes less than
   about 10^-3.
   
   Under the condition that the routers on the path of a flow employs
   PPQ, when a sender sends packets
     * at exponential distribution intervals or at less bursty intervals,
     * with an average bandwidth of l , which is reserved in advance,
       
   end-to-end QoS guarantee
     * with a probability of more than 1-10^-3 (at the packet loss ratio
       of 10^-3 ),
     * and with the queuing delay which is the sum of the transmission



FUJIKAWA Kenji              Expires on 10 September              [Page 5]






INTERNET DRAFT                      CS                         March 2000


       delay and the queuing delays K/u of all the routers.
       
   is realized.
   
   Each router can freely set up the values of K and p as long as it
   achieves the packet loss ratio of 10^-5. Here the packet loss ratio
   caused by bit errors on links should be further lower than 10^-5.

   
6. Issues

  6.1 Is Packet Loss Ratio of 10^-3 of Use?
  
   The packet loss ratio of 10^-3 may seem to be no use for communication
   requiring a severe loss ratio such as high-quality video transmission,
   however this is not correct.
   
   Shanon's theorem shows that channel capacity of a communication
   channel is determined by bandwidth and error probability of the
   channel, and that an error probability can be made as small as wished
   by means of block coding, as long as a transmitting rate is lower than
   the channel capacity. Instead, the theorem also implies that it takes
   more time for coding and decoding.
   
   Actually, error correction coding can drasticly reduce an error
   probability. Since many packets are handled together in strong error
   correction coding, delay for spooling these packets occurs. However,
   the delay is just 1/30 seconds even when 100 packets of 1280 bytes are
   handled together for error correction in a 30-Mbps communication. This
   can be ignored for humans. In addition, if this is a communication for
   digital video transmission of 30 frame per second, the delay of 1/30
   seconds is originally inevitable for JPEG coding. Error correction
   coding does not cause a new delay in this case.
   
   Therefore, an error probability can be reduced by sender's elaborate
   process. It is important to give the defined low error probability
   before communication, but is not important to provide various error
   probabilities for various applications.
   
  6.2 Limitation of PPQ
  
   PPQ is valid only on fast links, and not on slow links, since the
   delay is in inverse proportion to the rate of an output interface. On
   slow links of less than 10 Mbps, there is a case that WFQ can decrease
   the maximum delay more.
   





FUJIKAWA Kenji              Expires on 10 September              [Page 6]






INTERNET DRAFT                      CS                         March 2000


  6.3 Is M/D/1/K Model Appropriate?
  
   Estimation by the M/D/1/K model may be exaggerated, since the actual
   arrival intervals of a flow tends to be less bursty and more periodic
   than exponential distribution. In this case, more bandwidth can be
   assigned to QoS-guaranteed services by means of making p larger.
   However in the Internet, it is required to assign bandwidth to
   best-effort services if any. It is not required to utilize almost all
   the bandwidth for QoS guarantee.
   
   Consequently, the M/D/1/K model is appropriate and sufficient for QoS
   guarantee on the Internet in the real world.


   
References

   [RFC2212]
          Shenker, S., Partridge, C., and Guerin, R., ``Specification of
          Guaranteed Quality of Service,'' RFC2212, September 1997.
          
   [WFQ1992]
          Parekh, A., ``A Generalized Processor Sharing Approach to Flow
          Control in Integrated Services Networks,'' MIT Laboratory for
          Information and Decision Systems, Report LIDS-TH-2089, February
          1992.
          
   [QST1975]
          Kleinrock, L., ``Queuing Systems Volume 1 Theory,'' John Wiley,
          1976.
          
   [ITC1963]
          Abramson, N., ``Information Theory and Coding,'' McGraw-Hill,
          1963.

   















FUJIKAWA Kenji              Expires on 10 September              [Page 7]






INTERNET DRAFT                      CS                         March 2000


Authors' Address

    FUJIKAWA Kenji
    FUJIMOTO Yoshito
    IKEDA Katsuo
    Graduate School of Informatics
    Kyoto University
    Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN
    Phone: +81-75-753-5387
    Fax: +81-75-751-0482
    EMail: fujikawa@real-internet.org
    EMail: yoshito@bio.i.kyoto-u.ac.jp
    EMail: ikeda@i.kyoto-u.ac.jp

    MATSUFURU Norio
    Graduate School of Engineering
    Hiroshima University
    Kagamiyama 1-4-2 Higashi-hiroshima City, 739-8526, JAPAN
    Phone: +81-824-24-6251
    Fax: +81-824-22-7043
    Email: matu@net.ipc.hiroshima-u.ac.jp

    OHTA Masataka
    Computer Center
    Tokyo Institute of Technology
    2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
    Phone: +81-3-5734-3299
    Fax: +81-3-5734-3415
    EMail: mohta@necom830.hpcl.titech.ac.jp






















FUJIKAWA Kenji              Expires on 10 September              [Page 8]

----Next_Part(Wed_Mar_22_17:14:54_2000_809)----


From owner-issll@mercury.lcs.mit.edu  Thu Mar 23 01:09:05 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21311
	for <issll-archive@odin.ietf.org>; Thu, 23 Mar 2000 01:09:04 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id AAA02418
	for issll-outgoing; Thu, 23 Mar 2000 00:08:17 -0500 (EST)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id AAA02417
	for <issll@mercury.lcs.mit.edu>; Thu, 23 Mar 2000 00:08:16 -0500 (EST)
Received: from blatz.bbn.com (BLATZ.BBN.COM [128.89.34.141])
	by po2.bbn.com (8.9.1/8.9.1) with ESMTP id AAA24995;
	Thu, 23 Mar 2000 00:08:09 -0500 (EST)
Received: from blatz (localhost [127.0.0.1])
	by blatz.bbn.com (8.8.5/8.8.5) with ESMTP id AAA19932;
	Thu, 23 Mar 2000 00:08:09 -0500 (EST)
Message-Id: <200003230508.AAA19932@blatz.bbn.com>
To: tccc@ieee.org, itc@ieee.org, int-serv@isi.edu, issll@mercury.lcs.mit.edu
Subject: ECOOP 2000: Final Call for Workshop on QoS and Dist Objects
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 23 Mar 2000 00:08:09 -0500
From: "John A. Zinky" <jzinky@bbn.com>
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Workshop on Quality of Service in Distributed Object Systems

In Association with:  14th European Conference on 
                      Object-Oriented Programming 
                      (ECOOP'2000) 
                      Sophia Antipolis and Cannes, France,  June 12-16, 2000

Workshop goal

The suitability of the object model for the modeling and implementation 
of distributed systems has lead to middleware platforms, such as e.g. 
CORBA, DCOM, and Java/RMI. Originally, these middleware systems 
aim at distribution transparency for application programmers. 

However, distributed systems are exposed to system issues, like 
dynamic performance changes or partial errors, that prevent a 
complete distribution transparency. Quality of Service (QoS) 
management addresses these issues. The goal is to add QoS management 
to the interactions between clients and services. 

Support for QoS management in distributed object systems is a hot 
topic of current research which poses a number of open questions: 
How is QoS integrated with the object model that emphasizes encapsulation 
and information hiding? Can one build generic support frameworks for 
multiple QoS categories, in contrast to specialized, single category 
systems, such as TAO, Electra, Eternal, DOORS among others. Can QoS be 
viewed as an aspect in the sense of Aspect Oriented Programming (AOP) or
are other classifications more appropriate? 

This ECOOP-workshop will discuss the open questions and will summarize 
the state of the art in the field. The workshop will stimulate discussions 
about how next generation QoS management facilities can be built into 
object infrastructures. We expect the workshop to attract researchers 
from several groups which have working prototypes for this infrastructure. 
Reports on prototype systems are welcome as well as theoretical aspects, 
modeling techniques, and application scenarios.

Call for papers

Topics include, but are not restricted to 

   - Modeling QoS: suitability of object oriented modeling techniques,
     influences of QoS provision on the object-model, e.g. type systems 
   - Structure and implementation issues: Aspect Oriented Programming, 
     open implementations, and design patterns 
   - Scope of QoS-integration: generic integration, multi-category support, 
     impact on architecture and underlying object-model 
   - Integration of QoS management and network and application 
     management 
   - Experiences and case studies of QoS integration in OO-Middleware platforms 
   - Specialized QoS platforms vs. extending existing platforms 
   - Interoperability issues across QoS platforms 
   - QoS in the WWW 
   - Negotiation of QoS in open distributed systems 
   - Accounting and Pricing of QoS 
   - Ressource Control for QoS management

Submissions

A one page extended abstract describing your research is required.
Selection of contributions is not only based on the quality of the 
submitted research work but also with regard to sessions with a distinct 
focus. Participants will have 15 minutes to present their research.
Submissions in ASCII, Postscript, PDF, or HTML are requested by email to 

qosdos@vsb.informatik.uni-frankfurt.de 

The accepted abstracts will be distributed to the other participants.  

Important Dates

 Deadline for submissions:
                                 March 24, 2000
 Notification of acceptance:
                                 April 10, 2000
 Workshop:
                                 June 13, 2000

  
Organizers

Christian Becker, University of Frankfurt, Germany and John Zinky, BBN, USA 
  
Links

http://ecoop2000.unice.fr/Program/Technical/Workshops/w19.html
http://www.vsb.informatik.uni-frankfurt.de/misc/QoSDOS/index.html
  


From owner-issll@mercury.lcs.mit.edu  Tue Mar 28 11:52:07 2000
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23479
	for <issll-archive@odin.ietf.org>; Tue, 28 Mar 2000 11:52:03 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA21877
	for issll-outgoing; Tue, 28 Mar 2000 10:29:40 -0500 (EST)
Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA21929
	for <issll@mercury.lcs.mit.edu>; Tue, 28 Mar 2000 10:29:37 -0500 (EST)
Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id RAA18355;
	Tue, 28 Mar 2000 17:22:17 +0200 (CEST)
Received: from prak (Prak.heidelberg.ccrle.nec.de [192.168.102.92])
	by wallace.heidelberg.ccrle.nec.de (8.8.7/3.6W980203HK) with SMTP id RAA21920;
	Tue, 28 Mar 2000 17:37:07 +0200 (CEST)
Message-ID: <008601bf98c9$7c215170$5c66a8c0@heidelberg.ccrle.nec.de>
From: "hjs" <stuttgen@ccrle.nec.de>
To: "atm2000" <atm2000@ccrle.nec.de>
Subject: IEEE HPSR/ATM2000 Program Online and Registration open
Date: Tue, 28 Mar 2000 17:22:51 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Colleague,

I am happy to announce that the preliminary program for the

IEEE High Performance Switching and Routing Conference 2000 (ATM2000)

from June 26 to June 29, 2000 at Heidelberg/Germany is now online
available at    http://atm2000.ccrle.nec.de/ . The web site also
includes all necessary registration forms for Tutorials, Conference,
Hotel, as well as travel and other useful information.

Please forward this email to anybody that may be interested in the
conference.

As we have to limit the number of attendants, I encourage you to
register as early as possible, thereby you will also enjoy the
cheaper early registration rates as well as a space in the
conference hotel. Rooms are limited and will be handled
on a FCFS base.

Looking forward to see you in Heidelberg

Heinrich Stüttgen
IEEE HPSR General Chair

PS. Please accept my apologies if you receive multiple copies
        of this invitation