From rsvp-owner@ISI.EDU Tue Feb 1 16:52:09 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05910 for ; Tue, 1 Feb 2000 16:52:06 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA17479 for rsvp-outgoing; Tue, 1 Feb 2000 11:22:58 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA17474 for ; Tue, 1 Feb 2000 11:22:56 -0800 (PST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA22028 for ; Tue, 1 Feb 2000 11:23:17 -0800 (PST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA16610; Tue, 1 Feb 2000 11:25:38 -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 LAA24844; Tue, 1 Feb 2000 11:26:44 -0800 Message-Id: <4.1.20000201111739.01a53aa0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 01 Feb 2000 11:20:46 -0800 To: Maria Elena Villapol From: Fred Baker Subject: Re: IETF Meeting Cc: RSVP , diffserv In-Reply-To: <38950FB1.6BEECF02@spri.levels.unisa.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rsvp@ISI.EDU Precedence: bulk At 02:59 PM 1/31/00 +1030, Maria Elena Villapol wrote: > > How could we get the work group scheduling (agenda) for the meeting? Are you on ietf-announce@ietf.org? If not, send a note to ietf-announce-request@ietf.org, and you should start receiving announcements of internet drafts, meetings, and the like. The agendas of the diff-serv and rsvp meetings should be posted on the diff-serv and rsvp mailing lists you can also find more meeting information at www.ietf.org, and more specifically, http://www.ietf.org/meetings/IETF-47.html. The agenda is not posted there as yet, but should be within the next few weeks. From rsvp-owner@ISI.EDU Tue Feb 1 22:06:23 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14187 for ; Tue, 1 Feb 2000 22:06:23 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA04327 for rsvp-outgoing; Tue, 1 Feb 2000 16:48:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA04321 for ; Tue, 1 Feb 2000 16:48:04 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA11887; Tue, 1 Feb 2000 16:48:11 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id AAA01623; Wed, 2 Feb 2000 00:48:11 GMT Date: Wed, 2 Feb 2000 00:48:11 GMT Message-Id: <200002020048.AAA01623@gra.isi.edu> To: rsvp@ISI.EDU, boomerang@soha.ttt.bme.hu, michael@tk.uni-linz.ac.at Subject: Re: QoSSIG BOF - now what are we trying to do? Cc: Istvan.I.Cselenyi@telia.se X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> *> Hi all, *> *> I have now seen various interpretations of what a QoSSIG WG should do; a *> few think of DiffServ (and/or IntServ), some (including me - or is it just *> me? ;) ) would like such a WG to work on stateless QoS signaling to make *> the most efficient use of the network without actual network-side QoS *> provisioning (this could be done with a "tweaked" RSVP, PTP or any other *> protocol that encompasses QoS-signaling) and others consider it a forum *> for a lightweight and more scalable resource reservation protocol. Even *> moving the problem to an intra-domain level as opposed to end2end has *> been requested. *> Stateless signaling. Hmmmm... maybe next we should work on bufferless reliable transport protocols. Seriously, the QoS architecture currently proposed that uses E2E RSVP signaling and aggregation in the core of the network *is* stateless signaling, at least in the parts of the network where statelessness is both necessary and possible. So, we are done. That is, as long as you don't want to do multicasting. People's estimate of the importance of multicasting varies; I suspect it is not large on your radar screen. Why do you think telephony over IP 20 years from now will be simply a rerun of what you have been doing for 100 years? Bob Braden From rsvp-owner@ISI.EDU Tue Feb 1 22:12:49 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14261 for ; Tue, 1 Feb 2000 22:12:48 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA04508 for rsvp-outgoing; Tue, 1 Feb 2000 16:53:29 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA04503 for ; Tue, 1 Feb 2000 16:53:28 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA12445; Tue, 1 Feb 2000 16:53:42 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id AAA01630; Wed, 2 Feb 2000 00:53:42 GMT Date: Wed, 2 Feb 2000 00:53:42 GMT Message-Id: <200002020053.AAA01630@gra.isi.edu> To: campbell@comet.columbia.edu, Zoltan.Turanyi@eth.ericsson.se Subject: Re: [Diffserv] QoSSIG BOF now After diffserv, ...... Cc: lixia@cs.ucla.edu, yoramb@Exchange.Microsoft.com, Joakim.F.Bergkvist@telia.se, rsvp@ISI.EDU, end2end-interest@ISI.EDU, mnl@comet.columbia.edu X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> Andrew, *> *> Beforehand I must state that in no way am I an ATM fan. But I still *> believe that in some cases separating the interface between the host and *> the network from the interface between network nodes is a good idea. *> This separates two businesses: OS/Apps and networking and makes much *> easier to change or modify networking protocols. It also allows local *> domains to use whatever protocol they wish without affecting hosts. This *> thing is also called modularity. *> *> Besides, the idea is already used. Indeed it is. It (the host/network interface) is called X.25. We've been there, and that experience helped the decision in RSVP to use basically the SAME protocol for both the DCE/DTE and the DCE/DCE communication. I have not seen any strong reason to think this was the wrong decision. For one thing, it handles the DTE/DTE case without fuss. Bob Braden From rsvp-owner@ISI.EDU Wed Feb 2 01:09:45 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17566 for ; Wed, 2 Feb 2000 01:09:44 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id TAA11632 for rsvp-outgoing; Tue, 1 Feb 2000 19:58:10 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id TAA11627 for ; Tue, 1 Feb 2000 19:58:09 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA25767; Tue, 1 Feb 2000 19:58:29 -0800 (PST) From: Masataka Ohta Message-Id: <200002020358.MAA15921@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA15921; Wed, 2 Feb 2000 12:58:05 +0900 Subject: Re: QoSSIG BOF - now what are we trying to do? To: braden@ISI.EDU (Bob Braden) Date: Wed, 2 Feb 0 12:58:05 JST Cc: rsvp@ISI.EDU, boomerang@soha.ttt.bme.hu, michael@tk.uni-linz.ac.at, Istvan.I.Cselenyi@telia.se In-Reply-To: <200002020048.AAA01623@gra.isi.edu>; from "Bob Braden" at Feb 2, 100 10:32 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-rsvp@ISI.EDU Precedence: bulk Bob; > Stateless signaling. Hmmmm... maybe next we should work on bufferless > reliable transport protocols. You can send packets repeartedly until acknowledged with no windows. The standard protocol is called TFTP. So, we are done. What's next? Shall we disband IETF or the transport area of it? > Seriously, the QoS architecture currently proposed that uses E2E RSVP > signaling and aggregation in the core of the network *is* stateless > signaling, at least in the parts of the network where statelessness is > both necessary and possible. What do you mean? The currently proposed CoS architechture has nothing to do with QoS. > That is, as long as you don't want to do multicasting. Multicast is not an only factor to make QoS assurance stateful. Masataka Ohta From rsvp-owner@ISI.EDU Wed Feb 2 03:05:17 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00834 for ; Wed, 2 Feb 2000 03:05:15 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id VAA14826 for rsvp-outgoing; Tue, 1 Feb 2000 21:49:43 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id VAA14821 for ; Tue, 1 Feb 2000 21:49:41 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA02163 for ; Tue, 1 Feb 2000 21:50:02 -0800 (PST) Received: from pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id VAA23921; Tue, 1 Feb 2000 21:49:49 -0800 (PST) Message-ID: <3897C57B.83B200DF@pluris.com> Date: Tue, 01 Feb 2000 21:49:47 -0800 From: Bora Akyol X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Istvan.I.Cselenyi@telia.se CC: pingpan@research.bell-labs.com, Zoltan.Turanyi@eth.ericsson.se, RSVP Subject: Re: [Diffserv] QoSSIG BOF - sceleton References: <200001251336.OAA09699@malmo.trab.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Frankly, I think we should focus on reinventing UNI/PNNI for the MPLS world and then we can reinvent it one more time for IP, just got to keep everyone busy. Also we *must* remember to change the name since otherwise we may look like we are not earning our keep. As far as I am concerned, there are two types of signaling protocols, soft-state and hard-state. RSVP without HELLO extension is a soft-state signaling protocol that can be extended rather easily as MPLS extensions have shown. It is well-understood. UNI/PNNI is a set of hard-state protocols that were developed for ATM but essentially are used to establish flows and QoS contracts within a network. Moreover, UNI essentially can be made to run over a connectionless network akin to TCP/IP. If you look at these protocols you will find that they meet the signaling requirements for a variety of environments. I think that instead of getting hung up on yet another signaling protocol, we should focus on the information that needs to get distributed and efficient (compact) ways of representing that information both between domains (or ASs) or within a domain. Once, the information we need to distribute is well-understood, the appropriate mechanisms will be easier to develop. I believe that at least the policy WG is working on this. Also, I worry about the network operator acceptance of automated signaling and negotiation protocols for communication between domains since anything dynamic exposes risk and stability issues. Regards Bora Akyol Sorry, could not resist. Bora Istvan Cselenyi wrote: > Hi all, > > I think we are getting closer to an agreement on the sceleton of the > QoSSIG BOF. > > The goal is to "give fresh blood to QoS Signaling". Thus we shall call for > presentation of alternative protocols which are solving specific > *problems* what RSVP is facing with today or within some years. The > problems shall be well defined and mapped to current RSVP work. > Moreover the proposed concepts shall be verified based on > implementation or simulations. > > Before and after the BOF we can identify the functionality really needed > for resource reservation, as many proposed. This result of the BOF and > related discussions is a framework for future QoS siginaling (which can > be used either for RSVP version 2 or for making a brandnew signaling > protocol depending on what is the faster and more effective approach). > > Do you like it? > > Istvan > > some comments to Yoram .... > > > > The danger with looking only at RSVP could be that we do not realize > > > its drawbacks. > > Interesting. I would suggest that the best way to see the drawbacks of RSVP > > are to look at RSVP. Perhaps you meant something else? > > Nono, I meant what I wrote (as you probably see) but let's take a > methaphore: most parents believe that their kid is the best one in the > universe thus you need outsiders to get real critique. It's human nature. > > > I propose to start with discussing a framework which > > > outlines what functionality and scaling we will actually need > > > in the area > > > of resource reservation within a few years. > > > > OK - no objection here. > > > > > We should really work together in a constructive way and let the good- > > > old RSVP to get some blood-transfusion from new-commer light-weight > > > protocols, otherwise people will think that only a miracle > > > can make QoS > > > signaling happen :-) > > > > I'm all for that! Let me suggest that the newcomers should acquaint > > themselves well with recent RSVP work and should be able to make a clear > > statement as to exactly what 'problems' in RSVP they will be fixing. > > (Thanks for patronizing...) > > -------------------------------------------------- > Istvan Cselenyi > Telia Research AB Phone: +46-8-7138173 > Vitsandsgatan 9 B431 Fax: +46-8-7138199 > S-12386 Farsta Mobile: +46-70-3228801 > Sweden E-mail: Istvan.I.Cselenyi@telia.se > -------------------------------------------------- From rsvp-owner@ISI.EDU Wed Feb 2 05:44:56 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02564 for ; Wed, 2 Feb 2000 05:44:55 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id AAA19320 for rsvp-outgoing; Wed, 2 Feb 2000 00:14:30 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id AAA19315 for ; Wed, 2 Feb 2000 00:14:28 -0800 (PST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA09615; Wed, 2 Feb 2000 00:14:48 -0800 (PST) Received: from telia.se (dhcp4199.haninge.trab.se [131.115.157.199]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id JAA10947; Wed, 2 Feb 2000 09:14:46 +0100 (MET) Message-ID: <3897E774.6BA6A178@telia.se> Date: Wed, 02 Feb 2000 09:14:44 +0100 From: Joakim Bergkvist X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Braden CC: rsvp@ISI.EDU, boomerang@soha.ttt.bme.hu, michael@tk.uni-linz.ac.at, Istvan.I.Cselenyi@telia.se, Joakim.F.Bergkvist@telia.se Subject: Re: [Boomerang] Re: QoSSIG BOF - now what are we trying to do? References: <200002020048.AAA01623@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: > Seriously, the QoS architecture currently proposed that uses E2E RSVP > signaling and aggregation in the core of the network *is* stateless > signaling, at least in the parts of the network where statelessness is > both necessary and possible. > > So, we are done. From current RSVP proposals stateless would mean not to touch.We are talking about nodes doing CAC without signaling states. If this is done in RSVP you must give me a pointer where to find it. > > That is, as long as you don't want to do multicasting. People's > estimate of the importance of multicasting varies; I suspect it is not > large on your radar screen. Why do you think telephony over IP 20 > years from now will be simply a rerun of what you have been doing for > 100 years? > > Bob Braden You can do multicast reservations even without signaling states.. What you can't do is multicast with heterogenous destinations. I still think we need a forum in the IETF in which to discuss these issues. It may well be that stateless nodes could be integrated in RSVP but RSVP was not designed for this. With this in mind I beleive a good startingpoint would be a framework to outline the possibilities without the legacy of RSVP. / Jocke > > _______________________________________________ > Boomerang mailing list > http://soha.ttt.bme.hu/mailman/listinfo/boomerang From rsvp-owner@ISI.EDU Wed Feb 2 14:33:25 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19139 for ; Wed, 2 Feb 2000 14:33:23 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id IAA03639 for rsvp-outgoing; Wed, 2 Feb 2000 08:27:04 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id IAA03634 for ; Wed, 2 Feb 2000 08:27:02 -0800 (PST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA00553 for ; Wed, 2 Feb 2000 08:27:22 -0800 (PST) Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id RAA28359; Wed, 2 Feb 2000 17:27:09 +0100 (MET) Message-Id: <200002021627.RAA28359@malmo.trab.se> From: "Istvan Cselenyi" To: Bora Akyol Date: Wed, 2 Feb 2000 17:27:13 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [Diffserv] QoSSIG BOF - sceleton Reply-to: Istvan.I.Cselenyi@telia.se CC: boomerang@soha.ttt.bme.hu, pingpan@research.bell-labs.com, Zoltan.Turanyi@eth.ericsson.se, RSVP Priority: normal In-reply-to: <3897C57B.83B200DF@pluris.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Bora, My comments are inserted below... > Frankly, I think we should focus on reinventing UNI/PNNI for the MPLS world and > then we can reinvent it one more time for IP, just got to keep everyone busy. > Also we *must* remember to change the name since otherwise we may look like we > are not earning our keep. :-) You are kidding, aren't you? > As far as I am concerned, there are two types of signaling protocols, soft-state > and hard-state. ... and stateless, such as the six DSCP bits in DiffServ, which signal the required treatment for each packet without forcing the routers to store states for the sake of signaling > RSVP without HELLO extension is a soft-state signaling protocol > that can be extended rather easily as MPLS extensions have shown. It is > well-understood. UNI/PNNI is a set of hard-state protocols that were developed > for ATM but essentially are used to establish flows and QoS contracts within a > network. Moreover, UNI essentially can be made to run over a connectionless > network akin to TCP/IP. > > If you look at these protocols you will find that they meet the signaling > requirements for a variety of environments. Yes, but there is a point when one shall get some fresh air before going further. > I think that instead of getting hung up on yet another signaling protocol, we > should focus on the information that needs to get distributed and efficient > (compact) ways of representing that information both between domains (or ASs) or > within a domain. Once, the information we need to distribute is well-understood, > the appropriate mechanisms will be easier to develop. I believe that at least the > policy WG is working on this. I think QoS signaling protocols and the QoS related info they carry are orthogonal in most cases. Thus if the Policy WG is already defining the QoS info objects we could look at the enhancement of signaling protocols in our BOF. > Also, I worry about the network operator acceptance of automated signaling and > negotiation protocols for communication between domains since anything dynamic > exposes risk and stability issues. I see your point, but there are already a couple of autonomous and dynamic solutions in internet and operators still like it :-) Regards Istvan > > > Istvan Cselenyi wrote: > > > Hi all, > > > > I think we are getting closer to an agreement on the sceleton of the > > QoSSIG BOF. > > > > The goal is to "give fresh blood to QoS Signaling". Thus we shall call for > > presentation of alternative protocols which are solving specific > > *problems* what RSVP is facing with today or within some years. The > > problems shall be well defined and mapped to current RSVP work. > > Moreover the proposed concepts shall be verified based on > > implementation or simulations. > > > > Before and after the BOF we can identify the functionality really needed > > for resource reservation, as many proposed. This result of the BOF and > > related discussions is a framework for future QoS siginaling (which can > > be used either for RSVP version 2 or for making a brandnew signaling > > protocol depending on what is the faster and more effective approach). > > > > Do you like it? > > > > Istvan > > > > some comments to Yoram .... > > > > > > The danger with looking only at RSVP could be that we do not realize > > > > its drawbacks. > > > Interesting. I would suggest that the best way to see the drawbacks of RSVP > > > are to look at RSVP. Perhaps you meant something else? > > > > Nono, I meant what I wrote (as you probably see) but let's take a > > methaphore: most parents believe that their kid is the best one in the > > universe thus you need outsiders to get real critique. It's human nature. > > > > > I propose to start with discussing a framework which > > > > outlines what functionality and scaling we will actually need > > > > in the area > > > > of resource reservation within a few years. > > > > > > OK - no objection here. > > > > > > > We should really work together in a constructive way and let the good- > > > > old RSVP to get some blood-transfusion from new-commer light-weight > > > > protocols, otherwise people will think that only a miracle > > > > can make QoS > > > > signaling happen :-) > > > > > > I'm all for that! Let me suggest that the newcomers should acquaint > > > themselves well with recent RSVP work and should be able to make a clear > > > statement as to exactly what 'problems' in RSVP they will be fixing. > > > > (Thanks for patronizing...) > > > > -------------------------------------------------- > > Istvan Cselenyi > > Telia Research AB Phone: +46-8-7138173 > > Vitsandsgatan 9 B431 Fax: +46-8-7138199 > > S-12386 Farsta Mobile: +46-70-3228801 > > Sweden E-mail: Istvan.I.Cselenyi@telia.se > > -------------------------------------------------- -------------------------------------------------- Istvan Cselenyi Telia Research AB Phone: +46-8-7138173 Vitsandsgatan 9 B431 Fax: +46-8-7138199 S-12386 Farsta Mobile: +46-70-3228801 Sweden E-mail: Istvan.I.Cselenyi@telia.se -------------------------------------------------- From rsvp-owner@ISI.EDU Wed Feb 2 15:02:53 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19873 for ; Wed, 2 Feb 2000 15:02:51 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA05330 for rsvp-outgoing; Wed, 2 Feb 2000 09:18:11 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA05325 for ; Wed, 2 Feb 2000 09:18:09 -0800 (PST) Received: from kid.isi.edu (root@kid.isi.edu [128.9.160.80]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA05156; Wed, 2 Feb 2000 09:18:30 -0800 (PST) From: Steven Berson Received: from localhost (berson@localhost) by kid.isi.edu (8.9.3/8.9.3) with ESMTP id JAA20247; Wed, 2 Feb 2000 09:16:52 -0800 X-Authentication-Warning: kid.isi.edu: berson owned process doing -bs Date: Wed, 2 Feb 2000 09:16:52 -0800 (PST) To: Joakim Bergkvist cc: Bob Braden , rsvp@ISI.EDU, boomerang@soha.ttt.bme.hu, michael@tk.uni-linz.ac.at, Istvan.I.Cselenyi@telia.se Subject: Re: [Boomerang] Re: QoSSIG BOF - now what are we trying to do? In-Reply-To: <3897E774.6BA6A178@telia.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk On Wed, 2 Feb 2000, Joakim Bergkvist wrote: > Bob Braden wrote: > > > Seriously, the QoS architecture currently proposed that uses E2E RSVP > > signaling and aggregation in the core of the network *is* stateless > > signaling, at least in the parts of the network where statelessness is > > both necessary and possible. > > > > So, we are done. > > From current RSVP proposals stateless would mean not to touch.We > are talking about nodes doing CAC without signaling states. If > this is done in RSVP you must give me a pointer where to find it. There is our work on state aggregation for RSVP, ``Aggregation of Internet Integrated Services State'' which describes how to greatly reduce the amount of signalling state. Quoting from the draft: This draft describes how to provide Internet Integrated Services for both unicast and multicast traffic with greatly reduced state requirements. We concentrate primarily on Controlled Load type service[10], which reserves bandwidth but not delay or jitter, though our approach should be more generally applicable (see [7] for a related approach). With our approach, the amount of scheduler state is bounded at all nodes for both unicast and multicast traffic. For unicast traffic, full classifier state and setup protocol state are stored only at the edges of the network. In the interior of the network, no unicast setup protocol state is stored, and only a bounded amount of classifier state is used. For multicast traffic, a minimal amount of additional classifier state and additional setup protocol state is used in the network interior. The draft is available from the RSVP web page: http://www.isi.edu/rsvp > > That is, as long as you don't want to do multicasting. People's > > estimate of the importance of multicasting varies; I suspect it is not > > large on your radar screen. Why do you think telephony over IP 20 > > years from now will be simply a rerun of what you have been doing for > > 100 years? > > > > Bob Braden > > You can do multicast reservations even without signaling states. It appears that you have read the draft. > What you can't do is multicast with heterogenous destinations. But what you can do is to store only the minimum amount of state and only at the specific points of heterogeneous branching. Doing this allows you to support multicast with heterogeneous destinations. > I still think we need a forum in the IETF in which to discuss > these issues. It may well be that stateless nodes could be > integrated in RSVP but RSVP was not designed for this. With this > in mind I beleive a good startingpoint would be a framework to > outline the possibilities without the legacy of RSVP. > > / Jocke Regards, Steve From rsvp-owner@ISI.EDU Wed Feb 2 16:45:16 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22176 for ; Wed, 2 Feb 2000 16:45:15 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA11037 for rsvp-outgoing; Wed, 2 Feb 2000 11:35:44 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11028 for ; Wed, 2 Feb 2000 11:35:42 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA22285; Wed, 2 Feb 2000 11:36:03 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Feb 2 14:35:52 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA08293; Wed, 2 Feb 2000 14:35:46 -0500 (EST) Message-ID: <38988656.8788B4E4@research.bell-labs.com> Date: Wed, 02 Feb 2000 14:32:39 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: michael@tk.uni-linz.ac.at CC: lewis@gennet.com.tw, end2end-interest@ISI.EDU, "'RSVP'" Subject: Re: QoSSIG BOF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Michael Welzl wrote: > > > RSVP and other proposals (BGRP, YESSIR...) are signaling protocols to > > distribute resource information between end hosts and > > routers. But IMO, > > they do NOT apply the actual reservation, packet queuing, buffer > > management, scheduling and classification. > > > > - Ping > > RSVP may not apply the reservation, but it relies on it to function. > Without reservation, how could RSVP generate a ResvErr message with > Error Code 1, Sub-code 2: Requested bandwidth unavailable, for example? > The definition of "available bandwidth" changes dramatically without > resource reservation. > > Regards, > Michael Welzl Micheal, When people use RSVP to setup MPLS, each LSP can have ZERO bandwidth. Please check the draft in MPLS WG. In we are only talking about bandwidth reservation, then state scaling problem is that serious at this point. But when we use it to setup virtual connections all over the network, then we need to be careful. BR -- Ping Pan http://www.cs.columbia.edu/~pingpan From rsvp-owner@ISI.EDU Wed Feb 2 17:19:48 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22877 for ; Wed, 2 Feb 2000 17:19:46 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA11915 for rsvp-outgoing; Wed, 2 Feb 2000 11:57:45 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA11907 for ; Wed, 2 Feb 2000 11:57:43 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id LAA27093; Wed, 2 Feb 2000 11:58:03 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Feb 2 14:57:04 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA09248; Wed, 2 Feb 2000 14:56:34 -0500 (EST) Message-ID: <38988B2D.5A568024@research.bell-labs.com> Date: Wed, 02 Feb 2000 14:53:17 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: James_Binder@3com.com CC: RSVP , end2end-interest@ISI.EDU Subject: Re: [Diffserv] QoSSIG BOF References: <88256871.007AF25D.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit James_Binder@3com.com wrote: > > Ping, > > Reading this chart, some interesting information stands out for me. First (and > it may be too early to really judge from the limited data points given) but, it > looks like the number of networks has begun to flatten out. While, Hosts and > Domains continue to rise to to the right at about the same slope. In addition, > eventhough we are increasing compacity of the networks (ie., WDM, dWDM, ect.), > if the trend contineus, host will overrun the core (even at the mutligig > speeds). This leads me to the agreement(s) I've heard here (as well as in other > forum) where the best would be a combination of protocols (ie., QoS(RSVP like) > at the edge to support host requirements and CoS (DS) in the core for use as > well as scaleability. > ;-) We indeed proposed a hierarchical architecture here: end-user driven reservation protocols at user network, and an inter-domain reservation protocol at core. I have heard the argument of using DiffServ at core. Here are my questions: In RFC2597 (AF PHB):"... A DS node MUST allocate a configurable, minimum amount of forwarding resources (buffer space and bandwidth) to each implemented AF class. Each class SHOULD be serviced in a manner to achieve the configured service rate (bandwidth) over both small and large time scales...." IN RFC2598 (EF PHB):"... Creating such a service has two parts: 1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.) 2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate. ..." I also heard that all network interior routers need to provide traffic conditioning functionality (policing/shaping, etc.). That means the routers need to be aware of the rates associated with each PHB. (Look: this is Frame Relay CIR/Bc/Be all over again essentially. ;-)) Question: Who set up the rate for each PHB in the core? Don't tell me we are setting them by hand. ;-) I think that BGRP (or other backbone resource management mechanism) is responsible for setting up and maintain the rate at routers. I don't believe these reservation states change a lot over time. but they need to be maintained regardless (to avoid route flapping for example). BTW, while we are making assumption on using DiffServ at core, can someone please provide some information on the DiffServ deployment plan/experience? Like to know how it works. Thanks in advance! BR, - Ping P.S.: I am not forwarding this to the DiffServ list per request. From rsvp-owner@ISI.EDU Wed Feb 2 17:30:46 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22949 for ; Wed, 2 Feb 2000 17:30:45 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA13081 for rsvp-outgoing; Wed, 2 Feb 2000 12:23:45 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA13073 for ; Wed, 2 Feb 2000 12:23:43 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA00763; Wed, 2 Feb 2000 12:24:03 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Feb 2 15:22:43 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA10431; Wed, 2 Feb 2000 15:22:41 -0500 (EST) Message-ID: <38989143.2B51628A@research.bell-labs.com> Date: Wed, 02 Feb 2000 15:19:15 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Bob Braden CC: campbell@comet.columbia.edu, Zoltan.Turanyi@eth.ericsson.se, lixia@cs.ucla.edu, yoramb@Exchange.Microsoft.com, Joakim.F.Bergkvist@telia.se, rsvp@ISI.EDU, end2end-interest@ISI.EDU, mnl@comet.columbia.edu Subject: Re: [Diffserv] QoSSIG BOF now After diffserv, ...... References: <200002020053.AAA01630@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Bob Braden wrote: > > > We've been there, and that experience helped the decision in RSVP to > use basically the SAME protocol for both the DCE/DTE and the DCE/DCE > communication. I have not seen any strong reason to think this was > the wrong decision. For one thing, it handles the DTE/DTE case > without fuss. > Agree. The original idea of Host vs Network is like a conspiracy by the telco's to limit customer's access and selection so that they can charge their usual retail prices to end-users. The concept was defined in telco's interest, but is not meant for the Internet. In our proposed model, users have the choice to subscribe service from more than one ISP and have the choice to put their data through any inter-domain reservation "tunnel". RSVP and other end-user drive reservation protocols fit in this model without a problem. For example in RSVP, to across an inter-domain reservation interconnecting network X and Y, RSVP can simply allow the Next-Hop to point to Y, and Previous-Hop to point to X. That's it! BR, -- Ping Pan http://www.cs.columbia.edu/~pingpan From rsvp-owner@ISI.EDU Thu Feb 3 07:39:06 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15026 for ; Thu, 3 Feb 2000 07:39:05 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id CAA08914 for rsvp-outgoing; Thu, 3 Feb 2000 02:05:36 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id CAA08905 for ; Thu, 3 Feb 2000 02:05:34 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id CAA21243; Thu, 3 Feb 2000 02:05:54 -0800 (PST) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id LAA12415; Thu, 3 Feb 2000 11:05:49 +0100 (MET) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA13582; Thu, 3 Feb 2000 11:05:43 +0100 (MET) Message-ID: <389952F6.1816EE16@eth.ericsson.se> Date: Thu, 03 Feb 2000 11:05:42 +0100 From: Zoltan Richard Turanyi Organization: Ericsson TrafficLab X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Hungarian, hu, en MIME-Version: 1.0 To: Ping Pan CC: Bob Braden , campbell@comet.columbia.edu, lixia@cs.ucla.edu, yoramb@Exchange.Microsoft.com, Joakim.F.Bergkvist@telia.se, rsvp@ISI.EDU, end2end-interest@ISI.EDU, mnl@comet.columbia.edu Subject: Re: [Diffserv] QoSSIG BOF now After diffserv, ...... References: <200002020053.AAA01630@gra.isi.edu> <38989143.2B51628A@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Ping Pan wrote: > > Bob Braden wrote: > > > > > > We've been there, and that experience helped the decision in RSVP to > > use basically the SAME protocol for both the DCE/DTE and the DCE/DCE > > communication. I have not seen any strong reason to think this was > > the wrong decision. For one thing, it handles the DTE/DTE case > > without fuss. > > > > Agree. The original idea of Host vs Network is like a conspiracy by the > telco's to limit customer's access and selection so that they can charge > their usual retail prices to end-users. The concept was defined in > telco's interest, but is not meant for the Internet. Gentlemen, please. Separating Network-Host and Network-Network (or Router-Router) interface (in general not only in case of QoS) has *technical* merits. It allows the easy deployment of different mechanism in the network without affecting the end systems. (Remember: You can use whatever multicast routing protocol you wish without changing the hosts. IGMP is used on the Host-Network interface and the multicast routing protocol is used on the Router-Router interface. That clearly has benefits.) Again: I do not care what was the reason for this separation in ATM, X.25 or whatever. Had RSVP/Intserv been designed like this, now it would be much easier to employ different mechanisms in different domains. But, perhaps it is not a requirement and should not be an issue. Finally: I accept that the people developing RSVP had really thought this issue through and rejected it if Bob says so. I just wanted to point out that the idea is not a complete nonsense from the technical point of view and is not only a devil telco invention. /Zoltan -- Zoltan Richard Turanyi Research Fellow, Ericsson Hungary Traffic Analysis and Network Performance Lab From rsvp-owner@ISI.EDU Thu Feb 3 08:27:05 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17142 for ; Thu, 3 Feb 2000 08:27:05 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA10758 for rsvp-outgoing; Thu, 3 Feb 2000 03:10:47 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA10751 for ; Thu, 3 Feb 2000 03:10:45 -0800 (PST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA23785; Thu, 3 Feb 2000 03:11:05 -0800 (PST) From: Masataka Ohta Message-Id: <200002031103.UAA23773@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA23773; Thu, 3 Feb 2000 20:03:05 +0900 Subject: Re: [Diffserv] QoSSIG BOF now After diffserv, ...... To: Zoltan.Turanyi@eth.ericsson.se (Zoltan Richard Turanyi) Date: Thu, 3 Feb 0 20:03:05 JST Cc: pingpan@research.bell-labs.com, braden@ISI.EDU, campbell@comet.columbia.edu, lixia@cs.ucla.edu, yoramb@Exchange.Microsoft.com, Joakim.F.Bergkvist@telia.se, rsvp@ISI.EDU, end2end-interest@ISI.EDU, mnl@comet.columbia.edu In-Reply-To: <389952F6.1816EE16@eth.ericsson.se>; from "Zoltan Richard Turanyi" at Feb 3, 100 7:52 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-rsvp@ISI.EDU Precedence: bulk Zoltan; > Gentlemen, please. Separating Network-Host and Network-Network (or > Router-Router) interface (in general not only in case of QoS) has > *technical* merits. It allows the easy deployment of different mechanism > in the network without affecting the end systems. (Remember: You can use > whatever multicast routing protocol you wish without changing the hosts. > IGMP is used on the Host-Network interface and the multicast routing > protocol is used on the Router-Router interface. That clearly has > benefits.) Wrong. As it is clearly demonstrated by IGMP and RSVP,if you want to allow whatever multicast routing protocl you wish, Network-Host protocol (IGMP) or multicast-related Network-Network protocol (RSVP) must be compatible with all the possible (including those which does not scale at all) Network-Network multicast routing protocols, which makes the Network-Host protocol (IGMP) or the multicast-related Network-Network protocol (RSVP) unnecessarily complex and, worse, not scalable. > Finally: I accept that the people developing RSVP had really thought > this issue through and rejected it if Bob says so. They did not rejected it w.r.t. multicast routing protocols. Masataka Ohta From rsvp-owner@ISI.EDU Fri Feb 4 13:40:28 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06063 for ; Fri, 4 Feb 2000 13:40:28 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA29416 for rsvp-outgoing; Fri, 4 Feb 2000 07:15:46 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id HAA29411 for ; Fri, 4 Feb 2000 07:15:44 -0800 (PST) Received: from miles.datcon.co.uk (smtp2.datcon.co.uk [192.91.191.8]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id HAA01858 for ; Fri, 4 Feb 2000 07:15:44 -0800 (PST) Received: by MILES with Internet Mail Service (5.5.2650.21) id <1C6PCFZY>; Fri, 4 Feb 2000 15:14:57 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E140044@monk.datcon.co.uk> From: Adrian Farrel To: lberger@labn.net Cc: rsvp@ISI.EDU Subject: Comments on draft-ietf-rsvp-refresh-reduct-02.txt Date: Fri, 4 Feb 2000 15:14:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk Lou et al, Good job with the latest version of the draft. I have a few very minor questions and editorial points, and a bunch of typos (sorry, I can't read a draft w/o marking up typos!) Hope this is of use. Regards, Adrian 1) Discovery that neighbor supports bundling. Section 3.3 suggests using configuration to discover that the neighbor supports bundling. Is this of any use given that the neighbor may change its support at any time and indicate the fact using the RRC bit? Are you just covering a possible implementation where it is well known what the behavior of the neighbor is so that it is never necessary to examine the RRC bit? If so, this is in contradiction with section 2 that says that the node MUST examine the RRO on every received message. 2) Refresh period/ Refresh delay Section 3 suggests that refresh messages may be delayed up to their refresh interval. This isn't clear to me. Are you saying that a refresh message that is generated _before_ the refresh timer pops can be delayed up until the time that the timer pops? Or are you saying that a refresh message that is generated when a refresh timer pops can be delayed up to at most another time period equal to the value of the refresh timer? 3) Bundle message Send_TTL Section 3.4 says that the Send_TTL is used to calculate the number of non-IP hops, and that this is used later in processing sub-messages. The same section says that each sub-message is processed as if it was received individually. Since each sub-message also contains a Send_TTL, what is the use of the Bundle Send_TTL? 4) Message Acknowledgement The last paragraph of section 4 says... Each message containing an MESSAGE_ID object may be acknowledged via a MESSAGE_ID_ACK object. Is "may be" too generous? An Ack may only be sent if the MESSAGE_ID object requests an Ack. 5) Epoch I think the definition in 4.2 would benefit from some of the text in 4.5. In particular: - include "the RSVP agent restarts" with the "node reboots" - the value SHOULD be different from the last time the node cycled 6) Message_Identifier Section 4 para 2 makes this unique within a sender/receiver pairing. The definition in 4.2 says that it is unique for a sender. Although this is unlikely to make a difference to the implementation at a receiver, it does make a difference to sender and line trace implementations. 7) MESSAGE_ID_NACK object See section 4.3 Is there scope for a reason code? There may be no use at the moment, but this looks good for future extensions. 8) Epoch value Section 4.5 para 3... On startup, a node SHOULD randomly select a value to be used in the Epoch field. The node SHOULD ensure that the selected value is not the same as was used when the node was last operational. - Why is it important that the assignment is random? The important bit is to try to keep the value different from previous use. Perhaps you should use RECOMMEND? - Is the previous use the only value to avoid? Might it be desirable to avoid several previous values, especially if the RSVP agent is cycled several times in quick succession? 9) Message_Identifier value See section 4.5, para 4... When a node is sending a trigger message, the Message_Identifier value MUST have a value that is greater than any other previously used value. This is within the scope of the current value of Epoch, right? Perhaps the text should say so. 10) Message_Identifier presence Section 5.1 Is it worth stating that at least one Message_Identifier must be present in the MESSAGE_ID LIST object? Ditto MESSAGE_ID SRC_LIST and MCAST_LIST. 11) Srefresh NACK I think it would help to add clarification that the MESSAGE_ID_NACK refers to the Message_Identifier in the (e.g.) MESSAGE_ID LIST object of the Srefresh, *not* to the Message_Identifier in the MESSAGE_ID object of the Srefresh. Perhaps it would also be useful to add a section on "Acknowledgement of Srefresh" to clarify what is meant by an Ack of an Srefresh (which may be requested through the flags in the MESSAGE_ID object in the Srefresh. In particular, an Ack of an Srefresh may still be followed by some MESSAGE_ID_NACKs relating to Message_Identifiers carried by the Srefresh. _Typos_ section 2. Flags. First line. Delete "to" to read "when set, indicates that this..." section 3.3. 2nd para. penultimate line. For "MUST not" read "MUST NOT" section 3.4. 1st line. For "an Bundle" read "a Bundle" section 4. final para. For "an MESSAGE_ID" read "a MESSAGE_ID" section 4.6, final para. final sentence should be clause of previous sentence. Read "...and longer time, although additional..." section 5.3, p27 last para. For "an MESSAGE_ID LIST" read "a MESSAGE_ID LIST" section 5.4 first line. For "indicated" read "indicate" -- Adrian Farrel mailto:af@datcon.co.uk ATM, MPLS and Telecoms Development Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From rsvp-owner@ISI.EDU Fri Feb 4 17:52:37 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12229 for ; Fri, 4 Feb 2000 17:52:36 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA11859 for rsvp-outgoing; Fri, 4 Feb 2000 12:28:23 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA11854 for ; Fri, 4 Feb 2000 12:28:22 -0800 (PST) Received: from public.sq.js.cn ([202.102.48.144]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA14728 for ; Fri, 4 Feb 2000 12:28:22 -0800 (PST) Received: from default ([202.102.60.112]) by public.sq.js.cn (Netscape Messaging Server 4.05) with ESMTP id FPFA3901.K2I; Sat, 5 Feb 2000 04:25:57 +0800 From: "新年好" <888@ISI.EDU> Reply-To: 888@ISI.EDU Subject: 世纪2000网上商城恭祝大家新年好，赠送18K镀金戒指。 To: 888@sq.js.cn X-Mailer: V3,1,6,1 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Sun, 04 Jul 1999 20:20:01 +0800 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by zephyr.isi.edu id MAA11855 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit 网友、朋友，大家新年好 盐城世纪2000网上商城恭喜新年发大财！ 在这辞旧迎新的时刻，我们特举办登陆“盐城世纪 2000网上商城，送18K镀金戒指活动。只要在我们 商城订阅我们的邮件列表，并进入礼品城选择一枚 你喜欢的戒指，然后寄包装邮寄费9元，即可获赠一 枚香港产价值88元左右的18K镀金一枚，每个邮件 地址限一枚。 商城通讯设备城新到日本九洲通讯公司荣誉出品的 九洲600型10-30公里远距离无绳电话，主机小巧精 美，全电脑芯片制作，手机大小1：1于三星600大 哥大，高频点230MHZ，液晶显示对方来电，10个已 接、10个未接、10个拨出电话储存。 采用三级发射技术，复杂地带通讯效果更有保障。 主机与手机通讯不计费，是家中与商店、单位通讯 的最佳选择。 在春节期间，每位订阅列表的网友可以批发价购买 一台该产品。 详细请到盐城世纪2000网上商城查看。 http://sj2000.126.com http://sj2000.yeah.net 春节值班电话：0515-3252091 13003488568 春节值班：市场部：陈小姐 From rsvp-owner@ISI.EDU Sun Feb 6 18:15:34 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13542 for ; Sun, 6 Feb 2000 18:15:34 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA02712 for rsvp-outgoing; Sun, 6 Feb 2000 12:05:32 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA02707 for ; Sun, 6 Feb 2000 12:05:31 -0800 (PST) Received: from hotmail.com (law-f111.hotmail.com [209.185.131.174]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id MAA10475 for ; Sun, 6 Feb 2000 12:05:32 -0800 (PST) Received: (qmail 81405 invoked by uid 0); 6 Feb 2000 20:05:01 -0000 Message-ID: <20000206200501.81404.qmail@hotmail.com> Received: from 63.14.253.43 by www.hotmail.com with HTTP; Sun, 06 Feb 2000 12:05:01 PST X-Originating-IP: [63.14.253.43] From: "SEOW LING ONG" To: mohta@necom830.hpcl.titech.ac.jp, pingpan@research.bell-labs.com Cc: J.Crowcroft@cs.ucl.ac.uk, pingpan@dnrc.bell-labs.com, curtis@avici.com, rsvp@ISI.EDU, mpls@uu.net, diffserv@ietf.org, te-wg@uu.net, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Subject: Re: [Why am I receiving all your mails.... Date: Sun, 06 Feb 2000 20:05:01 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk Hello, Whoever your people are.... I seems to be recieveing all your mails communicating with each other but I DON'T EVEN KNOW YOU PEOPLE. I also realise that my email address is not in your communication but the true fact is I have been recieving hundreds of your mails in the pass few months. Please check your system and make sure I don't recieve them again. I am getting sick and tired of deleting all these junk mails! Thanks. >From: Masataka Ohta >To: pingpan@research.bell-labs.com (Ping Pan) >CC: J.Crowcroft@cs.ucl.ac.uk, pingpan@dnrc.bell-labs.com, curtis@avici.com, > rsvp@ISI.EDU, mpls@uu.net, diffserv@ietf.org, te-wg@uu.net, >schulzrinne@cs.columbia.edu, hahne@bell-labs.com >Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource >management >Date: Wed, 19 Jan 0 8:37:47 JST > >Ping Pan; > > > > hmm - interesting - thouhg i am still not sure why you can't work on > > > an evolutionary path with RSVP rather than a whole new protocol > > > > > > > We've tried very hard to address the scaling problem with RSVP in the > > past year or so. Lou Berger, George Swallow, Lixia (and her students) > > and us have tried to enhance RSVP soft-state properties in various > > drafts. At this point, I believe RSVP (and its LSP extension) will have > > no problem whatsoever to handle intra-domain requirements. But RSVP does > > have the N**2 problem. When you look at the data we had gathered in > > Section-2 of our draft, any signaling protocol with N**2 property would > > be difficult work in inter-domain environment. > >As I have pointed out in RSVP-related WGs and several research papers, >RSVP has no scalability problem from the begining. > >So, I agree with you that it is very hard (impossible) to solve >your problem, because the problem does not exist. > > > One of the issues in RSVP is the notion of "route-pinning" at PATH > > processing time. This forces the routers to remember every reservation > > sender. At RESV processing time, the routers need to map the RESV to the > > previous PATH. > >No. As I pointed it out in some I-D and the INET'97 paper, the solution >is to route RESV first and let PATH follows the route. > >Note that route stabilization is easy that route-pinning is not >necessary at all. > >There are simple reasons why BGP like policy can not be applicable to >resource reservation. But it seems to me that the topic is to hard >for you to understand. > > Masataka Ohta > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rsvp-owner@ISI.EDU Mon Feb 7 00:23:02 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17624 for ; Mon, 7 Feb 2000 00:23:01 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id SAA12869 for rsvp-outgoing; Sun, 6 Feb 2000 18:06:23 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA12860 for ; Sun, 6 Feb 2000 18:06:22 -0800 (PST) Received: from web3304.mail.yahoo.com (web3304.mail.yahoo.com [204.71.201.146]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id SAA20889 for ; Sun, 6 Feb 2000 18:06:23 -0800 (PST) Message-ID: <20000207020552.18010.qmail@web3304.mail.yahoo.com> Received: from [152.1.162.57] by web3304.mail.yahoo.com; Sun, 06 Feb 2000 18:05:52 PST Date: Sun, 6 Feb 2000 18:05:52 -0800 (PST) From: MILIND NEMLEKAR To: rsvp@ISI.EDU MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-rsvp@ISI.EDU Precedence: bulk hi, I would like to have a Linux implementation of RSVP... Would any one tell me about the source site Thanks, MN __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From rsvp-owner@ISI.EDU Wed Feb 9 00:28:05 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18930 for ; Wed, 9 Feb 2000 00:28:04 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA08832 for rsvp-outgoing; Tue, 8 Feb 2000 17:38:47 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id RAA08827 for ; Tue, 8 Feb 2000 17:38:45 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05285; Tue, 8 Feb 2000 17:38:45 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id BAA06677; Wed, 9 Feb 2000 01:38:45 GMT Date: Wed, 9 Feb 2000 01:38:45 GMT Message-Id: <200002090138.BAA06677@gra.isi.edu> To: rsvp@ISI.EDU Subject: WORKING GROUP LAST CALL Cc: braden@ISI.EDU, lixia@cs.ucla.edu, sob@harvard.edu X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a Working Group Last Call on RSVP Refresh Overhead Reduction Extensions for Proposed Standard, as defined in: draft-ietf-rsvp-refresh-reduct-02.txt We strongly urge you to read it and comment. Bob Braden Lixia Zhang Co-chairs From rsvp-owner@ISI.EDU Wed Feb 9 10:48:23 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08389 for ; Wed, 9 Feb 2000 10:48:23 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id EAA28062 for rsvp-outgoing; Wed, 9 Feb 2000 04:25:37 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id EAA28057 for ; Wed, 9 Feb 2000 04:25:35 -0800 (PST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id EAA04546 for ; Wed, 9 Feb 2000 04:25:37 -0800 (PST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id GAA21535; Wed, 9 Feb 2000 06:25:12 -0600 Message-Id: <4.2.2.20000204201314.00c219e0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 09 Feb 2000 07:25:30 -0500 To: Adrian Farrel From: Lou Berger Subject: Re: Comments on draft-ietf-rsvp-refresh-reduct-02.txt Cc: lberger@labn.net, rsvp@ISI.EDU In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E140044@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk At 03:14 PM 2/4/00 +0000, Adrian Farrel wrote: >Lou et al, >Good job with the latest version of the draft. >I have a few very minor questions and editorial points, and a bunch of typos >(sorry, I can't read a draft w/o marking up typos!) Don't worry, we really appreciate the careful review! We'll integrate your comments into the post last call version. >Hope this is of use. absolutely. >Regards, >Adrian > >1) Discovery that neighbor supports bundling. > Section 3.3 suggests using configuration to discover that > the neighbor supports bundling. Is this of any use given > that the neighbor may change its support at any time and > indicate the fact using the RRC bit? > Are you just covering a possible implementation where it > is well known what the behavior of the neighbor is so that > it is never necessary to examine the RRC bit? If so, this > is in contradiction with section 2 that says that the node > MUST examine the RRO on every received message. > This is primarily aimed at covering the initialization case. When so configured a node need not wait to receive a message from a neighbor before sending a bundle message. It may also be used when non-RSVP nodes exist in the network and all RSVP nodes are known to support the extensions. In my opinion, it would be a configuration error for the a node to be configured to expect that a neighbor supported the extensions when it in fact does not. >2) Refresh period/ Refresh delay > Section 3 suggests that refresh messages may be delayed up > to their refresh interval. This isn't clear to me. oh well, I thought I was clear... > Are you saying that a refresh message that is generated > _before_ the refresh timer pops can be delayed up until the > time that the timer pops? yes. Implicit in this is implementations can take advantage of this but aren't required to. > Or are you saying that a refresh message that is generated > when a refresh timer pops can be delayed up to at most > another time period equal to the value of the refresh timer? definitely not. >3) Bundle message Send_TTL > Section 3.4 says that the Send_TTL is used to calculate the > number of non-IP hops, and that this is used later in > processing sub-messages. > The same section says that each sub-message is processed as > if it was received individually. Since each sub-message also > contains a Send_TTL, what is the use of the Bundle Send_TTL? You are correct. The the results of the test on Bundle message Send_TTL should be used in Path sub-message processing to detect a non-RSVP hop. All other sub-messages are processed without modification. >4) Message Acknowledgement > The last paragraph of section 4 says... > Each message containing an MESSAGE_ID object may be > acknowledged via a MESSAGE_ID_ACK object. > Is "may be" too generous? An Ack may only be sent if the > MESSAGE_ID object requests an Ack. I don't see a real problem with this given where it is in the document. I also don't mind making it more clear by adding some words. > >5) Epoch > I think the definition in 4.2 would benefit from some of the > text in 4.5. In particular: > - include "the RSVP agent restarts" with the "node reboots" > - the value SHOULD be different from the last time the node > cycled a reasonable comment. >6) Message_Identifier > Section 4 para 2 makes this unique within a sender/receiver > pairing. The definition in 4.2 says that it is unique for > a sender. > Although this is unlikely to make a difference to the > implementation at a receiver, it does make a difference to > sender and line trace implementations. Another good comment. Consistency here would be useful. >7) MESSAGE_ID_NACK object > See section 4.3 > Is there scope for a reason code? Scope? Do you mean room or value? >There may be no use at the > moment, but this looks good for future extensions. I'm not in favor of adding anything to the object that's not needed at this point. We've been working to minimize features and options. We can always define a "reason code" object or new c-type if and when the need arises. > >8) Epoch value > Section 4.5 para 3... > On startup, a node SHOULD randomly select > a value to be used in the Epoch field. The > node SHOULD ensure that the selected value > is not the same as was used when the node > was last operational. > - Why is it important that the assignment is random? The > important bit is to try to keep the value different from > previous use. Perhaps you should use RECOMMEND? SHOULD=RECOMMEND see rfc 2119. > - Is the previous use the only value to avoid? Might it be > desirable to avoid several previous values, especially > if the RSVP agent is cycled several times in quick > succession? You're getting into probabilities of when values get reused. Randomness helps here. > >9) Message_Identifier value > See section 4.5, para 4... > When a node is sending a trigger message, the > Message_Identifier value MUST have a value that > is greater than any other previously used value. > This is within the scope of the current value of Epoch, right? > Perhaps the text should say so. I think it's adequately covered by text in the preceding paragraph: The [Epoch] value MUST NOT be changed unless the node or the RSVP agent is restarted. >10) Message_Identifier presence > Section 5.1 > Is it worth stating that at least one Message_Identifier must > be present in the MESSAGE_ID LIST object? > Ditto MESSAGE_ID SRC_LIST and MCAST_LIST. sure. You like things even more explicit than I do... >11) Srefresh NACK > I think it would help to add clarification that the > MESSAGE_ID_NACK refers to the Message_Identifier in the (e.g.) > MESSAGE_ID LIST object of the Srefresh, *not* to the > Message_Identifier in the MESSAGE_ID object of the Srefresh. > > Perhaps it would also be useful to add a section on > "Acknowledgement of Srefresh" to clarify what is meant by an > Ack of an Srefresh (which may be requested through the flags > in the MESSAGE_ID object in the Srefresh. In particular, an > Ack of an Srefresh may still be followed by some > MESSAGE_ID_NACKs relating to Message_Identifiers carried by > the Srefresh. I though the text was fairly explicit in this area. I'll review it with this comment in mind and see if we can be clearer. >_Typos_ > >section 2. Flags. First line. Delete "to" to read "when set, indicates that >this..." > >section 3.3. 2nd para. penultimate line. For "MUST not" read "MUST NOT" > >section 3.4. 1st line. For "an Bundle" read "a Bundle" > >section 4. final para. For "an MESSAGE_ID" read "a MESSAGE_ID" > >section 4.6, final para. final sentence should be clause of previous >sentence. Read "...and longer time, although additional..." > >section 5.3, p27 last para. For "an MESSAGE_ID LIST" read "a MESSAGE_ID >LIST" > >section 5.4 first line. For "indicated" read "indicate" most appreciated! >-- >Adrian Farrel mailto:af@datcon.co.uk >ATM, MPLS and Telecoms Development Group >Data Connection Ltd., Chester, UK >http://www.datcon.co.uk/ >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 Thank you for the detailed review and very useful comments. Lou From rsvp-owner@ISI.EDU Wed Feb 9 15:16:49 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21360 for ; Wed, 9 Feb 2000 15:16:49 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA08594 for rsvp-outgoing; Wed, 9 Feb 2000 09:51:58 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08589 for ; Wed, 9 Feb 2000 09:51:56 -0800 (PST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA27355; Wed, 9 Feb 2000 09:51:58 -0800 (PST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id LAA32300; Wed, 9 Feb 2000 11:51:31 -0600 Message-Id: <4.2.2.20000209125109.00b565d0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 09 Feb 2000 12:51:32 -0500 To: Bob Braden From: Lou Berger Subject: Re: WORKING GROUP LAST CALL Cc: rsvp@ISI.EDU, braden@ISI.EDU, lixia@cs.ucla.edu, sob@harvard.edu In-Reply-To: <200002090138.BAA06677@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk Bob, When does the last call close? Thanks, Lou At 01:38 AM 2/9/00 +0000, Bob Braden wrote: >This is a Working Group Last Call on RSVP Refresh Overhead Reduction >Extensions for Proposed Standard, as defined in: > > draft-ietf-rsvp-refresh-reduct-02.txt > >We strongly urge you to read it and comment. > >Bob Braden >Lixia Zhang >Co-chairs From rsvp-owner@ISI.EDU Wed Feb 9 15:25:50 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21677 for ; Wed, 9 Feb 2000 15:25:48 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA08729 for rsvp-outgoing; Wed, 9 Feb 2000 09:55:15 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA08724 for ; Wed, 9 Feb 2000 09:55:13 -0800 (PST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA28166; Wed, 9 Feb 2000 09:55:09 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA06817; Wed, 9 Feb 2000 17:55:09 GMT Date: Wed, 9 Feb 2000 17:55:09 GMT Message-Id: <200002091755.RAA06817@gra.isi.edu> To: braden@ISI.EDU, lberger@labn.net Subject: Re: WORKING GROUP LAST CALL Cc: rsvp@ISI.EDU, lixia@cs.ucla.edu, sob@harvard.edu X-Sun-Charset: US-ASCII Sender: owner-rsvp@ISI.EDU Precedence: bulk *> Bob, *> When does the last call close? *> *> Thanks, *> Lou *> *> At 01:38 AM 2/9/00 +0000, Bob Braden wrote: *> *> *> >This is a Working Group Last Call on RSVP Refresh Overhead Reduction *> >Extensions for Proposed Standard, as defined in: *> > *> > draft-ietf-rsvp-refresh-reduct-02.txt *> > *> >We strongly urge you to read it and comment. *> > *> >Bob Braden *> >Lixia Zhang *> >Co-chairs *> *> Ah! Forgot that detail! How about Friday Feb 25? That is a bit over two weeks. Bob From rsvp-owner@ISI.EDU Wed Feb 9 15:29:12 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22064 for ; Wed, 9 Feb 2000 15:29:11 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA09556 for rsvp-outgoing; Wed, 9 Feb 2000 10:13:57 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA09551 for ; Wed, 9 Feb 2000 10:13:55 -0800 (PST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA01625; Wed, 9 Feb 2000 10:13:57 -0800 (PST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id MAA04298; Wed, 9 Feb 2000 12:13:53 -0600 Message-Id: <4.2.2.20000209131330.00c27a10@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 09 Feb 2000 13:13:44 -0500 To: Bob Braden From: Lou Berger Subject: Re: WORKING GROUP LAST CALL Cc: braden@ISI.EDU, lberger@labn.net, rsvp@ISI.EDU, lixia@cs.ucla.edu, sob@harvard.edu In-Reply-To: <200002091755.RAA06817@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk Sounds good to me. Thanks, Lou At 05:55 PM 2/9/00 +0000, Bob Braden wrote: > *> Bob, > *> When does the last call close? > *> > *> Thanks, > *> Lou > *> > *> At 01:38 AM 2/9/00 +0000, Bob Braden wrote: > *> > *> > *> >This is a Working Group Last Call on RSVP Refresh Overhead Reduction > *> >Extensions for Proposed Standard, as defined in: > *> > > *> > draft-ietf-rsvp-refresh-reduct-02.txt > *> > > *> >We strongly urge you to read it and comment. > *> > > *> >Bob Braden > *> >Lixia Zhang > *> >Co-chairs > *> > *> >Ah! Forgot that detail! > >How about Friday Feb 25? That is a bit over two weeks. > >Bob From rsvp-owner@ISI.EDU Thu Feb 10 11:18:14 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02695 for ; Thu, 10 Feb 2000 11:18:12 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA17678 for rsvp-outgoing; Thu, 10 Feb 2000 05:29:32 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id FAA17673 for ; Thu, 10 Feb 2000 05:29:30 -0800 (PST) Received: from coltrane.datcon.co.uk (smtp.datcon.co.uk [192.91.191.4]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id FAA00545 for ; Thu, 10 Feb 2000 05:29:32 -0800 (PST) Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id <1D1DBXYG>; Thu, 10 Feb 2000 13:28:54 -0000 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E1400EE@monk.datcon.co.uk> From: Adrian Farrel To: Lou Berger Cc: rsvp@ISI.EDU Subject: RE: Comments on draft-ietf-rsvp-refresh-reduct-02.txt Date: Thu, 10 Feb 2000 13:28:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk Lou Berger wrote... >>2) Refresh period/ Refresh delay >> Section 3 suggests that refresh messages may be delayed up >> to their refresh interval. This isn't clear to me. >> Are you saying that a refresh message that is generated >> _before_ the refresh timer pops can be delayed up until the >> time that the timer pops? > >yes. Implicit in this is implementations can take advantage >of this but aren't required to. OK. Clear now. >>7) MESSAGE_ID_NACK object >> See section 4.3 >> Is there scope for a reason code? > >Scope? Do you mean room or value? I meant, is it worth adding a reason code now so that future extensions don't require a modification of the format of the object. But then you said... >I'm not in favor of adding anything to the object that's not >needed at this point. We've been working to minimize >features and options. We can always define a "reason code" >object or new c-type if and when the need arises. OK. >>9) Message_Identifier value >> See section 4.5, para 4... >> When a node is sending a trigger message, the >> Message_Identifier value MUST have a value that >> is greater than any other previously used value. >> This is within the scope of the current value of Epoch, right? >> Perhaps the text should say so. > >I think it's adequately covered by text in the preceding paragraph: > The [Epoch] value MUST NOT be changed unless the node or the > RSVP agent is restarted. Not a big issue. The point I was trying to make is that it is OK to reset the Message Identifier to 0 when starting with a new Epoch. The text actually says "greater than any other previously used value". Regards, Adrian From rsvp-owner@ISI.EDU Thu Feb 10 11:23:37 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02891 for ; Thu, 10 Feb 2000 11:23:34 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA18628 for rsvp-outgoing; Thu, 10 Feb 2000 06:01:49 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA18623 for ; Thu, 10 Feb 2000 06:01:47 -0800 (PST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA01946 for ; Thu, 10 Feb 2000 06:01:49 -0800 (PST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id IAA31669; Thu, 10 Feb 2000 08:01:45 -0600 Message-Id: <4.2.2.20000210085439.00b27a90@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 10 Feb 2000 09:01:46 -0500 To: Adrian Farrel From: Lou Berger Subject: RE: Comments on draft-ietf-rsvp-refresh-reduct-02.txt Cc: Lou Berger , rsvp@ISI.EDU In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E1400EE@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk At 01:28 PM 2/10/00 +0000, Adrian Farrel wrote: >Lou Berger wrote... > >[...] > >>9) Message_Identifier value > >> See section 4.5, para 4... > >> When a node is sending a trigger message, the > >> Message_Identifier value MUST have a value that > >> is greater than any other previously used value. > >> This is within the scope of the current value of Epoch, right? > >> Perhaps the text should say so. > > > >I think it's adequately covered by text in the preceding paragraph: > > The [Epoch] value MUST NOT be changed unless the node or the > > RSVP agent is restarted. > >Not a big issue. The point I was trying to make is that it is OK to reset >the Message Identifier to 0 when starting with a new Epoch. The text >actually says "greater than any other previously used value". Ahh, you're right, I missed your point. It is valid (although a little redundant with the definition of the field). I'll clarify. Thanks again for the comments, Lou >Regards, >Adrian From rsvp-owner@ISI.EDU Mon Feb 14 20:43:09 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29207 for ; Mon, 14 Feb 2000 20:43:06 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA22500 for rsvp-outgoing; Mon, 14 Feb 2000 15:06:27 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22495 for ; Mon, 14 Feb 2000 15:06:26 -0800 (PST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA08852; Mon, 14 Feb 2000 15:06:29 -0800 (PST) Received: by SOL with Internet Mail Service (5.5.2650.21) id <1WZ4YDTQ>; Mon, 14 Feb 2000 15:05:15 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC545@SOL> From: Andrew Smith To: "rap (E-mail)" Cc: "Bert Wijnen (E-mail)" , "Randy Bush (E-mail)" , "'Scott Bradner'" , "Bob Braden (E-mail)" , "Lixia Zhang (E-mail)" , "Mark Stevens (E-mail)" , "rsvp@isi. edu (E-mail)" Subject: RAP WG Last Call on draft for Application-ID for RSVP Policy Obje cts Date: Mon, 14 Feb 2000 15:05:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF773F.F4307688" Sender: owner-rsvp@ISI.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF773F.F4307688 Content-Type: text/plain; charset="iso-8859-1" This is to announce the RAP Working Group LAST-CALL for the COPS client MIB document. The relevant IETF draft announcement is enclosed below. The current intent is for this document to be on the Internet Standards track as described in RFC-2026 although we will use this last call period, amongst other things, to sense whether the RAP WG believes this is the appropriate status for this document, or not. The RAP Working Group plans to make a decision on a recommendation for progressing this document to the Proposed Standard state at the end of the Working Group Last Call period which will be February 28th, 2000. Comments should be sent to the RAP WG mailing list (rap@iphighway.com) as soon as possible but not later than Monday February 28th, 2000. Thanks, Andrew Smith Mark Stevens RAP WG co-chairs ------_=_NextPart_000_01BF773F.F4307688 Content-Type: message/rfc822 Content-Description: I-D ACTION:draft-ietf-rap-rsvp-appid-01.txt Message-ID: <808F64DDB492D3119D3C00508B5D8D7301051CB2@SOL> From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: Cc: rap@iphighway.com Subject: I-D ACTION:draft-ietf-rap-rsvp-appid-01.txt Date: Fri, 11 Feb 2000 03:31:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF773F.F4307688" ------_=_NextPart_002_01BF773F.F4307688 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Application and Sub Application Identity Policy Element for Use with RSVP Author(s) : Y. Bernet, R. Pabbati Filename : draft-ietf-rap-rsvp-appid-01.txt Pages : 4 Date : 10-Feb-00 RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This informational draft details the usage of policy elements that provide application information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-appid-01.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-rap-rsvp-appid-01.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-rap-rsvp-appid-01.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_002_01BF773F.F4307688 Content-Type: message/rfc822 To: Subject: Date: Mon, 14 Feb 2000 14:50:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_004_01BF773F.F4307688" ------_=_NextPart_004_01BF773F.F4307688 Content-Type: text/plain ------_=_NextPart_004_01BF773F.F4307688 Content-Type: application/octet-stream; name="ATT11575" Content-Disposition: attachment; filename="ATT11575" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000210092532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-appid-01.txt ------_=_NextPart_004_01BF773F.F4307688 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-rap-rsvp-appid-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_004_01BF773F.F4307688-- ------_=_NextPart_002_01BF773F.F4307688-- ------_=_NextPart_000_01BF773F.F4307688-- From rsvp-owner@ISI.EDU Mon Feb 14 21:07:13 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29933 for ; Mon, 14 Feb 2000 21:07:12 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA24440 for rsvp-outgoing; Mon, 14 Feb 2000 16:00:17 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA24435 for ; Mon, 14 Feb 2000 16:00:16 -0800 (PST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA17893; Mon, 14 Feb 2000 16:00:19 -0800 (PST) Received: by SOL with Internet Mail Service (5.5.2650.21) id <1WZ4Y1AP>; Mon, 14 Feb 2000 15:59:05 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC54E@SOL> From: Andrew Smith To: "rap (E-mail)" , "rsvp@isi. edu (E-mail)" Cc: "Bert Wijnen (E-mail)" , "Randy Bush (E-mail)" , "'Scott Bradner'" , "Bob Braden (E-mail)" , "Lixia Zhang (E-mail)" Subject: RAP WG Last Call on draft for Application-ID for RSVP Policy Obje cts Date: Mon, 14 Feb 2000 15:59:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF7747.7974E2F0" Sender: owner-rsvp@ISI.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF7747.7974E2F0 Content-Type: text/plain; charset="iso-8859-1" This is to announce the RAP Working Group LAST-CALL for the COPS client MIB document. The relevant IETF draft announcement is enclosed below. The current intent is for this document to be on the Internet Standards track as described in RFC-2026 although we will use this last call period, amongst other things, to sense whether the WG believes this is the appropriate status for this document, or not. The Working Group plans to make a decision on a recommendation for progressing this document to the Proposed Standard state at the end of the Working Group Last Call period which will be February 28th, 2000. Comments should be sent to the WG mailing list (rap@iphighway.com) as soon as possible but not later than Monday February 28th, 2000. Thanks, Andrew Smith Mark Stevens RAP WG co-chairs ------_=_NextPart_000_01BF7747.7974E2F0 Content-Type: message/rfc822 Content-Description: I-D ACTION:draft-ietf-rap-rsvp-appid-01.txt Message-ID: <808F64DDB492D3119D3C00508B5D8D7301051CB2@SOL> From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: Cc: rap@iphighway.com Subject: I-D ACTION:draft-ietf-rap-rsvp-appid-01.txt Date: Fri, 11 Feb 2000 03:31:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF7747.7974E2F0" ------_=_NextPart_002_01BF7747.7974E2F0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Application and Sub Application Identity Policy Element for Use with RSVP Author(s) : Y. Bernet, R. Pabbati Filename : draft-ietf-rap-rsvp-appid-01.txt Pages : 4 Date : 10-Feb-00 RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This informational draft details the usage of policy elements that provide application information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-appid-01.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-rap-rsvp-appid-01.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-rap-rsvp-appid-01.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_002_01BF7747.7974E2F0 Content-Type: message/rfc822 To: Subject: Date: Mon, 14 Feb 2000 14:50:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_004_01BF7747.7974E2F0" ------_=_NextPart_004_01BF7747.7974E2F0 Content-Type: text/plain ------_=_NextPart_004_01BF7747.7974E2F0 Content-Type: application/octet-stream; name="ATT11575" Content-Disposition: attachment; filename="ATT11575" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000210092532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-appid-01.txt ------_=_NextPart_004_01BF7747.7974E2F0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-rap-rsvp-appid-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_004_01BF7747.7974E2F0-- ------_=_NextPart_002_01BF7747.7974E2F0-- ------_=_NextPart_000_01BF7747.7974E2F0-- From rsvp-owner@ISI.EDU Tue Feb 15 16:00:50 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22567 for ; Tue, 15 Feb 2000 16:00:49 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id KAA21676 for rsvp-outgoing; Tue, 15 Feb 2000 10:24:48 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA21671 for ; Tue, 15 Feb 2000 10:24:43 -0800 (PST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA00582; Tue, 15 Feb 2000 10:24:47 -0800 (PST) Received: by SOL with Internet Mail Service (5.5.2650.21) id <1WZ4Y2K0>; Tue, 15 Feb 2000 10:23:32 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC556@SOL> From: Andrew Smith To: "rap (E-mail)" Cc: "Bert Wijnen (E-mail)" , "Randy Bush (E-mail)" , "'Scott Bradner'" , "Bob Braden (E-mail)" , "Lixia Zhang (E-mail)" , "Mark Stevens (E-mail)" , "rsvp@isi. edu (E-mail)" Subject: RAP WG Last Call on draft for Application-ID for RSVP Policy Obje cts - take 2 Date: Tue, 15 Feb 2000 10:23:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF77E1.C378910E" Sender: owner-rsvp@ISI.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF77E1.C378910E Content-Type: text/plain; charset="iso-8859-1" Oops, so much for cut'n'paste: try again ... apologies for clogging your mailboxes - you all knew what I *meant* to write. ------------------------------------------------- This is to announce the RAP Working Group LAST-CALL for the draft on *** Application-ID for RSVP Policy Objects ***. The relevant IETF draft announcement is enclosed below. The current intent is for this document to be on the Internet Standards track as described in RFC-2026 although we will use this last call period, amongst other things, to sense whether the RAP WG believes this is the appropriate status for this document, or not. The RAP Working Group plans to make a decision on a recommendation for progressing this document to the Proposed Standard state at the end of the Working Group Last Call period which will be February 28th, 2000. Comments should be sent to the RAP WG mailing list (rap@iphighway.com) as soon as possible but not later than Monday February 28th, 2000. Thanks, Andrew Smith Mark Stevens RAP WG co-chairs ------_=_NextPart_000_01BF77E1.C378910E Content-Type: message/rfc822 Message-ID: <808F64DDB492D3119D3C00508B5D8D7301051CB2@SOL> From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: Cc: rap@iphighway.com Subject: I-D ACTION:draft-ietf-rap-rsvp-appid-01.txt Date: Fri, 11 Feb 2000 03:31:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF77E1.C378910E" ------_=_NextPart_002_01BF77E1.C378910E Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Application and Sub Application Identity Policy Element for Use with RSVP Author(s) : Y. Bernet, R. Pabbati Filename : draft-ietf-rap-rsvp-appid-01.txt Pages : 4 Date : 10-Feb-00 RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This informational draft details the usage of policy elements that provide application information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-appid-01.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-rap-rsvp-appid-01.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-rap-rsvp-appid-01.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_002_01BF77E1.C378910E Content-Type: message/rfc822 From: rsvp-owner@ISI.EDU To: Subject: Date: Mon, 14 Feb 2000 14:50:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_004_01BF77E1.C378910E" ------_=_NextPart_004_01BF77E1.C378910E Content-Type: text/plain ------_=_NextPart_004_01BF77E1.C378910E Content-Type: application/octet-stream; name="ATT11575" Content-Disposition: attachment; filename="ATT11575" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000210092532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-appid-01.txt ------_=_NextPart_004_01BF77E1.C378910E Content-Type: application/octet-stream; name="ATT12844" Content-Disposition: attachment; filename="ATT12844" Content-type: message/external-body; site="internet-drafts"; dir="draft-ietf-rap-rsvp-appid-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_004_01BF77E1.C378910E-- ------_=_NextPart_002_01BF77E1.C378910E-- ------_=_NextPart_000_01BF77E1.C378910E-- From rsvp-owner@ISI.EDU Tue Feb 15 23:40:03 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05718 for ; Tue, 15 Feb 2000 23:40:02 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id SAA03845 for rsvp-outgoing; Tue, 15 Feb 2000 18:18:34 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id SAA03832 for ; Tue, 15 Feb 2000 18:18:32 -0800 (PST) Received: from dns.ido.net.tw (root@dns.iwill.com.tw [203.74.176.1]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA27134 for ; Tue, 15 Feb 2000 18:18:32 -0800 (PST) From: janson19@mail.ht.net.tw Received: from janson19 (host196.2037788.gcn.net.tw [203.77.88.196]) by dns.ido.net.tw (8.9.3/8.8.7) with SMTP id KAA06516; Wed, 16 Feb 2000 10:16:51 +0800 To: money@dns.ido.net.tw Subject: make money Date: Wed, 16 Feb 2000 10:28:40 +0800 Message-Id: <36572.436584490745600.7137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 8bit 稱硓筁呼隔淮肞寥窥,稱е硉秨承ㄆ穨 盢э跑眤ネ,е硉璓碔盡 叫ㄨ,眤寥窥!! http://skyfamily.com/ctking-1 ~~很港舧眤~~~ =============================== 約獺ㄧ約诀穦 ╆簆ゴ耑!璝眤ぃ惠璶,叫ミㄨ埃 獶盽獶盽癸ぃ癬! ============================== From rsvp-owner@ISI.EDU Thu Feb 17 22:06:07 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00980 for ; Thu, 17 Feb 2000 22:06:06 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA19639 for rsvp-outgoing; Thu, 17 Feb 2000 16:54:52 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA19634 for ; Thu, 17 Feb 2000 16:54:51 -0800 (PST) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA16265; Thu, 17 Feb 2000 16:54:54 -0800 (PST) Received: from m1.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway) id JAA05153; Fri, 18 Feb 2000 09:53:09 +0900 (JST) (envelope-from ohya@atom.flab.fujitsu.co.jp) Received: from flabmail.flab.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master) id JAA01812; Fri, 18 Feb 2000 09:53:09 +0900 (JST) Received: from silver by flabmail.flab.fujitsu.co.jp (8.9.3/3.7W-991208-Fujitsu Labs. Domain Mail Master) id JAA06749; Fri, 18 Feb 2000 09:53:08 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by silver (8.8.7/3.6Wbeta7-98082009) with ESMTP id JAA29052; Fri, 18 Feb 2000 09:53:06 +0900 (JST) To: rsvp@ISI.EDU Cc: braden@ISI.EDU, lixia@cs.ucla.edu, sob@harvard.edu Subject: Re: WORKING GROUP LAST CALL From: Mayumi Tomikawa In-Reply-To: <200002090138.BAA06677@gra.isi.edu> References: <200002090138.BAA06677@gra.isi.edu> X-Mailer: Mew version 1.94b28 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000218095306D.ohya@atom.flab.fujitsu.co.jp> Date: Fri, 18 Feb 2000 09:53:06 +0900 X-Dispatcher: imput version 990425(IM115) Lines: 31 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Comment on draft-ietf-rsvp-refresh-reduct-02.txt. Section 5.5. the second paragraph says, "the node compares the new checksum value and stored one periodically, and if the values differ, then a corresponding standard Path or Resv refresh message should be sent." But it is not clear who should send the standard refresh message. Is it the node which found the checksum error, or the original node of the corresponding state? If the former sends a standard refresh message, an incorrect state may be sent to the next hop, because the different values show some internal errors. So we think, when the values differ, the node which found the error needs to receive a standard message. However, most likely, the node will not receive any standard message, since the sender continues to send Srefresh messages. So, the node must explicitly request the sender for a full (standard) message. We think there are two approachs. 1) The node sends NACK to the original node as soon as he finds the checksum error. 2) The node sends NACK, when he receives the next Srefresh message from the original node. When the node receives a standard message, it processes the whole message regardless of the Message_ID value. --- Mayumi Tomikawa Fujitsu Laboratories Ltd. From rsvp-owner@ISI.EDU Sun Feb 20 16:30:48 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12957 for ; Sun, 20 Feb 2000 16:30:47 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA24102 for rsvp-outgoing; Sun, 20 Feb 2000 11:05:43 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA24097 for ; Sun, 20 Feb 2000 11:05:42 -0800 (PST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA19684; Sun, 20 Feb 2000 11:05:41 -0800 (PST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id NAA25083; Sun, 20 Feb 2000 13:05:22 -0600 Message-Id: <4.2.2.20000220135228.00cdc710@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 20 Feb 2000 14:05:11 -0500 To: Mayumi Tomikawa From: Lou Berger Subject: Re: WORKING GROUP LAST CALL Cc: rsvp@ISI.EDU, braden@ISI.EDU, lixia@cs.ucla.edu, sob@harvard.edu In-Reply-To: <20000218095306D.ohya@atom.flab.fujitsu.co.jp> References: <200002090138.BAA06677@gra.isi.edu> <200002090138.BAA06677@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rsvp@ISI.EDU Precedence: bulk At 09:53 AM 2/18/00 +0900, Mayumi Tomikawa wrote: >Comment on draft-ietf-rsvp-refresh-reduct-02.txt. > >Section 5.5. the second paragraph says, "the node compares the new >checksum value and stored one periodically, and if the values differ, >then a corresponding standard Path or Resv refresh message should be >sent." >But it is not clear who should send the standard refresh message. Is >it the node which found the checksum error, or the original node of >the corresponding state? I think it's clear in full context: The first mechanism uses a checksum or other algorithm to detect a previously unnoticed change in internal state. When sending a Path or Resv trigger message, a node should run a checksum or other algorithm, such as [MD5], over the internal state and store the result. The choice of algorithm is an administrative decision. Periodically the node should rerun the algorithm and compare the new result with the stored result. If the values differ, then a corresponding standard Path or Resv refresh message should be sent and the new value should be stored. The recomputation period should be set based on the computation resources of the node and the reliability requirements of the network. it's the node that finds the difference. >If the former sends a standard refresh message, an incorrect state may >be sent to the next hop, because the different values show some >internal errors. The describe mechanism is aimed solely aimed at advertising state changes that may have gone unnoticed by the mechanism that generates trigger messages. (This is inherent in standard RSVP refreshes.) Protection against internal state corruption is not addressed by this mechanism and cannot be addressed by the transmission of a refresh message. As eluded to in your message, it may be addressed by the receipt of a refresh messages. This is the purpose of the paragraph following the one mentioned above. It simply says to periodically send standard refreshes even when doing summary refreshes. >So we think, when the values differ, the node which >found the error needs to receive a standard message. I think you're combining two cases here: unnoticed state changes and internal state corruption. Both of these are separately addressed in section 5.5. >However, most likely, the node will not receive any standard message, >since the sender continues to send Srefresh messages. right, because the described mechanism is covering unnoticed changed not corruption. >So, the node must explicitly request the sender for a full (standard) >message. >We think there are two approachs. >1) The node sends NACK to the original node as soon as he finds the > checksum error. >2) The node sends NACK, when he receives the next Srefresh message > from the original node. >When the node receives a standard message, it processes the whole >message regardless of the Message_ID value. or just follow all of section 5.5. Thank you for the comment, Lou Berger >--- >Mayumi Tomikawa >Fujitsu Laboratories Ltd. From rsvp-owner@ISI.EDU Wed Feb 23 01:50:14 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06541 for ; Wed, 23 Feb 2000 01:50:13 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA15869 for rsvp-outgoing; Tue, 22 Feb 2000 20:12:37 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA15864 for ; Tue, 22 Feb 2000 20:12:36 -0800 (PST) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA21946 for ; Tue, 22 Feb 2000 20:12:36 -0800 (PST) Received: from mailsv4.nec.co.jp (mailsv4-le1 [192.168.1.93]) by TYO202.gate.nec.co.jp (8.9.3/3.7W99122211) with ESMTP id NAA19083 for ; Wed, 23 Feb 2000 13:12:34 +0900 (JST) Received: from ncse18.e1hd.ncos.nec.co.jp (ncse18.e1hd.ncos.nec.co.jp [10.40.24.93]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id NAA20400 for ; Wed, 23 Feb 2000 13:12:34 +0900 (JST) Received: from e1hp129 by ncse18.e1hd.ncos.nec.co.jp (8.7.6+2.6Wbeta7/3.4W4-960304) id NAA16514; Wed, 23 Feb 2000 13:25:06 +0900 (JST) Date: Wed, 23 Feb 2000 13:13:38 +0900 From: Hideki Mae To: rsvp@ISI.EDU Subject: E_Police Flag Message-Id: <38B35E72320.AAB3H_MAE@ncse18.e1hd.ncos.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.06 Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Apologies in advance if this question was already asked. I heard that the E_Police flag is no longer valid. Is this true? If so, why was it invalidated? Also, are there any documents that specifically say that it was invalidated? Thanks in advance. +--------------------------------------------------------------+ Hideki Mae Design Engineer 1st Switching Systems Engineering Dept. Engineering Division Address: NEC Communication Systems, Ltd. (NCOS) 1131, Hinode, Abiko-shi, Chiba 270-1198, Japan TEL: +81 471 85 6940 FAX: +81 471 85 7864 E-mail: h_mae@e1hd.ncos.nec.co.jp +---------------------------------------------------------------+ From rsvp-owner@ISI.EDU Wed Feb 23 07:01:15 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19163 for ; Wed, 23 Feb 2000 07:01:14 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id BAA26575 for rsvp-outgoing; Wed, 23 Feb 2000 01:46:03 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id BAA26570 for ; Wed, 23 Feb 2000 01:46:02 -0800 (PST) Received: from twnt0.teleware.fi (weboffice.teleware.fi [193.65.76.13]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id BAA06688 for ; Wed, 23 Feb 2000 01:46:03 -0800 (PST) From: ilkka.hakala@teleware.fi Received: by weboffice.teleware.fi with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Feb 2000 11:46:59 +0200 Message-ID: <111D42604E7BD311897B00902755514A0F0C40@weboffice.teleware.fi> To: rsvp@ISI.EDU Subject: unsubscrible Date: Wed, 23 Feb 2000 11:46:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rsvp@ISI.EDU Precedence: bulk -----Original Message----- From: Hideki Mae [mailto:h_mae@e1hd.ncos.nec.co.jp] Sent: Wednesday, February 23, 2000 6:14 AM To: rsvp@ISI.EDU Subject: E_Police Flag Apologies in advance if this question was already asked. I heard that the E_Police flag is no longer valid. Is this true? If so, why was it invalidated? Also, are there any documents that specifically say that it was invalidated? Thanks in advance. +--------------------------------------------------------------+ Hideki Mae Design Engineer 1st Switching Systems Engineering Dept. Engineering Division Address: NEC Communication Systems, Ltd. (NCOS) 1131, Hinode, Abiko-shi, Chiba 270-1198, Japan TEL: +81 471 85 6940 FAX: +81 471 85 7864 E-mail: h_mae@e1hd.ncos.nec.co.jp +---------------------------------------------------------------+ From rsvp-owner@ISI.EDU Wed Feb 23 17:34:06 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04131 for ; Wed, 23 Feb 2000 17:34:05 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA20636 for rsvp-outgoing; Wed, 23 Feb 2000 12:23:12 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id MAA20630 for ; Wed, 23 Feb 2000 12:23:10 -0800 (PST) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA23826 for ; Wed, 23 Feb 2000 12:23:11 -0800 (PST) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id VAA10284 for ; Wed, 23 Feb 2000 21:22:38 +0100 (MET) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.9.3/8.7.5) id VAA05686 for rsvp@ISI.EDU; Wed, 23 Feb 2000 21:22:38 +0100 Message-Id: <200002232022.VAA05686@KOM.tu-darmstadt.de> Subject: Announcement: KOM RSVP Procotol Engine, version 2.0 To: rsvp@ISI.EDU Date: Wed, 23 Feb 2000 21:22:38 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I would like to announce, to any interested party, the availability of the KOM RSVP protocol engine, release version 2.0. This release contains a number of new features over previous releases: - improved internal code structure - multi-threaded message processing (optional) - integration of ALTQ package (CBQ and HFSC scheduling) on FreeBSD - fuzzy timer optimization (optional) - initial performance tests Although I don't claim the code to be highly optimized, I have done some initial performance evaluations (on PCs with PIII 450Mhz); the results are quite promising (I believe): - A FreeBSD router can handle the raw signalling of 20,000 unicast flows. CPU utilization is about 77%. - In combination with ALTQ-HFSC packet classification and scheduling, it can be loaded with up to 10,000 unicast flows and at the same time handle packet classification and forwarding of ~ 20,000 packets/sec. - Preliminary tests show that if other optimizations, especially enabling fuzzy timers, and further tuning are carried out, these results can be increased quite significantly, i.e. raw signalling for ~ 30,000 flows => ~ 50% CPU utilization. Fur further information and download: http://www.kom.e-technik.tu-darmstadt.de/rsvp/ Greetings, Martin From rsvp-owner@ISI.EDU Thu Feb 24 16:09:37 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10499 for ; Thu, 24 Feb 2000 16:09:34 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA07512 for rsvp-outgoing; Thu, 24 Feb 2000 11:09:23 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA07506 for ; Thu, 24 Feb 2000 11:09:22 -0800 (PST) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA01319 for ; Thu, 24 Feb 2000 11:09:22 -0800 (PST) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id UAA16631; Thu, 24 Feb 2000 20:08:49 +0100 (MET) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.7.5/8.7.5) id UAA20635; Thu, 24 Feb 2000 20:08:47 +0100 (MET) Message-Id: <200002241908.UAA20635@KOM.tu-darmstadt.de> Subject: Re: Announcement: KOM RSVP Procotol Engine, version 2.0 In-Reply-To: <4.2.2.20000224092554.00ac44b0@dogwood.cisco.com> from Chip Sharp at "Feb 24, 2000 09:26:38 am" To: Chip Sharp Date: Thu, 24 Feb 2000 20:08:47 +0100 (MET) CC: rsvp@ISI.EDU X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I forgot to mention the following: Details about the performance tests can also be found via the web site below or directly at http://www.kom.e-technik.tu-darmstadt.de/rsvp/performance.html Please let me know if you have further questions. Greetings, Martin > When you say it can handle the raw signaling of 20,000 flows, how does this > break down into the number of reservations per second? > > Thanks, > Chip > > > At 09:22 PM 2/23/00 +0100, you wrote: > >I would like to announce, to any interested party, the availability of the > >KOM RSVP protocol engine, release version 2.0. > > > >This release contains a number of new features over previous releases: > >- improved internal code structure > >- multi-threaded message processing (optional) > >- integration of ALTQ package (CBQ and HFSC scheduling) on FreeBSD > >- fuzzy timer optimization (optional) > >- initial performance tests > > > >Although I don't claim the code to be highly optimized, I have done some > >initial performance evaluations (on PCs with PIII 450Mhz); the results are > >quite promising (I believe): > > > >- A FreeBSD router can handle the raw signalling of 20,000 unicast flows. > > CPU utilization is about 77%. > > > >- In combination with ALTQ-HFSC packet classification and scheduling, it can > > be loaded with up to 10,000 unicast flows and at the same time handle > > packet > > classification and forwarding of ~ 20,000 packets/sec. > > > >- Preliminary tests show that if other optimizations, especially enabling > > fuzzy timers, and further tuning are carried out, these results can be > > increased quite significantly, i.e. raw signalling for ~ 30,000 flows > > => ~ 50% CPU utilization. > > > >Fur further information and download: > >http://www.kom.e-technik.tu-darmstadt.de/rsvp/ > > > >Greetings, > >Martin > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > From rsvp-owner@ISI.EDU Thu Feb 24 19:12:31 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12995 for ; Thu, 24 Feb 2000 19:12:31 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA17085 for rsvp-outgoing; Thu, 24 Feb 2000 14:03:24 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA17076 for ; Thu, 24 Feb 2000 14:03:22 -0800 (PST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA16462; Thu, 24 Feb 2000 14:03:23 -0800 (PST) Received: from stefanog-u10.cisco.com (stefanog-u10.cisco.com [171.69.50.51]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id OAA04644; Thu, 24 Feb 2000 14:24:36 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by stefanog-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA00690; Thu, 24 Feb 2000 14:01:49 -0800 (PST) Message-ID: <38B5AA4D.6B40083E@cisco.com> Date: Thu, 24 Feb 2000 14:01:49 -0800 From: Stefano Giorcelli Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Martin Karsten CC: rsvp@ISI.EDU, rsvp-test@ISI.EDU Subject: Re: Announcement: KOM RSVP Procotol Engine, version 2.0 References: <200002232022.VAA05686@KOM.tu-darmstadt.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Hi Martin, I read your paper "Design and Implementation of RSVP based on Object-Relationships", that describes your RSVP implementation, and I have a question regarding a sentence in section 6.4: "...as has been reported to the rsvp-test mailing list [Mev99], the ISI code currently has a hard-coded limitation to support only 64 concurrent sessions." The email quoted (sent by Patrick Mevzek on June 24th, 1999) says that some MAX_SESSIONS parameter is set to 64 in the ISI code, and that attempts to increase this number result in other problems with some data structures. I recently downloaded the 4.2a4 release of ISI code, and I don't see such limitation. Am I missing something? Could you explain? Can anyone confirm (or object to) this statement? Thanks in advance, Stefano -- Stefano Giorcelli Cisco Systems, Inc. From rsvp-owner@ISI.EDU Thu Feb 24 20:36:09 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14003 for ; Thu, 24 Feb 2000 20:36:08 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA20944 for rsvp-outgoing; Thu, 24 Feb 2000 15:09:45 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA20925 for ; Thu, 24 Feb 2000 15:09:42 -0800 (PST) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22690; Thu, 24 Feb 2000 15:09:42 -0800 (PST) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id AAA20435; Fri, 25 Feb 2000 00:08:34 +0100 (MET) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.7.5/8.7.5) id AAA05840; Fri, 25 Feb 2000 00:08:33 +0100 (MET) Message-Id: <200002242308.AAA05840@KOM.tu-darmstadt.de> Subject: Re: Announcement: KOM RSVP Procotol Engine, version 2.0 In-Reply-To: <38B5AA4D.6B40083E@cisco.com> from Stefano Giorcelli at "Feb 24, 2000 02:01:49 pm" To: stefanog@cisco.com Date: Fri, 25 Feb 2000 00:08:32 +0100 (MET) CC: rsvp@ISI.EDU, rsvp-test@ISI.EDU, pat@patoche.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rsvp@ISI.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > I read your paper "Design and Implementation of RSVP based on > Object-Relationships", that describes your RSVP implementation, and I have a > question regarding a sentence in section 6.4: > > "...as has been reported to the rsvp-test mailing list [Mev99], the ISI code > currently has a hard-coded limitation to support only 64 concurrent sessions." > > The email quoted (sent by Patrick Mevzek on June 24th, 1999) says that some > MAX_SESSIONS parameter is set to 64 in the ISI code, and that attempts to > increase this number result in other problems with some data structures. > > I recently downloaded the 4.2a4 release of ISI code, and I don't see such > limitation. Am I missing something? > > Could you explain? Can anyone confirm (or object to) this statement? I am sorry I can neither object or confirm. Nobody ever replied to the email above and Patrick confirmed his observation during a private email exchange. He also told me that he managed to compile it to be able to handle 262144 flows, but then it allocated 83 MBytes memory at startup. When I have looked at the code (before this email), I found it rather unsuitable for extending it or generally playing around with it, so I decided to develop new code and did not look into rsvpd's details. Maybe I should have done it before quoting this email, but then again, nobody replied... Note that I do not intend to bash anything or anyone here. Developing code while you are defining a protocol is something completely different from developing code when everything is settled. Greetings, Martin From rsvp-owner@ISI.EDU Fri Feb 25 08:34:21 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07268 for ; Fri, 25 Feb 2000 08:34:21 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA03528 for rsvp-outgoing; Fri, 25 Feb 2000 03:05:00 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA03522 for ; Fri, 25 Feb 2000 03:04:58 -0800 (PST) Received: from twnt0.teleware.fi (weboffice.teleware.fi [193.65.76.13]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA05588 for ; Fri, 25 Feb 2000 03:04:59 -0800 (PST) From: ilkka.hakala@teleware.fi Received: by weboffice.teleware.fi with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Feb 2000 13:05:54 +0200 Message-ID: <111D42604E7BD311897B00902755514A0F0C46@weboffice.teleware.fi> To: rsvp@ISI.EDU Subject: unsubscrible Date: Fri, 25 Feb 2000 13:05:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rsvp@ISI.EDU Precedence: bulk > -----Original Message----- > From: Martin Karsten [SMTP:Martin.Karsten@KOM.tu-darmstadt.de] > Sent: 25. helmikuuta 2000 1:09 > To: stefanog@cisco.com > Cc: rsvp@ISI.EDU; rsvp-test@ISI.EDU; pat@patoche.org > Subject: Re: Announcement: KOM RSVP Procotol Engine, version 2.0 > > > I read your paper "Design and Implementation of RSVP based on > > Object-Relationships", that describes your RSVP implementation, and I > have a > > question regarding a sentence in section 6.4: > > > > "...as has been reported to the rsvp-test mailing list [Mev99], the ISI > code > > currently has a hard-coded limitation to support only 64 concurrent > sessions." > > > > The email quoted (sent by Patrick Mevzek on June 24th, 1999) says that > some > > MAX_SESSIONS parameter is set to 64 in the ISI code, and that attempts > to > > increase this number result in other problems with some data structures. > > > > I recently downloaded the 4.2a4 release of ISI code, and I don't see > such > > limitation. Am I missing something? > > > > Could you explain? Can anyone confirm (or object to) this statement? > > I am sorry I can neither object or confirm. Nobody ever replied to the > email > above and Patrick confirmed his observation during a private email > exchange. > He also told me that he managed to compile it to be able to handle 262144 > flows, but then it allocated 83 MBytes memory at startup. When I have > looked > at the code (before this email), I found it rather unsuitable for > extending > it or generally playing around with it, so I decided to develop new code > and > did not look into rsvpd's details. Maybe I should have done it before > quoting this email, but then again, nobody replied... > > Note that I do not intend to bash anything or anyone here. Developing code > while you are defining a protocol is something completely different from > developing code when everything is settled. > > Greetings, > Martin From rsvp-owner@ISI.EDU Sat Feb 26 01:48:58 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01691 for ; Sat, 26 Feb 2000 01:48:57 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id UAA27042 for rsvp-outgoing; Fri, 25 Feb 2000 20:07:44 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id UAA27037 for ; Fri, 25 Feb 2000 20:07:42 -0800 (PST) Received: from mariareina.edu.pe ([209.58.61.186]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA00162 for ; Fri, 25 Feb 2000 20:07:42 -0800 (PST) Received: from roger [209.58.67.71] by mariareina.edu.pe with ESMTP (SMTPD32-5.05) id AB02DD00B2; Tue, 22 Feb 2000 22:15:30 -0500 From: "friend" Reply-To: ann@sogclub.com Subject: Gambling of Taiwan President Candidate To: puaqiao3@ISI.EDU X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Tue, 22 Feb 2000 22:11:36 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Message-Id: <200002222216816.SM00422@roger> Sender: owner-rsvp@ISI.EDU Precedence: bulk This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SOG Taiwan President gambling

3D"Chinese

This mail is never sent unsolicited=2E  If your email address shou= ldn't appear in our mailing list, please go to the following address for unsubscribe, than= ks=2E

http://d= fs0=2Esogclub=2Ecom/mail/membershk01=2Ehtm

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D= =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D

Gambling of Taiwan President Candidate, please go to the following Chin= ese big5 website


= http://www=2Esogclub=2Ecom/elections/indro=2Ehtm

or

http://www=2Epuaqiao=2E= com

------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From rsvp-owner@ISI.EDU Tue Feb 29 19:47:22 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05866 for ; Tue, 29 Feb 2000 19:47:20 -0500 (EST) Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id OAA26198 for rsvp-outgoing; Tue, 29 Feb 2000 14:20:14 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id OAA26193 for ; Tue, 29 Feb 2000 14:20:12 -0800 (PST) Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA10195 for ; Tue, 29 Feb 2000 14:20:15 -0800 (PST) Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA23445; Tue, 29 Feb 2000 14:18:25 -0800 Message-Id: <3.0.5.32.20000229141821.009eaaf0@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 29 Feb 2000 14:18:21 -0800 To: Marty Bickford From: Marty Bickford Subject: Call for Presentations: iBAND4 June 11-14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rsvp@ISI.EDU Precedence: bulk Call for Papers - http://www.stardust.com/iband4/conference.htm --------------- iBAND4 - Advancing the Technology of Internet Bandwidth Management and Traffic Engineering Technical Conference - June 11-13 Workshops with DMTF - June 14 iBAND4 is the fourth in a series of events focused on innovation in the areas of bandwidth management and traffic engineering. iBAND5 will be co-located and run together with ISPCON. The goal of iBAND is to help IP network professionals at ISP's and enterprise's understand the direction of work being done by standards groups and vendors. These events have also become a meeting place for the folks driving innovation in the areas of bandwidth management and traffic engineering. iBAND attendees include IP network engineers, network architects, engineering and business executives, MIS and IT professionals, product and development managers, researchers and other innovators. You are invited to submit a presentation proposal. To aid you in submitting a proposal, please visit http://www.stardust.com/iband4/conference.htm If you do not wish to present, we hope you will mark your calendar to attend this fun and innovative conference. Email or call me with any questions. Sincerely, Marty --- Marty Bickford - 408.879.8080 (8081-fax) Stardust.com - http://www.stardust.com