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

["Gross, Gerhard" <gerhard.gross@intel.com>]

> Mark, if we were to use RSVP for certain applications, e.g., VoIP, then
this
> ID would provide us absolutely necessary features. I encourage the WG to
> make this an official work item and progress it on the standards track
ASAP.
> -- al

These are not *absolutely necessary features*.
Issues concerning integration of QoS (RSVP) and
VoIP (as well as AAA) have been the focus of
work by a number of people for quite some time
now. See the following drafts, submitted to the
SIP (Session Initiation Protocol) working group.

draft-gross-sipaq-00.txt
draft-gross-cops-sip-00.txt
draft-sinnreich-aaa-interdomain-sip-qos-osp-00.txt
draft-sinnreich-interdomain-sip-qos-osp-01.txt
draft-sinnreich-johnston-sip-osp-token-00.txt

No extensions or modifications to RSVP need to be made.

A snippet from the santitoro draft:

> The first ErrorValue informs the sending application that it MUST NOT
> send the traffic described in its PATH message. The second ErrorValue
> informs the sending application that prioritized resources are not
> available but that it may proceed to send with no resource guarantees.
> (The ErrorValues are intended to be included in PATH_ERR messages, in
> response to corresponding PATH messages).

Both of these cases have already been addressed.
draft-sinnreich-interdomain-sip-qos-osp-01.txt discusses
in detail two QoS models: QoS Assured and QoS Enabled.
The QoS assured model only completes call setup if/when
QoS has been established. In this case, the sender does
not send until/unless QoS has been established. The QoS
enabled model completes call setup regardless. In this
case, the user wants the call to proceed before QoS has
been granted and even if QoS is never granted for the
session.

draft-gross-sipaq-00.txt defines a COPS extension for
SIP to integrate policy (and AAA) messaging into the VoIP
picture. See draft-gross-sipaq-00.txt for a general
overview.

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    gerhard.gross@intel.com    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@avaya.com]
> Sent: Tuesday, December 26, 2000 12:23 AM
> To: 'Ron Cohen'; rap@ops.ietf.org
> Cc: Anwar Siddiqui; Eyal Amitai
> 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.
> > 
> 	[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
> 
> 
>