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