Subject: [tsvwg] draft-polk-tsvwg-intserv-multiple-tspec-01.txt

From: ken carlberg <[email-masked]>
Date: Wed, 21 Oct 2009 09:01:23 -0400

James and Subha,

here are some comments on your draft, that include some nits.

-ken

General comments

- the document seems to focus on two tightly narrow views: real-time  
applications (with a telephony/calling flavor) and bandwidth.  For the  
former, the natural question arises as to whether this effort is  
applicable to non-real time applications.  If yes, then I'd recommend  
the use of more generic text.  Otherwise, it would be helpful to know  
why it only applies to real-time apps.

- as for the subject of bandwidth, Int-Serv and the current service  
models are not just about bandwidth.  Depending on the desired service  
model, strict latency requirements may also be a factor.  I'd  
recommend a more general description in reference to QoS parameters.   
Its fine to say "as an example, more bandwidth...", but from my  
perspective, you need to always qualify your position when you talk  
about one aspect of the service.

- I may have missed it, but while your document makes a strict  
requirement in maintaining the exact order of the multiple TSPECs and  
FLOWSPECs (outside of those FLOWSPECs that have been discarded), there  
didn't seem to be any mention of the *basis* for the establishing the  
original order of the TSPECs.  One would assume that the order is from  
the highest set of resources to the lowest.  And if this is the case,  
it needs to be explicitly stated.

- for section 2 (and appendix A), I'd recommend getting rid of the  
text describing Options 1 & 2.  Its very helpful in first introducing  
the work to the group, but there is no need to keep it from this point  
on.

- For section 3, I don't see the need to restate the original TSPEC  
and FLOWSPEC.  Just show the new MULTI_TSPEC and MULTI_FLOWSPEC.

- page 12 places a recommended limit of 16 TSPECs.  Given that one  
could produce up to 16 downstream error messages with just that limit,  
I'd prefer to have a harder more strict limit.  It would be  
uncomfortable to have poorly configured and unbounded set of  
MULTI_TSPECs generating a considerable amount of overhead per flow.   
16 really would seem to be more than enough.

Some nits...

1) for the sake of clarity, you need to put more space between the  
table of contents and the following paragraph because on the first  
read, the top of page 2 makes no sense.

2) its probably best to stay with the naming convention of rfc-2205  
and just use the terms sender and receiver.  Calling and Called node  
has too much of a telephony connotation, and I think it would be  
better to be application neutral in this document.

3) page 3, section 1, 1'st paragraph.  It would be helpful to split it  
into two paragraphs, with the second paragraph starting with "There is  
a separation of function"

4) page 3, section 1, 2'nd paragraph.  Its probably best not to refer  
to the receiver as the "PATH receiver".  It could be a bit confusing  
and give the impression that you are referring to a node other than  
the destination.

5) section 1, paragraph 5.  You need to reword the last sentence of  
the following paragraph

    "Thus the current mechanism of the Integrated Services, and  
therefore
    RSVP, allowing the PATH generator to only provide one traffic
    specification and for the resulting RESV generator to only include
    one bandwidth request is limiting. "

Because its too muddled.

6) section 1, paragraph 6.  The first sentence is way too long.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 22 Oct 2009 15:06:30 -0500

>here are some comments on your draft, that include some nits.

thanks for the review

comments in-line

>about one aspect of the service.

We're working on the two points above. stay tuned.

>it needs to be explicitly stated.

This is a dilemma, as there is no ability to signal the order, other 
than to maintain the order in the PATH.  Now, if you get merging, and 
happen to keep the relative orders within each FLOWSPEC (which we 
RECOMMEND in -02), how does the merging node know which is more 
important of two lists (1,2,3) and (a,b,c)?  I think you have to go 
with r for Controlled load and R for Guaranteed Service.  Got any 
other suggestions?

>the work to the group, but there is no need to keep it from this point

I'm moving the current section 2 to the appendix, and replacing 
what's already there in the appendix. I'm further rewriting section 2 
towards the only proposal this ID is moving forward with.

>and FLOWSPEC.  Just show the new MULTI_TSPEC and MULTI_FLOWSPEC.

are you sure?

it's showing the contrast from how it is today with how we're changing it...

>16 really would seem to be more than enough.

we're working on this

>read, the top of page 2 makes no sense.

done

>better to be application neutral in this document.

sender and receiver from the perspective of the PATH or RESV?

each are opposite, so I though Calling Node and Called node would be 
easier to understand.

>a separation of function"

done

>and give the impression that you are referring to a node other than

replaced "receiver" with "destination"

>    one bandwidth request is limiting. "

rewrote to

   "It is therefore limiting to have a single bandwidth request in
   Integrated Services, and by extension, RSVP."

how's this?

>6) section 1, paragraph 6.  The first sentence is way too long.

ga... I'm working on that now (I like the caveat - as it adds needed 
meaning, but will work on a rewrite)

---

From: ken carlberg <[email-masked]>
Date: Fri, 23 Oct 2009 11:16:05 -0400

> than to maintain the order in the PATH.  Now, if you get merging,  
> and happen to keep the relative orders within each FLOWSPEC (which  
> we RECOMMEND in -02), how does the merging node know which is more  

well, Control Load and Guaranteed Service are kind of like oranges and  
grapefruit -- both part of the citrus family, but not things you'll  
merge with each other.  instead, unless I missed something, you'll  
only end up merging different Control Load *or* different Guaranteed  
Service TSPECs.  Or does Cisco have a value added policy service that  
can merge the two different service classes. (my apologies, I'm going  
by my ancient memory from the original discussions on the topic)

>> and FLOWSPEC.  Just show the new MULTI_TSPEC and MULTI_FLOWSPEC.

yes :-)

> it's showing the contrast from how it is today with how we're  

understood, and actually I did something similar ages ago, and was  
asked to remove it.  Initially, I wasn't thrilled, but in the end you  
need to ask yourself what exactly is gained by showing the what has  
changed in the same document.  It doesn't change the new  
specification, and if the implementor/designer/architect needs a  
refresher of the original TSPEC/FLOWSPEC format, he or she can simply  
bring up a new window or be non-eco-friendly and print out the old  
specs.  So, I'd prefer to default to the conservative position of just  
presenting the minimum.

> each are opposite, so I though Calling Node and Called node would be  

different, but there is consistency.  Senders always send the PATH  
message downstream, and the receiver always sends the RESV upstream.

>  Integrated Services, and by extension, RSVP."

ok.  Another suggestion is to say, "It is therefore limiting in terms  
of the potential inefficiency of multiple RTT to have a single request  
for resources in Integrated Services, and by extension, RSVP."

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 23 Oct 2009 14:43:47 -0500

Ken

comments in-line

At 10:16 AM 10/23/2009, ken carlberg wrote:
>merge with each other.

I'm sorry I confused you. I never meant to imply CL and GS would ever merge.

I was giving the limitation of merging FLOWSPEC-A of 1,2,3 and 
FLOWSPEC-B of a,b,c the limitation of just how to you merge the two 
in the right order?  I can't think of a solution now, but I believe 
we need to maintain the relative preference order within any one 
FLOWSPEC intact (for either all CL or all GS), agreed?

>instead, unless I missed something, you'll
>changed in the same document.

well, it's not "...in the same document." but contrasting what's 
changed " ...by this document verses what's in RFCs previous to this document."

Does that make more sense?

>It doesn't change the new
>specs.

if they can find the old spec. I'm the not the first to admit RFCs 
2205-15 weren't the best arranged grouping of RFCs (even within any 
one of them (with the possible exception of 2205)).

>So, I'd prefer to default to the conservative position of just
>presenting the minimum.

if need be, I can try and find the exact figure in the exact RFC 
number for someone who needs this refresher to go and look at (to 
prevent further laziness  ;-)

>message downstream, and the receiver always sends the RESV upstream.

This isn't so understood by the community, and if it was, I'd have 
gone with that in the first place.

>for resources in Integrated Services, and by extension, RSVP."

ok

twist my arm

;-)

Thanks

James

---

From: ken carlberg <[email-masked]>
Date: Mon, 26 Oct 2009 07:14:33 -0400

On Oct 23, 2009, at 3:43 PM, James M. Polk wrote:

>  was giving the limitation of merging FLOWSPEC-A of 1,2,3 and  

agreed on your second sentence.  my inclination would be to recommend  
a merging that places the most aggressive request for resources on a  
top down basis.  so if in your example above the values corresponded  
to units of requested resources and a=1, b=1.1, and c=4, then a merged  
set would appear as the following:
{c,3,2,b,1}

> Does that make more sense?

well, it makes sense, but not a convincing argument.  However, this is  
not a deal-breaker by any means, and if you feel more comfortable with  
the information remaining inside the document, then leave it in as is  
to see if others feel differently.

-ken