Hi Michael, Thanks for the comments -- just what we need :-). Tom P. > -----Original Message----- > From: Michael Scharf [mailto:michael.scharf@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, August 11, 2008 2:32 PM > To: Gorry Fairhurst; Phelan, Tom > Cc: Arjuna Sathiaseelan > Subject: Review of draft-ietf-dccp-quickstart-00.txt > > Hi all, > > I've been asked to have a look at "draft-ietf-dccp-quickstart-00.txt" > and to provide feedback. But first, I'd like to state to two things > up-front: > > * I am quite familiar with Quick-Start TCP (we have running code for > the Linux ), but, unfortunately, I'm not a DCCP expert. Thus, this > might be a somewhat TCP-biased review. > > * I'm not subscribed to the dccp mailinglist. Therefore, any > questions should be CC'ed to me. Please feel free to forward this > e-mail to the WG mailing list if desired. > > > Summary: > > I've read the draft and think that it is a sound specification of > the Quick-Start mechanism for DCCP. Apparently, the functions are > similar to Quick-Start TCP as described in RFC 4782, and the draft > adequately complements RFC 4782. > > However, there are still a couple of minor issues (detailed below). > Some clarifications would help to improve the readibility of the > text. > > > Comments: > > * Overall document: There are some slight non-functional differences > in the behavior of Quick-Start as described in RFC 4782 and this > DCCP protocol specification. This includes e. g. the Quick-Start > Interval (Section 2.2), the Quick-Start validation phase (Section > Section 3.2.4), and the reaction to mobility triggers (Section > 2.7). It would make sense to add a short paragraph to Section 1 or > 2 that briefly introduces and motivates these changes compared to > TCP and RFC 4782. For instance, RFC 4782 does not mandate > Quick-Start TCP senders to adhere to the Quick-Start interval. > > * Section 2.1: The term "natural media rate" is rather vague. > For VBR traffic, is it the average rate? Or the peak rate? > > * Section 2.2: IMHO it should be somewhere stated that this > mechanism goes beyond RFC 4782. > > * Section 2.2: 64 seconds is not a multiple of 6 seconds... > > * Section 2.2: s/the previous Quick-Start interval and QSPrev_Interval/ > the Quick-Start interval and the QSPrev_Interval/ > > * Section 2.7: The motivation of the random period after a mobility > trigger is not entirely clear to me. An example might help to > illustrate why syncronization is indeed an issue and why it should > be avoided. > > * Section 3.1.1: "A Quick-Start Request that follows a loss or > congestion event MUST NOT request a Quick-Start rate that exceeds > the largest congestion window [...]": I've not found a > corresponding rule for CCID-3, and I am not aware of a similar > restriction for a Quick-Start request of a comparable TCP flow. Is > this specifically required by CCID-2? > > * Section 3.1.3: The Parameter T in the equation is not introduced > (RTT?). > > * Section 3.1.4: According to my understanding, there is no > "Quick-Start Validation Phase" in CCID-2. > > * Section 3.1.4: "[MUST] enter the congestion avoidance phase" does > not precisely describe the actions to be performed by the > sender. I would suggest to describe more explicitly if and how > cwnd must be modified. > > * Section 3.2.4: The third paragraph might state more clearly that > there is a parameter "Quick-Start Validation Time = 1.5 RTT". > > * Section 3.2.6: The figure could also be moved to the beginning of > Section 3.2.4, since it would help to illustrate the scope of the > "Quick-Start Validation Phase" that is introduced there. > > > I hope that these comments help... > > Best regards > > Michael
