From owner-issll@mercury.lcs.mit.edu Wed Feb 2 23:10:33 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 XAA27994 for ; Wed, 2 Feb 2000 23:10:32 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id VAA25274 for issll-outgoing; Wed, 2 Feb 2000 21:59:27 -0500 (EST) Received: from postoffice.srv.cs.cmu.edu (POSTOFFICE.SRV.CS.CMU.EDU [128.2.181.62]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id VAA27864 for ; Wed, 2 Feb 2000 21:59:25 -0500 (EST) Message-Id: <200002030259.VAA27864@mercury.lcs.mit.edu> Received: from HAWAII.CMCL.CS.CMU.EDU by postoffice.srv.cs.cmu.edu id aa01104; 2 Feb 2000 21:58 EST X-Sender: prs@postoffice.srv.cs.cmu.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 02 Feb 2000 21:58:55 -0500 To: int-serv@isi.edu, issll@mercury.lcs.mit.edu From: Peter Steenkiste Subject: IWQoS 2000 CFP deadling is Feb 21 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Appended is teh CFP for IWQoS 2000. Please consider submitting a paper, Peter Steenkiste Hui Zhang *CALL FOR PAPERS* EIGHTH INTERNATIONAL WORKSHOP on QUALITY of SERVICE (IWQoS) http://www.cs.cmu.edu/~iwqos/ June 5-7, 2000 Westin William Penn Hotel Pittsburgh, PA SPONSORS: - IEEE Communications Society and IFIP WG6.1 - In Association with ACM SIGCOMM WORKSHOP THEME: This is the eighth of a series of workshops providing an international forum for the exchange of information on quality of service (QoS) research in all the facets of QoS in a networked or distributed environment, including architectures, services, multimedia, operating systems and middleware. The objective of the Eighth International Workshop on Quality of Service is to bring together researchers, developers, and practitioners working in all these areas to discuss recent innovative results and future directions. Besides soliciting contributions in all areas of QoS research in distributed systems and networking, we would like to place special emphasis this year on papers reporting experience in developing and using applications that use QoS-enabled systems. TOPICS (included, but are not limited to): * QoS Specification, Resource Allocation, (Re)negotiation, and Monitoring * QoS and the Internet * QoS Performance Modeling, Analysis and Evaluation * Adaptive Applications and Services * QoS Measurement, Management and Control * QoS Support for Mobility and Wireless Networks * Middleware Solutions for End-to-End QoS * QoS Support for Information Appliances * Storage Systems/Database Support for QoS * Experimental Studies on QoS, including Human Perception * QoS Programmability, Languages and Formal Method Techniques * QoS Economics and Implications In the past the workshop has been cross-disciplinary, small and well focused, with the emphasis on innovation. As a result, a considerable amount of time is devoted to informal discussion. The programs of the previous workshops is available online. *IMPORTANT DATES:* * Paper deadline: February 21, 2000 * Notification: April 3, 2000 * Final papers due: April 21 ______________ CO-CHAIRS: Peter Steenkiste and Hui Zhang, Carnegie Mellon University IWQoS STEERING COMMITTEE: Andrew Campbell, Columbia University Jon Crowcroft, UCL, London Jan de Meer, GMD-FOKUS Rich Friedrich, HP labs Edward Knightly, Rice University Klara Nahrstedt, University of Illinois PROGRAM COMMITTEE: Nina Bhatti, HP Labs Ernst Biersack, Eurecom, France Gordon Blair, University of Lancaster, UK Jose Brustoloni, Bell Labs Bruce Davies, Cisco Hermann de Meer, UCL, London Christopher Diot, Sprint Labs Matthias Grossglauser, AT&T Research Roch Guerin, University of Pennsylvania Jorg Liebeherr, University of Virginia Steve Low, University of Melbourne, Australia Songwu Lu, UCLA Qingming Ma, Cisco Bernard Plattner, ETH Zurich, Switzerland Ralph Steinmetz, University of Darmstadt, Germany Steve Weinstein, NEC Thomas Woo, Bell labs John Wroclawski, MIT Geoff Xie, Naval Postgraduate School Lixia Zhang, UCLA Gisli Hjalmtysson, AT&T Research From owner-issll@mercury.lcs.mit.edu Thu Feb 3 07:37:31 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 HAA14947 for ; Thu, 3 Feb 2000 07:37:30 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA29818 for issll-outgoing; Thu, 3 Feb 2000 06:39:44 -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 GAA30012 for ; Thu, 3 Feb 2000 06:39:42 -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 GAA13220; Thu, 3 Feb 2000 06:39:41 -0500 (EST) Message-Id: <200002031139.GAA13220@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-is802-sbm-10.txt Date: Thu, 03 Feb 2000 06:39:40 -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 : SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks Author(s) : R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker Filename : draft-ietf-issll-is802-sbm-10.txt Pages : 67 Date : 02-Feb-00 This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-issll-is802-sbm-10.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-is802-sbm-10.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-is802-sbm-10.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: <20000202090324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-issll-is802-sbm-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-issll-is802-sbm-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000202090324.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-issll@mercury.lcs.mit.edu Thu Feb 3 13:19:41 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 NAA25900 for ; Thu, 3 Feb 2000 13:19:41 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id MAA27047 for issll-outgoing; Thu, 3 Feb 2000 12:02:47 -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 MAA26695 for ; Thu, 3 Feb 2000 12:02:41 -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 MAA22993; Thu, 3 Feb 2000 12:02:14 -0500 (EST) Message-Id: <200002031702.MAA22993@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: issll@mercury.lcs.mit.edu From: The IESG Subject: Protocol Action: SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks to Proposed Standard Date: Thu, 03 Feb 2000 12:02:14 -0500 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk The IESG has approved the following Internet-Drafts as Proposed Standards: o SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks o Integrated Service Mappings on IEEE 802 Networks In the same action, the IESG also approved publication of A Framework for Providing Integrated Services Over Shared and Switched IEEE 802 LAN Technologies as an Informational RFC. These documents are the product of the Integrated Services over Specific Link Layers Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary These documents define the Subnet Bandwidth Manager (SBM) protocol, a set of service mappings to be used with SBM and a framework for providing Integrated Services over shared and switched IEEE-802-style LAN technologies. The SBM (Subnet Bandwidth Manager) protocol provides a method for mapping an internet-level setup protocol such as RSVP onto IEEE 802-style networks. In particular, it describes the operation of RSVP-enabled hosts/routers and link layer devices (switches, bridges) to support reservation of LAN resources for RSVP-enabled data flows. The service mapping document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies The framework document describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queuing support in LAN switches. It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol (RSVP) in such LAN environments. Working Group Summary The working group supported the publication of these documents and no issues were raised during IETF Last-Call. Protocol Quality These documents were reviewed for the IESG by Scott Bradner. From owner-issll@mercury.lcs.mit.edu Sun Feb 13 15:59: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 PAA13574 for ; Sun, 13 Feb 2000 15:59:07 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id OAA02299 for issll-outgoing; Sun, 13 Feb 2000 14:58:55 -0500 (EST) Received: from smartt.com (ktk6.smartt.com [209.52.5.253]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id OAA29311 for ; Sun, 13 Feb 2000 14:58:52 -0500 (EST) From: taxfree9567@yahoo.com Received: from your (vict-mx0100101.smartt.com [207.34.159.14]) by smartt.com (8.9.0/8.9.0) with SMTP id LAA03493; Sun, 13 Feb 2000 11:55:53 -0800 (PST) Date: Sun, 13 Feb 2000 11:55:53 -0800 (PST) Message-Id: <200002131955.LAA03493@smartt.com> Reply-To: taxfree9567@yahoo.com To: taxfree9567@yahoo.com Subject: Tired of the 9 to 5 yet? Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Are you serious? Serious about finally working for yourself and not somebody else? Serious about having more time to do what you want when you want? Serious about taking control of your finances and having your money go to work for you? Do you want to work for your dreams, and quit building someone else’s? Are you serious about finally working from home? Are you serious about being truly free? Are you serious? I am looking for people who are willing to get to work and make it happen. This is not multi-level-marketing To find out more, call Toll Free. 1-800-636-6773 ext 3886. Serious inquiries only God Bless From owner-issll@mercury.lcs.mit.edu Tue Feb 15 18:14:26 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 SAA27075 for ; Tue, 15 Feb 2000 18:14:25 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA05864 for issll-outgoing; Tue, 15 Feb 2000 16:47:26 -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 QAA32539 for ; Tue, 15 Feb 2000 16:47:24 -0500 (EST) Received: from acharny-pc2.cisco.com (ch2-dhcp134-226.cisco.com [161.44.134.226]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA19284 for ; Tue, 15 Feb 2000 16:46:49 -0500 (EST) Message-Id: <4.2.0.58.20000215164034.00b27a90@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 15 Feb 2000 16:49:46 -0500 To: issll@mercury.lcs.mit.edu From: Anna Charny Subject: RE: delay bounds over Diffserv cloud In-Reply-To: <200001111329.IAA29125@pilgrim.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Hi, The updated and corrected draft of a document discussing delay bounds over Diffserv cloud is available at ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay_v3.ps Thanks again to Jim Roberts and Jean-Yves Le Bouldec for pointing out an error in the original version of the document. Feedback and comments will be appreciated. Thanks, Anna At 08:25 AM 1/11/00 -0500, you wrote: >X-Sender: acharny@pilgrim.cisco.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 >Date: Tue, 11 Jan 2000 08:25:06 -0500 >To: issll@mercury.lcs.mit.edu >From: Anna Charny >Subject: RE: delay bounds over Diffserv cloud >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Sender: owner-issll@mercury.lcs.mit.edu >Precedence: bulk >X-UIDL: fd45c9655aca675cfdac07de4db831a0 >Status: U > >Hi, > >There appears to be a hole in the proof of the delay bound in the paper that I posted recently. As written, the proof does not handle a general topology case as I had previously thought. Thanks to Jim Roberts of France Telecom for pointing it out. > >At the moment it is not clear (at least to me) whether the bound itself is incorrect for a general network, or it is the proof that needs to be fixed. What is clear is that the bound for a general topology is at least as bad as shown in the paper - but at the moment there is a possibility that it can actually be worse for some topologies. > >Any insights or comments will be appreciated. > >Thanks, >Anna > > >X-Sender: acharny@pilgrim.cisco.com > >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 > >Date: Wed, 05 Jan 2000 15:36:33 -0500 > >To: issll@mercury.lcs.mit.edu > >From: Anna Charny > >Subject: delay bounds over Diffserv cloud > >Sender: owner-issll@mercury.lcs.mit.edu > >X-SMTP-HELO: mercury.lcs.mit.edu > >X-SMTP-MAIL-FROM: owner-issll@mercury.lcs.mit.edu > >X-SMAP-Received-From: outside > >X-SMTP-PEER-INFO: mercury.lcs.mit.edu [18.26.0.122] > > > >Hi, > > > >The slides from the meeting in D.C. regarding delay bounds over a Diffserv cloud, and a paper containing the proof of the bounds and anlysis of the accuracy of the bound can be obtained from > > > >ftp://ftpeng.cisco.com/ftp/acharny/issll_vwg.ps > >ftp://ftpeng.cisco.com/ftp/acharny/aggregate_delay.ps > > > >via anonymous ftp. > > > > > >Apologies for the delay in posting it, > > > >Anna > > From owner-issll@mercury.lcs.mit.edu Sun Feb 20 11:26: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 LAA11096 for ; Sun, 20 Feb 2000 11:26:24 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA28632 for issll-outgoing; Sun, 20 Feb 2000 10:35:15 -0500 (EST) Received: from postoffice.srv.cs.cmu.edu (POSTOFFICE.SRV.CS.CMU.EDU [128.2.181.62]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id KAA25769 for ; Sun, 20 Feb 2000 10:35:13 -0500 (EST) Message-Id: <200002201535.KAA25769@mercury.lcs.mit.edu> Received: from HAWAII.CMCL.CS.CMU.EDU by postoffice.srv.cs.cmu.edu id aa29033; 20 Feb 2000 10:35 EST X-Sender: prs@postoffice.srv.cs.cmu.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sun, 20 Feb 2000 10:36:32 -0500 To: tccc@ieee.org, itc@ieee.org, int-serv@isi.edu, issll@mercury.lcs.mit.edu From: Peter Steenkiste Subject: Deadline IWQOS 2000 extended Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk The deadline for the International Workshop on Quality of Service has been extended until Saturday, Feb 26. However, we would like you to register you submission earlier. Please look at the conference web page http://www.cs.cmu.edu/~iwqos for details, Peter Steenkiste Hui Zhang > > *CALL FOR PAPERS* > > EIGHTH INTERNATIONAL WORKSHOP > on QUALITY of SERVICE (IWQoS) > > http://www.cs.cmu.edu/~iwqos/ > > June 5-7, 2000 > Westin William Penn Hotel > Pittsburgh, PA >SPONSORS: > - IEEE Communications Society and IFIP WG6.1 > - In Association with ACM SIGCOMM > >WORKSHOP THEME: > >This is the eighth of a series of workshops providing an international forum >for the exchange of information on quality of service (QoS) research in all >the facets of QoS in a networked or distributed environment, including >architectures, services, multimedia, operating systems and middleware. The >objective of the Eighth International Workshop on Quality of Service is to >bring together researchers, developers, and practitioners working in all >these areas to discuss recent innovative results and future directions. >Besides soliciting contributions in all areas of QoS research in distributed >systems and networking, we would like to place special emphasis this year on >papers reporting experience in developing and using applications that use >QoS-enabled systems. > >TOPICS (included, but are not limited to): > > * QoS Specification, Resource Allocation, (Re)negotiation, and Monitoring > * QoS and the Internet > * QoS Performance Modeling, Analysis and Evaluation > * Adaptive Applications and Services > * QoS Measurement, Management and Control > * QoS Support for Mobility and Wireless Networks > * Middleware Solutions for End-to-End QoS > * QoS Support for Information Appliances > * Storage Systems/Database Support for QoS > * Experimental Studies on QoS, including Human Perception > * QoS Programmability, Languages and Formal Method Techniques > * QoS Economics and Implications > >In the past the workshop has been cross-disciplinary, small and well focused, >with the emphasis on innovation. As a result, a considerable amount of time >is devoted to informal discussion. The programs of the previous workshops is >available online. > > *IMPORTANT DATES:* > > * Paper deadline: February 21, 2000 > * Notification: April 3, 2000 > * Final papers due: April 21 >______________ > >CO-CHAIRS: >Peter Steenkiste and Hui Zhang, Carnegie Mellon University > >IWQoS STEERING COMMITTEE: > >Andrew Campbell, Columbia University >Jon Crowcroft, UCL, London >Jan de Meer, GMD-FOKUS >Rich Friedrich, HP labs >Edward Knightly, Rice University >Klara Nahrstedt, University of Illinois > >PROGRAM COMMITTEE: > >Nina Bhatti, HP Labs >Ernst Biersack, Eurecom, France >Gordon Blair, University of Lancaster, UK >Jose Brustoloni, Bell Labs >Bruce Davies, Cisco >Hermann de Meer, UCL, London >Christopher Diot, Sprint Labs >Matthias Grossglauser, AT&T Research >Roch Guerin, University of Pennsylvania >Jorg Liebeherr, University of Virginia >Steve Low, University of Melbourne, Australia >Songwu Lu, UCLA >Qingming Ma, Cisco >Bernard Plattner, ETH Zurich, Switzerland >Ralph Steinmetz, University of Darmstadt, Germany >Steve Weinstein, NEC >Thomas Woo, Bell labs >John Wroclawski, MIT >Geoff Xie, Naval Postgraduate School >Lixia Zhang, UCLA >Gisli Hjalmtysson, AT&T Research > > > From owner-issll@mercury.lcs.mit.edu Wed Feb 23 18:47: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 SAA05243 for ; Wed, 23 Feb 2000 18:47:09 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA02310 for issll-outgoing; Wed, 23 Feb 2000 17:48:00 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA03729 for ; Wed, 23 Feb 2000 17:47:58 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA10887 for ; Wed, 23 Feb 2000 14:47:48 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Feb 2000 14:47:49 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B403E9@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: issll@mercury.lcs.mit.edu Subject: BW reservation over Diffserv using RSVP Date: Wed, 23 Feb 2000 14:45:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Hi, I know that the following draft by Yoram Bernet et-al: http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-03.txt addresses the usage of RSVP for dynamic Admission Control in a Diffserv cloud. Has anybody extended this operation for actually reserving BW over a Diffserv cloud. By reserving BW I mean adjusting/tuning the pre-configured (provisioned) BW in the RSVP path for each Diffserv Class? Thanks, Shahram From owner-issll@mercury.lcs.mit.edu Thu Feb 24 02:22: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 CAA23550 for ; Thu, 24 Feb 2000 02:22:15 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id BAA32559 for issll-outgoing; Thu, 24 Feb 2000 01:19:25 -0500 (EST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id BAA08025 for ; Thu, 24 Feb 2000 01:19:22 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 Feb 2000 22:12:58 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <198BNBJD>; Wed, 23 Feb 2000 22:12:58 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A60A5739DC@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: Shahram Davari , issll@mercury.lcs.mit.edu Subject: RE: BW reservation over Diffserv using RSVP Date: Wed, 23 Feb 2000 22:12:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk See Fred Baker and co-authors draft on aggregate rsvp, in the same working group. I think that it does what you mention. Y > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, February 23, 2000 2:45 PM > To: issll@mercury.lcs.mit.edu > Subject: BW reservation over Diffserv using RSVP > > > Hi, > > I know that the following draft by Yoram Bernet et-al: > > http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv- rsvp-03.txt addresses the usage of RSVP for dynamic Admission Control in a Diffserv cloud. Has anybody extended this operation for actually reserving BW over a Diffserv cloud. By reserving BW I mean adjusting/tuning the pre-configured (provisioned) BW in the RSVP path for each Diffserv Class? Thanks, Shahram From owner-issll@mercury.lcs.mit.edu Thu Feb 24 15:28:34 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 PAA09764 for ; Thu, 24 Feb 2000 15:28:33 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id OAA07547 for issll-outgoing; Thu, 24 Feb 2000 14:34:14 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id OAA02864 for ; Thu, 24 Feb 2000 14:34:12 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA10903; Thu, 24 Feb 2000 11:34:10 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Feb 2000 11:34:10 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B403F7@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: issll@mercury.lcs.mit.edu, "'fred@cisco.com'" Cc: Shahram Davari , "'Yoram Bernet'" Subject: RE: BW reservation over Diffserv using RSVP Date: Thu, 24 Feb 2000 11:31:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Hi Fred, I am trying to understand the BW reservation in a Diffserv network using RSVP. I have read your Aggregate RSVP draft and I have the following questions: 1) Do you require a two level hierarchical scheduling in the interior nodes (i.e., a level of scheduling before the class queues)? in other words do you require per-class queuing only (the same as Diffserv) or per-RSVP-aggregate queuing in addition to per-Class-queuing? in the former case all the Aggregate-RSVP BW requests passing through the same ingress and egress interfaces of a node (not necessarily following the same path), can be added together and a single queue (depending on the DSCP) be used for all of them, while in the latter case each RSVP-aggregate will reserve a separate BW and the packets of that flow don't share the same queue (very much like Intserv or ATM VC scheduling). 2) You mention that it is better to use different PHBs for the BW signaled flows (using aggregate RSVP). Can we use the same PHB for both provisioned and signaled traffic, but use the RSVP-aggregate signaling to fine tune the provisioned BW assignments to Diffserv classes in interior nodes? Thanks, - Shahram > -----Original Message----- > From: Yoram Bernet [mailto:yoramb@exchange.microsoft.com] > Sent: Thursday, February 24, 2000 1:13 AM > To: Shahram Davari; issll@mercury.lcs.mit.edu > Subject: RE: BW reservation over Diffserv using RSVP > > > See Fred Baker and co-authors draft on aggregate rsvp, in the > same working > group. I think that it does what you mention. > > Y > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, February 23, 2000 2:45 PM > > To: issll@mercury.lcs.mit.edu > > Subject: BW reservation over Diffserv using RSVP > > > > > > Hi, > > > > I know that the following draft by Yoram Bernet et-al: > > > > http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv- > rsvp-03.txt > > addresses the usage of RSVP for dynamic Admission Control in > a Diffserv > cloud. Has anybody extended this operation for actually > reserving BW over a > Diffserv cloud. By reserving BW I mean adjusting/tuning the > pre-configured > (provisioned) BW in the RSVP path for each Diffserv Class? > > Thanks, > Shahram > From owner-issll@mercury.lcs.mit.edu Fri Feb 25 17:24: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 RAA22342 for ; Fri, 25 Feb 2000 17:24:27 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA13085 for issll-outgoing; Fri, 25 Feb 2000 16:14:57 -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 QAA15318 for ; Fri, 25 Feb 2000 16:14:54 -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 QAA14295; Fri, 25 Feb 2000 16:14:48 -0500 (EST) Received: from blatz.bbn.com (localhost [127.0.0.1]) by blatz.bbn.com (8.8.8+Sun/8.8.5) with ESMTP id QAA17829; Fri, 25 Feb 2000 16:14:48 -0500 (EST) Message-Id: <200002252114.QAA17829@blatz.bbn.com> To: tccc@ieee.org, itc@ieee.org, int-serv@isi.edu, issll@mercury.lcs.mit.edu Subject: ECOOP 2000: Workshop on QoS in Distributed Systems Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Fri, 25 Feb 2000 16:14:48 -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 --AhhlLboLdkugWU4S-- From owner-issll@mercury.lcs.mit.edu Mon Feb 28 10:46: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 KAA12166 for ; Mon, 28 Feb 2000 10:46:24 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA14460 for issll-outgoing; Mon, 28 Feb 2000 09:43:53 -0500 (EST) Received: from nausicaa.coritel.it ([193.205.242.5]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA18894 for ; Mon, 28 Feb 2000 09:43:40 -0500 (EST) Received: from coritel.it (fermat.coritel.it [193.205.242.41]) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id PAA06452; Mon, 28 Feb 2000 15:40:24 +0100 (MET) Message-ID: <38BA897A.71A50B4A@coritel.it> Date: Mon, 28 Feb 2000 15:43:07 +0100 From: Roberto Mameli Organization: CoRiTeL X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: issll CC: Stefano Salsano , Roberto Mameli Subject: Three new IDs submitted... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, we have submitted three ID related to the Intserv operation over Diffserv network. Basically they propose a scenario where dynamic allocation in the Diffserv network is performed by means of a "Bandwidth Broker". The COPS protocol is used to support the communication between the Edge Router and the Bandwidth Broker. The first draft proposes the COPS extension to support Outsourcing Diffserv Resource Allocation, defining a COPS-ODRA client type; the second draft describes the interaction between RSVP and COPS in the Edge Router; the third draft proposes an API to interact with the COPS client (in our case the API is used by the RSVP daemon). We are in the process of implementing the proposed solution. We have implemented the COPS-ODRA client side and server side. We are modifying the RSVP daemon for the interaction with COPS client. We already have implemented a mapping of RSVP to Diffserv on the data plane. You can ask for further details... We would like to hear comments... do you think this work can be of interest of the issll working group ? Please find below the abstract of the drafts... COPS Usage for Outsourcing Diffserv Resource Allocation This document introduces a new client type for the COPS protocol to support dynamic DiffServ admission control. The Policy Decision Point (PDP) acts as a "Bandwidth Broker" for the Policy Enforcement Point (PEP) which is requesting resources. The use of the defined mechanism is suited for (but it is not limited to) the Integrated Services operation over Diffserv networks. http://www.ietf.org/internet-drafts/draft-salsano-issll-cops-odra-00.txt Integrated services over DiffServ network using COPS-ODRA http://www.ietf.org/internet-drafts/draft-mameli-issll-is-ds-cops-00.txt http://www.ietf.org/internet-drafts/draft-mameli-issll-cops-api-00.txt -- Roberto Mameli CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni EMAIL : mameli@coritel.it URL : http://www.coritel.it TEL : +39-06-20410038 ADDRESS : Via di Tor Vergata, 135 FAX : +39-06-20410037 00133 Roma - ITALY From owner-issll@mercury.lcs.mit.edu Mon Feb 28 10:49: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 KAA12228 for ; Mon, 28 Feb 2000 10:49:23 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA07068 for issll-outgoing; Mon, 28 Feb 2000 09:49:24 -0500 (EST) Received: from nausicaa.coritel.it ([193.205.242.5]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA13607 for ; Mon, 28 Feb 2000 09:49:15 -0500 (EST) Received: from coritel.it (fermat.coritel.it [193.205.242.41]) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id PAA06490; Mon, 28 Feb 2000 15:46:29 +0100 (MET) Message-ID: <38BA8AE8.44C5AA9E@coritel.it> Date: Mon, 28 Feb 2000 15:49:12 +0100 From: Roberto Mameli Organization: CoRiTeL X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: issll CC: Stefano Salsano , Roberto Mameli Subject: Three new IDs submitted (correct) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, the previous message was not complete... Dear all, we have submitted three ID related to the Intserv operation over Diffserv network. Basically they propose a scenario where dynamic allocation in the Diffserv network is performed by means of a "Bandwidth Broker". The COPS protocol is used to support the communication between the Edge Router and the Bandwidth Broker. The first draft proposes the COPS extension to support Outsourcing Diffserv Resource Allocation, defining a COPS-ODRA client type; the second draft describes the interaction between RSVP and COPS in the Edge Router; the third draft proposes an API to interact with the COPS client (in our case the API is used by the RSVP daemon). We are in the process of implementing the proposed solution. We have implemented the COPS-ODRA client side and server side. We are modifying the RSVP daemon for the interaction with COPS client. We already have implemented a mapping of RSVP to Diffserv on the data plane. You can ask for further details... We would like to hear comments... do you think this work can be of interest of the issll working group ? Please find below the abstract of the drafts... Best regards Stefano Salsano Roberto Mameli COPS Usage for Outsourcing Diffserv Resource Allocation This document introduces a new client type for the COPS protocol to support dynamic DiffServ admission control. The Policy Decision Point (PDP) acts as a "Bandwidth Broker" for the Policy Enforcement Point (PEP) which is requesting resources. The use of the defined mechanism is suited for (but it is not limited to) the Integrated Services operation over Diffserv networks. http://www.ietf.org/internet-drafts/draft-salsano-issll-cops-odra-00.txt Integrated services over DiffServ network using COPS-ODRA This document details the IntServ operation over a DiffServ network in the case of dynamic admission control procedure supported by the COPS protocol. An RSVP aware Edge Router uses the COPS protocol in order to query a Bandwidth Broker, which manages the resources within the DiffServ domain. This document relies on the COPS extensions proposed in the companion draft "COPS usage for Outsourcing DiffServ Resource Allocation" [COPS-ODRA]. http://www.ietf.org/internet-drafts/draft-mameli-issll-is-ds-cops-00.txt The CCAPI (COPS Client Application Programming Interface) This document focuses on the Admission Control functionality performed by the Edge Router in the IntServ/DiffServ interworking scenario described in [COPS-ISDS]. More precisely it describes the interaction between the RSVP and the COPS protocols in the Edge Router and introduces an API (Application Programming Interface) aimed at allowing the intercommunication between them. Anyway, the API described here is designed as a flexible interface, and should be able to support communication between a generic application and the COPS Client Type described in [COPS-ODRA]. http://www.ietf.org/internet-drafts/draft-mameli-issll-cops-api-00.txt From owner-issll@mercury.lcs.mit.edu Mon Feb 28 16:34:35 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 QAA20522 for ; Mon, 28 Feb 2000 16:34:34 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id PAA21043 for issll-outgoing; Mon, 28 Feb 2000 15:37:42 -0500 (EST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id PAA14257 for ; Mon, 28 Feb 2000 15:37:40 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id NAA19261; Mon, 28 Feb 2000 13:00:29 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id MAA28725; Mon, 28 Feb 2000 12:42:17 -0800 Message-Id: <4.1.20000228122642.03752670@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 28 Feb 2000 12:37:02 -0800 To: Shahram Davari From: Fred Baker Subject: RE: BW reservation over Diffserv using RSVP Cc: issll@mercury.lcs.mit.edu In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B403F7@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk At 11:31 AM 2/24/00 -0800, Shahram Davari wrote: >1) Do you require a two level hierarchical scheduling in the interior nodes >(i.e., a level of scheduling before the class queues)? I don't require anything in particular in the queuing. The question is "can we reserve bandwidth for a stream of traffic marked with a given code point", and the answer is "yes". That's not to say that fancy queuing might not be useful. But at most what is required is that the queuing support the reservation by giving the needed bandwidth to the class of traffic, and that it conform to the controlled load specification. >2) You mention that it is better to use different PHBs for the BW signaled >flows (using aggregate RSVP). Can we use the same PHB for both provisioned >and signaled traffic, but use the RSVP-aggregate signaling to fine tune the >provisioned BW assignments to Diffserv classes in interior nodes? I think you mixed some concepts there. To me, a DSCP is something one uses to identify traffic, a PHB is a document that describes what you will do with traffic that is so marked, and various other configurations are required to implement the PHB. Can you use the same PHB for different classes of traffic? Yes, absolutely. But you cannot mark them the same. If they are different classes of traffic, to differentiate them, you need differing DSCPs. To accomplish literally what you said, I think you provision the network to believe that there needs to be some amount of provisioned capacity between given ingress and egress points, and you set up reservations for that amount. Signalled traffic might increase those provisions. So you could certainly write a policy that achieved that.