-----Original Message-----
From: Ramesh Pabbati [mailto:rameshpa@Exchange.Microsoft.com]
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.txtWalter,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:wweiss@ellacoya.com]
Sent: Friday, February 02, 2001 3:36 PM
To: Yoram Bernet; Ron Cohen; rap@ops.ietf.org
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txtYoram,
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:yoramb@microsoft.com]
> Sent: Wednesday, January 17, 2001 12:23 PM
> To: Ron Cohen; rap@ops.ietf.org
> 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
>