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

From: "Grimstad, Al" <[email-masked]>
Date: Fri, 12 Jan 2001 13:21:24 -0500

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:[email-masked]]
Sent: Thursday, January 11, 2001 4:15 PM
To: Yoram Bernet; [email-masked]
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:[email-masked]]
> > Sent: Monday, December 25, 2000 10:09 PM
> > To: [email-masked]
> > 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