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 ; 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 ; 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" To: 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

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.

Visit the SIP 2000 International Conference programme:

http://www.upperside.fr/basip.= htm

------=_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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Wed, 15 Mar 2000 15:36:09 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: Date: Wed, 15 Mar 2000 15:35:53 -0500 To: issll@mercury.lcs.mit.edu From: John Wroclawski 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/ 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 ; 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 ; Wed, 15 Mar 2000 16:32:10 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: Date: Wed, 15 Mar 2000 15:35:53 -0500 To: issll@mercury.lcs.mit.edu From: John Wroclawski 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/ 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 ; 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 ; Wed, 15 Mar 2000 16:38:45 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: Date: Wed, 15 Mar 2000 16:38:29 -0500 To: issll@mercury.lcs.mit.edu From: John Wroclawski 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/ oops, wrong protocol. Really ftp://ana.lcs.mit.edu/ISSLL/drafts/ 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 ; 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 ; Wed, 15 Mar 2000 17:05:27 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: Date: Wed, 15 Mar 2000 17:05:09 -0500 To: issll@mercury.lcs.mit.edu From: John Wroclawski 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 ; 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 ; Wed, 15 Mar 2000 17:09:11 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: Date: Wed, 15 Mar 2000 17:08:55 -0500 To: issll@mercury.lcs.mit.edu From: John Wroclawski 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 ; 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 ; 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 ; 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 ; 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" To: , , , Cc: 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 ; 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 ; 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 X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simone Molendini 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 ; 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: 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 , acharny@cisco.com From: John Wroclawski 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 , 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 ; 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 ; Fri, 17 Mar 2000 18:58:37 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: Date: Fri, 17 Mar 2000 18:58:20 -0500 To: issll@mercury.lcs.mit.edu From: John Wroclawski 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 ; 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 ; 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 ; 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: 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 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 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 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 ; 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 ; 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" 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 ; 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 ; 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" To: "atm2000" 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