[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tsvwg] draft-polk-tsvwg-intserv-multiple-tspec-01.txt
At 08:01 AM 10/21/2009, ken carlberg wrote:
James and Subha,
here are some comments on your draft, that include some nits.
-ken
thanks for the review
comments in-line
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.
We're working on the two points above. stay tuned.
- 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.
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?
- 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.
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.
- 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.
are you sure?
it's showing the contrast from how it is today with how we're changing it...
- 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.
we're working on this
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.
done
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.
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.
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"
done
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.
replaced "receiver" with "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. "
rewrote to
"It is therefore limiting to have a single bandwidth request in
Integrated Services, and by extension, RSVP."
how's this?
Because its too muddled.
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)