From owner-rap@ops.ietf.org Tue Dec 26 01:12:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05698 for ; Tue, 26 Dec 2000 01:12:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14AnJr-000C1F-00 for rap-data@psg.com; Mon, 25 Dec 2000 22:10:43 -0800 Received: from csi-admin1.cisco.com ([144.254.91.12] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14AnJq-000C0e-00 for rap@ops.ietf.org; Mon, 25 Dec 2000 22:10:42 -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 IAA26112 for ; Tue, 26 Dec 2000 08:10:09 +0200 (IST) Message-Id: <4.3.2.7.2.20001225220830.00d07630@csi-admin1> X-Sender: ronc@csi-admin1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Dec 2000 22:09:13 -0800 To: rap@ops.ietf.org From: Ron Cohen Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rap@ops.ietf.org Precedence: bulk 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. 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). 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 Ron From owner-rap@ops.ietf.org Tue Dec 26 03:24:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17840 for ; Tue, 26 Dec 2000 03:24:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ApO0-000Dmw-00 for rap-data@psg.com; Tue, 26 Dec 2000 00:23:08 -0800 Received: from at.lannet.com ([194.90.94.231] helo=itc-eml2.lannet.com) by psg.com with esmtp (Exim 3.16 #1) id 14ApNz-000Dmo-00 for rap@ops.ietf.org; Tue, 26 Dec 2000 00:23:08 -0800 Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 10:22:48 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA6142342F8@itc-eml2.lannet.com> From: Dan Romascanu To: "'Ron Cohen'" , rap@ops.ietf.org Cc: Anwar Siddiqui , Eyal Amitai Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Tue, 26 Dec 2000 10:22:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk > 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 From owner-rap@ops.ietf.org Tue Dec 26 13:44:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21076 for ; Tue, 26 Dec 2000 13:44:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Az3z-000LFp-00 for rap-data@psg.com; Tue, 26 Dec 2000 10:43:07 -0800 Received: from selene.cps.intel.com ([192.198.165.10]) by psg.com with esmtp (Exim 3.16 #1) id 14Az3x-000LFR-00 for rap@ops.ietf.org; Tue, 26 Dec 2000 10:43:06 -0800 Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by selene.cps.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 KAA29288; Tue, 26 Dec 2000 10:42:34 -0800 (PST) Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 26 Dec 2000 18:42:34 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 10:42:32 -0800 Message-ID: <4148FEAAD879D311AC5700A0C969E8902D48FD@orsmsx35.jf.intel.com> From: "Gross, Gerhard" 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 Date: Tue, 26 Dec 2000 10:42:30 -0800 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 > 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 > > > From owner-rap@ops.ietf.org Wed Dec 27 03:55:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15523 for ; Wed, 27 Dec 2000 03:55:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14BCLT-00085T-00 for rap-data@psg.com; Wed, 27 Dec 2000 00:54:03 -0800 Received: from at.lannet.com ([194.90.94.231] helo=itc-eml2.lannet.com) by psg.com with esmtp (Exim 3.16 #1) id 14BCLS-00085K-00 for rap@ops.ietf.org; Wed, 27 Dec 2000 00:54:02 -0800 Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 10:37:08 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA61423430F@itc-eml2.lannet.com> From: Dan Romascanu 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)" , Anwar Siddiqui Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt Date: Wed, 27 Dec 2000 10:37:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-rap@ops.ietf.org Precedence: bulk [Dan] I try to be cautious and hope to avoid entering some 'religious' discussion :-) > 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. > [Dan] The reason why I personally did not look previously at the drafts that you point to is related to the fact that SIP is not right now in my focus. The five drafts that you refer seem all to assume the use of SIP and propose SIP-related extensions. The approach taken by draft-santitoro-rap-policyerrorcodes-01.txt seems to avoid such an assumption and this is the reason for proposing a solution at the level of RSVP error values. I did not think by myself long enough to decide that this is the 'only' or the 'preferred' solution, but it works in these environments that do not implement SIP. Regards, Dan From owner-rap@ops.ietf.org Thu Dec 28 12:18:17 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17323 for ; Thu, 28 Dec 2000 12:18:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14BggF-0005JJ-00 for rap-data@psg.com; Thu, 28 Dec 2000 09:17:31 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14BggE-0005J2-00 for rap@ops.ietf.org; Thu, 28 Dec 2000 09:17:30 -0800 Received: from ellacoya.com (mstevens.eng.ellacoya.com [192.168.121.46]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZVTJWMJB; Thu, 28 Dec 2000 12:10:03 -0500 Message-ID: <3A4B7527.F6AF8BD7@ellacoya.com> Date: Thu, 28 Dec 2000 12:15:19 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Cohen CC: rap@ops.ietf.org Subject: Re: draft-santitoro-rap-policy-errorcodes-01.txt References: <4.3.2.7.2.20001225220830.00d07630@csi-admin1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ron, your comments make me think that this approach serves to not only overload the purpose of the error message, but also sends us down a Diffserv-specific path. With an alternative DCLASS object coming back in what amounts to a rejection notice from the network, how is a network to prepare for the alternatively marked traffic? Is the network to assume that the client will accept the alternative? How can we know how much of the given alternatively classified traffic can be doled out unless the alternative is mandatory? This approach seems to short-circuit the spirit purpose of negotiating for resources. -Mark Ron Cohen wrote: > 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. > > 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). > > 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 > > Ron From owner-rap@ops.ietf.org Fri Dec 29 10:40:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09989 for ; Fri, 29 Dec 2000 10:40:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14C1dq-000JHw-00 for rap-data@psg.com; Fri, 29 Dec 2000 07:40:26 -0800 Received: from 216-064-109-139.inaddr.vitts.com ([216.64.109.139] helo=bor.ellacoya.com) by psg.com with esmtp (Exim 3.16 #1) id 14C1dp-000JHA-00 for rap@ops.ietf.org; Fri, 29 Dec 2000 07:40:25 -0800 Received: from ellacoya.com (mstevens.ellacoya.com [10.99.10.111]) by bor.ellacoya.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZVTJW3CP; Fri, 29 Dec 2000 10:32:55 -0500 Message-ID: <3A4CAFE7.DF45EDE2@ellacoya.com> Date: Fri, 29 Dec 2000 10:38:16 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Mark L. Stevens" Organization: Ellacoya Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rap@ops.ietf.org CC: ronc@cisco.com Subject: [Fwd: draft-santitoro-rap-policy-errorcodes-01.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ron Cohen wrote: > Mark, > > I don't understand what you are asking/saying here. Are you referring to the > draft or to my remarks? What is the alternative you are asking about? What > is 'This approach' - do you mean the approach taken by the draft or my 2cent > proposal? > > (It might be good to send the clarification to the list) > > Appologies for being difficult > Ron Ron, No difficulty, my hurried comments were not clear. Perhaps they will remain so, but let me try to clarify. The approach to which I was referring was the approach outlined in the draft-santitoro-rap-policy-errorcodes.01.txt document. The alternative to which I referred was the alternative quality of service implied by the DCLASS object returned to the client in the error indication. If the error indication includes a DCLASS object, does not it imply that the client can use the DSCP to mark the traffic it subsequently sends despite the receipt of a PATH error message? If so, then if the DCLASS was returned in an error indication, it effectively serves as an alternative to the request originally made to the network. My concern is that allocating network resources becomes more difficult if it is not clear whether or not a client decides to use the alternative. In the model proposed in the draft, the implication is that clients go ahead and use the alternative by marking subsequent traffic according to the DCLASS object rather than restart the negotiation by sending another PATH message, but nothing would stop a client from declining to use the alternative and electing to initiate another request yet another alternative. It seems to me that the network elements involved in resource allocation activities would have a much more difficult job given that reservations are no longer deterministic. It would seem to me that network elements would not necessarily know if a client used the alternative or opted to renegotiate with another PATH message. Perhaps the problem is not as complex as I am perceiving it to be, provided that the alternative is always designated to a LBE service. So, I am agreeing with what I believe to be some of the implications of your statements, but I may have read more into them than you had intended. The underlying question that remains is, Does overloading the error message with this additional information substantially increase the difficulty of the network elements involved in the allocation of resources? -Mark > > > > Ron, your comments make me think that this approach serves to not > > only overload > > the purpose of the error message, but also sends us down a > > Diffserv-specific > > path. With an alternative DCLASS object coming back in what amounts to a > > rejection notice from the network, how is a network to prepare for the > > alternatively marked traffic? Is the network to assume that the > > client will > > accept the alternative? How can we know how much of the given > > alternatively > > classified traffic can be doled out unless the alternative is > > mandatory? This > > approach seems to short-circuit the spirit and purpose of negotiating for > > resources. > > > > -Mark > > > > Ron Cohen wrote: > > > > > 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. > > > > > > 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). > > > > > > 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 > > > > > > Ron > > > >