[Fwd: draft-santitoro-rap-policy-errorcodes-01.txt]

["Mark L. Stevens" <mstevens@ellacoya.com>]

Ron Cohen wrote:

> Mark,
>
> I don't understand what you are asking/saying here. Are you referring to the
> draft or to my remarks? What is the alternative you are asking about? What
> is 'This approach' - do you mean the approach taken by the draft or my 2cent
> proposal?
>
> (It might be good to send the clarification to the list)
>
> Appologies for being difficult
> Ron

Ron,

No difficulty, my hurried comments were not clear. Perhaps they will remain so,
but let me try to clarify.  The approach to which I was referring was the
approach outlined in the draft-santitoro-rap-policy-errorcodes.01.txt document.
The alternative to which I referred was the alternative quality of service
implied by the DCLASS object returned to the client in the error indication. If
the error indication includes a DCLASS object, does not it imply that the client
can use the DSCP to mark the traffic it subsequently sends despite the receipt
of a PATH error message? If so, then if the DCLASS was returned in an error
indication, it effectively serves as an alternative to the request originally
made to the network.

My concern is that allocating network resources becomes more difficult if it is
not clear whether or not a client decides to use the alternative. In the model
proposed in the draft, the implication is that clients go ahead and use the
alternative by marking subsequent traffic according to the DCLASS object rather
than restart the negotiation by sending another PATH message, but nothing would
stop a client from declining to use the alternative and electing to initiate
another request yet another alternative.  It seems to me that the network
elements involved in resource allocation activities would have a much more
difficult job given that reservations are no longer deterministic. It would seem
to me that network elements would not necessarily know if a client used the
alternative or opted to renegotiate with another PATH message. Perhaps the
problem is not as complex as I am perceiving it to be, provided that the
alternative is always designated to a LBE service.

So, I am agreeing with what I believe to be some of the implications of your
statements, but I may have read more into them than you had intended.

The underlying question that remains is, Does overloading the error message with
this additional information substantially increase the difficulty of the network
elements involved in the allocation of resources?

-Mark

>
>
> > Ron, your comments make me think that this approach serves to not
> > only overload
> > the purpose of the error message, but also sends us down a
> > Diffserv-specific
> > path. With an alternative DCLASS object coming back in what amounts to a
> > rejection notice from the network, how is a network to prepare for the
> > alternatively marked traffic? Is the network to assume that the
> > client will
> > accept the alternative? How can we know how much of the given
> > alternatively
> > classified traffic can be doled out unless the alternative is
> > mandatory? This
> > approach seems to short-circuit the spirit and purpose of negotiating for
> > resources.
> >
> > -Mark
> >
> > Ron Cohen wrote:
> >
> > > I think that this draft deserves working group attention and discussion.
> > > I'm not sure whether it should be a working group item yet.
> > >
> > > Here are some basic questions about this draft:
> > >
> > > 1. I don't agree with the following text in the draft:
> > >
> > > "From the perspective of a sender and a receiver of application traffic,
> > > the conventional usage of RSVP is as follows:
> > > ...
> > >   5. Sender sends traffic regardless of the admission control
> > decision. "
> > >
> > > I think this indicates a 'bad' RSVP application. If the application
> > > requires QoS, than it should not 'send it anyway', but rather either
> > > renegotiate TSPECs or turn to an alternative. For example, if
> > you want to
> > > run a VoIP flow, and get a QoS refusal, you would than turn to
> > send it via
> > > PSTN.
> > >
> > > 2. In the description of the alternatives available today to the network
> > > administrator to make sure that an application would not send anything
> > > across the WAN the following option is not mentioned:
> > >
> > > Create a 'Discard-on-WAN' PHB, and associate it with a DSCP.
> > Set rules on
> > > all WAN routers that discard all packets arriving with this DSCP set.
> > > Return to such applications that send there traffic anyhow this
> > DSCP value
> > > in the DCLASS object. In this way you are sure that even if the
> > application
> > > does send the traffic even when QoS is rejected, traffic would
> > be discarded
> > > on the WAN edge (assuming that at least it conforms with the
> > DCLASS object
> > > sent to it).
> > >
> > > 3. It is not explained in the draft why the added values should
> > go into the
> > > policy error object and not to the error object policy errors
> > as defined in
> > > appendix A of RFC2750. It does not say what should be carried
> > in the RSVP
> > > error object
> > >
> > > Ron
> >
> >