[rsvp-dir] Our first work items for RSVP Directorate - would like some progress before July 18

[Bruce Davie <[e-mail]>]

Directorate,
 Some weeks back, I asked for some review of 3 drafts related to RSVP, and I got a request from Bob to get some justification from the authors for why the drafts deserve consideration. Below, you will now see that justification for each draft. My hope is that at the very least  some people from the directorate will have an opinion about said drafts in time for next IETF (July 18) even if you are not attending. 

Feel free to share your opinions on this list.

Thanks,

Bruce

> 
> RSVP Flexible Resource Sharing
> ========================
> The bulk of the work has been merged into draft-berger-ccamp-assoc-info-01.txt.
> The rest is progressed as standalone I-D :draft-narayanan-tsvwg-rsvp-resource-sharing-02.txt
> 
> - What problem with existing RSVP/Intserv are you trying to solve? What new capability will we have if this draft becomes a standard?
> 	* RSVP currently offers some support for resource sharing (historically designed with multicast applications in mind). However, this is restricted to sharing across reservations with the same destination transport address (ie with same Session). The proposed extensions retain the existing concept of resource sharing, but adds the flexibility to apply resource sharing across any arbitrary set of reservations.
> 
> - What class of application will benefit if your draft becomes a standard?
> 	* Many Voice/Multimedia/Collaboration applications that need resource reservation will benefit from the extensions because those will avoid significant bandwidth wastage in various practical scenarios. For example, without the extensions, in a Voice Call-Waiting scenario, RSVP will reserve twice the necessary resources on common links. Similarly, in a Voice Shared Line scenario (i.e. a single number that rings multiple endpoints), without the extensions, RSVP will reserve N times the necessary resources on common links. Another example scenario is where a Video on Demand streamer uses RSVP to establish reservations to an endpoint behind a symmetric NAT: In case of session handover from streamer to streamer, current RSVP will reserver twice the necessary resources.
> 
> - Is there another way to solve this problem (or might someone think there is)? If so, explain how your solution is better.
> 	* We are not aware of any other way to solve the problem of sharing resources across arbitrary RSVP reservations. However, it was brought to our attention that CCAMP had already defined an ASSOCIATION object that allows to associate states (including some resource sharing state) across different GMPLS RSVP-TE established Label Switch Paths, which has a lot in common with the RSVP Flexible Resource Sharing problem/solution. This is why the bulk of the RSVP Flexible Resource Sharing work has now been merged with the corresponding CCAMP document (draft-berger-ccamp-assoc-info).
> 
> - What community of users will benefit from this work?
> Enterprises using Voice/Multimedia/Collaboration applications and wanting to guarantee QoS to those through RSVP resource reservation.
> Service Providers offering managed Voice/Multimedia/Collaboration applications to Enterprise customers.
> Service Providers offering Video on Demand services to residential customers and wanting to guarantee QoS of VoD sessions through RSVP resource reservation.
> 

The next 2 drafts are considered as a pair.
> 
> "Multi-TSPEC/Multi-PREEMPTION"
> 
> 
> * draft-polk-tsvwg-intserv-multiple-tspec
> * draft-lefaucheur-tsvwg-rsvp-multiple-preemption
> 
> - What problem with existing RSVP/Intserv are you trying to solve? What new capability will we have if this draft becomes a standard?
> 	Modern real-time applications and endpoints are very often capable of transmitting at different bandwidth rates, and capable of dynamically adjusting their transmission rate at session establishment, or mid-session, to achieve the best possible user experience in the current conditions. When resource reservation is not used, endpoints can perform dynamic rate adjustment in a reactive manner based on congestion detection. When resource reservation is used, endpoints can take advantage of it to achieve efficient dynamic encoding/bandwidth adjustment in a proactive manner (i.e. before any congestion occurs). To that end, the resource reservation protocol needs to perform dynamic reservation sizing/resizing in order to help endpoints determine the best "codec/resolution" that can be achieved in the current conditions. The MULTI_TSPEC/MULTI_PREEMPTION I-Ds provide a mechanism to achieve this dynamic reservation sizing/resizing in a single signaling round-trip (by essentially allowing to convey multiple "bandwidth" -aka TSPEC/FLOWSPEC- in a single RSVP message). 
> 
> - What class of application will benefit if your draft becomes a standard?
> 	Many Video/Multimedia/Collaboration applications will benefit from these extensions because they will be able to perform pro-active and controlled dynamic adjustment of codec/resolution/bandwidth.
> 
> - Is there another way to solve this problem (or might someone think there is)? If so, explain how your solution is better.
> 	IntServ/RSVP currently only allow signaling of a single "bandwidth", so that dynamic sizing/resizing can only be achieved through successive trial-and-errors involving multiple signaling round trips. This increases session establishment times and results in transient loss of any reservation in case of necessary mid-session bandwidth reduction. The proposed extension allow reservation sizing/resizing in a single round-trip and allow to maintain the base reservation in case of mid-session bandwidth reduction.
> 	draft-ietf-avt-ecn-for-rtp discusses how explicit congestion notification (ECN) can be used by endpoints to perform dynamic rate adjustment in a reactive manner. This reactive approach is expected to be suitable in environments where resource reservation is not available. However, in environments where resource reservation is available, it is expected that a proactive approach based on the proposed Intserv/RSVP extensions) will be used because of its benefits. These benefits include determinism/control in the apportionment of resources (because the arbitration is performed by the network in accordance with the network administrator policy, as opposed to individually by endpoints) and strict QoS protection (because adjustment can take place before any congestion -or early congestion- occurs, as opposed to a reactive approach depending on congestion -or early congestion- detection).
> 
> - What community of users will benefit from this work?
> 	Enterprises using Video/Multimedia/Collaboration applications wanting to perform pro-active and controlled dynamic adjustment of codec/bandwidth. 
> 	Service Providers offering managed Voice/Multimedia/Collaboration applications to Enterprise customers.
>