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

["Ralph Santitoro" <rsantito@nortelnetworks.com>]

Reposting due to email problems.......

-----Original Message-----
From: Santitoro, Ralph [GUAR:1482-M:EXCH] 
Sent: Monday, January 08, 2001 10:57 AM
To: 'Ron Cohen'; rap@ops.ietf.org
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt


Just catching up on email after vacation..... See comments below...

Regards,
Ralph Santitoro

-----Original Message-----
From: Ron Cohen [mailto:ronc@cisco.com]
Sent: Monday, December 25, 2000 10:09 PM
To: rap@ops.ietf.org
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt



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.

---------------
[Ralph] 
Sending traffic with no QoS after an RSVP reservation failure is not
necessarily a 'bad' RSVP-enabled application.  An app. may still be usable
without an RSVP reservation, albeit not optimal.  However, sending traffic
after and RSVP reservation failure may not be desirable for applications
such as VoIP.  A VoIP application may not be able to tolerate the call setup
delay when renegotiating a new TSpec.  While PSTN bypass is an option, the
VoIP gateway or IP Phone may not support this functionality.  Some network
administrators/operators may want to simply block the VoIP app. while others
may want to allow it to be sent as best effort.  It all depends on the
service being offered and the service level expectations.

There are many possible scenarios that can occur if the RSVP reservation
failed.  I didn't list them in the draft because it wasn't meant to be
specific to VoIP.  If the WG would like this to be covered more extensively,
I can add some of the many possible scenarios.
---------------

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

---------
[Ralph]
Your example provides additional guarantees for apps that are not
"DO_NOT_SEND" compliant.  However, it would be better described as a
"Discard-on-WAN DSCP" because you are simply dropping all traffic with the
associated DSCP.  I don't mind adding this to the draft.  Does anyone else
on the list have any comments on this?
---------

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

---------------
[Ralph]
Let me take a look at RFC 2750 again.  I recall some reasons for not using
them but don't remember.  I'll get back to the list on this....
---------------


Ron