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

[Yoram Bernet <yoramb@microsoft.com>]

Ron:

Thanks for the comments. This is getting complicated enouhg to warrant some
face to face discussion. In any case, some responses below:

> 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).

The application may or may not know this. For example - an application might
(in response to failed admission control, but not the 'do not send' message)
defer to the user, with a UI of the form: "You will not be granted QoS for
this session. You may: 1) try your call again later 2) proceed with no qos
3) retry with a lesser codec (e.g. press the 56 Kbps button instead of the
T-1 button).

> (2) Whether it supports the new instructions.

As i'll explain below - an application could tell you this, but I don't
think it affords you to behave any differently...
> 
> 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.

I beleive that - if you add to a protocol - you must be able to explain
specifically how the addition will change the behaviour of the peers that
participate in the protocol. You do take a stab at this below, but - as I
will show, i'm not sure that the behaviours you propose really work. If we
conclude that there are no valuable behavioural changes that result from the
protocol addition, then I don't think it can be justified on the abstract
basis of "smart networks and felxible policy enforcement".
 
> 
> 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.

This approach suffers from a number of problems. 

First of all - it largely removes the incentive for an application to be
well-behaved. If the application is not upgraded, it at least gets to try to
get service. If it's upgraded - it gets completely denied. Why should an
application upgrade?

Second - if you have the means in the network to provide traffic separation,
then you should apply this means regardless of what the app says or does not
say it will do. In other words - the signaling provides you with the
classification information that you need to recognize the flow of interest.
If you have the ability to use this classification info to downgrade the
priority of the traffic in the WAN, then you should do so - regardless. Thus
- your behaviour would not change because the app claims to be well behaved.

The 'do not send' policy is primarily intended for networks that do not have
the ability to offer traffic separation between b/e and lbe. On these
networks, the choice of the netadmin is to 1) allow the app to be deployed,
regardless of its behaviour, thereby running the risk that the wan resources
will be trashed. 2) refuse to deploy the app on the wan. 3) allow the app to
be deployed only if it is well-behaved.

> 
> 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.

Indeed, the hypothetical parameter could tell the pdp that the app would or
would not do something. but - i maintain that you still would have to apply
the same behaviour, regardless.
> 
> 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.

I imagined that there would be one resource counter for each service level
(except b/e and lbe). The counter would be conditionally debited as soon as
a path message is seen. The debit could be reversed if the reservation is
denied. This does result in brief underestimations of available resources,
but - this situation occurs in many scenarios and doesn't strike me as a
problem.

> 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 the sender is going to send without a reservation, the sender will not
consume resources at a prioritized service level. The sender's traffic will
be in be or lbe and therefore, need not be counted. 

> See some minor remarks inline as well
> 
> >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.
> 

As I proposed the protocol exchanges, there would be no additional
information in the 'query' or the application's message to the network (the
path message in this case). The additional information would be only in the
'response' (the path_err message). As you propose it, there would be
additional info in both. If you were to for example, build a protocol
simulator/tester, your approach is more complex to model (and therefore, to
implement, to test and to operate). Unless you can show a concrete benefit
of the added complexity, I oppose the added complexity.

> >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.
> 

As stated in my earlier comments, the application may defer this choice to
the user. The network should not need to behave differently on this basis. 

> >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.
> 

Sorry - by 'protocol exchange' I meant, 'additional information carried in
protocol messages which require additional parsing, additional decision
making and may alter the progression of a protocol exchange'.

Regards,
Yoram