Fwd: Re: draft-polk-tsvwg-intserv-multiple-tspec-06

[Gorry Fairhurst <[e-mail]>]

I'm happy to discuss the future steps for this draft.

I'll also take an action to check the status and then seek help from the 
RSVP directorate, the last note I saw from rsv-dir was 09/11/2010.

I'll also try to sumarise where I see this draft has reached. I can't do 
this today though.

Gorry

-------- Original Message --------
Subject: Re: draft-polk-tsvwg-intserv-multiple-tspec-06
Date: Wed, 16 Mar 2011 15:23:32 -0700
From: Fred Baker <[e-mail]>
To: ken carlberg <[e-mail]>
CC: tsvwg <[e-mail]>


On Mar 16, 2011, at 10:56 AM, ken carlberg wrote:

> hello,
>
> my understanding is that the decision is still open as to whether this individual draft should become a working group draft.  I'd like to express my interest in making that migration.  My first comments on the draft came way back at the IETF-stockholm meeting in '09, where I brought up questions about multicast.  The current draft satisfies these questions, and other comments I have made since then.  I think this effort is properly baked for acceptance as a working group draft.
>
> But perhaps more importantly, I very much like its focus on optimization.  The bulk of the work we come across at the IETF either introduces new stuff, or augmentations to existing efforts.  Its refreshing to see work that focuses on optimizing something we already have.
>
> my 2 cents,
>
> -ken

I think a relevant note is:

On Nov 1, 2010, at 4:14 PM, Bruce Davie wrote:
> 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.

It would be good to know whether other members of the RSVP Directorate 
have commented. If there has been a charter discussion, I have managed 
to miss it.

As to the draft itself, I think there is reason to support it, as we now 
have multi-rate codecs that can interact with it; rather than firing up, 
disturbing competing traffic to a degree that the codec data experiences 
loss and other traffic presumably does as well, and then backing off to 
a more acceptable rate (which is what rate-adaptive codecs do), it would 
be nice of the network could say "that will happen if you choose this 
rate, but if you choose this lower rate you will be better off." Having 
multiple T-Specs gives the network the option of making that choice on 
the first pas rather than taking binary decisions on multiple sequential 
decision steps.