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
