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

From: Ron Cohen <[email-masked]>
Date: Mon, 25 Dec 2000 22:09:13 -0800

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

---

From: "Mark L. Stevens" <[email-masked]>
Date: Thu, 28 Dec 2000 12:15:19 -0500

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