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

["James M. Polk" <[e-mail]>]

At 03:00 PM 10/16/2009, Francois Le Faucheur wrote:
>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.

should be good to go then...


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