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

[Fred Baker <[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.