Dear all, in particular Tom,
I read through the last version of the user guide and here are some
miscellaneous comments:
- Introduction and all other sections should mention and consider CCID-4.
- Introduction: also some current TCP-based applications could switch to
DCCP.
- Intro: there should be a ~1 page intro to DCCP, it wouldn't be good to
force the potential reader to first read through tens and tens of pages
about DCCP and then check the user guide - it should be the other way
around: the user guide is the sales pitch for DCCP. :)
- Intro and elsewhere: also certain monitoring and sensor applications
would be candidate users of DCCP.
- I would add some clear discussion, e.g. a new subsection 1.2 about the
benefits of using DCCP, after 1.1.
- S2.2, 1st para: are there any examples of actual media that can do
this switching bw. two encoding rates?
- S2.6, p9, 2nd to last bullet: what if you want to be bad, and lower
the packet sending rate but increase the packet size? Would that work?
- S2.7.2, p11, 2nd para: I guess in certain cases, and up to a certain
point this comment is valid, but not always and everywhere?
- S2.7.2, p11: why not use TCP for the pre-recorded 1-way media, like
youtube, doesn't that go over TCP? Okey, you could argue that TCP is a
bad idea for even 1-way streaming, but still. (Just argued about this
with a colleague on the air plane while writing this review ;).
- S2.9.1, p14, 3rd para: I wouldn't know how to implement the padding
you propose here. It would be nice to get some more text in here.
(- S2.9.4, p17: I had a student do a nice msc. thesis on comparing
different CCIDs for VoIP and the results were somewhat surprising. We
never got to write a paper about the experiments, but I'll try to look
back and find the thesis.)
- S2.9.4, p18 1st para: here you actually point out a very important
issue, and a clear sales pitch for DCCP(!): I'd rather choose myself
which packets will be discarded rather than send blindly and loose
random packets. So DCCP let's in certain application use cases the
sender to choose by itself (prioritize a priori) what to (try to) send
to the receiver, and what to voluntarily drop.
- S3, p 19, 2nd para (before 3.1): this is actually a good point, DCCP
would let the application probe for the available capacity dynamically,
and not force the user to set some update rate. (I remember this
parameter way back when I had the chance to play FPS games on the net
and optimizing client side parameters was an art form ;).
- S4.2, p22: I guess the mobility extensions have been dropped, right?
- S4.3, p22, 1st para: was this partial checksum still experimental,
can't recall...
- S5, p24, 2nd para: talks about the move functionality...
- Should there be a section at the end about API issues? I liked
Damon's original version partly because of the API discussion (but I
like your version, too, Tom, don't worry ;).
- I would add a summary at the end and highlight the pros and cons of
DCCP.
- References need to be updated. ;)
Hope this helps. I can do some parts of these updates to the draft,
provided people feel my comments are useful.
cheers,
Jukka
