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

["Ramesh Pabbati" <rameshpa@Exchange.Microsoft.com>]

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