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

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 5 Feb 2001 09:13:36 -0500

Having spent a few years at Lucent that included some work around IPT
deployment solutions, I know all about Call Setup delay goals (there are no
specific standards for this that I am aware of beyond some studies of use
expectations). The truth is that I was always skeptical of using RSVP in
conjunction with IPT because it required two sequenced round-trip
negotiations (H.323/SIP + RSVP). However, that is not really the point. The
main point is that IntServ and RSVP specifically imply a contract between
sender and receiver. It makes no sense to me whatsoever to standardize a
successful end2end reservation with the appropriate DSCP if the Tspec can be
met and to convey a less optimal DSCP without a reservation when the Tspec
can not be met. It would seem more reasonable to at least ensure that the
receiver is aware that a less optimal service being delivered (say by
sending a sub optimal Tspec). 
 
If you want to reduce setup delay, send a PathErr back with the less optimal
Tspec that is more likely to result in a successful reservation. At least
then you are getting consistent IntServ semantics and you are only adding
incremental call setup delay.
 
regards,
 
-Walter

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

Walter,
 
For IP telephony (IPT) applications, this draft addresses some particular
problems related to call setup time during the RSVP reservation process.
During the call admission control process, the IPT device needs to know
whether a sufficient QoS level is available from the network prior to
establishing the call.    
 
The sending device (caller) uses RSVP to signal the desired QoS level based
on an SLA or enterprise network policies.  If there are insufficient network
resources to achieve this QoS level, then it is desirable to immediately
send a response back to the sending device via a Path-Err rather than wait
for the RSVP message to make its 'round trip' from the receiver back to the
sender.
 
The approach in the draft minimizes call setup time by providing a much
quicker RSVP 'response' to the IPT device so it can quickly make alternate
choices.  (The IPT device may provide fast busy tones to the user, an IPT
gateway may have a PSTN fallback connection or the IPT device may reinitiate
the reservation with a low bandwidth codec.) 
 
I agree with Ramesh's point below that the receiver doesn't provide any
additional information so there is no need to add the extra round trip delay
of the ResvErr message.
 
Regards,
 
..... Ralph

-----Original Message-----
From: Ramesh Pabbati [mailto:[email-masked]]
Sent: Friday, February 02, 2001 5:10 PM
To: Weiss, Walter; Yoram Bernet; Ron Cohen; rap
Cc: Santitoro, Ralph [GUAR:1482-M:EXCH]
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Walter,
 
One of the main aims of this draft is let the a class of sender know ASAP
when there are no resources available to meet this requirements of this
session. One such example is IP phones which operate with a fixed flowspec
and receiver just a copy of sender Tspec. The PDP will return this specific
error based on the application sending (i.e., receiver is not going provide
PDP any more information beyond what is in the PATH message). By sending a
ResvErr back to receiver and receiver sending this ResvErr indication using
another control channel will add to delay in setting up the call. Some class
of applications can not tolerate this delay, for those applications PDP will
return this error code in PathErr message. Ralph can provide more details on
this class of applications.
 
Ramesh

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