From owner-issll@mercury.lcs.mit.edu Mon Apr 2 08:06:06 2001 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03506 for ; Mon, 2 Apr 2001 08:06:05 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id HAA02724 for issll-outgoing; Mon, 2 Apr 2001 07:05:51 -0400 (EDT) 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 HAA02722 for ; Mon, 2 Apr 2001 07:05:48 -0400 (EDT) Received: from jack (drum.unile.it [193.204.77.151]) by ultra5.unile.it (8.9.1b+Sun/8.9.1) with SMTP id NAA17128; Mon, 2 Apr 2001 13:03:46 +0100 (WET DST) Message-ID: <010e01c0bb64$889a2120$974dccc1@unile.it> Reply-To: "Simone Molendini" From: "Simone Molendini" To: "Kuthonuzo Luruo" Cc: "issll_list" , "Franco Tommasi" , "Andrea Tricco" References: Subject: Re: MPLS and Aggregated RSVP for Intserv/Diffserv Date: Mon, 2 Apr 2001 13:03:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id HAA02724 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03506 Hi, Other interesting relations between RSVP/intServ and MPLS/CR-LDP are discussed in a new draft announced on Friday: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Integrated Services across MPLS domains using CR-LDP > signaling > Author(s) : F. Tommasi, S. Molendini, A. Tricco > Filename : draft-tommasi-mpls-intserv-00.txt > Pages : 26 > Date : 29-Mar-01 Best regards, Simone Molendini ----- Original Message ----- From: Kuthonuzo Luruo To: Cc: Shashank R Khanvilkar Sent: giovedì 29 marzo 2001 1.24 Subject: MPLS and Aggregated RSVP for Intserv/Diffserv > RFC 2998 from the ISSLL mentions MPLS (exactly once, almost in passing) as > one of the mechanisms [other examples being aggregated RSVP, per-flow > RSVP] by which an efficient and dynamic provisioning of resources in a > Diffserv network region may be done. > > noting that draft-ietf-mpls-diff-ext-08.txt in MPLS WG specifies "MPLS > Support of Differentiated Services", I'm interested in learning what are > the merits/demerits of using MPLS Versus Aggregated RSVP for the > Intserv/Diffserv interoperation. has this been thrashed out sometime in > the ISSLL? [if it was, i can't find anything abt it in the mail archives] > > thanks. > > -thonuzo > > > > From owner-issll@mercury.lcs.mit.edu Thu Apr 5 07:44:01 2001 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28258 for ; Thu, 5 Apr 2001 07:44:00 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA31193 for issll-outgoing; Thu, 5 Apr 2001 06:41:34 -0400 (EDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id GAA31205 for ; Thu, 5 Apr 2001 06:41:30 -0400 (EDT) Message-Id: <200104051041.GAA31205@mercury.lcs.mit.edu> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:02:57 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 11:00:28 +0200 Content-Transfer-Encoding: 8bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From owner-issll@mercury.lcs.mit.edu Thu Apr 5 13:23:16 2001 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08845 for ; Thu, 5 Apr 2001 13:23:14 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id MAA00737 for issll-outgoing; Thu, 5 Apr 2001 12:05:03 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id MAA00742 for ; Thu, 5 Apr 2001 12:04:58 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29064; Thu, 5 Apr 2001 09:03:24 -0700 (PDT) Message-Id: <5.0.2.1.2.20010405084417.046b10f0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 08:44:29 -0700 To: mankin@east.isi.edu From: Fred Baker Subject: Re: RSVP Aggregation - cleanup of IANA considerations needed Cc: bsd@cisco.com, jtw@lcs.mit.edu, esc@argon.com, sob@harvard.edu, issll@mercury.lcs.mit.edu In-Reply-To: <10103281315.AA12734@maia.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk At 08:15 AM 3/28/2001 -0500, Allison Mankin wrote: >But the draft needs one further rev because the IANA has asked us to have >the IANA considerations written out explicitly. By this mail, I ask the >document's editor to do so and submit a new i-d. OK, we'll get a new paragraph in there. From owner-issll@mercury.lcs.mit.edu Thu Apr 5 15:51:54 2001 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12643 for ; Thu, 5 Apr 2001 15:51:51 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id NAA01254 for issll-outgoing; Thu, 5 Apr 2001 13:04:42 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id NAA01250 for ; Thu, 5 Apr 2001 13:04:38 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA13752; Thu, 5 Apr 2001 10:03:23 -0700 (PDT) Message-Id: <5.0.2.1.2.20010405084446.046abc18@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 08:59:08 -0700 To: bsd@cisco.com From: Fred Baker Subject: Re: RSVP Aggregation - cleanup of IANA considerations needed Cc: mankin@east.isi.edu, jtw@lcs.mit.edu, esc@argon.com, sob@harvard.edu, issll@mercury.lcs.mit.edu, cei@cisco.com, Francois Le Faucheur In-Reply-To: <10103281315.AA12734@maia.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk At 08:15 AM 3/28/2001 -0500, Allison Mankin wrote: > > 6. IANA Considerations > > > > Beyond allocating an IP Protocol, a PathErr code, a set of > > values for the IPv6 router alert option, and an RSVP > > Addressing object "type", there are no IANA issues in this > > document. We do not define an object that will itself require > > assignment by IANA. Bruce - I think you're the guy with the most up to date draft text. Here is some proposed text: .nh 1 "IANA Considerations" .lp Section 1.2 proposes a new protocol type, RSVP-E2E-IGNORE, which is used to identify a message which routers in the network core will see and must evaluate the egress interface type to determine what they must do with. Section 1.4.9 describes the manner in which the Router Alert is used in the context of this specification, which is essentially an algorithmic numeration of the number of aggregation nesting levels it is passed. RFC 2113, the IPv4 Router Alert, has the option simply ask the router to look at the protocol type of the intercepted datagram and decide what to do with it; the parameter is additional information to that decision. RFC 2711, the IPv6 Router Alert, turns the parameter into an option sub-type. As a result, the IPv6 router alert option may not be used algorithmically in the context of the protocol in question. We therefore request IANA to assign a block of 32 values which we may map to nesting depths 0..31, hoping that 32 levels is enough. Since RFC 2711 assigns the values 0, 1, and 2, we suggest that these values occupy the range 3..35. Section 3.2 discusses a path error code NEW-AGGREGATE-NEEDED, to be assigned. Sections 3.3, 3.4, and 35 describe extensions to three object classes: Session, Filter Specification, and Sender Template. These require two common C-Types to be specified for the aggregator's address, which we call the RSVP-AGGREGATE-IP4 and RSVP-AGGREGATE-IP6. The same number should be used for all three objects, as is done for IPv4 and IPv6 address tuples in RFC 2205. From owner-issll@mercury.lcs.mit.edu Fri Apr 6 18:49:32 2001 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22507 for ; Fri, 6 Apr 2001 18:49:17 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA11051 for issll-outgoing; Fri, 6 Apr 2001 17:40:49 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA10847 for ; Fri, 6 Apr 2001 17:40:44 -0400 (EDT) Received: from lax.isi.edu (lax.isi.edu [128.9.144.88]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f36LeXq13442; Fri, 6 Apr 2001 14:40:33 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by lax.isi.edu (8.8.7/8.8.6) id OAA00494; Fri, 6 Apr 2001 14:40:32 -0700 (PDT) Date: Fri, 6 Apr 2001 14:40:32 -0700 (PDT) Message-Id: <200104062140.OAA00494@lax.isi.edu> To: bsd@cisco.com, fred@cisco.com Subject: Re: RSVP Aggregation - cleanup of IANA considerations needed Cc: mankin@isi.edu, jtw@lcs.mit.edu, esc@argon.com, sob@harvard.edu, issll@mercury.lcs.mit.edu, cei@cisco.com, flefauch@cisco.com X-Sun-Charset: US-ASCII Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk I don't think this is the right model for an IANA Considerations section. When an RFC assigns particular values to existing parameter series, it just does it. The RFC Editor and IANA make it right. The IANA Considerations section is used (only) when an RFC defines a NEW parameter series, and exists to program the IANA on how to assign FUTURE values in that series. Apologies if I am misunderstanding... Bob From owner-issll@mercury.lcs.mit.edu Fri Apr 6 18:49:37 2001 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22519 for ; Fri, 6 Apr 2001 18:49:24 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA11128 for issll-outgoing; Fri, 6 Apr 2001 17:53:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA11146 for ; Fri, 6 Apr 2001 17:53:08 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA14050; Fri, 6 Apr 2001 14:52:09 -0700 (PDT) Message-Id: <5.0.2.1.2.20010406144621.02e2ab58@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 14:47:11 -0700 To: Bob Braden From: Fred Baker Subject: Re: RSVP Aggregation - cleanup of IANA considerations needed Cc: bsd@cisco.com, mankin@isi.edu, jtw@lcs.mit.edu, esc@argon.com, sob@harvard.edu, issll@mercury.lcs.mit.edu, cei@cisco.com, flefauch@cisco.com In-Reply-To: <200104062140.OAA00494@lax.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk At 02:40 PM 4/6/2001 -0700, Bob Braden wrote: >I don't think this is the right model for an IANA Considerations >section. When an RFC assigns particular values to existing >parameter series, it just does it. The RFC Editor and IANA >make it right. The IANA Considerations section is used (only) >when an RFC defines a NEW parameter series, and exists to program >the IANA on how to assign FUTURE values in that series. well, we changed it as instructed, to make IANA/RFC Editor happy. Could you suggest text that would make you happier? From owner-issll@mercury.lcs.mit.edu Sat Apr 7 18:42:03 2001 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18462 for ; Sat, 7 Apr 2001 18:42:02 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id PAA16599 for issll-outgoing; Sat, 7 Apr 2001 15:39:18 -0400 (EDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id PAA16550 for ; Sat, 7 Apr 2001 15:39:15 -0400 (EDT) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id PAA19361; Sat, 7 Apr 2001 15:39:06 -0400 (EDT) Posted-Date: Sat, 07 Apr 2001 15:43:51 -0400 Message-Id: <10104071943.AA29185@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Sat, 7 Apr 01 15:43:52 EDT To: Bob Braden Cc: bsd@cisco.com, fred@cisco.com, jtw@lcs.mit.edu, esc@argon.com, sob@harvard.edu, issll@mercury.lcs.mit.edu, cei@cisco.com, flefauch@cisco.com, iana@iana.org Reply-To: mankin@isi.edu Subject: Re: RSVP Aggregation - cleanup of IANA considerations needed In-Reply-To: Your message of Fri, 06 Apr 2001 14:40:32 -0700. <200104062140.OAA00494@lax.isi.edu> Date: Sat, 07 Apr 2001 15:43:51 -0400 From: Allison Mankin Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk > I don't think this is the right model for an IANA Considerations > section. When an RFC assigns particular values to existing > parameter series, it just does it. The RFC Editor and IANA > make it right. The IANA Considerations section is used (only) > when an RFC defines a NEW parameter series, and exists to program > the IANA on how to assign FUTURE values in that series. > > Apologies if I am misunderstanding... Bob, IANA asked IESG to make the IANA Considerations in this draft point out what section each IANA action was in, and to be explicit about the requests made. The concern was serious enough for the fixes to be the obstacle for transmitting the doc to the RFC Editor (it has passed IESG for PS except for this). IESG now gets guidance from IANA directly on every document we pass to standards track. My understanding is that new/revised specs: 1. always include IANA Considerations 2. give explicit instructions in that section, even if it is just to point back to the text, not only for forming new registries I think a side benefit of this is for education: spec writers (the Internet authorship group has become very large), WG chairs, even we IESG who may forget things (as well as coming in new) find instruction in each spec about how IANA protocol number registrations work and are used. I've added IANA to the cc list, and they should feel free to speak up if I've misstated... I hope the ISSLL WG (I've left the WG cc'd) isn't saying "sheesh, what does this have to do with ISSLL?", even though it's about a WG doc. Allison From owner-issll@mercury.lcs.mit.edu Tue Apr 10 08:13:51 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12726 for ; Tue, 10 Apr 2001 08:13:50 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id HAA01751 for issll-outgoing; Tue, 10 Apr 2001 07:05:13 -0400 (EDT) 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 HAA01771 for ; Tue, 10 Apr 2001 07:05:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10874; Tue, 10 Apr 2001 07:04:30 -0400 (EDT) Message-Id: <200104101104.HAA10874@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-04.txt Date: Tue, 10 Apr 2001 07:04:30 -0400 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, C. Iturralde, F. Le Faucheur, B. Davie Filename : draft-ietf-issll-rsvp-aggr-04.txt Pages : 41 Date : 09-Apr-01 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-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-rsvp-aggr-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-rsvp-aggr-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: <20010409100744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-issll-rsvp-aggr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-issll-rsvp-aggr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010409100744.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-issll@mercury.lcs.mit.edu Tue Apr 10 17:51:01 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26813 for ; Tue, 10 Apr 2001 17:51:00 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA07478 for issll-outgoing; Tue, 10 Apr 2001 16:37:42 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id QAA07518 for ; Tue, 10 Apr 2001 16:37:40 -0400 (EDT) Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa00743; 10 Apr 2001 16:34 EDT Date: Tue, 10 Apr 2001 16:34:11 -0400 (EDT) From: Constantinos Dovrolis To: Constantinos Dovrolis Subject: ICNP 2001 - CFP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk -------------------------------------------------------------------------- CALL FOR PAPERS -------------------------------------------------------------------------- 9th International Conference on Network Protocols (ICNP 2001) Mission Inn, Riverside, California November 11-14, 2001 http://www.cis.udel.edu/icnp2001/ In just eight years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, and implementation. Protocol functions of interest include network access, switching, routing, flow and congestion control, multimedia transport, wireless and mobile networks, network security, web protocols and applications, electronic commerce, network management, interoperability, internetworking, home computing and networks and digital broadcasting. ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place filled with history. Riverside is located in the Sunny Southern California, 60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from Disney Land. The city is served by three nearby airports: Los Angeles, Ontario (California) and Orange County Airport. Topics of interest include, but are not limited to: - network access - switching - routing - flow and congestion control - multimedia transport protocols - wireless and mobile networks - network security - web protocols and applications - electronic commerce - network management - interoperability, internetworking - home computing and networking - digital broadcasting - QoS and service differentiation - network measurements - protocols for distributed games - peer-to-peer communication protocols Important Dates: Paper Submission Deadline: May 7, 2001 Tutorial Submission Deadline: May 7, 2001 Notification of Acceptance: July 13, 2001 Camera Ready Due: August 8, 2001 Tutorials: November 11, 2001 Conference: November 12 - 14, 2001 Information for authors: Papers must be written in English, and they have to be in Postscript, PDF, or Word format. The complete manuscript should be no more than 12 pages of double-spaced text with 11pt fonts. If you have any questions, you can contact us at icnp@ics.uci.edu. To register and submit your paper, visit the URL: http://violin.ics.uci.edu/~icnp/ConfMan/REG-paper/ General Chair Satish K. Tripathi, University of California - Riverside Technical Program Co-Chairs Magda El Zarki, University of California, Irvine Klara Narhstedt, University of Illinois, Urbana-Champaign Tutorial Co-Chairs Pravin Bhagwat, ReefEdge, Inc Ed Knightly, Rice University Local Arrangement and Registration Co-Chairs Michalis Faloutsos, University of California - Riverside Srikant Krishnamurthy, University of California - Riverside Publicity Co-Chairs Constantinos Dovrolis, University of Delaware Samar Singh, La Trobe University, Australia Technical Program Committee Alex Petrenko (CRIM, Computer Research Institute of Montreal) Ana Rosa CAVALLI (Institut National des Telecommunications, France) Mart, Molle (University of California, Riverside) Andrew T. Campbell (Columbia University) Bobby Bhattacharjee (University of Maryland) Christophe Diot (Sprint) Cormac J. Sreenan (University College, Cork, Ireland) David Hutchison (Lancaster University) David Su (National Institute of Standards and Technology) David, Yau (Computer Science, Purdue University) Edward Knightly (Rice University ) Ellen L. Hahne (AT&T Labs - Research) Geert Heijenk (Ericsson) Gene Tsudik (UC, Irvine) Geoffrey Xie (Naval Postgraduate School) Ernst W. Biersack (Institut EURECOM) Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden) Hartmut Koenig (BTU Cottbus, Germany Hasan Ural (University of Ottawa, Canada) Ibrahim Matta (Boston University) Jennifer Hou (Ohio State University) Jorg Lieberherr (University of Virginia) Jorge Cobb (The University of Texas at Dallas) Ken Calvert (University of Kentucky) Kevin Almeroth (UC-Santa Barbara) Kirshna Sivalingam (Washington State University / Jasmine Networks) Lars Wolf (University of Karlsruhe, Germany) Lixia Zhang (UCLA) Ljiljana Trajkovic (Simon Fraser University) Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY)) Marco Schneider (SBC Technology Resources Inc.) Martha Steenstrup (Stow Research L.L.C.) Martina Zittterbart (University of Karlsruhe, Germany) Masayuki Murata (Osaka University, Japan) Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.) Mohamed G. Gouda (University of Texas at Austin) Nalini Venkatasubramanian (University of California, Irvine) Chris Edmondson-Yurkanan (University of Texas) Ness B. Shroff (Purdue University) Nina Bhatti (Nokia) Robin Kravets (University of Illinois at Urbana-Champaign) Shigang Chen (Cisco Systems) Songwu Lu (UCLA) Stanislaw Budkowski (Institut National des Telecommunications (INT), France) Terry Todd (McMaster University, Canada) Teruo Higashino (Osaka University, Japan) Timothy Roscoe (Sprint Advanced Technology Labs) William Tezlaff (IBM T. J. Watson Research Center) Yoshiaki Kakuda (Hiroshima City University, Japan) Yow-Jian Lin (Bell Labs Research, Lucent Technologies) Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel) ICNP Steering Committee Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs From owner-issll@mercury.lcs.mit.edu Thu Apr 12 00:21:25 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09563 for ; Thu, 12 Apr 2001 00:21:22 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id XAA18843 for issll-outgoing; Wed, 11 Apr 2001 23:05:49 -0400 (EDT) Received: from pollen.cs.concordia.ca (root@pollen.cs.concordia.ca [132.205.44.61]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id XAA17595 for ; Wed, 11 Apr 2001 23:05:48 -0400 (EDT) Received: from cs.concordia.ca (yqshi@antlion [132.205.45.76]) by pollen.cs.concordia.ca (8.8.8/8.8.8) with ESMTP id XAA00884 for ; Wed, 11 Apr 2001 23:05:50 -0400 (EDT) Message-ID: <3AD51B8E.8C95A008@cs.concordia.ca> Date: Wed, 11 Apr 2001 23:05:50 -0400 From: "Yiqun(Steven) Shi" X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: zh,zh-CN,zh-TW MIME-Version: 1.0 To: issll@mercury.lcs.mit.edu Subject: question about RFC2998 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In the chapter: '4.2.3 Per-flow RSVP', the mechanism supporting per flow signaling in DiffServ region, which should be described in referece: [3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated Services State", Work in Progress. seems under developing. But there was an internet draft 'draft-berson-rsvp-aggregation-00.txt' previous to above reference. Could anybody tell me where I can get it, or where I can find the trace of this issue going? Thanks. Yiqun From owner-issll@mercury.lcs.mit.edu Thu Apr 12 21:40:22 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15689 for ; Thu, 12 Apr 2001 21:40:21 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA25503 for issll-outgoing; Thu, 12 Apr 2001 18:26:52 -0400 (EDT) Received: from web12703.mail.yahoo.com (web12703.mail.yahoo.com [216.136.173.240]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id SAA25542 for ; Thu, 12 Apr 2001 18:26:50 -0400 (EDT) Message-ID: <20010412222642.75283.qmail@web12703.mail.yahoo.com> Received: from [132.205.45.76] by web12703.mail.yahoo.com; Thu, 12 Apr 2001 15:26:42 PDT Date: Thu, 12 Apr 2001 15:26:42 -0700 (PDT) From: Steven Shi Subject: How does RSVP dynamically provision resources in DS region? To: issll@mercury.lcs.mit.edu, diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk My question is about e2e QoS reservation which is in a manner of per flow reservation(not aggregate RSVP)in DS region. When the RSVP messages go through DS region to collect the information of the availability of resource in DS region, how does the DS region treat them: 1. Is the Adspec in sender PATH message updated by the RSVP awared nodes in DS region? If it is, how can DS region interpret the meaning of Adspec since Adspec is defined for IntServ? 2. Or the updating of Adspec can be ONLY done at border router of DS region? If there is any statement of my question, what is that? Regrads, Steven __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-issll@mercury.lcs.mit.edu Fri Apr 13 05:15:12 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03871 for ; Fri, 13 Apr 2001 05:15:11 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id EAA30656 for issll-outgoing; Fri, 13 Apr 2001 04:05:13 -0400 (EDT) Received: from hotmail.com (f81.law9.hotmail.com [64.4.9.81]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id EAA30391 for ; Fri, 13 Apr 2001 04:05:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 Apr 2001 01:04:40 -0700 Received: from 66.24.36.162 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 13 Apr 2001 08:04:40 GMT X-Originating-IP: [66.24.36.162] From: "Mike Badil" To: stevenbj2001@yahoo.com, issll@mercury.lcs.mit.edu, diffserv@ietf.org Subject: Re: [Diffserv] How does RSVP dynamically provision resources in DS region? Date: Fri, 13 Apr 2001 04:04:40 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Apr 2001 08:04:40.0859 (UTC) FILETIME=[644B2EB0:01C0C3F0] Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Steven, As far as I know there is no reservation protocol for diffserv yet and RSVP is not suitable, therefore it is not being used. Thus, diffserv does not provide reliable e2e QoS at this moment. Another important point is per-flow requests does not go beyond edges, when a customer requests a service, the request is handled in edge. For more information look at: rfc2998 >My question is about e2e QoS reservation which is in a >manner of per flow reservation(not aggregate RSVP)in >DS region. When the RSVP messages go through DS region >to collect the information of the availability of >resource in DS region, how does the DS region treat >them: > >1. Is the Adspec in sender PATH message updated by the >RSVP awared nodes in DS region? If it is, how can DS >region interpret the meaning of Adspec since Adspec is >defined for IntServ? > >2. Or the updating of Adspec can be ONLY done at >border router of DS region? > >If there is any statement of my question, what is >that? > >Regrads, > >Steven > > > > > >__________________________________________________ >Do You Yahoo!? >Get email at your own domain with Yahoo! Mail. >http://personal.mail.yahoo.com/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-issll@mercury.lcs.mit.edu Fri Apr 13 10:52:27 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09894 for ; Fri, 13 Apr 2001 10:52:27 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA31593 for issll-outgoing; Fri, 13 Apr 2001 09:26:21 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA32014 for ; Fri, 13 Apr 2001 09:26:16 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA58770; Fri, 13 Apr 2001 06:25:14 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA25122; Fri, 13 Apr 2001 06:25:16 -0700 Message-ID: <3AD6FE0F.EFA23EC3@hursley.ibm.com> Date: Fri, 13 Apr 2001 08:24:31 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mike Badil CC: stevenbj2001@yahoo.com, issll@mercury.lcs.mit.edu, diffserv@ietf.org Subject: Re: [Diffserv] How does RSVP dynamically provision resources in DS region? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In any case... this is a topic for the ISSLL WG alone, not diffserv. Diffserv's charter specifically excludes signalling. If you want to continue this thread, please drop diffserv from the CC: list Regards Brian Carpenter diffserv co-chair Mike Badil wrote: > > Steven, > > As far as I know there is no reservation protocol for diffserv yet and RSVP > is not suitable, therefore it is not being used. Thus, diffserv does not > provide reliable e2e QoS at this moment. > > Another important point is per-flow requests does not go beyond edges, when > a customer requests a service, the request is handled in edge. > > For more information look at: rfc2998 > > >My question is about e2e QoS reservation which is in a > >manner of per flow reservation(not aggregate RSVP)in > >DS region. When the RSVP messages go through DS region > >to collect the information of the availability of > >resource in DS region, how does the DS region treat > >them: > > > >1. Is the Adspec in sender PATH message updated by the > >RSVP awared nodes in DS region? If it is, how can DS > >region interpret the meaning of Adspec since Adspec is > >defined for IntServ? > > > >2. Or the updating of Adspec can be ONLY done at > >border router of DS region? > > > >If there is any statement of my question, what is > >that? > > > >Regrads, > > > >Steven > > From owner-issll@mercury.lcs.mit.edu Fri Apr 13 17:44:56 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19105 for ; Fri, 13 Apr 2001 17:44:55 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA02555 for issll-outgoing; Fri, 13 Apr 2001 16:28:15 -0400 (EDT) Received: from mail.eecs.uic.edu (mail.eecs.uic.edu [131.193.32.27]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA02748 for ; Fri, 13 Apr 2001 16:28:11 -0400 (EDT) Received: from grover.eecs.uic.edu (grover.eecs.uic.edu [131.193.40.35]) by mail.eecs.uic.edu (8.9.3/8.9.3) with ESMTP id PAA26911 for ; Fri, 13 Apr 2001 15:27:13 -0500 (CDT) Received: from localhost by grover.eecs.uic.edu (8.9.3/8.9.3) with ESMTP id PAA20968 for ; Fri, 13 Apr 2001 15:28:17 -0500 (CDT) X-Authentication-Warning: grover.eecs.uic.edu: kluruo owned process doing -bs Date: Fri, 13 Apr 2001 15:28:17 -0500 (CDT) From: Kuthonuzo Luruo To: issll@mercury.lcs.mit.edu Subject: Motivation for Intserv/Diffserv interoperation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk hi, My initial perception of the motivation for Intserv/diffserv interworking was that the mathematically bound QoS guarantees associated with Intserv, when combined with Diffserv would bring better QoS performance to the end-users than when Diffserv alone, with its less strict QoS guarantees is used. Thus from this viewpoint, given a number of network elements, the more number of Intserv network elements you have in the end-to-end path the better would be the QoS performance. However, from RFC 2998 + other documents on the web, I've come to the conclusion that the main motivation for using Intserv with Diffserv is the signalling control and end-to-end semantics that RSVP/Intserv brings to the local behavior definition inclination of Diffserv. The first three of the four benefits mentioned in Section 2 of RFC 2998: *Resource Based Admission Control *Policy Based Admission Control *Assistance in Traffic Identification/Classifica *Traffic Conditioning seem to support this. Can I conclude that my initial perception was wrong and the second viewpoint is more in line with the IETF sentiment? thanks for any inputs. -thonuzo From owner-issll@mercury.lcs.mit.edu Sat Apr 14 00:18:33 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25049 for ; Sat, 14 Apr 2001 00:18:32 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id XAA05277 for issll-outgoing; Fri, 13 Apr 2001 23:15:36 -0400 (EDT) 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 XAA05429 for ; Fri, 13 Apr 2001 23:15:29 -0400 (EDT) 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 XAA08882; Fri, 13 Apr 2001 23:18:15 -0400 (EDT) Received: from blatz (localhost [127.0.0.1]) by blatz.bbn.com (8.8.5/8.8.5) with ESMTP id XAA08404; Fri, 13 Apr 2001 23:15:23 -0400 (EDT) Message-Id: <200104140315.XAA08404@blatz.bbn.com> To: issll@mercury.lcs.mit.edu, KUVS-L@RELAY.URZ.UNI-HEIDELBERG.DE, Cabernet Events Subject: 2nd Workshop on Quality of Service in Distributed Object Systems Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Fri, 13 Apr 2001 23:15:23 -0400 From: "John A. Zinky" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Final Call for Papers 2nd Workshop on Quality of Service in Distributed Object Systems Workshop #2 at ECOOP 2001 http://www.dist-systems.bbn.com/confs/2001/QoSDOS/ Budapest Hungary: June 19, 2001 (Tuesday) The workshop addresses the state of the art and the future of Quality of Service management in distributed object systems. The objective is to provide presentations and discussions about the influence of QoS provision on the object model. An additional focus is put on component-based systems and the influence of QoS provision on the component specification and proper mapping to the underlying distribution infrastructure. 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 - Specification: Use of containers to specify and enforce QoS properties for a component. - Structure: AOP, open implementations design patterns, or contract aware components - Implementation: Use of components for implementing ORBs - Scope of QoS-integration: generic integration, multi-category support, impact on architecture and underlying object-model - Management: integration of QoS management and network and application management - Experiences: of QoS integration in OO-Middleware platforms - Specialized QoS platforms vs. extending existing platforms - Bind-time QoS integration: Naming, Trading, and Negotiation of QoS in open distributed systems - Accounting and Pricing of QoS Submission Process: A one to two page extended abstract describing your research is required. The paper will be distributed to the other participants and published on this website. The preferred format is pdf or html. Participants should also be prepared to give a 15 minute presentation on their research. To facilitate discussion, workshop is limited to 15-20 people. Send the paper to qosdos@bbn.com by April 17, A workshop summary will be published as part of ECOOP 2001 Workshop Reader. Important Deadlines: April 17, 2001 Submission Deadline May 8, 2001 Invitation for Participation May 15, 2001 Early Registration Deadline for ECOOP 2001 June 19, 2001 Workshop Date Organizers: Name: Christian Becker Email: becker@informatik.uni-frankfurt.de Company: FB Biologie und Informatik, Verteilte Systeme und Betriebssysteme University of Frankfurt/Main, Germany Name: John Zinky Email: jzinky@bbn.com Company: BBN Technologies, Part of Verizon Workshop Homepage: http://www.dist-systems.bbn.com/confs/2001/QoSDOS/ From owner-issll@mercury.lcs.mit.edu Sun Apr 15 23:45:26 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16767 for ; Sun, 15 Apr 2001 23:45:21 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id WAA17678 for issll-outgoing; Sun, 15 Apr 2001 22:51:07 -0400 (EDT) Received: from godmail.com (cm20816625250.coralsprings.ispchannel.com [208.166.25.250]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id WAA17633; Sun, 15 Apr 2001 22:50:32 -0400 (EDT) Message-Id: <3x3y2x3g27x.rwpgdo6t732h6crm7q@godmail.com> X-Mailer: ALPHA_XMR75_00001SLBL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: emailu05@mailroom.com Date: Sun, 15 Apr 2001 22:55:18 -0500 From: hairy@WolfMail.com Subject: Prospects and Internet Sales Leads! Reply-To: moemoe@yeayea.com Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit As a dot.com professional you know that it is essential to your teams' success to advertise your web site, business, product, service, or your organizations' cause to the masses. You also know that your marketing and advertising budget limits your options. If you are a Fortune 500 corporation, you have the advantage of being able to book 30 second TV spots during the SuperBowl. Most of us are not in that position though. Besides, did you know that something on the order of 92% of TV viewers run to the washroom at commercial breaks during the program, thereby missing the expensive commercial spot. Q: Of all the various advertising mediums which do you feel is most effective, in cases when you require your prospect to remember your telephone number or web address? Let's outline and agree on a list of the main advertising and marketing mediums first: - Television Commercial - Television Infomercial - Internet Banner Ads (paid for on a click-through basis) - Internet Banner Ads (paid for on an impression basis) - So-Called opted-in email list rental and broadcast - Radio Commercial - Print Media (Newspapers, Magazines) - Print Media (Hand-Outs) - Trade Shows - News or Media organization story or profile on your project - Affiliate Links - Signage - Telemarketing - Direct Mail - Broadcast Fax (not personalized to its recipients) - Broadcast Fax (personalized and to the Attention of its recipients) - Targeted Broadcast Email (personalized or not) Now consider the effectiveness of each advertising choice, remembering that in many cases your audience must still remember a telephone number in order to contact you. Q: Which is the least costly and most effective? E-mail marketing works! Why? There are many reasons, but primarily because people are focused on their monitors while checking their e-mail. Totally focused. In addition, they have a hard copy of your ad on their hard drive, and it is simple for them to forward the ad to their friends and associates as well. You can tell your story with more words and target your list to particular types of recipients or geographical areas. We offer some of the best delivery and bulk e-mail prices on the Internet. Bulk e-mail can get you the best exposure on the net. What makes this kind of advertising so effective is the fact that you go to the potential customer. Not like search engines or print ads that the potential customer has to do all the searching. Dollar for dollar bulk e-mailing is also the most economical. We do all the mailing for you. You just provide us with the ad! It's that simple! What we offer is simple: *General Lists or other ISPs #100,000 Emails $495.00 #250,000 Emails $995.00 #500,000 Emails $1,495.00 #1,000,000 Emails $2,495.00 #2,500,000 Emails $4,995.00 #5,000,000+ Emails (Call for Quote) WE ALSO HAVE LARGER PACKAGES! *Targeted Lists (Starting @): #100,000 Emails $995.00 #250,000 Emails $1,495.00 #500,000 Emails $2,995.00 #1,000,000 Emails (Call for Quote) METHOD OF PAYMENT, CASHIERS CHECK MONEY ORDER OR BANK WIRE. $$$GET AN ADDITIONAL FREE 25% ON TOP OF EVERY ORDER... IF YOU ORDER WITHIN 5 DAYS OF RECIEVING THIS MESSAGE! Call for bigger packages! ORDER NOW!!! AND GET THE RIGHT EXPOSURE! For more details on Email Services, please call: #954.340.1628 (US & International) IF YOU ARE THE DO IT YOURSLF TYPE OR ARE STILL USING TRADITONAL MARKETING TECHNICS, YOU MUST TAKE A LOOK AT THE 8 1/2 MILLION BUSINESS TO BUSINESS DATABASE!! Our 3.0 Version B2B Database Will Go Online and Sell For 2.5 to 25 Cents Per Record in early July! (Extended Due to Delays From The 1st) You can now access contact data for over 8.5 Million Records. All of them have their own .com .org or .net domain name, making them serious prospects for Internet business. Our data base readily accessible on CD-Rom, list the Names, Contact Information, Physical Address, Phone #, Fax #, SIC Industry Code, URL (Domain Name), and Contact Email Address which you can use to efficiently target companies worldwide. Over 8.5 Million Physical Addresses let you target businesses by Country, State, City, Province, Zip Code, Area Code or by using the SIC Industry Code. The data comes in a Comma-Delimited ASCII format which makes it easy to manipulate and Import/Export records to your Contact-Management, Spreadsheet, analysis and Broadcasting Applications. We’d be happy to give you rough counts for your industry target market. We also build databases to order and carry more than a dozen other data bases both Domestic and International ( B2B and B2C). Please send me more info about: [ ] Master Disc 2000 8.5 Million Records, Cost US$799.00 [ ] Online Updates & Download Access Cost US$199.00 (Annually) [ ] Commercial Email Services & Products Note: Not all records contain complete data, call for breakdowns. For more details on Database, please call: #954.340.1628 (US & International) or fax form below to: #954.753.2846 (Make Sure To Mention Reseller Id #1789 When Calling) Company name: ___________________________________________ Web Site Url: ___________________________________________ Contact name: ___________________________________________ Email: __________________________________________________ Phone: __________________________________________________ Fax: ___________________________________________________ Street address: _________________________________________ City, Zip, State: _______________________________________ Country: ________________________________________________ Check the following that apply: _____ Please Notify Me Of Online Web Site & Register Me For Access Using The Information Above. Also Please, Send Additional Information on: _____ Online Adult & Gaming Owner/Operaters _____ Online Adult Subscribers & Online Gamers Databases _____ Online Billing/Credit Card Processing _____ Emailing Services and Databases _____ Search Engine Positioning _____ International Contact Lists _____ Buying / Selling Traffic _____ Web Site Hosting Services _____ Internet Bandwidth Services (T-1's Starting at $999.00) _____ Other:_______________________________ ############################################################################## ############################################# THIS MESSAGE IS BEING SENT IN COMPLIANCE OF THE EMAIL BILL: SECTION 301. PER SECTION, PARAGRAPH (a) (2) (c) of S. 1618. To discontinue receipt of further notice at not cost and to be removed from our database, please reply with the word "Remove" in subject. Or call us at #954.340.1628 leave your email address for removal from the database and future mailings. Any attempts to disrupt the removal email address etc., will not allow us to be able to retrieve and process the remove requests. ############################################################################## ############################################# .0401601 From owner-issll@mercury.lcs.mit.edu Mon Apr 16 11:36:26 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06662 for ; Mon, 16 Apr 2001 11:36:25 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA20749 for issll-outgoing; Mon, 16 Apr 2001 10:34:53 -0400 (EDT) Received: from gw.tropicnetworks.com (gw.tropicnetworks.com [209.87.233.9]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id KAA20967 for ; Mon, 16 Apr 2001 10:34:51 -0400 (EDT) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for mercury.lcs.mit.edu [18.26.0.122]) with SMTP; 16 Apr 2001 14:34:55 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA394F; Mon, 16 Apr 2001 10:29:59 -0400 Message-ID: <3ADB00A3.83A5C697@tropicnetworks.com> Date: Mon, 16 Apr 2001 10:24:35 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steven Shi CC: issll@mercury.lcs.mit.edu Subject: Re: [Diffserv] How does RSVP dynamically provision resources in DS region? References: <20010412222642.75283.qmail@web12703.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 1. Is the Adspec in sender PATH message updated by the > RSVP awared nodes in DS region? If it is, how can DS > region interpret the meaning of Adspec since Adspec is > defined for IntServ? > > 2. Or the updating of Adspec can be ONLY done at > border router of DS region? > In theory, for Diffserv, ADSPEC would be updated at the edge or border routers and not the core routers. In practice, however, I'm not sure how many implementations actually update ADSPEC for Diffserv border or edge devices. The Diffserv/RSVP implementations that I was aware of and involved with, did not update ADSPEC. --- Best, Nabil Seddigh nseddigh@tropicnetworks.com From owner-issll@mercury.lcs.mit.edu Mon Apr 16 19:18:03 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15186 for ; Mon, 16 Apr 2001 19:18:00 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA24591 for issll-outgoing; Mon, 16 Apr 2001 18:05:51 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA23176 for ; Mon, 16 Apr 2001 18:05:48 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA12529; Mon, 16 Apr 2001 15:05:13 -0700 (PDT) Message-Id: <5.0.2.1.2.20010416141815.024eb690@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 16 Apr 2001 14:25:29 -0700 To: Kuthonuzo Luruo From: Fred Baker Subject: Re: Motivation for Intserv/Diffserv interoperation Cc: issll@mercury.lcs.mit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk At 06:55 PM 4/15/2001 -0500, Kuthonuzo Luruo wrote: >I've come to the conclusion that the main motivation for using Intserv >with Diffserv is the signalling control and end-to-end semantics that >RSVP/Intserv brings to Diffserv. Parekh and Gallagher, in Infocomm '93, demonstrated what is necessary to have a predictable behavior in a network. It has two elements: you have to know how much traffic there is, and you have to have the queuing points (host and router) behave predictably. If those two things are true, you can mathematically calculate the end to end delay. They give equations. Diff-serv, which is a data plane tool, enables us to scalably make the router do predictable things, given that the amount of traffic and the bandwidth available are known. TCP will put a stable amount of traffic into the network; unfortunately, it approximates the cliff rather than the knee. With red we can bring that down to the knee, and with ECN we can do so without dropping traffic. So if the routers behave predictably, we can create a quite predictable network for TCP-based applications. But voice/video don't respond to delay, ECN marks, or loss; each such application sends at a constant rate while it is sending, and using diff-serv alone the number of senders (and therefore total traffic load) is unbounded. Hence, using diff-serv alone, one cannot build a predictable voice network. The alternatives are (1) to provide effectively infinite bandwidth for voice, so that it is never significantly delayed regardless of user count, or (2) to know how many calls there are in the network with what characteristics, and refuse excess calls. In networks that consider communications capability to be a cost of doing business as opposed to the business itself, (2) becomes necessary, and (2) is the province of int-serv, a control-plane tool. Hence, for voice/video, we must use int-serv and diff-serv together. From owner-issll@mercury.lcs.mit.edu Mon Apr 16 20:27:38 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15590 for ; Mon, 16 Apr 2001 20:27:22 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA23132 for issll-outgoing; Mon, 16 Apr 2001 16:10:26 -0400 (EDT) Received: from [18.26.0.86] (callisto.lcs.mit.edu [18.26.0.86]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA23418; Mon, 16 Apr 2001 16:09:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: Date: Mon, 16 Apr 2001 16:00:43 -0400 To: minutes@ietf.org, issll@mercury.lcs.mit.edu From: John Wroclawski Subject: ISSLL WG Meeting minutes, 50th IETF Cc: Eric Crawley , jtw@mercury.lcs.mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Minutes of the ISSLL WG Meeting 50th IETF - Minneapolis, MN. Tuesday, March 20, 2001 13:00-14:00 ISSLL held a one-hour meeting at the 50th IETF. Issues related to several Intserv/Diffserv documents were discussed. * draft-ietf-issll-rsvp-aggr-03.txt The chair gave a short summary of the status of this draft. It was submitted to the IESG for publication as a RFC months ago. At the December, 2000 WG meeting the cognizant AD (Allison Mankin) gave a short presentation explaining the concerns, which focused around the draft's requirement that the IP next-protocol field be altered as the packet traveled through routers. She suggesting that the concerns could be resolved either through technical revision or through a more detailed security concerns section. After some discussion at the 49th IETF meeting and consideration among the authors, a new security section was drafted and a revised version of the document was submitted before the deadline for this meeting. No further comments on the revised version have been received on the mailing list. At the time of the WG meeting, the IESG was still reviewing this revised version. [Ed. after the meeting, the IESG approved publication of the draft, subject only to some clarification of the IANA considerations section. That clarification led to a -04 version draft being submitted. This version will now go to the RFC editor.] * draft-ietf-issll-rsvp-cap-02.txt This draft defines the RSVP CAP object. The -02 version of this draft, incorporating previous comments, was submitted in February. A key change was removing most of the explanatory material into a separate document, draft-hamid-issll-rsvp-cap-dsmark-00.txt, leaving this one as a standalone spec. Comments from the mailing list and the chairs identified several small issues with this document. These points include: 1) Sections of the previous document that specified bit assignments were incorrectly removed to the explanatory document. Bit assignments should be part of the standard, not the explanation 2) The document presently implies that each capability will only require one bit. There is no reason that this need be true, and the limitation is not needed. 3) Message processing rule descriptions need to be either completely generic or specified per-capability, rather than in a general section. The author of the draft was unable to attend the meeting. In his absense, the chairs proposed revising the document to address these issues by a) editing the present definition of the CAP object itself to include only generic (not per-capability) information and to not limit the definition of a particular capability, and b) adding new sections for each defined capability, giving bit assignments and message processing rules for that capability. The intent is that new revisions of the document would be issued if and when new capabilities are defined. A brief discussion did not reveal any objections to this approach from meeting attendees. The chairs will draft a note to the mailing list and forward comments to the draft author. * draft-ietf-issll-ds-map-01.txt [Ed. The chairs note that one of them is also an author of the current version of this draft.] This is the "service mapping" draft, which gives advice about using diffserv technologies to cause a DS cloud to effectively emulate an intserv "network element" and thus play a part in an intserv end-to-end QoS path. The current version of the document was written some time ago and has not been modified in any significant way in some time. However, in the view of the authors, it is missing some important sections and thus is still work in progress. At this meeting, the chairs raised the question of whether to continue work on the document, and if so, what path forward would be most useful: Specifically, the chair raised three questions as a starting point for discussion. 1: Is the document, either as it stands or as it might stand, useful? 2: Present practice is to implement and use the defined intserv services, particularly Guaranteed, in ways that do not completely match the RFC definitions. Should the document focus on mapping diffserv to the defined services, or to some approximation of these services that is emerging from current practice? If so, should we attempt to write down these approximations, either in this document or in a separate one? 3: One specific technical area that is not addressed in the current document is statistical approximations of G-like services. (CL is already defined in this way). Should the document specifically attempt to capture the current state of knowledge in this area, even though that knowledge is evolving fast? A vigorous discussion ensued. The results of this discussion can be summarised as: 1) There was substantial concensus in the meeting that the document is useful and should be completed. Some speakers expressed the opinion that the document is useful as it stands now, and should be published as is even if no further technical work is done. 2) There was substantial concensus in the meeting that the document should focus on implementing the intserv services as they are actually being used, rather than strictly following the RFC definition. 3) There was substantial concensus that it would be useful to crisply document the assumptions and approximations made by current implementations of the intserv services, as a starting point for doing the above. The question of whether this should be a separate document or a section of the mapping draft was left open. 4) Some speakers suggested that the intserv service definitions themselves were subject to misunderstandings that led to problems. A document or section of the current draft discussing these issues was suggested. 5) There was an extended discussion of whether it would be useful to define one or more new IntServ services with definitions that captured what people perceive as the current requirements for VoIP. The meeting was more or less evenly split on this topic, with several speakers arguing for a new service at the Intserv level and several others arguing that appropriate selection, implementation and approximation of the existing services in different environments is a simpler and adequate approach. A complicating factor in this discussion was point 4, above, which raised the possibility that some concerns about the current specs were based on interpretation of the spec document rather than technical unsuitability. Based on this discussion, and followup discussions with the document authors and people that expressed interest in the meeting, the chairs will draft a proposal for revising this I-D and forward it to the mailing list for discussion as soon as practical. From owner-issll@mercury.lcs.mit.edu Mon Apr 16 20:52:31 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15758 for ; Mon, 16 Apr 2001 20:51:45 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id TAA24183 for issll-outgoing; Mon, 16 Apr 2001 19:31:21 -0400 (EDT) Received: from mail.eecs.uic.edu (mail.eecs.uic.edu [131.193.32.27]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id TAA25134 for ; Mon, 16 Apr 2001 19:31:19 -0400 (EDT) Received: from grover.eecs.uic.edu (grover.eecs.uic.edu [131.193.40.35]) by mail.eecs.uic.edu (8.9.3/8.9.3) with ESMTP id SAA21132; Mon, 16 Apr 2001 18:30:15 -0500 (CDT) Received: from localhost by grover.eecs.uic.edu (8.9.3/8.9.3) with ESMTP id SAA13937; Mon, 16 Apr 2001 18:31:24 -0500 (CDT) X-Authentication-Warning: grover.eecs.uic.edu: kluruo owned process doing -bs Date: Mon, 16 Apr 2001 18:31:24 -0500 (CDT) From: Kuthonuzo Luruo To: Fred Baker cc: issll@mercury.lcs.mit.edu Subject: Re: Motivation for Intserv/Diffserv interoperation In-Reply-To: <5.0.2.1.2.20010416141815.024eb690@mira-sjcm-2.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk pls see inline. On Mon, 16 Apr 2001, Fred Baker wrote: > At 06:55 PM 4/15/2001 -0500, Kuthonuzo Luruo wrote: > >I've come to the conclusion that the main motivation for using Intserv > >with Diffserv is the signalling control and end-to-end semantics that > >RSVP/Intserv brings to Diffserv. > > Parekh and Gallagher, in Infocomm '93, demonstrated what is necessary to > have a predictable behavior in a network. It has two elements: you have to > know how much traffic there is, and you have to have the queuing points > (host and router) behave predictably. If those two things are true, you can > mathematically calculate the end to end delay. They give equations. > > Diff-serv, which is a data plane tool, enables us to scalably make the > router do predictable things, given that the amount of traffic and the > bandwidth available are known. > > TCP will put a stable amount of traffic into the network; unfortunately, it > approximates the cliff rather than the knee. With red we can bring that > down to the knee, and with ECN we can do so without dropping traffic. So if > the routers behave predictably, we can create a quite predictable network > for TCP-based applications. > > But voice/video don't respond to delay, ECN marks, or loss; each such > application sends at a constant rate while it is sending, and using > diff-serv alone the number of senders (and therefore total traffic load) is > unbounded. Hence, using diff-serv alone, one cannot build a predictable > voice network. The alternatives are (1) to provide effectively infinite > bandwidth for voice, so that it is never significantly delayed regardless > of user count, or (2) to know how many calls there are in the network with > what characteristics, and refuse excess calls. In networks that consider > communications capability to be a cost of doing business as opposed to the > business itself, (2) becomes necessary, and (2) is the province of > int-serv, a control-plane tool. > > Hence, for voice/video, we must use int-serv and diff-serv together. so, can i conclude that the primary motivation for the Intserv/Diffserv interoperation is the signaling that control plane Intserv brings to data plane Diffserv for such voice/video flows that do not use TCP? with other benefits being... able to perform better resource mgmt in Diffserv clouds, fine-grained policy control etc (the 4 benefits in RFC 2998). ergo, from the operational "real world" viewpoint, my ISP would introduce Intserv/Diffserv for the above reasons and NOT for the tighter qos guarantees attributes of Intserv. this perception also seems to be supported by a look at the Intserv/Diffserv network model: Intserv n/w elements are at the stub n/ws where congestion is less likely, and hence perflow intserv is unlikely to bring significantly better qos guarantees (as opposed to extending Diffserv all the way to the stubs). on the other hand, from a purely academic "scientific" perspective, perhaps investigating the interworking problem from my initial perception ("hard qos guarantees Intserv benefits less strict qos guarantees Diffserv") is worthwhile, thesis-wise :-). thanks. -thonuzo > > From owner-issll@mercury.lcs.mit.edu Mon Apr 16 21:59:59 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17112 for ; Mon, 16 Apr 2001 21:59:57 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id VAA25834 for issll-outgoing; Mon, 16 Apr 2001 21:00:03 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA25945 for ; Mon, 16 Apr 2001 20:59:29 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA06372; Mon, 16 Apr 2001 17:58:52 -0700 (PDT) Message-Id: <5.0.2.1.2.20010416174459.04519b60@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 16 Apr 2001 17:51:25 -0700 To: Kuthonuzo Luruo From: Fred Baker Subject: Re: Motivation for Intserv/Diffserv interoperation Cc: issll@mercury.lcs.mit.edu In-Reply-To: References: <5.0.2.1.2.20010416141815.024eb690@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk At 06:31 PM 4/16/2001 -0500, Kuthonuzo Luruo wrote: >ergo, from the operational "real world" viewpoint, my ISP would introduce >Intserv/Diffserv for the above reasons and NOT for the tighter qos >guarantees attributes of Intserv. given that controlled load presumes a common queue for all voice traffic, scheduled using priority or similar scheduler, I'm not sure I see a distinction. Controlled Load can be read pretty directly as "per-microflow signalling for EF-managed microflows". The difference here, I believe, is that we would like to see aggregate signaling as well as aggregate data management. When you talk about fine-grained data management, you are talking about the Guaranteed Service, which presumes the characteristics of per-flow WFQ, although somehow it manages to not actually require a WFQ/WRR algorithm. This is something that is eminently possible using calendar-queue-scheduled WFQ algorithms, but has potentially interesting scaling properties. >on the other hand, from a purely academic "scientific" perspective, >perhaps investigating the interworking problem from my initial perception >("hard qos guarantees Intserv benefits less strict qos guarantees >Diffserv") is worthwhile, thesis-wise :-). very possibly. You could start out by arguing that the guarantees differ, and say why you think that. hint: with a control plane, you get told what you are guaranteeing. But I wouldn't compare a control plane solution to a data plane solution - the control plane isn't going anywhere without a data plane, and controlled load has the SAME data plane; the only thing that differs is how the classifier works. You want to explore what not having a control plane does to arbitrary amounts of voice and video. From owner-issll@mercury.lcs.mit.edu Mon Apr 16 22:08:23 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17170 for ; Mon, 16 Apr 2001 22:08:16 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA25858 for issll-outgoing; Mon, 16 Apr 2001 20:56:36 -0400 (EDT) Received: from [24.147.233.189] (h0005025edf78.ne.mediaone.net [24.147.233.189]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA25810 for ; Mon, 16 Apr 2001 20:56:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu Message-Id: Date: Mon, 16 Apr 2001 20:56:05 -0400 To: issll@mercury.lcs.mit.edu From: John Wroclawski Subject: IETF ISSLL WG mailing list cleanup Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Hi, Once again it's time to clean up the ISSLL WG mailing list - lots of bounces from dead addresses. Some time over the next 24 hours I'm going to remove all of the addresses that are consistently getting permanent errors. When I'm done I'll send another note to let you know. If you don't get the second note within a day or two, Something Bad has happened. If, at that point, you still want to be on the list, please either let me know or just resubscribe. Regards, John W. From owner-issll@mercury.lcs.mit.edu Tue Apr 17 16:25:25 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16043 for ; Tue, 17 Apr 2001 16:25:15 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id PAA00335 for issll-outgoing; Tue, 17 Apr 2001 15:14:24 -0400 (EDT) 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 PAA00309 for ; Tue, 17 Apr 2001 15:14:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13872; Tue, 17 Apr 2001 15:13:39 -0400 (EDT) Message-Id: <200104171913.PAA13872@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: issll@mercury.lcs.mit.edu From: The IESG Subject: Protocol Action: RSVP Reservations Aggregation to Proposed Standard Date: Tue, 17 Apr 2001 15:13:39 -0400 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk The IESG has approved the Internet-Draft 'RSVP Reservations Aggregation' as a Proposed Standard. This document is the product of the Integrated Services over Specific Link Layers Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary 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 provides 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. The document addresses both intra- and inter-domain unicast routes and multicast resrevations. Working Group Summary The working group supported progressing this document. Protocol Quality The proposal was reviewed for the IETF by Allison Mankin. From owner-issll@mercury.lcs.mit.edu Tue Apr 17 16:29:32 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16153 for ; Tue, 17 Apr 2001 16:29:31 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id PAA00393 for issll-outgoing; Tue, 17 Apr 2001 15:19:54 -0400 (EDT) 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 PAA31738 for ; Tue, 17 Apr 2001 15:19:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13964; Tue, 17 Apr 2001 15:19:44 -0400 (EDT) Message-Id: <200104171919.PAA13964@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: issll@mercury.lcs.mit.edu From: The IESG Subject: Protocol Action: RSVP Reservations Aggregation to Proposed Standard Date: Tue, 17 Apr 2001 15:19:44 -0400 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk The IESG has approved the Internet-Draft 'RSVP Reservations Aggregation' as a Proposed Standard. This document is the product of the Integrated Services over Specific Link Layers Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary 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 provides 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. The document addresses both intra- and inter-domain unicast routes and multicast resrevations. Working Group Summary The working group supported progressing this document. Protocol Quality The proposal was reviewed for the IETF by Allison Mankin. From owner-issll@mercury.lcs.mit.edu Wed Apr 18 17:49:21 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18562 for ; Wed, 18 Apr 2001 17:49:17 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA12692 for issll-outgoing; Wed, 18 Apr 2001 16:19:09 -0400 (EDT) Received: from 3w-smtp-ae.korea.com ([211.109.1.115]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA12460 for ; Wed, 18 Apr 2001 16:19:06 -0400 (EDT) Received: from 3w-pop3-aa.korea.com ([172.31.1.4]) by 3w-smtp-ae.korea.com with Microsoft SMTPSVC(5.0.2195.2345); Thu, 19 Apr 2001 05:22:23 +0900 Received: from thrunet ([210.205.197.156]) by 3w-pop3-aa.korea.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Apr 2001 05:22:23 +0900 Date: Thu, 19 Apr 2001 05:17:02 +0900 From: "¿Â¶óÀÎÄÚ¸®¾Æ" To: issll@mercury.lcs.mit.edu Subject: issll´Ô ¾È³çÇϼ¼¿ä? X-AD2000-Serial: 1033 X-AD2000-Register: "¹ÚÀçÇö" MIME-Version: 1.0 Content-Type: text/html Message-ID: <3W-POP3-AAWs4FhIXIt0001c187@3w-pop3-aa.korea.com> X-OriginalArrivalTime: 18 Apr 2001 20:22:23.0791 (UTC) FILETIME=[471F5BF0:01C0C845] Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxNRVRBIE5BTUU9IkdFTkVSQVRPUiIgQ29udGVudD0iTWljcm9z b2Z0IERIVE1MIEVkaXRpbmcgQ29udHJvbCI+DQo8VElUTEU+PC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPg0KPFA+PEZPTlQgY29sb3I9IzAwMDA4MCBmYWNlPbG8uLLDvCBzaXplPTI+osQg v8C0w8DHIMCvuNMgosU8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0y PqHhsPq9w7/lPEJSPkEgZ2lybCBnb3QgYW4gZW5nYWdlbWVudCByaW5nLCBhbmQgd291bGQg c2VpemUgDQpldmVyeSBvcHBvcnR1bml0eSBmb3IgPEJSPmNhbGxpbmcgYXR0ZW50aW9uIHRv IGl0LiZuYnNwOyA8QlI+SW4gYSBncm91cCB3aXRoIA0KZ2lybCBmcmllbmRzIG5vIG9uZSBu b3RpY2VkIGl0LiZuYnNwOyBGaW5hbGx5IHdoZW4gaGVyPEJSPmZyaWVuZHMgd2VyZSBzaXR0 aW5nIA0KYXJvdW5kIHRhbGtpbmcsIHNoZSBnb3QgdXAgc3VkZGVubHkgYW5kIHNhaWQsIDxC Uj4iSXQncyBhd2Z1bGx5IGhvdCBpbiBoZXJlLiBJIA0KdGhpbmsgSSdsbCB0YWtlIG15IHJp bmcgb2ZmLiI8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPqHec2Vp emUgZXZlcnkgb3Bwb3J0dW5pdHkgZm9yIH4gaW5nIDogseLIuLi4IMDWwLi46SB+IA0Kx8+0 2S48QlI+od5jYWxsIGF0dGVudGlvbiB0byA6IH4gv6EgwdbAx7imIMivseK9w8WwtNkuIDxC Uj6h3mF3ZnVsbHkgOiB2ZXJ5IDwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBz aXplPTI+vuDIpbndwfa4piC53sC6IL7GsKG+vrTCILHiyLi4uCDA1sC4uOkgu+e297Xpv6Gw 1CCx1yC53cH2uKYguri/qcHWt8Gw7SZuYnNwOyANCjxCUj616b76tNkmbmJzcDsgPEJSPsfR ufjAuiC/qcDaxKOxuLXpsPogvu6/77fItMK1pSC+xrmrtbUgsdcgud3B9rimILSrv6mw3CC6 wcHWwfYgvsq+0rTZPEJSPri2xKezuyC+xrChvr60wiC02bXpILXRt6++yb7GIA0KwMy+37Hi uKYgs6q0qbDtIMDWtMIgxse/oSC5+raxIMDPvu68rbjpvK0gPEJSPri7x9+02S48QlI+Ir7u yN4sILT1v/a8rSC4+CCw37XwsNqz1y4gs6ogud3B9rimILupvt8gx9Kx7rrBISImbmJzcDsg DQo8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgY29sb3I9IzAwMDA4MCBmYWNlPbG8uLLDvCBzaXpl PTI+osQgv8C0w8DHIL+1vu4gx9G4trXwIKLFPC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9 sby4ssO8IHNpemU9Mj6iwyCwqLvnwMcguLvAuyDH0iC2pzxCUj6/3LG5wM616cC6ILOyv6Gw 1CC+xsHWIMDbwLogtbW/8sC7ILnevsa1tSAiVGhhbmsgDQp5b3UuKLCou+fH1bTPtNkuKSK2 87DtIDxCUj64u8fYv+QuIMDMsM3AuiC+7rfIwLsgtqe6zsXNILHXt7EgsbPAsMC7ILnewLi4 6bytIMDatvMgv9Sx4iC2p7muv6EguPa/oSA8QlI+uqO+7iDA1r7uILvztOu55sDHILvnvNLH 0SANCrW1v/LAzLOqIMSjwP2/obW1ICJUaGFuayB5b3UuIrbzsO0guLvHz7TCIL3AsPw8QlI+ wLsgsK6w1CC1yLDFILCwvsa/5C4gubC30Cwgv+y4rrW1ILi2wvmwocH2wfa4uL/kLjxCUj4i VGhhbmsgDQp5b3UuIr+hILTrx9EgwMC05MC6ICLDtbi4v6G/5C4itvO0wiC25sC4t84gIllv dSBhcmUgd2VsY29tZS4gLzxCUj5Eb24ndCBtZW50aW9uIGl0LiAvTm90IGF0IA0KYWxsLiK1 7sDHIMelx/bAuyC+ssHSLiA8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6 ZT0yPkE6IEl0IHdhcyB2ZXJ5IGtpbmQgb2YgeW91IHRvIGdvIHRvIHRoYXQgdHJvdWJsZSBm b3IgDQptZS48QlI+QjogSXQgd2FzIG5vIHRyb3VibGUgYXQgYWxsLiBJdCB3YXMgbXkgcGxl YXN1cmUuPEJSPkE6IEl0J3MgdmVyeSBraW5kIG9mIA0KeW91IHRvIHNheSBzby48QlI+Jm5i c3A7PEJSPkE6IMD6uKYgwKfH2LytILHXt7EgvPaw7bimIMfYIMHWvcO0zyDBpLi7ILDtuL+9 wLTPtNkuPEJSPkI6ILm5ILz2sO229iCwzcDMIMDWs6q/5C4gDQrBprChIMHBvsa8rSDH0SDA z8DOtaW/5C48QlI+QTogsde3uLDUILi7vrjH2CDB1r3DtM8gwaS4uyCw7bi/vcC0z7TZLjxC Uj4mbmJzcDs8QlI+oeGwqLvnwMcgseK6uyDHpcf2PEJSPqLCIFRoYW5rIA0KeW91LiAvVGhh bmtzLjxCUj4mbmJzcDsmbmJzcDsgormwqLvnx9W0z7TZLjxCUj6iwiBUaGFua3MgYSBsb3Qu IC9UaGFuayB5b3UgdmVyeSBtdWNoLiANCi9UaGFuayB5b3Ugc28gbXVjaC48QlI+Jm5ic3A7 Jm5ic3A7IKK5tOu03Mj3ILCou+fH1bTPtNkuPEJSPqLCIEknZCBhcHByZWNpYXRlIA0KaXQu PEJSPiZuYnNwOyZuYnNwOyCiubHXt7iw1CDH2CDB1r3DuOkgsKi758fPsNq9wLTPtNkuPEJS PqLCIEkgYXBwcmVjaWF0ZSBpdCB2ZXJ5IA0KbXVjaC48QlI+Jm5ic3A7Jm5ic3A7IKK5sdcg waEgwaS4uyCwqLvnx9W0z7TZLjxCUj6iwiBPbiBiZWhhbGYgb2Ygb3VyIGVtcGxveWVlcyBJ J2QgbGlrZSB0byANCnRoYW5rIHlvdS48QlI+Jm5ic3A7Jm5ic3A7IKK5wPrI8SDIuLvnv/i1 6cC7ILTrx6XH2LytILTnvcW/obDUILCou+cgteW4rrDtIL3NvcC0z7TZLjxCUj4mbmJzcDs8 QlI+PEZPTlQgDQpjb2xvcj0jMDAwMDgwPqLEIMDfuPggvrLAzyC89iDA1rTCIMelx/YgosU8 QlI+Jm5ic3A7PEJSPjwvRk9OVD6iwyC/qbHivK0gMcijvLHAuLfOILClvsbFuLzFvt8gDQrH 1bTPtNk8QlI+Jm5ic3A7PEJSPjxGT05UIGNvbG9yPSNmZjAwMDA+oeFZb3UgaGF2ZSB0byBz aGlmdCB0byB0aGUgTm8uMSANCkxpbmUuoeuh66Hroeuh66Hroeuh66Hroeuh66HtKFgpPEJS PjwvRk9OVD48Rk9OVCBjb2xvcj0jMDA4MDgwPqHhWW91J2xsIGhhdmUgdG8gdHJhbnNmZXIg dG8gDQp0aGUgTm8uMSBMaW5lIGZyb20gaGVyZS6h66Hroeuh7ShPKTxCUj4mbmJzcDs8QlI+ PC9GT05UPqLBc2hpZnS0wiC067CzILDFwdbB9rOqILv9sKLAuyC52bLbtNm0wiANCrbmwMy5 x7fOIL+pseK8rbTCILjCwfYgvsq+xr/kLiA8QlI+Jm5ic3A7ILGzxevG7cC7ILClvsbFuLTC ILDNwLogurjF6yB0cmFuc2ZlcrbzsO0gx9i/5C4gsde4rrDtILPrvLHAuyCwpb7Gxbi0wiAN CjxCUj4mbmJzcDsgyK+9wr+qtbUgdHJhbnNmZXK287DtIMfPtMK1pSwgwMy2p7TCILjtu+fA 1LTPtNkuIDxCUj4mbmJzcDsguvHH4LHiIL+px+Agwd+/oSCwpb7Gxbi0wiCx4sL4wfa0wiAN CnN0b3BvdmVytvOw7SDH2L/kLjxCUj4mbmJzcDs8QlI+od5Ob3cgeW91IGhhdmUgdG8gc3dp dGNoIHRvIHRoZSBOby4xIExpbmUuKL+pseK8rSAxyKO8scC4t84gDQqwpb7Gxbi8vL/kLik8 QlI+od5Zb3UgaGF2ZSB0byBnZXQgb3ZlciB0byB0aGUgTm8uMSBMaW5lLigxyKO8sSDCysC4 t84gsKG8xbytIMW4vLy/5C4pPC9GT05UPjwvUD4NCjxQPjxGT05UIGNvbG9yPSMwMDAwODAg ZmFjZT2xvLiyw7wgc2l6ZT0yPqLEIL/AtMPAxyDAz77uIMfRuLa18CCixTwvRk9OVD48L1A+ DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+osLAz7q7vu61tSC/tb7uv80gsLDAuiDH /MXCt84gsbi8urXHvu4gDQrA1r3AtM+02S48QlI+oeuh66Hroeuh66Hroeuh66Hroeuh66Hr oeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh6zxCUj5pc3Ns bLTUIL7Is+fHz7y8v+Q/IDwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXpl PTI+wPrI8bTCIMD8yK24piDAzL/rx9i8rSCwrbvnv80gMSA6IDEgt84gv9yxub7uIMfQvcDA uyDH0iC89iDA1rTCIDxCUj48QSANCmhyZWY9Imh0dHA6Ly93d3cub2xrLmNvLmtyL2Fubm91 X2ZyYW1lLmh0bSI+osQgT25saW5lIEtvcmVhIKLFIDwvQT6287DtIMfVtM+02S48QlI+ucy4 riANCsfjtvS53sH2IL7KsO0gxu3B9iC15bfBIMHLvNvH1bTPtNkuILrOtfAgs8qx17evv+y9 xSC/67ytuKYuLi4uLi48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0y PsD6yPEgyLi757+hvK20wiC/3LG5vu4ov7W+7izAz77uKb+hILD8vckgwNa0wiC4ucC6ILrQ temysiC4xcDPKL/5LbHdKSwgPEJSPr+1vu7Ar7jTv80gDQq7/ciwv6Egx8q/5MfRIMi4yK0g x9Egua7A5b6/wLsguau34bfOILq4s7sgteW4rrDtIMDWvu6/5C48L0ZPTlQ+PC9QPg0KPFA+ PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPsCnv80gsLDAuiCzu7/rwMcgvK268b26uKYgud6+ xrq4seIgv/jHz73DuOkgoewgPEEgDQpocmVmPSJtYWlsdG86b2xrQG9say5jby5rciI+b2xr QG9say5jby5rcjwvQT4goe23ziA8QlI+PEZPTlQgDQpjb2xvcj0jZmYwMDAwPiJ5ZXMiPC9G T05UPrbztMIgs7u/68DHILTkwOXAuyDB1r3DseIgudm2+LTPtNkuIDwvRk9OVD48L1A+DQo8 UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+sde4rrDtLCDA+sjxIMD8yK0gv9yxub7uILCt wMewoSCxw7Hdx8+9xSC60LXpwLsgwKfH2CwgMci4v6Egx9HH2LytPEJSPjxBIA0KaHJlZj0i aHR0cDovL3d3dy5vbGsuY28ua3IvaW5zdGlfZnJhbWUuaHRtIj6iwiC5q7fhIL3DufywrcDH IKLCPC9BPrW1IL3HvcPH2CC15biusO0gwNbAuLTPIMfRufggtem+7rq4sO0gDQq9zcC4vcO4 6SA8QlI+wfax3SC9xcO7x9ggwda8vL/kLjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPbG8 uLLDvCBzaXplPTI+uau34SC9w7n8sK3AxyC9xcO7ILnmuf3AuiA8QSANCmhyZWY9Imh0dHA6 Ly93d3cub2xrLmNvLmtyL2luc3RpX2ZyYW1lLmh0bSI+orogwMyw9yCiuCA8L0E+wLsgxay4 r8fPvcUgyMQgsK3AxyC9xcO7tvW/oSANCsDWtMI8QlI+vcO5/LCtwMcgvcXDuyDG+8C7IMDb vLrHz7zFvK0gurizuyDB1r3DuOkgtcu0z7TZLjxCUj65sLfQLCDA/MitIDxGT05UIGNvbG9y PSM4MDAwODA+MDItNTg4LTA1MTAgDQo8L0ZPTlQ+wLi3zrW1IL3Fw7vHz73HILz2IMDWsbi/ 5C48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPr7GuavCybfPIMDM IMfQvcC5/cDMIGlzc2xstNTAxyDIuMitIL3Ht8Igx+K787+hIMDbwLogurjFxsDMIDxCUj61 x776wLi46SANCsfVtM+02S48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6 ZT0yPmlzc2xstNSysrTCIGh0dHA6Ly9jY2wuY2h1bmduYW0uYWMua3IvSUVURi9pc3NsbC9p c3NsbC5odG2/oSDA1rTCIMHWvNK4piC6uLDtILjewM8gteW3yLTCtaW/5Cw8QlI+utLHyr/k x9EgDQrBpLq4v7S02bjpIMGkuLsgwcu828fVtM+02S48QlI+vtXAuLfOIMfjtvS++LTCILje wM/AuiC15biuwfYgvsq1tbfPIMfPsNq9wLTPtNkuPEJSPrHXt7MsIL7Is+fI9yANCrDovLy/ 5C48L0ZPTlQ+PC9QPg0KPC9CT0RZPg0KPC9IVE1MPg0K From owner-issll@mercury.lcs.mit.edu Wed Apr 18 21:05:55 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20081 for ; Wed, 18 Apr 2001 21:05:51 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id TAA13696 for issll-outgoing; Wed, 18 Apr 2001 19:58:21 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id TAA14305 for ; Wed, 18 Apr 2001 19:58:14 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA25904; Wed, 18 Apr 2001 16:57:51 -0700 (PDT) Message-Id: <5.0.2.1.2.20010418164553.048ae898@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 18 Apr 2001 16:47:22 -0700 To: John Wroclawski From: Fred Baker Subject: Re: IETF ISSLL WG mailing list cleanup Cc: issll@mercury.lcs.mit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk At 08:56 PM 4/16/2001 -0400, John Wroclawski wrote: >If, at that point, you still want to be on the list, please either let me >know or just resubscribe. just a thought. Next time this happens, maybe you want to send a note to the list indicating that you will empty the list momentarily, and everyone should send the appropriate "subscribe" message. From owner-issll@mercury.lcs.mit.edu Thu Apr 26 16:10:08 2001 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18097 for ; Thu, 26 Apr 2001 16:10:08 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA00214 for issll-outgoing; Thu, 26 Apr 2001 10:29:16 -0400 (EDT) Received: from mailgate.rz.uni-karlsruhe.de (mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA00434 for ; Thu, 26 Apr 2001 10:29:11 -0400 (EDT) Received: from uni-karlsruhe.de (wolf1.rz.uni-karlsruhe.de [129.13.90.49]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1) id 14smfk-0005fC-00; Thu, 26 Apr 2001 16:23:08 +0200 Message-ID: <3AE82F6E.28F853FE@uni-karlsruhe.de> Date: Thu, 26 Apr 2001 16:23:42 +0200 From: Lars Wolf Organization: University of Karlsruhe X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 Subject: Call for Participation: IWQoS2001 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit [Our apologies for duplicate transmissions] ############################################################### Ninth International Workshop on Quality of Service (IWQoS 2001) ############################################################### Further information and registration: http://www.uni-karlsruhe.de/~iwqos/ Karlsruhe, Germany, June 6-8, 2001 hosted by University of Karlsruhe, Institute of Telematics supported by technical co-sponsorship by / in-cooperation with IEEE Communications Society (TCCC and ITC), ACM SIGCOMM and IFIP WG6.1 Sponsors SAP AG / CEC -- Karlsruhe Corporate Research Enterasys Networks Ericsson Eurolab Siemens IBM NENTEC Gunther-Schroff-Stiftung IWQoS2001 Advanced Program ########################## Tuesday, June 5, 2001 ===================== 20:00 IWQoS Reception Wednesday, June 6, 2001 ======================= 08:45 Welcome Lars Wolf, David Hutchison, Ralf Steinmetz 09:00 Keynote Quality of Service - 20 Years old and Ready to get a Job? Henning Schulzrinne 10:00 Break 10:30 Session 1: Provisioning and Pricing Dynamic Core Provisioning for Quantitative Differentiated Service Raymond R.-F. Liao, Andrew T. Campbell Towards Provisioning DiffServ Intra-Nets Ulrich Fiedler, Polly Huang, Bernhard Plattner Analysis of Paris Metro Pricing Strategy for QoS with a Single Service Provider Ravi Jain, Tracy Mullen, Robert Hausman Why Value is Everything: A User-Centered Approach to Internet Quality of Service and Pricing Anna Bouch, M. Angela Sasse 12:30 Break 14:00 Session 2: Systems QoS Traveling to Rome: QoS Specifications for Automated Storage System Management John Wilkes Extending a Best-Effort Operating System to Provide QoS Processor Management Hans Domjan, Thomas R, Gross User Focus in Consumer Terminals and Conditionally Guaranteed Budgets Reinder J. Bril, E. (Liesbeth) F.M. Steffens 15:30 Break 16:00 Session 3: Routing Extending BGMP for Shared-Tree Inter-Domain QoS Multicast Aiguo Fei, Mario Gerla Granularity of QoS Routing in MPLS Networks Ying-Dar Lin, Nai-Bin Hsu, Ren-Hung Hwan Fault Tolerance and Load Balancing in QoS Provisioning with Multiple MPLS Paths Scott Seongwook Lee, Mario Gerla On Selection of Paths for Multipath Routing Srihari Nelakuditi, Zhi-Li Zhang 18:00 Break 19:00 Workshop Dinner Thursday, June 7, 2001 ======================= 08:30 Session 4: TCP Related Preferential Treatment of Acknowledgment Packets in a Differentiated Services Network Konstantina Papagiannaki, Patrick Thiran, Jon Crowcroft, Christophe Diot A Quantitative Model for Parameter Setting of RED with TCP Traffic Thomas Ziegler, Christof Brandauer, Serge Fdida Evaluation of the QoS offered by PRTP-ECN - A TCP-Compliant Partially Reliable Transport Protocol Karl-Johan Grinnemo, Anna Brunstrom 10:00 Break 10:30 Session 5: Wireless and Mobile GAME based QoS Provisioning in Multimedia Wideband CDMA Networks Mohamed Moustafa, Ibrahim Habib, Mahmoud Naghshineh QoS-aware Adaptive Services in Mobile Ad-hoc Networks Baochun Li 11:30 Break (Short) 11:45 Panel How will Media Distribution work in the Internet? Andrew Campbell, Carsten Griwodz (Chair), Joerg Liebeherr, Dwight Makaroff, Andreas Mauthe, Giorgio Ventre, and Michael Zink 12:45 Break 14:00 Short Paper Session Experimental Extensions to RSVP - Remote Client and One-Pass Signalling Martin Karsten Extended Quality-of-Service for Mobile Networks Jukka Manner, Kimmo Raatikainen Quality of Service Schemes for IEEE 802.11 - A Simulation Study Anders Lindgren, Andreas Almquist, Olov Schelen Differentiated Services over Shared Media Pascal Anelli, Gwendal Le Grand End-to-Edge QoS System Integration: Integrated Resource Reservation Framework for Mobile Internet Yasunori Yasuda, Nobuhiko Nishio, Hideyuki Tokuda Problems of Elastic Traffic Admission Control in an HTTP Scenario Joachim Charzinski 16:00 Break 16:30 Session 6: Aggregation and Active Networks Based QoS Aggregation and Scalable QoS: A Performance Study Huirong Fu, Edward W. Knightly Customizable Cooperative Metering for Multi-Ingress Service Level Agreements in Differentiated Network Services Syed Umair Ahmed Shah, Peter Steenkiste Segmented Adaptation of Traffic Aggregates Hermann de Meer, Piers O`Hanlon 18:00 Friday, June 8, 2001 ==================== 08:30 Invited Talk Automated, Dynamic Traffic Engineering in Multi-Service IP Networks Joe Sventek 09:30 Break 10:00 Session 7: Scheduling and Dropping Differentiated Services with Lottery Queueing Joseph Eggleston, Sugih Jamin On Creating Proportional Loss-rate Differentiation: Predictability and Performance Ulf Bodin, Andreas Jonsson, Olov Schelen 11:00 Break 11:30 Session 8: Scheduling and Admission Control A Novel Scheduler For a low Delay Service Within Best-Effort Paul Hurley, Jean-Yves Le Boudec, Mourad Kara, Patrick Thiran JoBS: Joint Buffer Management and Scheduling for Differentiated Services Jorg Liebeherr, Nicolas Christin Optimal Call Admission Control under Generalized Processor Sharing Scheduling Antonis Panagakis, Ioannis Stavrakakis 13:00 Summary