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

From: Yoram Bernet <[email-masked]>
Date: Fri, 2 Feb 2001 15:51:56 -0800

walter:
 
expectations regarding rsvp have changed significantly. rsvp, as it was
intially imagined to be deployed, with per-flow reservations at each hop and
pure intserv services, was not well received. we've worked on adapting it
(rfcs 2996. 2997, 2998). part of this adaptation is a change in the
end-to-end semantics and a broadening beyond pure intserv. the draft should
be considered in this context. 
 
yoram

 -----Original Message-----
From: Weiss, Walter [mailto:[email-masked]]
Sent: Friday, February 02, 2001 3:36 PM
To: Yoram Bernet; Ron Cohen; [email-masked]
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

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