Re: Comments on the user guide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux