Re: [tsvwg] RSVP Proxy Approaches - Migrating from Proxy RSVP to e2e RSVP

[Francois Le Faucheur <[e-mail]>]

James and all,

On 16 Oct 2009, at 20:20, James M. Polk wrote:
>>>>
>>>>
>>>> 1) I noted was "When generating a proxy Resv, a receiver proxy  
>>>> MAY choose to forward the Path message downstream instead of  
>>>> terminating it."  - The new text discusses something that it  
>>>> makes it optional. Has there been discussion of whether this  
>>>> could be a SHOULD. The drawbacks seem limited (at first read),  
>>>> and the mechanisms could be useful, enable the PATH seems at  
>>>> least the first stage in getting interoperability. The first  
>>>> problem seems to be a misconfiguration as well (?), the second  
>>>> problem seems minor in most cases (?).
>>>
>>> ASHOK> Maybe. In this case I'd read the use of "SHOULD" as more of  
>>> a guideline for proxy implementors that moving to end-to-end RSVP  
>>> is a worthy goal.
>>
>> The proxy-approaches I-D does not really contain real MUSTs/SHOULDs/ 
>> MAYs so far. It is Informational and intended to describe the  
>> various approaches and their pros and cons, and not intended to be  
>> prescriptive.
>> So I propose to keep prescriptive MAYs and SHOULDs to the rsvp- 
>> proto I-D.
>
> I agree with what Francis says immediately above wrt the use of  
> RFC2119 language.
>
> If the proxy-approaches I-D (as a non-requirements INFO doc) has any  
> 'mays' or 'shoulds', they need to be in lower case - or,  
> alternatively, change the wording to 'can' or 'might' or 'need(s)  
> to' or 'ought to'.

At this stage the I-D is fine and does not have any uppercase "MA/ 
SHOULD/MUST". Those only started showing up inadvertently in the draft  
text that Ashok & I posted on the list for review. We are tweaking  
that text (while incorporating in the I-D) in line with your  
recommendation above.

Cheers

Francois

>
> James
> (with my chair hat on)
>
>
>> Francois
>>
>>
>>>
>>>>
>>>> 2) Is it clear what a Proxy does when it receives RSVP signaling  
>>>> in the downstream, for both the cases where it sent a PATh and  
>>>> for when it did not send a PATH, but still found there was a RSVP  
>>>> capable downstream?
>>>
>>> ASHOK> Well...
>>>
>>> - For per-flow signaling, if we receive a Resv from downstream for  
>>> a Path that we forwarded as well as proxied, the receiver proxy  
>>> should simply convert itself to a midpoint. This is fairly  
>>> straightforward given that RSVP signaling runs hop-by-hop, so  
>>> there's practically no significant difference between Resv  
>>> messages generated on behalf of a local receiver proxy, or  
>>> generated on behalf of a received Resv. Of course, any changes in  
>>> bandwidth requests or policy information made by the eventual  
>>> receiver would make their way into the new Resv sent upstream, but  
>>> this is only an issue in applications where some sophistication is  
>>> required on the receiver to take action over and above simply  
>>> echoing these from the Path. In that case the receiver proxy must  
>>> either be more sophisticated, or this application is unsuitable  
>>> for a receiver proxy. This is discussed in the current approaches  
>>> draft.
>>>
>>> - Again for per-flow signaling, we could receive a Resv pertaining  
>>> to a flow for which we never received a Path or sent a Path  
>>> downstream. RSVP has standard procedures for discarding these  
>>> messages.
>>>
>>> - There is some component of non-flow signaling like RSVP Hello  
>>> messages or Summary Refresh which technically it is possible to  
>>> send/receive them without flow state, although no implementation  
>>> does so today. Probably a better example would be RFC2207  
>>> authentication challenge messages (although even those typically  
>>> only travel to neighbors to which you already do signaling). But  
>>> there's nothing in a RSVP receiver proxy that need affect this  
>>> component of signaling. It might be useful to the node to notice  
>>> that a RSVP neighbor exists downstream and just automatically  
>>> switch to non-proxy mode for flows going to that neighbor, I  
>>> suppose. But since the case doesn't exist today I'm not sure what  
>>> we could do about it.
>>
>>
>>
>>>
>>> -Ashok
>>>
>>>>
>>>> Gorry
>>>>
>>>> Francois Le Faucheur wrote:
>>>>> Hello,
>>>>> Several IESG members brought up a valid concern about the fact  
>>>>> that once RSVP proxy is deployed, it may be difficult to migrate  
>>>>> back to an end-to-end RSVP model. In response to this:
>>>>> * With respect to the "Path-Triggered Receiver Proxy" approach:
>>>>> ===============================================
>>>>> We propose to include a discussion of two mechanisms that can  
>>>>> facilitate dynamic migration from a Proxy mode to an e2e RSVP  
>>>>> mode:
>>>>>  * Dynamic Discovery: in addition to generating a Resv (that  
>>>>> triggers reservation upstream of the Proxy towards the sender),  
>>>>> the Receiver Proxy can forward the Path message downstream  
>>>>> towards the receiver. If no Resv is received by the Proxy, then  
>>>>> it continues operating as a Proxy. If a Resv is received, then  
>>>>> the Proxy converts this into an end-to-end reservation.
>>>>>  * Sender-influenced Proxy Bypass: this is similar to the NSIS  
>>>>> Proxy flag mechanisms. Except we would propose that the Proxy  
>>>>> decision (to proxy or not proxy) be based on information  
>>>>> conveyed inside an RSVP Policy Element.
>>>>> You'll find at the bottom of this message proposed text for a  
>>>>> potential additional section discussing this topic of  
>>>>> interaction between proxy and end point (eg to go in proxy- 
>>>>> approaches as a new section 4.1.1).
>>>>> With respect to "Application-Triggered Proxies":
>>>>> ==================================
>>>>> We feel it is reasonable to assume that applications that would  
>>>>> control an RSVP Proxy (e.g. a SIP Call Agent) would be aware of  
>>>>> a number of endpoint capabilities including whether it is RSVP- 
>>>>> capable or not. In the first place, the application has to be  
>>>>> aware about which endpoint can be best "served" by which RSVP  
>>>>> Proxy anyways when using Proxies. The application may also  
>>>>> consider the QoS preconditions and QoS mechanisms signaled by an  
>>>>> endpoint as per RFC 3312/4032 and RFC5432. The information about  
>>>>> endpoint RSVP capability can then be used by the application to  
>>>>> decide whether to trigger Proxy behavior or not, for a given  
>>>>> endpoint.
>>>>> With respect to "Inspection-Triggered Sender Proxies":
>>>>> ========================================
>>>>> Those devices inspect signaling and/or control traffic  
>>>>> associated with a flow in order to trigger reservation  
>>>>> establishment. When operating off signaling traffic, the Proxy  
>>>>> may be able to detect from the signaling that the endpoint is  
>>>>> capable of establishing a reservation (e.g. in the case of SIP  
>>>>> via inspection of the RFC3312/4032 Precondition). Otherwise, the  
>>>>> proxy can also inspect RSVP signaling and if it sees RSVP  
>>>>> signaling for the flow of interest, it can disable its sender  
>>>>> proxy behavior for that flow (or sender). Optionally, through  
>>>>> RSVP signaling inspection, the sender proxy might also gradually  
>>>>> "learn" (possibly with some timeout) which sender is RSVP  
>>>>> capable of not.
>>>>> Feedback on this proposal as well as proposed corresponding text  
>>>>> below is welcome.
>>>>> Francois
>>>>> =========================================================
>>>>> Draft text for a proposed additional section discussing this  
>>>>> topic of interaction between proxy and end point (eg to go in  
>>>>> proxy-approaches as a new section 4.1.1).
>>>>> 4.1.1) Interaction between a RSVP receiver proxy and a RSVP- 
>>>>> capable receiver
>>>>> The presence of a receiver proxy (for a given flow) in the  
>>>>> signalling path will cause the Path message to be terminated and  
>>>>> a Resv generated towards the sender. If the eventual receiver  
>>>>> was in fact RSVP capable, it would not be able to participate in  
>>>>> RSVP signalling since it does not receive the Path. A similar  
>>>>> problem exists with multiple receiver proxies in the path of the  
>>>>> flow. It is ideal if the RSVP reservation spans the entire flow  
>>>>> path from source to destination, and highly desirable that the  
>>>>> reservation span as much of the flow path as possible. This can  
>>>>> be achieved in the following ways.
>>>>> 4.1.1.1) Selective receiver proxy
>>>>> A RSVP receiver proxy MAY be selective about the sessions that  
>>>>> it terminates, based on local policy decision. For example, an  
>>>>> edge router functioning as a receiver proxy MAY only choose to  
>>>>> proxy for Path messages that are actually going to exit the  
>>>>> domain in question, not for Path messages that are transiting  
>>>>> through it but stay within the domain. As another example, the  
>>>>> receiver proxy MAY be configurable to only proxy for flows  
>>>>> addressed to a given destination address or destination address  
>>>>> ranges (for which end devices are known to not be RSVP capable).
>>>>> The decision to proxy a Resv for a Path may also be based on  
>>>>> information signalled from the sender in the Path message. For  
>>>>> example, the sender may identify the type of application or flow  
>>>>> in the Application-ID Policy Element in the Path, and the  
>>>>> receiver proxy may choose to only proxy for certain types of  
>>>>> flows. Or, if the sender knows through application signalling  
>>>>> that the receiver is capable of signalling RSVP, the sender may  
>>>>> include an indication in a Policy Element to any receiver proxy  
>>>>> that it must not terminate the Path (and conversely, may include  
>>>>> an indication to receiver proxies that they _should_ terminate a  
>>>>> Path if the receiver is known not to support RSVP). A similar  
>>>>> functionality is defined in NSIS [draft-ietf-nsis-qos-nslp].
>>>>> 4.1.1.2) Dynamic discovery of downstream RSVP functionality
>>>>> When generating a proxy Resv, a receiver proxy MAY choose to  
>>>>> forward the Path message downstream instead of terminating it.  
>>>>> If the destination endpoint supports RSVP, it will receive the  
>>>>> Path and generate a Resv upstream. When this Resv reaches the  
>>>>> receiver proxy, it recognizes the presence of a RSVP-capable  
>>>>> receiver downstream and internally converts its state from a  
>>>>> proxied reservation to a regular midpoint behavior. This dynamic  
>>>>> discovery mechanism has the benefit that new (or upgraded) RSVP  
>>>>> endpoints will automatically and seamlessly support end-to-end  
>>>>> flows, without impacting the ability of a receiver proxy to  
>>>>> proxy RSVP for other, non-RSVP-capable endpoints. This mechanism  
>>>>> also achieves the goal of automatically discovering the longest  
>>>>> possible CAC-supporting segment in a network with multiple  
>>>>> receiver proxies along the path. This mechanism dynamically  
>>>>> adjusts to any topology and routing change. Also, this mechanism  
>>>>> dynamically handles the situation where a receiver was RSVP- 
>>>>> capable and for some reason (e.g. software downgrade) no longer  
>>>>> is. Finally, this approach requires no new RSVP extensions and  
>>>>> no configuration changes to the receiver proxy as new RSVP- 
>>>>> capable endpoints come and go. The only identified drawbacks to  
>>>>> this approach are:
>>>>> - If admission control fails on the segment between the receiver  
>>>>> proxy and the RSVP-capable receiver, the receiver will get a  
>>>>> ResvError and can take application-level signalling steps to  
>>>>> terminate the call. However, the receiver proxy has already sent  
>>>>> a Resv upstream for this flow, so the sender will see a "false"  
>>>>> reservation which is not truly end-to-end. The actual admission  
>>>>> control status will resolve itself in a short while, but the  
>>>>> sender will need to roll back any permanent action (such as  
>>>>> billing) that may have been taken on receipt of the phantom  
>>>>> Resv. Note that if the second receiver is also a receiver proxy  
>>>>> which is not participating in application signalling, it will  
>>>>> convert the received ResvError into a PathError which will be  
>>>>> received by the first receiver proxy. This proxy can then signal  
>>>>> the failure of the reservation upstream.
>>>>> - If there is no RSVP-capable receiver downstream of the  
>>>>> receiver proxy, then the Path messages sent by the receiver  
>>>>> proxy every refresh interval (e.g. 30 seconds by default) will  
>>>>> never be responded to. However, these messages consume a small  
>>>>> amount of bandwidth, and in addition may install some RSVP state  
>>>>> on RSVP-capable midpoint nodes downstream of the first receiver  
>>>>> proxy. This is seen as a very minor sub-optimality and observe  
>>>>> that such resources would be consumed anyways if the receiver  
>>>>> was RSVP capable. Still, if deemed necessary, to mitigate this,  
>>>>> the receiver proxy MAY tear down any unanswered downstream Path  
>>>>> state after a predetermined time, and stop sending Path messages  
>>>>> for the flow (or do stop at much lower frequency).
>