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

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 17 Mar 2011 08:29:58 +0000

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 <[email-masked]>
To: ken carlberg <[email-masked]>
CC: tsvwg <[email-masked]>

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.

---

From: Bruce Davie <[email-masked]>
Date: Thu, 17 Mar 2011 10:16:01 -0400

On Mar 17, 2011, at 4:29 AM, Gorry Fairhurst wrote:

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

You'll note that Fred recently posted my note from Nov 1, 2010, and Scott Bradner just commented as a directorate member.

So, the 3 directorate members who have commented are in favor of adopting this draft.

Bruce

> I'll also try to sumarise where I see this draft has reached. I can't do this today though.
> 
> Gorry
> 
> 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.
> 
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 17 Mar 2011 18:46:25 -0400

I too think this is useful work and worth bringing into the WG.

Authors,

I have some comments/questions that can be addressed as the draft moves
forward (and don't need discussing if the draft isn't):

1) a real nit:
I suspect that the <flow descriptor list> RBNF is broken, and
[MULTI_FLOWSPEC] should be [ <MULTI_FLOWSPEC> ] .  (You might want to
add a reference to 5511 too.)

2) I could see this as a more generally applicable problem, in
particular it could apply to the non-IntServ class types supported by
RSVP (TSPEC/FLOWSPEC).  What do you think about having the MULT_xxSPEC
objects being defined solely on the RSVP level (perhaps using
subobjects) rather than as defined now which is a change to RSVP and
IntServ?

Lou

PS I'm on the rsv-dir mailing list, but not listed on the web page so
have no idea if this means this is a comment as a directorate member or not.

PPS I won't be in the Prague session as I'll be chairing a WG at the
same time, but do support this work as a WG document if the topic comes up.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Mar 2011 16:04:02 -0500

>I too think this is useful work and worth bringing into the WG.

Thanks!!

>[MULTI_FLOWSPEC] should be [ <MULTI_FLOWSPEC> ] .

yep, sorry - this is obvious

>  (You might want to add a reference to 5511 too.)

probably

>subobjects) rather than as defined now which is a change to RSVP and

Hadn't thought about this before. We'll think about how this would 
work and if there are any gotchas.

Thanks for the comments and support.

James

> >> 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.
> >>
> >
> > You'll note that Fred recently posted my note from Nov 1, 2010, 
> and Scott Bradner just commented as a directorate member.
> >
> >>> 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
> >>
> >>> 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.
> >>
> >>
> >
> >
> >
> >
> >