RE: draft-santitoro-rap-policy-errorcodes-01.txt

[Yoram Bernet <yoramb@microsoft.com>]

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
>