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

[Dan Romascanu <dromasca@avaya.com>]

> I think that this draft deserves working group attention and discussion. 
> I'm not sure whether it should be a working group item yet.
> 
	[Dan]  I agree. I think the draft starts to address a set of issues
related to implementing real-life applications like VoIP by means of RSVP
extensions over Diffserv networks. 

> 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.
> 
	[Dan]  This draft is about searching a practical approach for the
use of RSVP signaling. According to the type of deployment we deal with,
several alternatives might or might not be available. Re-negotiating
different TSPECs might make even worse the problem of the time that is
allowable for completion of signaling in a VoIP application. The user
experience of a phone user is to have some audio feedback available about
the network resources availability as soon as he picked the phone. Admission
control by end-to-end RSVP signaling with or without outsourcing some of the
decisions to PDPs on the way is a time consuming operation.

	On the other hand, PSTN re-routing might not be available in all
environments. In some cases a 'sub-optimal' traffic transmission as
suggested by the draft might be acceptable. It looks like me might need to
consider different alternate policies, even with the price of becoming more
liberal in what we label as 'good' or 'bad' RSVP application.


> 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).
> 
	[Dan]  Yes, this is an interesting idea, though I would avoid using
the term 'WAN' and try to define differently the discard domain. 

	My question is what is the PHB for the 'non-WAN routers'? If the
traffic is sent best-effort, there should be no resource allocation problem,
even for the WAN routers - applications should just ensure that they send
some feedback to the user 'your call won't make it over the discard domain
(WAN) and may be performance degraded'. Or maybe you had in mind the local
routers treating this traffic with same PHB as high admitted traffic within
the 'local' domain? Maybe we should map this DSCP to a 'Better than Best
Effort' behavior, which would ensure a better PH service than BE - if
available - but would protect already admitted traffic.

	Regards,

	Dan