Hi Jukka, Thanks for taking this on. I agree with all of your suggestions, but I'm having trouble syncing up with your questions. What version of the draft are you using? I'm looking at version -03 at http://www.phelan-4.com/dccp/draft-ietf-dccp-user-guide-03.txt and page and section numbers don't seem to match up. Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Jukka Manner > Sent: Wednesday, October 07, 2009 5:42 PM > To: DCCP > Subject: Comments on the user guide > > 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
