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

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

At 10:55 AM 10/16/2009, Francois Le Faucheur wrote:
>Ashok, Gorry,
>
>On 8 Oct 2009, at 19:54, Ashok Narayanan wrote:
>
>>Inline for ASHOK>
>>
>>On Oct 8, 2009, at 10/8 1:42 PM, Gorry Fairhurst wrote:
>>
>>>Thanks,
>>>
>>>I'll let others ask questions...
>>>
>>>I have two myself:
>>>
>>>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'.

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