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

[ken carlberg <carlberg at g11.org.uk>]

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.