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

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 2 Feb 2001 18:36:27 -0500

Yoram,

The premise of IntServ is that both ends agree to a service level. One of
the main concerns I have with this proposal is that only one side is being
told of a specific (less optimal)service alternative. In order to preserve
the end-to-end nature of RSVP, one alternative possiblity (suggested by Bob
B.), might be to send a ResvErr back to the receiver with a flowspec that
has a higher probability of success. This would allow the receiver to send a
revised Resv back to the sender allowing for both a viable reservation (with
all it's properties), as well as the most ideal DSCP mapping.

regards,

-Walter

> -----Original Message-----
> From: Yoram Bernet [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2001 12:23 PM
> To: Ron Cohen; [email-masked]
> Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt
> 
> 
> 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
>