From owner-rap@ops.ietf.org Tue Jan 2 17:54:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23761 for ; Tue, 2 Jan 2001 17:54:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14DaJt-0003Br-00 for rap-data@psg.com; Tue, 02 Jan 2001 14:54:17 -0800 Received: from femail7.sdc1.sfba.home.com ([24.0.95.87]) by psg.com with esmtp (Exim 3.16 #1) id 14DaJs-0003Bl-00 for rap@ops.ietf.org; Tue, 02 Jan 2001 14:54:16 -0800 Received: from dperkins-nb2.dsperkins.com ([24.15.219.251]) by femail7.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010102225414.YNBA16755.femail7.sdc1.sfba.home.com@dperkins-nb2.dsperkins.com> for ; Tue, 2 Jan 2001 14:54:14 -0800 Message-Id: <5.0.2.1.2.20010102142436.01e51720@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 14:26:10 -0800 To: rap@ops.ietf.org From: "David T. Perkins" Subject: SPPI compiler Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rap@ops.ietf.org Precedence: bulk HI, Does there exist any SPPI compilers? If so, would you send the contact info. Thanks, /david t. perkins From owner-rap@ops.ietf.org Tue Jan 2 17:54:55 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23772 for ; Tue, 2 Jan 2001 17:54:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14DaJv-0003Bz-00 for rap-data@psg.com; Tue, 02 Jan 2001 14:54:19 -0800 Received: from femail7.sdc1.sfba.home.com ([24.0.95.87]) by psg.com with esmtp (Exim 3.16 #1) id 14DaJu-0003Bt-00 for rap@ops.ietf.org; Tue, 02 Jan 2001 14:54:18 -0800 Received: from dperkins-nb2.dsperkins.com ([24.15.219.251]) by femail7.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010102225417.YNBR16755.femail7.sdc1.sfba.home.com@dperkins-nb2.dsperkins.com> for ; Tue, 2 Jan 2001 14:54:17 -0800 Message-Id: <5.0.2.1.2.20010102142614.01e532f0@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 14:54:04 -0800 To: rap@ops.ietf.org From: "David T. Perkins" Subject: SPPI data type assignments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rap@ops.ietf.org Precedence: bulk HI, I noticed that there are some conflicts with the data type definitions in the SPPI I-D. The following assignment in the SPPI document: Integer64 ::= [APPLICATION 7] IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) conflicts with the following assignment from RFC 1442: UInteger32 ::= [APPLICATION 7] IMPLICIT INTEGER (0..4294967295) The following assignment from the SPPI document: Unsigned64 [APPLICATION 8] IMPLICIT INTEGER (0..18446744073709551615) conflicts with the following assignment found in internet-draft draft-perkins-float-00.txt: FloatType ::= [APPLICATION 8] IMPLICIT OCTET STRING (SIZE(4)) Also in internet-draft draft-perkins-bigint-00.txt there are the following definitions for signed and unsigned 64-bit integers: -- A signed integer of up to 64 bits of precision. I64Type ::= [APPLICATION 10] IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) -- An unsigned integer of up to 64 bit of precision. U64Type ::= [APPLICATION 11] IMPLICIT INTEGER (0.. 18446744073709551615) Note that the above assignments from the perkins I-Ds are in use in the net-snmp distribution (previously called the UC-DAVIS SNMP distribution). (See http://net-snmp.sourceforge.net/) Thus, I believe that the SPPI should be updated to use "[APPLICATION 10]" and "[APPLICATION 11]" instead of "[APPLICATION 7]" and "[APPLICATION 8]". Regards, /david t. perkins From owner-rap@ops.ietf.org Fri Jan 5 03:19:39 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07538 for ; Fri, 5 Jan 2001 03:19:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ES5Y-0002cc-00 for rap-data@psg.com; Fri, 05 Jan 2001 00:19:04 -0800 Received: from [202.96.135.132] (helo=smtp.huawei.com) by psg.com with esmtp (Exim 3.16 #1) id 14ES5S-0002bT-00 for rap@ops.ietf.org; Fri, 05 Jan 2001 00:19:01 -0800 Received: from W25224 ([10.105.33.147]) by smtp.huawei.com (Netscape Messaging Server 4.15) with ESMTP id G6OKAB02.510 for ; Fri, 5 Jan 2001 16:15:47 +0800 Message-ID: <004201c076f0$2a533a60$9321690a@huawei.com.cn> From: "WanJie" To: Subject: COPS Question Date: Fri, 5 Jan 2001 16:19:03 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rap@ops.ietf.org Precedence: bulk I have a simple question about COPS: Is it possible that a PEP connect with multiple PDPs simultaneously? I think it is impossible, but I hope your confirm. Thank you very much! Jacky From owner-rap@ops.ietf.org Fri Jan 5 04:09:35 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07917 for ; Fri, 5 Jan 2001 04:09:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ESsG-000539-00 for rap-data@psg.com; Fri, 05 Jan 2001 01:09:24 -0800 Received: from infres.enst.fr ([137.194.160.3]) by psg.com with esmtp (Exim 3.16 #1) id 14ESsF-000533-00 for rap@ops.ietf.org; Fri, 05 Jan 2001 01:09:23 -0800 Received: from yahoo.com (dhcp160-212.enst.fr [137.194.161.212]) by infres.enst.fr (Postfix) with ESMTP id 8658245406 for ; Fri, 5 Jan 2001 10:09:17 +0100 (MET) Message-ID: <3A558FEB.87DAB617@yahoo.com> Date: Fri, 05 Jan 2001 10:12:11 +0100 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org Subject: Re: COPS Question References: <004201c076f0$2a533a60$9321690a@huawei.com.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think that it's possible but each PDP occupies a client type. Mai Trang WanJie wrote: > I have a simple question about COPS: > > Is it possible that a PEP connect with multiple PDPs simultaneously? > > I think it is impossible, but I hope your confirm. > > Thank you very much! > > Jacky -- Nguyen Thi Mai Trang Departement INFRES Ecole Nationale Superieure des Telecommunications 46 - Rue Barrault - 75013 Paris Tel: 01 45 81 76 87 - 01 45 81 73 52 From owner-rap@ops.ietf.org Fri Jan 5 09:58:13 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14259 for ; Fri, 5 Jan 2001 09:58:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14EYJN-0009Pn-00 for rap-data@psg.com; Fri, 05 Jan 2001 06:57:45 -0800 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by psg.com with esmtp (Exim 3.16 #1) id 14EYJN-0009Pa-00 for rap@ops.ietf.org; Fri, 05 Jan 2001 06:57:45 -0800 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G6P004012V6PI@firewall.mcit.com> for rap@ops.ietf.org; Fri, 5 Jan 2001 14:57:06 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G6P003AD2V6GR@firewall.mcit.com>; Fri, 05 Jan 2001 14:57:06 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G6P000012V6CB@pmismtp04.wcomnet.com>; Fri, 05 Jan 2001 14:57:06 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G6P000012UZ5M@pmismtp04.wcomnet.com>; Fri, 05 Jan 2001 14:57:06 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G6P00M3T2UMPR@pmismtp04.wcomnet.com>; Fri, 05 Jan 2001 14:56:46 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Fri, 05 Jan 2001 14:56:46 +0000 Content-return: allowed Date: Fri, 05 Jan 2001 14:56:42 +0000 From: "Iliff, Tina" Subject: RE: COPS Question To: "'Nguyen Thi Mai Trang'" , rap@ops.ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E14B49A@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: text/plain; charset=ISO-8859-1 Sender: owner-rap@ops.ietf.org Precedence: bulk I agree with Mai Trang's response. Some PDPs may not support each client type which the PEP does support; therefore, it must establish connections with other PDPs in order to obtain policy for each client type if it so desires. There is nothing preventing the PEP from having multiple COPS connections (one for each client type) simultaneously. Tina Iliff -----Original Message----- From: Nguyen Thi Mai Trang [mailto:maitrangqos@yahoo.com] Sent: Friday, January 05, 2001 3:12 AM To: rap@ops.ietf.org Subject: Re: COPS Question I think that it's possible but each PDP occupies a client type. Mai Trang WanJie wrote: > I have a simple question about COPS: > > Is it possible that a PEP connect with multiple PDPs simultaneously? > > I think it is impossible, but I hope your confirm. > > Thank you very much! > > Jacky -- Nguyen Thi Mai Trang Departement INFRES Ecole Nationale Superieure des Telecommunications 46 - Rue Barrault - 75013 Paris Tel: 01 45 81 76 87 - 01 45 81 73 52 From owner-rap@ops.ietf.org Fri Jan 5 11:46:36 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16425 for ; Fri, 5 Jan 2001 11:46:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ea0W-000Ay3-00 for rap-data@psg.com; Fri, 05 Jan 2001 08:46:24 -0800 Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14Ea0Q-000Axr-00; Fri, 05 Jan 2001 08:46:18 -0800 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA15147; Fri, 5 Jan 2001 17:46:15 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA01918; Fri, 5 Jan 2001 17:46:14 +0100 Date: Fri, 5 Jan 2001 17:46:14 +0100 Message-Id: <200101051646.RAA01918@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dperkins@dsperkins.com CC: rap@ops.ietf.org, SMIng WG In-reply-to: <5.0.2.1.2.20010102142614.01e532f0@mail.scruznet.com> (dperkins@dsperkins.com) Subject: Re: SPPI data type assignments References: <5.0.2.1.2.20010102142614.01e532f0@mail.scruznet.com> Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> David T Perkins writes: David> I noticed that there are some conflicts with the data type David> definitions in the SPPI I-D. [...] David> Thus, I believe that the SPPI should be updated to use David> "[APPLICATION 10]" and "[APPLICATION 11]" instead of David> "[APPLICATION 7]" and "[APPLICATION 8]". Makes sense to me to use [APPLICATION 10] for Integer64 and [APPLICATION 11] for Unsigned64. (And I realize that this comment also applies for the equivalent definitions in the SMIng to SNMP mapping.) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-rap@ops.ietf.org Tue Jan 9 19:20:42 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23568 for ; Tue, 9 Jan 2001 19:20:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14G8zQ-000Jja-00 for rap-data@psg.com; Tue, 09 Jan 2001 16:19:44 -0800 Received: from h50s48a140n47.user.nortelnetworks.com ([47.140.48.50] helo=zrtps06s.us.nortel.com) by psg.com with esmtp (Exim 3.16 #1) id 14G8zP-000JjJ-00 for rap@ops.ietf.org; Tue, 09 Jan 2001 16:19:44 -0800 Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Tue, 9 Jan 2001 19:07:37 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 9 Jan 2001 19:07:19 -0500 Message-ID: From: "Ralph Santitoro" To: RAP list Subject: testing - please ignore Date: Tue, 9 Jan 2001 19:07:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" X-Orig: Sender: owner-rap@ops.ietf.org Precedence: bulk Testing to see if list is working properly. I didn't see my last posting.... Sorry for the inconvenience. From owner-rap@ops.ietf.org Tue Jan 9 20:12:32 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23978 for ; Tue, 9 Jan 2001 20:12:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14G9oG-000Kpo-00 for rap-data@psg.com; Tue, 09 Jan 2001 17:12:16 -0800 Received: from ertpg14e1.nortelnetworks.com ([47.234.0.35]) by psg.com with esmtp (Exim 3.16 #1) id 14G9oG-000Kph-00 for rap@ops.ietf.org; Tue, 09 Jan 2001 17:12:16 -0800 Received: from zrtpd00y.us.nortel.com by ertpg14e1.nortelnetworks.com; Tue, 9 Jan 2001 20:09:02 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 9 Jan 2001 20:09:03 -0500 Message-ID: From: "Ralph Santitoro" To: RAP list Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Tue, 9 Jan 2001 20:08:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Reposting due to email problems....... -----Original Message----- From: Santitoro, Ralph [GUAR:1482-M:EXCH] Sent: Monday, January 08, 2001 10:57 AM To: 'Ron Cohen'; rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Just catching up on email after vacation..... See comments below... Regards, Ralph Santitoro -----Original Message----- From: Ron Cohen [mailto:ronc@cisco.com] Sent: Monday, December 25, 2000 10:09 PM To: rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt I think that this draft deserves working group attention and discussion. I'm not sure whether it should be a working group item yet. Here are some basic questions about this draft: 1. I don't agree with the following text in the draft: "From the perspective of a sender and a receiver of application traffic, the conventional usage of RSVP is as follows: ... 5. Sender sends traffic regardless of the admission control decision. " I think this indicates a 'bad' RSVP application. If the application requires QoS, than it should not 'send it anyway', but rather either renegotiate TSPECs or turn to an alternative. For example, if you want to run a VoIP flow, and get a QoS refusal, you would than turn to send it via PSTN. --------------- [Ralph] Sending traffic with no QoS after an RSVP reservation failure is not necessarily a 'bad' RSVP-enabled application. An app. may still be usable without an RSVP reservation, albeit not optimal. However, sending traffic after and RSVP reservation failure may not be desirable for applications such as VoIP. A VoIP application may not be able to tolerate the call setup delay when renegotiating a new TSpec. While PSTN bypass is an option, the VoIP gateway or IP Phone may not support this functionality. Some network administrators/operators may want to simply block the VoIP app. while others may want to allow it to be sent as best effort. It all depends on the service being offered and the service level expectations. There are many possible scenarios that can occur if the RSVP reservation failed. I didn't list them in the draft because it wasn't meant to be specific to VoIP. If the WG would like this to be covered more extensively, I can add some of the many possible scenarios. --------------- 2. In the description of the alternatives available today to the network administrator to make sure that an application would not send anything across the WAN the following option is not mentioned: Create a 'Discard-on-WAN' PHB, and associate it with a DSCP. Set rules on all WAN routers that discard all packets arriving with this DSCP set. Return to such applications that send there traffic anyhow this DSCP value in the DCLASS object. In this way you are sure that even if the application does send the traffic even when QoS is rejected, traffic would be discarded on the WAN edge (assuming that at least it conforms with the DCLASS object sent to it). --------- [Ralph] Your example provides additional guarantees for apps that are not "DO_NOT_SEND" compliant. However, it would be better described as a "Discard-on-WAN DSCP" because you are simply dropping all traffic with the associated DSCP. I don't mind adding this to the draft. Does anyone else on the list have any comments on this? --------- 3. It is not explained in the draft why the added values should go into the policy error object and not to the error object policy errors as defined in appendix A of RFC2750. It does not say what should be carried in the RSVP error object --------------- [Ralph] Let me take a look at RFC 2750 again. I recall some reasons for not using them but don't remember. I'll get back to the list on this.... --------------- Ron From owner-rap@ops.ietf.org Thu Jan 11 16:13:36 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14790 for ; Thu, 11 Jan 2001 16:13:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Gp1P-000FOT-00 for rap-data@psg.com; Thu, 11 Jan 2001 13:12:35 -0800 Received: from csi-admin1.cisco.com ([144.254.91.12] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14Gp1N-000FMa-00 for rap@ops.ietf.org; Thu, 11 Jan 2001 13:12:34 -0800 Received: from user-53.cisco.com (telaviv3-dhcp142.cisco.com [144.254.93.80]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id XAA06479; Thu, 11 Jan 2001 23:11:56 +0200 (IST) Message-Id: <4.3.2.7.2.20010111110658.00c543c0@csi-admin1> X-Sender: ronc@csi-admin1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Jan 2001 13:15:06 -0800 To: Yoram Bernet , rap@ops.ietf.org From: Ron Cohen Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rap@ops.ietf.org Precedence: bulk Yoram, I think I have a better alternative to solve the problem raised by the draft. This is summarized in point 1. In point 2 I agree with Mark that it is not a good idea to carry DSCP values in Path error messages. point 1: alternate proposal: Instead of extending the error object, allow the application to add a policy object reformatting the Path message as a send/do-not-send question. A path-error (carrying the standard error-object with the standard RFC2750 policy error codes) message would than indicate to the application that it should not send this flow. A resv-error message would remain with the regular meaning of admission failure. Applications that are going to send the traffic anyhow, will always ask the 'do you allow me to send' question, because that is all they need to know. Applications that are going to use alternatives (renegotiate TSPEC, use a different route) are going to ask only admission control questions, and are not going to start sending prior to receiving a successful Resv message. Therefore, these applications will use the standard RSVP Path / Resv procedure, and nothing need to be extended for them. Another good aspect of this proposal that the PEP/PDP knows from the request the capabilities of the application, as they see the new policy object carried in the Path message. This is lacking in the current proposal. Point 2: The draft doesn't say whether the application need to tear down the Path when it receives a Path Error message with the new error value. The answer is not simple. If it is torn down (which I think is the implicit assumption), than I agree with Mark that it becomes a problem to recommend a DSCP in a Path Error, as the PDP and PEP will never know when the flow ends and the DSCP is no longer used. If it is not torn down, there should be text that specify how an application should decide whether it should or should not tear down the path. All in all, I do not see a need to carry DSCP values in PathErr messages, and I would rather keep the simple approach that when you get a Path Error, you should tear down the Path. Regards Ron >Thanks for your comments. Responses are interspersed below... > > > -----Original Message----- > > From: Ron Cohen [mailto:ronc@cisco.com] > > Sent: Monday, December 25, 2000 10:09 PM > > To: rap@ops.ietf.org > > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > > > > > > I think that this draft deserves working group attention and > > discussion. > > I'm not sure whether it should be a working group item yet. > > > > Here are some basic questions about this draft: > > > > 1. I don't agree with the following text in the draft: > > > > "From the perspective of a sender and a receiver of > > application traffic, > > the conventional usage of RSVP is as follows: > > ... > > 5. Sender sends traffic regardless of the admission control > > decision. " > >Perhaps calling this "conventional usage" is a poor choice of words. >However, from my experience speaking with application writers - they tend to >look at RSVP and at QoS in general as something that might help them to get >better service, but not as something that should prevent them from getting >what they can. Their view is that they will signal and if they get QoS >that's great, but - if they don't, they'd still like to try to get whatever >b/e service they can. You're suggesting that this is a bad application and >that the application would be better advised to try a different tspec. I >think that this is very much a debatable position. For one, even when an app >is not explicitly refused a qos request, it has no way of knowing (other >than by measurement) that it is really getting qos and how good that qos is. >So - a model of "I will only send if I am told by the network that I got >QoS" is not necessarily going to be very successful. Furthermore, who's to >say that the user experience would be better for a session that uses a great >(if resource demanding) codec that does not get qos or a poorer codec that >does? > >Anyway - the bottom line from my perspective is that none of the current >usages of RSVP are intended to tell the application "thou shalt not send" >and so - the application is allowed to send regardless of the outcome of the >rsvp request. Perhaps we could modify the words to reflect this notion >better. > > > > > I think this indicates a 'bad' RSVP application. If the application > > requires QoS, than it should not 'send it anyway', but rather either > > renegotiate TSPECs or turn to an alternative. For example, if > > you want to > > run a VoIP flow, and get a QoS refusal, you would than turn > > to send it via > > PSTN. > > > >See comments above. > > > > > 2. In the description of the alternatives available today to > > the network > > administrator to make sure that an application would not send > > anything > > across the WAN the following option is not mentioned: > > > > Create a 'Discard-on-WAN' PHB, and associate it with a DSCP. > > Set rules on > > all WAN routers that discard all packets arriving with this DSCP set. > > Return to such applications that send there traffic anyhow > > this DSCP value > > in the DCLASS object. In this way you are sure that even if > > the application > > does send the traffic even when QoS is rejected, traffic > > would be discarded > > on the WAN edge (assuming that at least it conforms with the > > DCLASS object > > sent to it). > >I agree with the goal of this approach, though not with the mechanism. Let's >consider unicast and multicast sepaerately. First - unicast: > >If there exists, on the end-to-end path between sender and receiver, a >congested point (likely, but not necessarily a WAN) that cannot (or should >not) dedicate the necessary resources to the signaled flow, then the flow >should be rejected at that node via *signaling* (explicit admission >control). It can be rejected either with the DO_NOT_SEND object or by >offering a DCLASS corresponsing to b/e, or just by rejecting the flow (which >will result in the traffic being marked for best-effort. By doing so via >signaling, other nodes along the path, including the sender, are coordinated >explicitly. This is important. In the alternative that you propose, the >traffic is policed, implicitly, at one (or possibly more) nodes along the >path. One of the possible consequences of your approach (that is avoided by >the explicit admission control approach)is that resources are dedicated to >the flow at certain nodes (including the sender) while the traffic is >discarded at the WAN node. As a result, the user does not enjoy the >necessary end-to-end quality and the resources that have been dedicated >elsewhere in the network are actually wasted as a result. We should let RSVP >do what it does well here - it accumulates explicit admission control >decisions - if any admission control agent along the path from sender to >receiver cannot accommodate the flow, then it will reject the RSVP request >and the traffic will not be prioritized (or will not be sent) and will not >waste resources anywhere along the path. > > > > > 3. It is not explained in the draft why the added values > > should go into the > > policy error object and not to the error object policy errors > > as defined in > > appendix A of RFC2750. It does not say what should be carried > > in the RSVP > > error object > >So - this is a matter of detail that we should certainly discuss once the >ideological issues are agreed upon. > > > > Ron > > >Yoram From owner-rap@ops.ietf.org Fri Jan 12 09:59:50 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10124 for ; Fri, 12 Jan 2001 09:59:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14H5fx-000OP1-00 for rap-data@psg.com; Fri, 12 Jan 2001 06:59:33 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14H5fw-000OOt-00 for rap@ops.ietf.org; Fri, 12 Jan 2001 06:59:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14H5fw-0009ZV-00 for rap@ops.ietf.org; Fri, 12 Jan 2001 06:59:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush Subject: Reminder - use correct "From:". Sender: owner-rap@ops.ietf.org Precedence: bulk Message-Id: To: rap-data@psg.com Date: Fri, 12 Jan 2001 06:59:33 -0800 Content-Transfer-Encoding: 7bit please remember to use the correct "From:" addres when you send messages to this list. 'correct' means that the address in your "From:" mail header field should be the same as the address with which you sub scribed to the list. failing to use the correct address will bounce your message to the list admin (me) for manual approval. this can lead to significant delay, and you turn your trust to _my_ memory to remember to forward the message to the list - which is something I would be very careful with myself ... ;-) randy From owner-rap@ops.ietf.org Fri Jan 12 10:11:04 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10255 for ; Fri, 12 Jan 2001 10:11:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14H5qr-000OtS-00 for rap-data@psg.com; Fri, 12 Jan 2001 07:10:49 -0800 Received: from web11103.mail.yahoo.com ([216.136.131.150]) by psg.com with smtp (Exim 3.16 #1) id 14H5qp-000OtF-00 for rap@ops.ietf.org; Fri, 12 Jan 2001 07:10:48 -0800 Message-ID: <20010112151042.59448.qmail@web11103.mail.yahoo.com> Received: from [47.248.0.42] by web11103.mail.yahoo.com; Fri, 12 Jan 2001 07:10:42 PST Date: Fri, 12 Jan 2001 07:10:42 -0800 (PST) From: vinay Subject: COPS key management question To: rap@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-rap@ops.ietf.org Precedence: bulk Hi Section 4.2 ( Key Maintenance) in RFC 2748 mentions : It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap allowing smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not. Does this mean that everytime a key is changed, the open session should be closed and the security and sequence number negotiation be done again ( i.e. by reconnecting and sending an OPN message with the new key id in the integrity object after closing the previous session ..) ? Thanks, Vinay __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-rap@ops.ietf.org Fri Jan 12 12:17:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12813 for ; Fri, 12 Jan 2001 12:17:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14H7oX-0003TI-00 for rap-data@psg.com; Fri, 12 Jan 2001 09:16:33 -0800 Received: from df-inet1.exchange.microsoft.com ([131.107.8.8] helo=DF-INET-1.dogfoodinternet.com) by psg.com with esmtp (Exim 3.16 #1) id 14H7oW-0003SR-00 for rap@ops.ietf.org; Fri, 12 Jan 2001 09:16:32 -0800 Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 12 Jan 2001 09:13:21 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Jan 2001 09:14:04 -0800 (Pacific Standard Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Fri, 12 Jan 2001 09:14:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Fri, 12 Jan 2001 09:14:02 -0800 Message-ID: <766EFCAA12CB514CAC64D8C440F5A50E629F26@DF-SCRAPPY.platinum.corp.microsoft.com> Thread-Topic: draft-santitoro-rap-policy-errorcodes-01.txt Thread-Index: AcB8Vrf4n2r4lfMOSTqTui0oYv3uAgAYnFPg From: "Ramesh Pabbati" To: "Yoram Bernet" Cc: X-OriginalArrivalTime: 12 Jan 2001 17:14:04.0390 (UTC) FILETIME=[107F9860:01C07CBB] Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA12813 Yoram, Ron has a point in #1. We can use the error codes defines in RFC2750, I forgot about them or did not notice. Please let me know when you can discuss this. Ramesh -----Original Message----- From: Ron Cohen [mailto:ronc@cisco.com] Sent: Thursday, January 11, 2001 1:15 PM To: Yoram Bernet; rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram, I think I have a better alternative to solve the problem raised by the draft. This is summarized in point 1. In point 2 I agree with Mark that it is not a good idea to carry DSCP values in Path error messages. point 1: alternate proposal: Instead of extending the error object, allow the application to add a policy object reformatting the Path message as a send/do-not-send question. A path-error (carrying the standard error-object with the standard RFC2750 policy error codes) message would than indicate to the application that it should not send this flow. A resv-error message would remain with the regular meaning of admission failure. Applications that are going to send the traffic anyhow, will always ask the 'do you allow me to send' question, because that is all they need to know. Applications that are going to use alternatives (renegotiate TSPEC, use a different route) are going to ask only admission control questions, and are not going to start sending prior to receiving a successful Resv message. Therefore, these applications will use the standard RSVP Path / Resv procedure, and nothing need to be extended for them. Another good aspect of this proposal that the PEP/PDP knows from the request the capabilities of the application, as they see the new policy object carried in the Path message. This is lacking in the current proposal. Point 2: The draft doesn't say whether the application need to tear down the Path when it receives a Path Error message with the new error value. The answer is not simple. If it is torn down (which I think is the implicit assumption), than I agree with Mark that it becomes a problem to recommend a DSCP in a Path Error, as the PDP and PEP will never know when the flow ends and the DSCP is no longer used. If it is not torn down, there should be text that specify how an application should decide whether it should or should not tear down the path. All in all, I do not see a need to carry DSCP values in PathErr messages, and I would rather keep the simple approach that when you get a Path Error, you should tear down the Path. Regards Ron >Thanks for your comments. Responses are interspersed below... > > > -----Original Message----- > > From: Ron Cohen [mailto:ronc@cisco.com] > > Sent: Monday, December 25, 2000 10:09 PM > > To: rap@ops.ietf.org > > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > > > > > > I think that this draft deserves working group attention and > > discussion. > > I'm not sure whether it should be a working group item yet. > > > > Here are some basic questions about this draft: > > > > 1. I don't agree with the following text in the draft: > > > > "From the perspective of a sender and a receiver of > > application traffic, > > the conventional usage of RSVP is as follows: > > ... > > 5. Sender sends traffic regardless of the admission control > > decision. " > >Perhaps calling this "conventional usage" is a poor choice of words. >However, from my experience speaking with application writers - they tend to >look at RSVP and at QoS in general as something that might help them to get >better service, but not as something that should prevent them from getting >what they can. Their view is that they will signal and if they get QoS >that's great, but - if they don't, they'd still like to try to get whatever >b/e service they can. You're suggesting that this is a bad application and >that the application would be better advised to try a different tspec. I >think that this is very much a debatable position. For one, even when an app >is not explicitly refused a qos request, it has no way of knowing (other >than by measurement) that it is really getting qos and how good that qos is. >So - a model of "I will only send if I am told by the network that I got >QoS" is not necessarily going to be very successful. Furthermore, who's to >say that the user experience would be better for a session that uses a great >(if resource demanding) codec that does not get qos or a poorer codec that >does? > >Anyway - the bottom line from my perspective is that none of the current >usages of RSVP are intended to tell the application "thou shalt not send" >and so - the application is allowed to send regardless of the outcome of the >rsvp request. Perhaps we could modify the words to reflect this notion >better. > > > > > I think this indicates a 'bad' RSVP application. If the application > > requires QoS, than it should not 'send it anyway', but rather either > > renegotiate TSPECs or turn to an alternative. For example, if > > you want to > > run a VoIP flow, and get a QoS refusal, you would than turn > > to send it via > > PSTN. > > > >See comments above. > > > > > 2. In the description of the alternatives available today to > > the network > > administrator to make sure that an application would not send > > anything > > across the WAN the following option is not mentioned: > > > > Create a 'Discard-on-WAN' PHB, and associate it with a DSCP. > > Set rules on > > all WAN routers that discard all packets arriving with this DSCP set. > > Return to such applications that send there traffic anyhow > > this DSCP value > > in the DCLASS object. In this way you are sure that even if > > the application > > does send the traffic even when QoS is rejected, traffic > > would be discarded > > on the WAN edge (assuming that at least it conforms with the > > DCLASS object > > sent to it). > >I agree with the goal of this approach, though not with the mechanism. Let's >consider unicast and multicast sepaerately. First - unicast: > >If there exists, on the end-to-end path between sender and receiver, a >congested point (likely, but not necessarily a WAN) that cannot (or should >not) dedicate the necessary resources to the signaled flow, then the flow >should be rejected at that node via *signaling* (explicit admission >control). It can be rejected either with the DO_NOT_SEND object or by >offering a DCLASS corresponsing to b/e, or just by rejecting the flow (which >will result in the traffic being marked for best-effort. By doing so via >signaling, other nodes along the path, including the sender, are coordinated >explicitly. This is important. In the alternative that you propose, the >traffic is policed, implicitly, at one (or possibly more) nodes along the >path. One of the possible consequences of your approach (that is avoided by >the explicit admission control approach)is that resources are dedicated to >the flow at certain nodes (including the sender) while the traffic is >discarded at the WAN node. As a result, the user does not enjoy the >necessary end-to-end quality and the resources that have been dedicated >elsewhere in the network are actually wasted as a result. We should let RSVP >do what it does well here - it accumulates explicit admission control >decisions - if any admission control agent along the path from sender to >receiver cannot accommodate the flow, then it will reject the RSVP request >and the traffic will not be prioritized (or will not be sent) and will not >waste resources anywhere along the path. > > > > > 3. It is not explained in the draft why the added values > > should go into the > > policy error object and not to the error object policy errors > > as defined in > > appendix A of RFC2750. It does not say what should be carried > > in the RSVP > > error object > >So - this is a matter of detail that we should certainly discuss once the >ideological issues are agreed upon. > > > > Ron > > >Yoram From owner-rap@ops.ietf.org Fri Jan 12 13:22:47 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14442 for ; Fri, 12 Jan 2001 13:22:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14H8pr-0005pM-00 for rap-data@psg.com; Fri, 12 Jan 2001 10:21:59 -0800 Received: from pigpen.lucentctc.com ([199.93.237.4]) by psg.com with esmtp (Exim 3.16 #1) id 14H8pq-0005nU-00 for rap@ops.ietf.org; Fri, 12 Jan 2001 10:21:58 -0800 Received: by pigpen.lucentctc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 13:21:25 -0500 Message-ID: From: "Grimstad, Al" To: rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Fri, 12 Jan 2001 13:21:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk I think the alternative sketched under point 1 will satisfy the requirements that stimulated our interest in the draft. We would like to see something progressed to address the "do not send" issue. Regarding point 2, I don't think we really need DSCPs in PathErr messages. -- al -----Original Message----- From: Ron Cohen [mailto:ronc@cisco.com] Sent: Thursday, January 11, 2001 4:15 PM To: Yoram Bernet; rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Yoram, I think I have a better alternative to solve the problem raised by the draft. This is summarized in point 1. In point 2 I agree with Mark that it is not a good idea to carry DSCP values in Path error messages. point 1: alternate proposal: Instead of extending the error object, allow the application to add a policy object reformatting the Path message as a send/do-not-send question. A path-error (carrying the standard error-object with the standard RFC2750 policy error codes) message would than indicate to the application that it should not send this flow. A resv-error message would remain with the regular meaning of admission failure. Applications that are going to send the traffic anyhow, will always ask the 'do you allow me to send' question, because that is all they need to know. Applications that are going to use alternatives (renegotiate TSPEC, use a different route) are going to ask only admission control questions, and are not going to start sending prior to receiving a successful Resv message. Therefore, these applications will use the standard RSVP Path / Resv procedure, and nothing need to be extended for them. Another good aspect of this proposal that the PEP/PDP knows from the request the capabilities of the application, as they see the new policy object carried in the Path message. This is lacking in the current proposal. Point 2: The draft doesn't say whether the application need to tear down the Path when it receives a Path Error message with the new error value. The answer is not simple. If it is torn down (which I think is the implicit assumption), than I agree with Mark that it becomes a problem to recommend a DSCP in a Path Error, as the PDP and PEP will never know when the flow ends and the DSCP is no longer used. If it is not torn down, there should be text that specify how an application should decide whether it should or should not tear down the path. All in all, I do not see a need to carry DSCP values in PathErr messages, and I would rather keep the simple approach that when you get a Path Error, you should tear down the Path. Regards Ron >Thanks for your comments. Responses are interspersed below... > > > -----Original Message----- > > From: Ron Cohen [mailto:ronc@cisco.com] > > Sent: Monday, December 25, 2000 10:09 PM > > To: rap@ops.ietf.org > > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > > > > > > I think that this draft deserves working group attention and > > discussion. > > I'm not sure whether it should be a working group item yet. > > > > Here are some basic questions about this draft: > > > > 1. I don't agree with the following text in the draft: > > > > "From the perspective of a sender and a receiver of > > application traffic, > > the conventional usage of RSVP is as follows: > > ... > > 5. Sender sends traffic regardless of the admission control > > decision. " > >Perhaps calling this "conventional usage" is a poor choice of words. >However, from my experience speaking with application writers - they tend to >look at RSVP and at QoS in general as something that might help them to get >better service, but not as something that should prevent them from getting >what they can. Their view is that they will signal and if they get QoS >that's great, but - if they don't, they'd still like to try to get whatever >b/e service they can. You're suggesting that this is a bad application and >that the application would be better advised to try a different tspec. I >think that this is very much a debatable position. For one, even when an app >is not explicitly refused a qos request, it has no way of knowing (other >than by measurement) that it is really getting qos and how good that qos is. >So - a model of "I will only send if I am told by the network that I got >QoS" is not necessarily going to be very successful. Furthermore, who's to >say that the user experience would be better for a session that uses a great >(if resource demanding) codec that does not get qos or a poorer codec that >does? > >Anyway - the bottom line from my perspective is that none of the current >usages of RSVP are intended to tell the application "thou shalt not send" >and so - the application is allowed to send regardless of the outcome of the >rsvp request. Perhaps we could modify the words to reflect this notion >better. > > > > > I think this indicates a 'bad' RSVP application. If the application > > requires QoS, than it should not 'send it anyway', but rather either > > renegotiate TSPECs or turn to an alternative. For example, if > > you want to > > run a VoIP flow, and get a QoS refusal, you would than turn > > to send it via > > PSTN. > > > >See comments above. > > > > > 2. In the description of the alternatives available today to > > the network > > administrator to make sure that an application would not send > > anything > > across the WAN the following option is not mentioned: > > > > Create a 'Discard-on-WAN' PHB, and associate it with a DSCP. > > Set rules on > > all WAN routers that discard all packets arriving with this DSCP set. > > Return to such applications that send there traffic anyhow > > this DSCP value > > in the DCLASS object. In this way you are sure that even if > > the application > > does send the traffic even when QoS is rejected, traffic > > would be discarded > > on the WAN edge (assuming that at least it conforms with the > > DCLASS object > > sent to it). > >I agree with the goal of this approach, though not with the mechanism. Let's >consider unicast and multicast sepaerately. First - unicast: > >If there exists, on the end-to-end path between sender and receiver, a >congested point (likely, but not necessarily a WAN) that cannot (or should >not) dedicate the necessary resources to the signaled flow, then the flow >should be rejected at that node via *signaling* (explicit admission >control). It can be rejected either with the DO_NOT_SEND object or by >offering a DCLASS corresponsing to b/e, or just by rejecting the flow (which >will result in the traffic being marked for best-effort. By doing so via >signaling, other nodes along the path, including the sender, are coordinated >explicitly. This is important. In the alternative that you propose, the >traffic is policed, implicitly, at one (or possibly more) nodes along the >path. One of the possible consequences of your approach (that is avoided by >the explicit admission control approach)is that resources are dedicated to >the flow at certain nodes (including the sender) while the traffic is >discarded at the WAN node. As a result, the user does not enjoy the >necessary end-to-end quality and the resources that have been dedicated >elsewhere in the network are actually wasted as a result. We should let RSVP >do what it does well here - it accumulates explicit admission control >decisions - if any admission control agent along the path from sender to >receiver cannot accommodate the flow, then it will reject the RSVP request >and the traffic will not be prioritized (or will not be sent) and will not >waste resources anywhere along the path. > > > > > 3. It is not explained in the draft why the added values > > should go into the > > policy error object and not to the error object policy errors > > as defined in > > appendix A of RFC2750. It does not say what should be carried > > in the RSVP > > error object > >So - this is a matter of detail that we should certainly discuss once the >ideological issues are agreed upon. > > > > Ron > > >Yoram From owner-rap@ops.ietf.org Fri Jan 12 14:08:01 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15185 for ; Fri, 12 Jan 2001 14:08:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14H9YC-0007Rp-00 for rap-data@psg.com; Fri, 12 Jan 2001 11:07:48 -0800 Received: from ganymede.or.intel.com ([134.134.248.3]) by psg.com with esmtp (Exim 3.16 #1) id 14H9YC-0007Rj-00 for rap@ops.ietf.org; Fri, 12 Jan 2001 11:07:48 -0800 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id LAA26313; Fri, 12 Jan 2001 11:07:22 -0800 (PST) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 12 Jan 2001 19:04:38 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jan 2001 11:04:35 -0800 Message-ID: <10C8636AE359D4119118009027AE998704F39CB2@FMSMSX34> From: "Durham, David" To: "'vinay'" , rap@ops.ietf.org Subject: RE: COPS key management question Date: Fri, 12 Jan 2001 10:23:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk > -----Original Message----- > From: vinay [mailto:mietf@yahoo.com] > > Hi > Section 4.2 ( Key Maintenance) in RFC 2748 mentions : > It is good practice to regularly change keys. Keys > MUST be configurable such > that their lifetimes overlap allowing smooth > transitions between keys. At > the midpoint of the lifetime overlap between two keys, > senders should > transition from using the current key to the > next/longer-lived key. > Meanwhile, receivers simply accept any identified key > received within its > configured lifetime and reject those that are not. > Does this mean that everytime a key is changed, the > open session should be closed > and the security and sequence number negotiation be > done again ( i.e. by > reconnecting and sending an OPN message with the new > key id in the integrity > object after closing the previous session ..) ? [Dave] No. All the session keys are identified by their KeyID. Thus, you do not have to renegotiate anything. The current sequence can be maintained, because when the key is switched, the KeyID is changed to that of the new key. The above quote deals with how switching keys in an active session is handled between the client and server (PEP & PDP). It allows their period of validity to overlap so the transition will work smoothly. > Thanks, > Vinay > > > From owner-rap@ops.ietf.org Fri Jan 12 15:59:26 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23910 for ; Fri, 12 Jan 2001 15:59:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14HBHo-000BsR-00 for rap-data@psg.com; Fri, 12 Jan 2001 12:59:00 -0800 Received: from h50s48a140n47.user.nortelnetworks.com ([47.140.48.50] helo=zrtps06s.us.nortel.com) by psg.com with esmtp (Exim 3.16 #1) id 14HBHn-000Bpg-00 for rap@ops.ietf.org; Fri, 12 Jan 2001 12:58:59 -0800 Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Fri, 12 Jan 2001 15:47:43 -0500 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 12 Jan 2001 15:47:22 -0500 Message-ID: From: "Ralph Santitoro" To: "Gross, Gerhard" , rap@ops.ietf.org Cc: "Diana Rawlins (E-mail)" , "Grosen, Mark (IDD)" , "Henry Sinnreich (E-mail)" , "Jeff Mark (E-mail)" , "Kelley, Kalon (IDD)" , "Liu, Changwen" , "Raghunath, Arun" , Stephen Thomas , "Theodore Havinis (E-mail)" Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Fri, 12 Jan 2001 15:47:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07CD8.D7D56300" X-Orig: Sender: owner-rap@ops.ietf.org 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_001_01C07CD8.D7D56300 Content-Type: text/plain; charset="iso-8859-1" Gerhard, I took a quick look at the drafts you listed below and they appear to be specific to SIP. (fyi, 2 of the drafts were not on the ietf site - perhaps they got renamed) The subject draft provides a generalized, protocol-independent approach for controlling sender behavior for any type of application, including voice. This approach would work for H.323, H.248/MEGACO, MGCP and SIP-based voice applications. In your "draft-gross-sipaq-00.txt" on page 4, you state that: "Other signaling means such as H.323, MEGACO or related protocols, may have a different structure in the dependency between signaling, QoS setup and AAA and are therefore not the object of this draft. Not all QoS-enabled applications, including VoIP, will use SIP." QoS Assured/Enabled calls discussed in "draft-sinnreich-aaa-interdomain-sip-qos-osp-00.txt" are w.r.t. whether a call receives QoS or not. "draft-santitoro-rap-policy-errorcodes-01.txt" discusses how the network tells the sender one of two things: 1) "Do not send any traffic" (All traffic will be dropped for non-compliant applications) - or - 2) "You can send traffic but no QoS will be provided" Here, the sender has many choices such as: - send the traffic achieving achieving only best effort or LBE service, - re-initiate another RSVP reservation with different TSPEC parameters, - take alternate paths (as in the case of a VoIP/PSTN gateway), etc. Bottom line: I think that the subject draft and the drafts you listed are addressing and solving different problem spaces. Regards, Ralph -----Original Message----- From: Gross, Gerhard [mailto:gerhard.gross@intel.com] Sent: Tuesday, December 26, 2000 10:43 AM To: rap@ops.ietf.org Cc: Diana Rawlins (E-mail); Grosen, Mark (IDD); Henry Sinnreich (E-mail); Jeff Mark (E-mail); Kelley, Kalon (IDD); Liu, Changwen; Raghunath, Arun; Stephen Thomas; Theodore Havinis (E-mail) Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > Mark, if we were to use RSVP for certain applications, e.g., VoIP, then this > ID would provide us absolutely necessary features. I encourage the WG to > make this an official work item and progress it on the standards track ASAP. > -- al These are not *absolutely necessary features*. Issues concerning integration of QoS (RSVP) and VoIP (as well as AAA) have been the focus of work by a number of people for quite some time now. See the following drafts, submitted to the SIP (Session Initiation Protocol) working group. draft-gross-sipaq-00.txt draft-gross-cops-sip-00.txt draft-sinnreich-aaa-interdomain-sip-qos-osp-00.txt draft-sinnreich-interdomain-sip-qos-osp-01.txt draft-sinnreich-johnston-sip-osp-token-00.txt No extensions or modifications to RSVP need to be made. A snippet from the santitoro draft: > The first ErrorValue informs the sending application that it MUST NOT > send the traffic described in its PATH message. The second ErrorValue > informs the sending application that prioritized resources are not > available but that it may proceed to send with no resource guarantees. > (The ErrorValues are intended to be included in PATH_ERR messages, in > response to corresponding PATH messages). Both of these cases have already been addressed. draft-sinnreich-interdomain-sip-qos-osp-01.txt discusses in detail two QoS models: QoS Assured and QoS Enabled. The QoS assured model only completes call setup if/when QoS has been established. In this case, the sender does not send until/unless QoS has been established. The QoS enabled model completes call setup regardless. In this case, the user wants the call to proceed before QoS has been granted and even if QoS is never granted for the session. draft-gross-sipaq-00.txt defines a COPS extension for SIP to integrate policy (and AAA) messaging into the VoIP picture. See draft-gross-sipaq-00.txt for a general overview. Gery XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X X X Gerhard W. Gross, Ph.D. X X Intel X X 2111 NE 25th Ave X X Hillsboro, OR 97124-5961, USA X X Policy Architecture Group X X - Internet and Communication Lab X X phone: (503) 264-6389 X X fax: (503) 264-3483 X X email: gerhard.gross@intel.com X X X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > -----Original Message----- > From: Dan Romascanu [mailto:dromasca@avaya.com] > Sent: Tuesday, December 26, 2000 12:23 AM > To: 'Ron Cohen'; rap@ops.ietf.org > Cc: Anwar Siddiqui; Eyal Amitai > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > > > > I think that this draft deserves working group attention > and discussion. > > I'm not sure whether it should be a working group item yet. > > > [Dan] I agree. I think the draft starts to address a > set of issues > related to implementing real-life applications like VoIP by > means of RSVP > extensions over Diffserv networks. > > > Here are some basic questions about this draft: > > > > 1. I don't agree with the following text in the draft: > > > > "From the perspective of a sender and a receiver of > application traffic, > > the conventional usage of RSVP is as follows: > > ... > > 5. Sender sends traffic regardless of the admission > control decision. " > > > > I think this indicates a 'bad' RSVP application. If the application > > requires QoS, than it should not 'send it anyway', but > rather either > > renegotiate TSPECs or turn to an alternative. For example, > if you want to > > run a VoIP flow, and get a QoS refusal, you would than turn > to send it via > > > > PSTN. > > > [Dan] This draft is about searching a practical > approach for the > use of RSVP signaling. According to the type of deployment we > deal with, > several alternatives might or might not be available. Re-negotiating > different TSPECs might make even worse the problem of the time that is > allowable for completion of signaling in a VoIP application. The user > experience of a phone user is to have some audio feedback > available about > the network resources availability as soon as he picked the > phone. Admission > control by end-to-end RSVP signaling with or without > outsourcing some of the > decisions to PDPs on the way is a time consuming operation. > > On the other hand, PSTN re-routing might not be available in all > environments. In some cases a 'sub-optimal' traffic transmission as > suggested by the draft might be acceptable. It looks like me > might need to > consider different alternate policies, even with the price of > becoming more > liberal in what we label as 'good' or 'bad' RSVP application. > > > > 2. In the description of the alternatives available today > to the network > > administrator to make sure that an application would not > send anything > > across the WAN the following option is not mentioned: > > > > Create a 'Discard-on-WAN' PHB, and associate it with a > DSCP. Set rules on > > all WAN routers that discard all packets arriving with this > DSCP set. > > Return to such applications that send there traffic anyhow > this DSCP value > > > > in the DCLASS object. In this way you are sure that even if the > > application > > does send the traffic even when QoS is rejected, traffic would be > > discarded > > on the WAN edge (assuming that at least it conforms with > the DCLASS object > > > > sent to it). > > > [Dan] Yes, this is an interesting idea, though I would > avoid using > the term 'WAN' and try to define differently the discard domain. > > My question is what is the PHB for the 'non-WAN routers'? If the > traffic is sent best-effort, there should be no resource > allocation problem, > even for the WAN routers - applications should just ensure > that they send > some feedback to the user 'your call won't make it over the > discard domain > (WAN) and may be performance degraded'. Or maybe you had in > mind the local > routers treating this traffic with same PHB as high admitted > traffic within > the 'local' domain? Maybe we should map this DSCP to a > 'Better than Best > Effort' behavior, which would ensure a better PH service than BE - if > available - but would protect already admitted traffic. > > Regards, > > Dan > > > ------_=_NextPart_001_01C07CD8.D7D56300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-santitoro-rap-policy-errorcodes-01.txt

Gerhard,

I took a quick look at the drafts you listed below = and they appear to be specific to SIP.    (fyi, 2 of the = drafts were not on the ietf site - perhaps they got renamed)

The subject draft provides a generalized, = protocol-independent approach for controlling sender behavior for any = type of application, including voice.  This approach would work = for H.323, H.248/MEGACO, MGCP and SIP-based voice applications.  =

In your "draft-gross-sipaq-00.txt" on page = 4, you state that:
"Other signaling means such as H.323, MEGACO or = related protocols, may have a different structure in the dependency = between signaling, QoS setup and AAA and are therefore not the object = of this draft. Not all QoS-enabled applications, including VoIP, will = use SIP."

QoS Assured/Enabled calls discussed in = "draft-sinnreich-aaa-interdomain-sip-qos-osp-00.txt" are = w.r.t. whether a call receives QoS or not. = "draft-santitoro-rap-policy-errorcodes-01.txt" discusses how = the network tells the sender one of two things:

1) "Do not send any traffic" (All traffic = will be dropped for non-compliant applications)
          - or = -
2) "You can send traffic but no QoS will be = provided" Here, the sender has many choices such as:
- send the traffic achieving achieving only best = effort or LBE service,
- re-initiate another RSVP reservation with = different TSPEC parameters,
- take alternate paths (as in the case of a = VoIP/PSTN gateway), etc.

Bottom line: I think that the subject draft and the = drafts you listed are addressing and solving different problem = spaces.

Regards,
Ralph

-----Original Message-----
From: Gross, Gerhard [mailto:gerhard.gross@intel.com]
Sent: Tuesday, December 26, 2000 10:43 AM
To: rap@ops.ietf.org
Cc: Diana Rawlins (E-mail); Grosen, Mark (IDD); = Henry Sinnreich
(E-mail); Jeff Mark (E-mail); Kelley, Kalon (IDD); = Liu, Changwen;
Raghunath, Arun; Stephen Thomas; Theodore Havinis = (E-mail)
Subject: RE: = draft-santitoro-rap-policy-errorcodes-01.txt



> Mark, if we were to use RSVP for certain = applications, e.g., VoIP, then
this
> ID would provide us absolutely necessary = features. I encourage the WG to
> make this an official work item and progress it = on the standards track
ASAP.
> -- al

These are not *absolutely necessary features*.
Issues concerning integration of QoS (RSVP) = and
VoIP (as well as AAA) have been the focus of
work by a number of people for quite some = time
now. See the following drafts, submitted to = the
SIP (Session Initiation Protocol) working group.

draft-gross-sipaq-00.txt
draft-gross-cops-sip-00.txt
draft-sinnreich-aaa-interdomain-sip-qos-osp-00.txt
draft-sinnreich-interdomain-sip-qos-osp-01.txt
draft-sinnreich-johnston-sip-osp-token-00.txt

No extensions or modifications to RSVP need to be = made.

A snippet from the santitoro draft:

> The first ErrorValue informs the sending = application that it MUST NOT
> send the traffic described in its PATH message. = The second ErrorValue
> informs the sending application that = prioritized resources are not
> available but that it may proceed to send with = no resource guarantees.
> (The ErrorValues are intended to be included in = PATH_ERR messages, in
> response to corresponding PATH = messages).

Both of these cases have already been = addressed.
draft-sinnreich-interdomain-sip-qos-osp-01.txt = discusses
in detail two QoS models: QoS Assured and QoS = Enabled.
The QoS assured model only completes call setup = if/when
QoS has been established. In this case, the sender = does
not send until/unless QoS has been established. The = QoS
enabled model completes call setup regardless. In = this
case, the user wants the call to proceed before QoS = has
been granted and even if QoS is never granted for = the
session.

draft-gross-sipaq-00.txt defines a COPS extension = for
SIP to integrate policy (and AAA) messaging into the = VoIP
picture. See draft-gross-sipaq-00.txt for a = general
overview.

Gery

        = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        = X            = ;            = ;            = ;     X
        = X    Gerhard W. Gross, = Ph.D.           &= nbsp;  X
        = X    = Intel           &= nbsp;           &= nbsp;        X
        = X    2111 NE 25th = Ave           &nb= sp;         X
        = X    Hillsboro, OR 97124-5961, = USA        X
        = X    Policy Architecture = Group            = X
        = X      - Internet and Communication = Lab   X
        = X    phone:    (503) = 264-6389          &nbs= p;  X
        = X    fax:      (503) = 264-3483          &nbs= p;  X
        = X    email:    = gerhard.gross@intel.com    X
        = X            = ;            = ;            = ;     X
        = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@avaya.com]=
> Sent: Tuesday, December 26, 2000 12:23 = AM
> To: 'Ron Cohen'; rap@ops.ietf.org
> Cc: Anwar Siddiqui; Eyal Amitai
> Subject: RE: = draft-santitoro-rap-policy-errorcodes-01.txt
>
>
>
>
> > I think that this draft deserves working = group attention
> and discussion.
> > I'm not sure whether it should be a = working group item yet.
> >
>       [Dan]  I = agree. I think the draft starts to address a
> set of issues
> related to implementing real-life applications = like VoIP by
> means of RSVP
> extensions over Diffserv networks.
>
> > Here are some basic questions about this = draft:
> >
> > 1. I don't agree with the following text = in the draft:
> >
> > "From the perspective of a sender and = a receiver of
> application traffic,
> > the conventional usage of RSVP is as = follows:
> > ...
> >   5. Sender sends traffic = regardless of the admission
> control decision. "
> >
> > I think this indicates a 'bad' RSVP = application. If the application
> > requires QoS, than it should not 'send it = anyway', but
> rather either
> > renegotiate TSPECs or turn to an = alternative. For example,
> if you want to
> > run a VoIP flow, and get a QoS refusal, = you would than turn
> to send it via
> >
> > PSTN.
> >
>       [Dan]  This = draft is about searching a practical
> approach for the
> use of RSVP signaling. According to the type of = deployment we
> deal with,
> several alternatives might or might not be = available. Re-negotiating
> different TSPECs might make even worse the = problem of the time that is
> allowable for completion of signaling in a VoIP = application. The user
> experience of a phone user is to have some = audio feedback
> available about
> the network resources availability as soon as = he picked the
> phone. Admission
> control by end-to-end RSVP signaling with or = without
> outsourcing some of the
> decisions to PDPs on the way is a time = consuming operation.
>
>       On the other = hand, PSTN re-routing might not be available in all
> environments. In some cases a 'sub-optimal' = traffic transmission as
> suggested by the draft might be acceptable. It = looks like me
> might need to
> consider different alternate policies, even = with the price of
> becoming more
> liberal in what we label as 'good' or 'bad' = RSVP application.
>
>
> > 2. In the description of the alternatives = available today
> to the network
> > administrator to make sure that an = application would not
> send anything
> > across the WAN the following option is not = mentioned:
> >
> > Create a 'Discard-on-WAN' PHB, and = associate it with a
> DSCP. Set rules on
> > all WAN routers that discard all packets = arriving with this
> DSCP set.
> > Return to such applications that send = there traffic anyhow
> this DSCP value
> >
> > in the DCLASS object. In this way you are = sure that even if the
> > application
> > does send the traffic even when QoS is = rejected, traffic would be
> > discarded
> > on the WAN edge (assuming that at least it = conforms with
> the DCLASS object
> >
> > sent to it).
> >
>       [Dan]  Yes, = this is an interesting idea, though I would
> avoid using
> the term 'WAN' and try to define differently = the discard domain.
>
>       My question is = what is the PHB for the 'non-WAN routers'? If the
> traffic is sent best-effort, there should be no = resource
> allocation problem,
> even for the WAN routers - applications should = just ensure
> that they send
> some feedback to the user 'your call won't make = it over the
> discard domain
> (WAN) and may be performance degraded'. Or = maybe you had in
> mind the local
> routers treating this traffic with same PHB as = high admitted
> traffic within
> the 'local' domain? Maybe we should map this = DSCP to a
> 'Better than Best
> Effort' behavior, which would ensure a better = PH service than BE - if
> available - but would protect already admitted = traffic.
>
>       Regards,
>
>       Dan
>
>
>


------_=_NextPart_001_01C07CD8.D7D56300-- From owner-rap@ops.ietf.org Mon Jan 15 13:25:39 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13025 for ; Mon, 15 Jan 2001 13:25:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IEIQ-000ASh-00 for rap-data@psg.com; Mon, 15 Jan 2001 10:23:58 -0800 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with smtp (Exim 3.16 #1) id 14IEIO-000AS6-00 for rap@ops.ietf.org; Mon, 15 Jan 2001 10:23:57 -0800 Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Jan 2001 09:56:49 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Mon, 15 Jan 2001 09:44:38 -0800 Message-ID: From: Yoram Bernet To: Ron Cohen , rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 15 Jan 2001 09:25:44 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-rap@ops.ietf.org Precedence: bulk Ron, et al: I'm resending this. It was bounced earlier by the list server... I will address your more recent mail in a subsequent response. Yoram > -----Original Message----- > From: /O=MICROSOFT/OU=NORTHAMERICA/CN=RECIPIENTS/CN=140929 On > Behalf Of > Yoram Bernet > Sent: Thursday, January 11, 2001 10:34 AM > To: 'Ron Cohen'; rap@ops.ietf.org > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > Ron: > > Thanks for your comments. Responses are interspersed below... > > > -----Original Message----- > > From: Ron Cohen [mailto:ronc@cisco.com] > > Sent: Monday, December 25, 2000 10:09 PM > > To: rap@ops.ietf.org > > Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt > > > > > > > > I think that this draft deserves working group attention and > > discussion. > > I'm not sure whether it should be a working group item yet. > > > > Here are some basic questions about this draft: > > > > 1. I don't agree with the following text in the draft: > > > > "From the perspective of a sender and a receiver of > > application traffic, > > the conventional usage of RSVP is as follows: > > ... > > 5. Sender sends traffic regardless of the admission control > > decision. " > > Perhaps calling this "conventional usage" is a poor choice of > words. However, from my experience speaking with application > writers - they tend to look at RSVP and at QoS in general as > something that might help them to get better service, but not > as something that should prevent them from getting what they > can. Their view is that they will signal and if they get QoS > that's great, but - if they don't, they'd still like to try > to get whatever b/e service they can. You're suggesting that > this is a bad application and that the application would be > better advised to try a different tspec. I think that this is > very much a debatable position. For one, even when an app is > not explicitly refused a qos request, it has no way of > knowing (other than by measurement) that it is really getting > qos and how good that qos is. So - a model of "I will only > send if I am told by the network that I got QoS" is not > necessarily going to be very successful. Furthermore, who's > to say that the user experience would be better for a session > that uses a great (if resource demanding) codec that does not > get qos or a poorer codec that does? > > Anyway - the bottom line from my perspective is that none of > the current usages of RSVP are intended to tell the > application "thou shalt not send" and so - the application is > allowed to send regardless of the outcome of the rsvp > request. Perhaps we could modify the words to reflect this > notion better. > > > > > I think this indicates a 'bad' RSVP application. If the application > > requires QoS, than it should not 'send it anyway', but > rather either > > renegotiate TSPECs or turn to an alternative. For example, if > > you want to > > run a VoIP flow, and get a QoS refusal, you would than turn > > to send it via > > PSTN. > > > > See comments above. > > > > > 2. In the description of the alternatives available today to > > the network > > administrator to make sure that an application would not send > > anything > > across the WAN the following option is not mentioned: > > > > Create a 'Discard-on-WAN' PHB, and associate it with a DSCP. > > Set rules on > > all WAN routers that discard all packets arriving with this > DSCP set. > > Return to such applications that send there traffic anyhow > > this DSCP value > > in the DCLASS object. In this way you are sure that even if > > the application > > does send the traffic even when QoS is rejected, traffic > > would be discarded > > on the WAN edge (assuming that at least it conforms with the > > DCLASS object > > sent to it). > > I agree with the goal of this approach, though not with the > mechanism. Let's consider unicast and multicast sepaerately. > First - unicast: > > If there exists, on the end-to-end path between sender and > receiver, a congested point (likely, but not necessarily a > WAN) that cannot (or should not) dedicate the necessary > resources to the signaled flow, then the flow should be > rejected at that node via *signaling* (explicit admission > control). It can be rejected either with the DO_NOT_SEND > object or by offering a DCLASS corresponsing to b/e, or just > by rejecting the flow (which will result in the traffic being > marked for best-effort. By doing so via signaling, other > nodes along the path, including the sender, are coordinated > explicitly. This is important. In the alternative that you > propose, the traffic is policed, implicitly, at one (or > possibly more) nodes along the path. One of the possible > consequences of your approach (that is avoided by the > explicit admission control approach)is that resources are > dedicated to the flow at certain nodes (including the sender) > while the traffic is discarded at the WAN node. As a result, > the user does not enjoy the necessary end-to-end quality and > the resources that have been dedicated elsewhere in the > network are actually wasted as a result. We should let RSVP > do what it does well here - it accumulates explicit admission > control decisions - if any admission control agent along the > path from sender to receiver cannot accommodate the flow, > then it will reject the RSVP request and the traffic will not > be prioritized (or will not be sent) and will not waste > resources anywhere along the path. > > > > > 3. It is not explained in the draft why the added values > > should go into the > > policy error object and not to the error object policy errors > > as defined in > > appendix A of RFC2750. It does not say what should be carried > > in the RSVP > > error object > > So - this is a matter of detail that we should certainly > discuss once the ideological issues are agreed upon. > > > > Ron > > > Yoram > From owner-rap@ops.ietf.org Mon Jan 15 17:22:17 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16812 for ; Mon, 15 Jan 2001 17:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IHyv-000EG5-00 for rap-data@psg.com; Mon, 15 Jan 2001 14:20:05 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with smtp (Exim 3.16 #1) id 14IHyu-000EFJ-00 for rap@ops.ietf.org; Mon, 15 Jan 2001 14:20:05 -0800 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Jan 2001 13:57:16 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Mon, 15 Jan 2001 13:57:13 -0800 Message-ID: From: Yoram Bernet To: Ron Cohen , rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Mon, 15 Jan 2001 13:57:00 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-rap@ops.ietf.org Precedence: bulk Ron et al: Comments on your comments below... > point 1: alternate proposal: > > Instead of extending the error object, allow the application to add a > policy object reformatting the Path message as a > send/do-not-send question. I don't see the advantage of this alternative. I do see two disadvantages: 1. It requires more work on behalf of the applications - instead of just learning the network's policy in response to the same standard path message that applications currently generate, they would have to generate a new and special path message. 2. It would complicate the protocol exchange - instead of relying solely on a response from the network indicating that the network does not want the app to send, this would require both a query from the application and a response from the network. > Applications that are going to send the traffic anyhow, will > always ask the > 'do you allow me to send' question, because that is all they > need to know. > > Applications that are going to use alternatives (renegotiate > TSPEC, use a > different route) are going to ask only admission control > questions, and are > not going to start sending prior to receiving a successful > Resv message. > Therefore, these applications will use the standard RSVP Path / Resv > procedure, and nothing need to be extended for them. > I'm not sure why it is necessary to pigeonhole applications as one or the other. The same application may use different strategies at different times. For example, an application might try lesser codecs until it finds that none are acceptable by the network, at which time it would just not send (or alternatively, send with best-effort). Such an application is both of the type that is going to send anyhow (unless prohibited) and simultaneously of the type that is going to renegotiate. Again - the distinction you draw seems to just complicate the set of application behaviours. > Another good aspect of this proposal that the PEP/PDP knows from the > request the capabilities of the application, as they see the > new policy > object carried in the Path message. This is lacking in the > current proposal. It is true that this alternative would give the PEP/PDP some explicit information about the application. However - i'm not sure what the PEP/PDP would do differently based on this information. Unless the PEP/PDP does something useful and different, i'm not sure that this justifies the additional protocol exchange. Yoram From owner-rap@ops.ietf.org Tue Jan 16 13:09:48 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18169 for ; Tue, 16 Jan 2001 13:09:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14IaWe-000BNj-00 for rap-data@psg.com; Tue, 16 Jan 2001 10:08:08 -0800 Received: from csi-admin1.cisco.com ([144.254.91.12] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14IaWc-000B1c-00 for rap@ops.ietf.org; Tue, 16 Jan 2001 10:08:07 -0800 Received: from user-53.cisco.com (telaviv3-dhcp142.cisco.com [144.254.93.80]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id UAA23762; Tue, 16 Jan 2001 20:07:31 +0200 (IST) Message-Id: <4.3.2.7.2.20010115142513.00d1aef0@csi-admin1> X-Sender: ronc@csi-admin1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jan 2001 10:10:24 -0800 To: Yoram Bernet , rap@ops.ietf.org From: Ron Cohen Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rap@ops.ietf.org Precedence: bulk Yoram, After thinking on this subject for a while, I agree that there needs to be a parameter (forget formats for a minute) returned to the sender that differs between do-not-send and no-QoS-admission failures. Otherwise the solution is not flexible enough. I (still) think that its required to let the PDP know two things in the Path message. (1) Its behavior (the fact that its going to send traffic in the specified TSPEC regardless of successful QoS admission). (2) Whether it supports the new instructions. I'll try to give examples why these are needed below, but regardless of providing a set of persuading examples, I believe in smart networks and policy makers to allow flexible policy enforcement, and therefore I believe in the necessity to add this information to the Path message. Example 1: transition period - why (2) is needed: Suppose we have a network environment where on some hosts an application x is upgraded to support the new standard and some are not. Suppose the application is sending traffic regardless of successful RSVP setup. The administrator must control the application on both upgraded an not-upgraded hosts and make sure that these do not harm the WAN traffic. For the upgraded applications Path-Err will instruct them to shut up. For the older ones, the only option is to map them to LBE. Therefore the policy specified would be something of the form: If (app=x AND upgraded) deny If (app=x AND not-upgraded) admit and set DSCP to LBE. The PDP can know if the app is upgraded if the additional object/parameter appears in the path message. Any alternative would force the administrator to add a list of hosts where the application is upgraded and where it is not. This would be a nightmare. Example 2: why (1) is needed: The policy I want to enforce on a WAN interface is the following: Don't admit QoS request beyond X kb/s Don't allow sending beyond Y kb/s To implement this policy I have two counters in my PDP: Counter x measures the amount of admitted bandwidth for QoS. It is updated for each successful Resv using the RSPEC carried in the Resv message. Counter y measures the amount of traffic sent by the sender as declared in the Path TSPEC. When should I update this counter? If traffic is sent only after successful admission, I should update the counter with the Path TSPEC only after successful admission of the Resv message. Otherwise, I will reject Path messages sent by other hosts before I'm sure that this is the actual TSPEC used, and not the reduced TSPEC that can be negotiated following admission failure. If the sender is going to send traffic in any case, without waiting for successful Resv message, I should update the counter when the Path message arrives, as I must guard against a situation where a Resv will not arrive at all. If I have the indication that differentiate between the two behaviors, I can update the counter in the correct events. ------------------------ See some minor remarks inline as well >Ron et al: > >Comments on your comments below... > > > point 1: alternate proposal: > > > > Instead of extending the error object, allow the application to add a > > policy object reformatting the Path message as a > > send/do-not-send question. > >I don't see the advantage of this alternative. I do see two disadvantages: > >1. It requires more work on behalf of the applications - instead of just >learning the network's policy in response to the same standard path message >that applications currently generate, they would have to generate a new and >special path message. See above >2. It would complicate the protocol exchange - instead of relying solely on >a response from the network indicating that the network does not want the >app to send, this would require both a query from the application and a >response from the network. I'm not sure what you mean by query and response. We are talking on the normal RSVP messages exchange. Path downstream, Resv or Path-Err upstream. > > Applications that are going to send the traffic anyhow, will > > always ask the > > 'do you allow me to send' question, because that is all they > > need to know. > > > > Applications that are going to use alternatives (renegotiate > > TSPEC, use a > > different route) are going to ask only admission control > > questions, and are > > not going to start sending prior to receiving a successful > > Resv message. > > Therefore, these applications will use the standard RSVP Path / Resv > > procedure, and nothing need to be extended for them. > > > >I'm not sure why it is necessary to pigeonhole applications as one or the >other. The same application may use different strategies at different times. >For example, an application might try lesser codecs until it finds that none >are acceptable by the network, at which time it would just not send (or >alternatively, send with best-effort). Such an application is both of the >type that is going to send anyhow (unless prohibited) and simultaneously of >the type that is going to renegotiate. Again - the distinction you draw >seems to just complicate the set of application behaviours. You don't pigeonhole applications, you describe their behavior for each flow they intend to send. In each round, the application sends different Path messages (different TSPECs according to codecs), it also knows whether it is going to wait for a successful Resv message before sending the traffic. It can send this information in the Path message. > > > > Another good aspect of this proposal that the PEP/PDP knows from the > > request the capabilities of the application, as they see the > > new policy > > object carried in the Path message. This is lacking in the > > current proposal. > >It is true that this alternative would give the PEP/PDP some explicit >information about the application. However - i'm not sure what the PEP/PDP >would do differently based on this information. Unless the PEP/PDP does >something useful and different, i'm not sure that this justifies the >additional protocol exchange. There is no additional protocol exchange. See above for examples. Regards Ron >Yoram From owner-rap@ops.ietf.org Wed Jan 17 16:30:29 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26441 for ; Wed, 17 Jan 2001 16:30:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14J08c-000M4f-00 for rap-data@psg.com; Wed, 17 Jan 2001 13:29:02 -0800 Received: from csi-admin1.cisco.com ([144.254.91.12] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14J08b-000M3x-00 for rap@ops.ietf.org; Wed, 17 Jan 2001 13:29:01 -0800 Received: from user-53.cisco.com (ronc-isdn-home.cisco.com [10.49.112.170]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id XAA26156; Wed, 17 Jan 2001 23:28:23 +0200 (IST) Message-Id: <4.3.2.7.2.20010117122513.00d74e70@csi-admin1> X-Sender: ronc@csi-admin1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Jan 2001 13:31:13 -0800 To: Yoram Bernet , rap@ops.ietf.org From: Ron Cohen Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rap@ops.ietf.org Precedence: bulk Yoram, >Thanks for the comments. This is getting complicated enouhg to warrant some >face to face discussion. In any case, some responses below: Ok. I think the good thing is that I'm more comfortable thinking that this draft deserves to be a WG item. So my vote is yes on this issue. Short answers to the points you raised: >First of all - it largely removes the incentive for an application to be >well-behaved. If the application is not upgraded, it at least gets to try to >get service. If it's upgraded - it gets completely denied. Why should an >application upgrade? The application is upgraded because the customers (the network administrator) asks for a better control over the send/do-not-send behavior. Being able to send unwanted flows is not a benefit. >Second - if you have the means in the network to provide traffic separation, >then you should apply this means regardless of what the app says or does not >say it will do. In other words - the signaling provides you with the >classification information that you need to recognize the flow of interest. >If you have the ability to use this classification info to downgrade the >priority of the traffic in the WAN, then you should do so - regardless. Thus >- your behaviour would not change because the app claims to be well behaved. Two points here. First, I might not have traffic separation, but use the LBE marking to control the application flow using a policer/shaper on the WAN edge in the form of if (LBE) limit flows to x. Second, Providing LBE to the application means that I want to let the application try and run even if I'm sure I'm not going to provide it with the appropriate QoS. Suppose my experience tell me that these application doesn't work in such situation, making the persons using them to conclude that either 'the network is not operating as should' or 'the application is worthless'. I want to be sure that if there is no room for the application, it will not send traffic. In this case, I want to return a don't send indication instead of an LBE decision. >The application may or may not know this. For example - an application might >(in response to failed admission control, but not the 'do not send' message) >defer to the user, with a UI of the form: "You will not be granted QoS for >this session. You may: 1) try your call again later 2) proceed with no qos >3) retry with a lesser codec (e.g. press the 56 Kbps button instead of the >T-1 button). Good example. There are several options for doing that, the cleanest is: The application is going to wait for a successful Resv, otherwise it can not prompt the users with the options upon admission failure. Therefore it should indicate this in the initial Path message exchange. The application might get a don't send indication. It might get admission error only. When this happens the user is prompted to answer. If he chooses 3, you resend a new Path message with the new TSPEC right? So do the same if he chooses option 2 and resend a Path with the indication that the application IS going to send now without regard for the final answer. This is how a 'good application' should behave. Note that this does not mean that you have to wait now for the successful Resv therefore it doesn't add any additional delay on the application. Regards Ron > > After thinking on this subject for a while, I agree that > > there needs to be > > a parameter (forget formats for a minute) returned to the sender that > > differs between do-not-send and no-QoS-admission failures. > > Otherwise the > > solution is not flexible enough. > > > > I (still) think that its required to let the PDP know two > > things in the > > Path message. > > (1) Its behavior (the fact that its going to send traffic in > > the specified > > TSPEC regardless of successful QoS admission). > >The application may or may not know this. For example - an application might >(in response to failed admission control, but not the 'do not send' message) >defer to the user, with a UI of the form: "You will not be granted QoS for >this session. You may: 1) try your call again later 2) proceed with no qos >3) retry with a lesser codec (e.g. press the 56 Kbps button instead of the >T-1 button). > > > (2) Whether it supports the new instructions. > >As i'll explain below - an application could tell you this, but I don't >think it affords you to behave any differently... > > > > I'll try to give examples why these are needed below, but > > regardless of > > providing a set of persuading examples, I believe in smart > > networks and > > policy makers to allow flexible policy enforcement, and > > therefore I believe > > in the necessity to add this information to the Path message. > >I beleive that - if you add to a protocol - you must be able to explain >specifically how the addition will change the behaviour of the peers that >participate in the protocol. You do take a stab at this below, but - as I >will show, i'm not sure that the behaviours you propose really work. If we >conclude that there are no valuable behavioural changes that result from the >protocol addition, then I don't think it can be justified on the abstract >basis of "smart networks and felxible policy enforcement". > > > > > Example 1: transition period - why (2) is needed: > > > > Suppose we have a network environment where on some hosts an > > application x > > is upgraded to support the new standard and some are not. Suppose the > > application is sending traffic regardless of successful RSVP > > setup. The > > administrator must control the application on both upgraded > > an not-upgraded > > hosts and make sure that these do not harm the WAN traffic. For the > > upgraded applications Path-Err will instruct them to shut up. > > For the older > > ones, the only option is to map them to LBE. Therefore the > > policy specified > > would be something of the form: > > > > If (app=x AND upgraded) deny > > If (app=x AND not-upgraded) admit and set DSCP to LBE. > >This approach suffers from a number of problems. > >First of all - it largely removes the incentive for an application to be >well-behaved. If the application is not upgraded, it at least gets to try to >get service. If it's upgraded - it gets completely denied. Why should an >application upgrade? > >Second - if you have the means in the network to provide traffic separation, >then you should apply this means regardless of what the app says or does not >say it will do. In other words - the signaling provides you with the >classification information that you need to recognize the flow of interest. >If you have the ability to use this classification info to downgrade the >priority of the traffic in the WAN, then you should do so - regardless. Thus >- your behaviour would not change because the app claims to be well behaved. > >The 'do not send' policy is primarily intended for networks that do not have >the ability to offer traffic separation between b/e and lbe. On these >networks, the choice of the netadmin is to 1) allow the app to be deployed, >regardless of its behaviour, thereby running the risk that the wan resources >will be trashed. 2) refuse to deploy the app on the wan. 3) allow the app to >be deployed only if it is well-behaved. > > > > > The PDP can know if the app is upgraded if the additional > > object/parameter > > appears in the path message. > > Any alternative would force the administrator to add a list > > of hosts where > > the application is upgraded and where it is not. This would > > be a nightmare. > >Indeed, the hypothetical parameter could tell the pdp that the app would or >would not do something. but - i maintain that you still would have to apply >the same behaviour, regardless. > > > > Example 2: why (1) is needed: > > > > The policy I want to enforce on a WAN interface is the following: > > > > Don't admit QoS request beyond X kb/s > > Don't allow sending beyond Y kb/s > > > > To implement this policy I have two counters in my PDP: > > Counter x measures the amount of admitted bandwidth for QoS. > > It is updated > > for each successful Resv using the RSPEC carried in the Resv message. > > Counter y measures the amount of traffic sent by the sender > > as declared in > > the Path TSPEC. When should I update this counter? If traffic > > is sent only > > after successful admission, I should update the counter with > > the Path TSPEC > > only after successful admission of the Resv message. > > Otherwise, I will > > reject Path messages sent by other hosts before I'm sure that > > this is the > > actual TSPEC used, and not the reduced TSPEC that can be negotiated > > following admission failure. > >I imagined that there would be one resource counter for each service level >(except b/e and lbe). The counter would be conditionally debited as soon as >a path message is seen. The debit could be reversed if the reservation is >denied. This does result in brief underestimations of available resources, >but - this situation occurs in many scenarios and doesn't strike me as a >problem. > > > If the sender is going to send traffic in any case, without > > waiting for > > successful Resv message, I should update the counter when the > > Path message > > arrives, as I must guard against a situation where a Resv > > will not arrive > > at all. > >If the sender is going to send without a reservation, the sender will not >consume resources at a prioritized service level. The sender's traffic will >be in be or lbe and therefore, need not be counted. > > > See some minor remarks inline as well > > > > >2. It would complicate the protocol exchange - instead of > > relying solely on > > >a response from the network indicating that the network does > > not want the > > >app to send, this would require both a query from the > > application and a > > >response from the network. > > > > I'm not sure what you mean by query and response. We are > > talking on the > > normal RSVP messages exchange. Path downstream, Resv or > > Path-Err upstream. > > > >As I proposed the protocol exchanges, there would be no additional >information in the 'query' or the application's message to the network (the >path message in this case). The additional information would be only in the >'response' (the path_err message). As you propose it, there would be >additional info in both. If you were to for example, build a protocol >simulator/tester, your approach is more complex to model (and therefore, to >implement, to test and to operate). Unless you can show a concrete benefit >of the added complexity, I oppose the added complexity. > > > >I'm not sure why it is necessary to pigeonhole applications > > as one or the > > >other. The same application may use different strategies at > > different times. > > >For example, an application might try lesser codecs until it > > finds that none > > >are acceptable by the network, at which time it would just > > not send (or > > >alternatively, send with best-effort). Such an application > > is both of the > > >type that is going to send anyhow (unless prohibited) and > > simultaneously of > > >the type that is going to renegotiate. Again - the > > distinction you draw > > >seems to just complicate the set of application behaviours. > > > > You don't pigeonhole applications, you describe their > > behavior for each > > flow they intend to send. In each round, the application > > sends different > > Path messages (different TSPECs according to codecs), it also > > knows whether > > it is going to wait for a successful Resv message before sending the > > traffic. It can send this information in the Path message. > > > >As stated in my earlier comments, the application may defer this choice to >the user. The network should not need to behave differently on this basis. > > > >It is true that this alternative would give the PEP/PDP some explicit > > >information about the application. However - i'm not sure > > what the PEP/PDP > > >would do differently based on this information. Unless the > > PEP/PDP does > > >something useful and different, i'm not sure that this justifies the > > >additional protocol exchange. > > > > There is no additional protocol exchange. > > > >Sorry - by 'protocol exchange' I meant, 'additional information carried in >protocol messages which require additional parsing, additional decision >making and may alter the progression of a protocol exchange'. > >Regards, >Yoram From owner-rap@ops.ietf.org Wed Jan 17 17:49:54 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27655 for ; Wed, 17 Jan 2001 17:49:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14J1NR-000Ojx-00 for rap-data@psg.com; Wed, 17 Jan 2001 14:48:25 -0800 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with smtp (Exim 3.16 #1) id 14J1NQ-000Ojn-00 for rap@ops.ietf.org; Wed, 17 Jan 2001 14:48:24 -0800 Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Jan 2001 14:13:07 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Wed, 17 Jan 2001 13:58:16 -0800 Message-ID: From: Yoram Bernet To: Ron Cohen , rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Wed, 17 Jan 2001 13:58:04 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-rap@ops.ietf.org Precedence: bulk > Ok. I think the good thing is that I'm more comfortable > thinking that this > draft deserves to be a WG item. So my vote is yes on this issue. > Great - i'm looking forward to getting some broader discussion around this. > Short answers to the points you raised: > > >First of all - it largely removes the incentive for an > application to be > >well-behaved. If the application is not upgraded, it at > least gets to try to > >get service. If it's upgraded - it gets completely denied. > Why should an > >application upgrade? > > The application is upgraded because the customers (the network > administrator) asks for a better control over the send/do-not-send > behavior. Being able to send unwanted flows is not a benefit. > I think that we have a different view of the way applications are written. To the network manager an application 'being able to send unwanted flows' is ceretainly not a benefit. However, to the application writer and to the user, every flow is 'wanted'. In certain cases, there will be a feedback loop of app writer misbehaves, therefore net manager refuses to deploy. In other cases, the net manager will have the ability to do some form of traffic separation, that is aided by the signaling and identification from the host. In these cases, it's just fine for apps to send even if they don't 'get qos'. The net manager will just downgrade their priority. So - these flows are tolerated but not wanted. The spectrum of possibilities is a littel overwhelming to me - so - I realize that my views here may not be correct or even entirely self-consistent, but - i'm not yet convinced that they are entirely wrong either. This is where I think we need to hear more opinions and to sit face to face and sketch some of the different possibilities. > >Second - if you have the means in the network to provide > traffic separation, > >then you should apply this means regardless of what the app > says or does not > >say it will do. In other words - the signaling provides you with the > >classification information that you need to recognize the > flow of interest. > >If you have the ability to use this classification info to > downgrade the > >priority of the traffic in the WAN, then you should do so - > regardless. Thus > >- your behaviour would not change because the app claims to > be well behaved. > > Two points here. > > First, I might not have traffic separation, but use the LBE > marking to > control the application flow using a policer/shaper on the > WAN edge in the > form of if (LBE) limit flows to x. When I said 'having the means in the network to provide traffic separation', I did not distinguish between the WAN edge or the core. Traffic separation in the network is traffic separation in the network, wherever it is done. > Second, Providing LBE to the application means that I want to let the > application try and run even if I'm sure I'm not going to > provide it with > the appropriate QoS. Suppose my experience tell me that these > application > doesn't work in such situation, making the persons using them > to conclude > that either 'the network is not operating as should' or 'the > application is > worthless'. I want to be sure that if there is no room for > the application, > it will not send traffic. In this case, I want to return a don't send > indication instead of an LBE decision. > I'm all for offering this kind of functionality. However, the greatest flexibility arises when there are the means to accommodate both apps that can use lbe as well as apps that do not. In many cases, app writers may defer this decision to the user: Dear user - you have noit been granted the service you asked for. Would you like to continue anyway? If so - don't complain about the service. If not - you may hang up and try your call again later. > >The application may or may not know this. For example - an > application might > >(in response to failed admission control, but not the 'do > not send' message) > >defer to the user, with a UI of the form: "You will not be > granted QoS for > >this session. You may: 1) try your call again later 2) > proceed with no qos > >3) retry with a lesser codec (e.g. press the 56 Kbps button > instead of the > >T-1 button). > > Good example. There are several options for doing that, the > cleanest is: > > The application is going to wait for a successful Resv, > otherwise it can > not prompt the users with the options upon admission failure. > Therefore it > should indicate this in the initial Path message exchange. Why? > The application > might get a don't send indication. It might get admission > error only. When > this happens the user is prompted to answer. If he chooses 3, > you resend a > new Path message with the new TSPEC right? So do the same if > he chooses > option 2 and resend a Path with the indication that the > application IS > going to send now without regard for the final answer. This > is how a 'good > application' should behave. I guess I just don't agree that one can expect all applications to behave in this manner. > Note that this does not mean that > you have to > wait now for the successful Resv therefore it doesn't add any > additional > delay on the application. > > Regards > Ron > Regards, Yoram From owner-rap@ops.ietf.org Wed Jan 17 23:13:15 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04723 for ; Wed, 17 Jan 2001 23:13:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14J6Q7-000HFM-00 for rap-data@psg.com; Wed, 17 Jan 2001 20:11:31 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with smtp (Exim 3.16 #1) id 14J6Q6-000HCr-00 for rap@ops.ietf.org; Wed, 17 Jan 2001 20:11:30 -0800 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Jan 2001 09:38:00 -0800 (Pacific Standard Time) Received: by inet-imc-05.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Wed, 17 Jan 2001 09:37:46 -0800 Message-ID: From: Yoram Bernet To: Ron Cohen , rap@ops.ietf.org Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Wed, 17 Jan 2001 09:23:13 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-rap@ops.ietf.org Precedence: bulk Ron: Thanks for the comments. This is getting complicated enouhg to warrant some face to face discussion. In any case, some responses below: > After thinking on this subject for a while, I agree that > there needs to be > a parameter (forget formats for a minute) returned to the sender that > differs between do-not-send and no-QoS-admission failures. > Otherwise the > solution is not flexible enough. > > I (still) think that its required to let the PDP know two > things in the > Path message. > (1) Its behavior (the fact that its going to send traffic in > the specified > TSPEC regardless of successful QoS admission). The application may or may not know this. For example - an application might (in response to failed admission control, but not the 'do not send' message) defer to the user, with a UI of the form: "You will not be granted QoS for this session. You may: 1) try your call again later 2) proceed with no qos 3) retry with a lesser codec (e.g. press the 56 Kbps button instead of the T-1 button). > (2) Whether it supports the new instructions. As i'll explain below - an application could tell you this, but I don't think it affords you to behave any differently... > > I'll try to give examples why these are needed below, but > regardless of > providing a set of persuading examples, I believe in smart > networks and > policy makers to allow flexible policy enforcement, and > therefore I believe > in the necessity to add this information to the Path message. I beleive that - if you add to a protocol - you must be able to explain specifically how the addition will change the behaviour of the peers that participate in the protocol. You do take a stab at this below, but - as I will show, i'm not sure that the behaviours you propose really work. If we conclude that there are no valuable behavioural changes that result from the protocol addition, then I don't think it can be justified on the abstract basis of "smart networks and felxible policy enforcement". > > Example 1: transition period - why (2) is needed: > > Suppose we have a network environment where on some hosts an > application x > is upgraded to support the new standard and some are not. Suppose the > application is sending traffic regardless of successful RSVP > setup. The > administrator must control the application on both upgraded > an not-upgraded > hosts and make sure that these do not harm the WAN traffic. For the > upgraded applications Path-Err will instruct them to shut up. > For the older > ones, the only option is to map them to LBE. Therefore the > policy specified > would be something of the form: > > If (app=x AND upgraded) deny > If (app=x AND not-upgraded) admit and set DSCP to LBE. This approach suffers from a number of problems. First of all - it largely removes the incentive for an application to be well-behaved. If the application is not upgraded, it at least gets to try to get service. If it's upgraded - it gets completely denied. Why should an application upgrade? Second - if you have the means in the network to provide traffic separation, then you should apply this means regardless of what the app says or does not say it will do. In other words - the signaling provides you with the classification information that you need to recognize the flow of interest. If you have the ability to use this classification info to downgrade the priority of the traffic in the WAN, then you should do so - regardless. Thus - your behaviour would not change because the app claims to be well behaved. The 'do not send' policy is primarily intended for networks that do not have the ability to offer traffic separation between b/e and lbe. On these networks, the choice of the netadmin is to 1) allow the app to be deployed, regardless of its behaviour, thereby running the risk that the wan resources will be trashed. 2) refuse to deploy the app on the wan. 3) allow the app to be deployed only if it is well-behaved. > > The PDP can know if the app is upgraded if the additional > object/parameter > appears in the path message. > Any alternative would force the administrator to add a list > of hosts where > the application is upgraded and where it is not. This would > be a nightmare. Indeed, the hypothetical parameter could tell the pdp that the app would or would not do something. but - i maintain that you still would have to apply the same behaviour, regardless. > > Example 2: why (1) is needed: > > The policy I want to enforce on a WAN interface is the following: > > Don't admit QoS request beyond X kb/s > Don't allow sending beyond Y kb/s > > To implement this policy I have two counters in my PDP: > Counter x measures the amount of admitted bandwidth for QoS. > It is updated > for each successful Resv using the RSPEC carried in the Resv message. > Counter y measures the amount of traffic sent by the sender > as declared in > the Path TSPEC. When should I update this counter? If traffic > is sent only > after successful admission, I should update the counter with > the Path TSPEC > only after successful admission of the Resv message. > Otherwise, I will > reject Path messages sent by other hosts before I'm sure that > this is the > actual TSPEC used, and not the reduced TSPEC that can be negotiated > following admission failure. I imagined that there would be one resource counter for each service level (except b/e and lbe). The counter would be conditionally debited as soon as a path message is seen. The debit could be reversed if the reservation is denied. This does result in brief underestimations of available resources, but - this situation occurs in many scenarios and doesn't strike me as a problem. > If the sender is going to send traffic in any case, without > waiting for > successful Resv message, I should update the counter when the > Path message > arrives, as I must guard against a situation where a Resv > will not arrive > at all. If the sender is going to send without a reservation, the sender will not consume resources at a prioritized service level. The sender's traffic will be in be or lbe and therefore, need not be counted. > See some minor remarks inline as well > > >2. It would complicate the protocol exchange - instead of > relying solely on > >a response from the network indicating that the network does > not want the > >app to send, this would require both a query from the > application and a > >response from the network. > > I'm not sure what you mean by query and response. We are > talking on the > normal RSVP messages exchange. Path downstream, Resv or > Path-Err upstream. > As I proposed the protocol exchanges, there would be no additional information in the 'query' or the application's message to the network (the path message in this case). The additional information would be only in the 'response' (the path_err message). As you propose it, there would be additional info in both. If you were to for example, build a protocol simulator/tester, your approach is more complex to model (and therefore, to implement, to test and to operate). Unless you can show a concrete benefit of the added complexity, I oppose the added complexity. > >I'm not sure why it is necessary to pigeonhole applications > as one or the > >other. The same application may use different strategies at > different times. > >For example, an application might try lesser codecs until it > finds that none > >are acceptable by the network, at which time it would just > not send (or > >alternatively, send with best-effort). Such an application > is both of the > >type that is going to send anyhow (unless prohibited) and > simultaneously of > >the type that is going to renegotiate. Again - the > distinction you draw > >seems to just complicate the set of application behaviours. > > You don't pigeonhole applications, you describe their > behavior for each > flow they intend to send. In each round, the application > sends different > Path messages (different TSPECs according to codecs), it also > knows whether > it is going to wait for a successful Resv message before sending the > traffic. It can send this information in the Path message. > As stated in my earlier comments, the application may defer this choice to the user. The network should not need to behave differently on this basis. > >It is true that this alternative would give the PEP/PDP some explicit > >information about the application. However - i'm not sure > what the PEP/PDP > >would do differently based on this information. Unless the > PEP/PDP does > >something useful and different, i'm not sure that this justifies the > >additional protocol exchange. > > There is no additional protocol exchange. > Sorry - by 'protocol exchange' I meant, 'additional information carried in protocol messages which require additional parsing, additional decision making and may alter the progression of a protocol exchange'. Regards, Yoram From owner-rap@ops.ietf.org Wed Jan 24 07:24:20 2001 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18765 for ; Wed, 24 Jan 2001 07:24:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14LOv7-00064X-00 for rap-data@psg.com; Wed, 24 Jan 2001 04:21:01 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14LOv6-00064R-00 for rap@ops.ietf.org; Wed, 24 Jan 2001 04:21:00 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18585; Wed, 24 Jan 2001 07:20:58 -0500 (EST) Message-Id: <200101241220.HAA18585@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-sppi-04.txt Date: Wed, 24 Jan 2001 07:20:58 -0500 Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart 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 : Structure of Policy Provisioning Information (SPPI) Author(s) : K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer Filename : draft-ietf-rap-sppi-04.txt Pages : 43 Date : 23-Jan-01 RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-sppi-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-sppi-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-sppi-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010123115418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-sppi-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-sppi-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010123115418.I-D@ietf.org> --OtherAccess-- --NextPart--