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

[Ron Cohen <ronc@cisco.com>]

Yoram,


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

Ok. I think the good thing is that I'm more comfortable thinking that this 
draft deserves to be a WG item. So my vote is yes on this issue.

Short answers to the points you raised:

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

The application is upgraded because the customers (the network 
administrator) asks for a better control over the send/do-not-send 
behavior. Being able to send unwanted flows is not a benefit.

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

Two points here.

First, I might not have traffic separation, but use the LBE marking to 
control the application flow using a policer/shaper on the WAN edge in the 
form of if (LBE) limit flows to x.
Second, Providing LBE to the application means that I want to let the 
application try and run even if I'm sure I'm not going to provide it with 
the appropriate QoS. Suppose my experience tell me that these application 
doesn't work in such situation, making the persons using them to conclude 
that either 'the network is not operating as should' or 'the application is 
worthless'. I want to be sure that if there is no room for the application, 
it will not send traffic. In this case, I want to return a don't send 
indication instead of an LBE decision.


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

Good example. There are several options for doing that, the cleanest is:

The application is going to wait for a successful Resv, otherwise it can 
not prompt the users with the options upon admission failure. Therefore it 
should indicate this in the initial Path message exchange. The application 
might get a don't send indication. It might get admission error only. When 
this happens the user is prompted to answer. If he chooses 3, you resend a 
new Path message with the new TSPEC right? So do the same if he chooses 
option 2 and resend a Path with the indication that the application IS 
going to send now without regard for the final answer. This is how a 'good 
application' should behave. Note that this does not mean that you have to 
wait now for the successful Resv therefore it doesn't add any additional 
delay on the application.

Regards
Ron


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