Re: [rsvp-dir] TSVWG Status Update (Oct 2010)

[Bruce Davie <[e-mail]>]

On these 2 drafts:
On Oct 26, 2010, at 8:29 AM, Gorry Fairhurst wrote:

> draft-polk-tsvwg-intserv-multiple-tspec
>     RSVP directorate to be consulted.
>     WG interest in this topic recorded at IETF-78.
>     Charter update would be needed to progress this work.
>     5 Reviews needed to determine energy/technical direction.
>     Author will update -04.
>     New revision expected.
> 
> draft-lefaucheur-tsvwg-rsvp-multiple-preemption
>     RSVP directorate to be consulted.
>     WG needs to assess if this topic should be a work item.

Two members of the RSVP directorate (myself and Lixia) have read these drafts and support their adoption by the WG. Below are some specific comments that I sent to the chairs, but I failed to send earlier to the WG. I believe at least one more directorate member has read these drafts but I've not received feedback one way or another about adoption from other directorate members.



Begin forwarded message:

> From: Bruce Davie <[e-mail]>
> Date: August 6, 2010 5:48:40 PM EDT
> To: [e-mail]
> Cc: [e-mail], [e-mail]
> Subject: Re: [rsvp-dir] Fwd: Update from RSVP directorate on RSVP Candidate items?
> 
> 
> On Jul 27, 2010, at 12:16 PM, Gorry Fairhurst wrote:
> 
>> Bruce,
>> 
>> It's good to know that you favour adoption. I think we are still working out the ways the directorate will work.
> 
>> 
>> I'd really appreciate a bit more detail, since there are quite a few things that Chairs need to determine before we can allow the WG to consider adopting the draft - The sort of things I'm interested as a Chair are:
>> 
>> * What specs would this draft update: Does this seem to update IntServ? Is it a minor update to RSVP?
> 
> In my view, the 2 drafts MULTI_TSPEC and MULTI_PREEMPTION are an update to how Intserv is invoked by RSVP, that is to say, RFC 2210. It is relatively minor (although this is totally subjective). Intserv defined some services. RSVP was defined as  a mechanism to invoke services. What this draft does is it says that you can invoke a service by saying what service parameters you would really like, and which lesser set of parameters you would accept. In the original RSVP design, you could only send one set of parameters and get a yes/no answer.
> 
> 
>> 
>> * Are there any areas that are less mature than others from a techical point of view: Can you see sections that would need more work? are there missing sections?
> 
> The draft looks pretty complete to me. But it will need careful line-by-line review by one or more RSVP experts.
> 
>> 
>> * Do we need to do this? Why?
> 
> Well, it seems that in the current state of things, you can't use RSVP to reserve the "right" amount of resources when the endpoints could live with a range of possible levels. For example, if two endpoints support a high bit rate and low bit rate encoding, you can't settle on the right choice of codec in  a single RTT today. So, to the extent that you accept that this is a problem (which I do) yes, we need the draft.
> 
>> 
>> * Do you know of indications that there may be a "customer" for the technology: e.g. another working group? to support an application? etc?
> 
> This is most useful to telephony/video conferencing apps in my reading. 
> 
>> 
>> * Do you know of other things that may help the chairs understand whether the WG should devote energy to this draft?
>> 
>> * Would one or more members of the directorate volunteer to comment on progress of this and also commit to reviewing the document as we get to WGLC?
> 
> I'm willing to do this (but I see that Bob Briscoe has also done a review which he has not yet posted.) 
> 
> Bruce
> 
>> 
>> * Anything else?
>> 
>> Best wishes,
>> 
>> Gorry
>