Re: draft-santitoro-rap-policy-errorcodes-01.txt

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

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