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

[Ron Cohen <ronc@cisco.com>]

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