The authors received the following helpful review comments from Michael
Scharf, as below. THANKS Michael!!!
Please see in-line our responses. We would appreciate any further
comments or questions people may have and then intend to produce a
revised document at the end of next week.
Best wishes,
Gorry and Arjuna
He wrote:
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.
We suggest to add this to the end of the introduction.
Rate-based protocols (e.g. TFRC [RFC-to-be-3448.bis], CCID-3 [RFC4342])
have a different feedback mechanism compared to TCP, where feedback may
be sent less frequently (e.g. once per RTT). In such cases, a sender
using Quick-Start needs to implement different mechanism to determine
whether the Quick-Start sending rate has been sustained by the network.
This is called the Quick-Start validation phase (Section 3.2.4).
In addition, this document defines two more general enhancements that
refine the use of Quick-Start after a flow has started (expected to be
more common in this environment). These are the Quick-Start Interval
(Section 2.2), and the reaction to mobility triggers (Section 2.7).
* Section 2.1: The term "natural media rate" is rather vague.
For VBR traffic, is it the average rate? Or the peak rate?
Good question, we intended to leave this open, but if you have
suggestions that would be interesting. Note though that the QS_rate is
rather course, and so this may not be a significant issue.,
* Section 2.2: IMHO it should be somewhere stated that this
mechanism goes beyond RFC 4782.
We suggest adding the following after the first sentence:
This document defines an enhancements to RFC4782 to update the use of
Quick-Start after a DCCP flow has started.
* Section 2.2: 64 seconds is not a multiple of 6 seconds...
True. But, there are cases where the Quick-Start Interval is also not a
multiple of 6 seconds (e.g. when 4RTT>6 secs).
* Section 2.2: s/the previous Quick-Start interval and QSPrev_Interval/
the Quick-Start interval and the QSPrev_Interval/
We shall update the document accordingly.
* 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 synchronization is indeed an issue and why it should
be avoided.
We will add this - based on the comments from Lars at the last IETF WG
meeting.
* 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?
In 3.2.1, last para, it says:
CCID-3 requires
that a sender must not send more than the upper bound dictated by
the loss event rate.
- I think this should be a MUST NOT.
* Section 3.1.3: The Parameter T in the equation is not introduced
(RTT?).
We will define it so.
* Section 3.1.4: According to my understanding, there is no
"Quick-Start Validation Phase" in CCID-2.
Correct, since we assume that a CCID-2 sender will return feedback at
least each other packet by default (i.e. TCP-like ACK-clocking, assuming
the default ACK-Ratio of 2).
To cater for more crazy cases, the current text says that after one RTT
the QS will be aborted if there is no feedback within one RTT. Now you
challenged this we think it may be wise to make this 1.5 RTTs to cater
for larger ACK Ratios, and would make performance closer to that for 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.
OK, agreed.
Here are some suggested edits:
OLD:
A sender in the Quick-Start Mode or Validation Phase that detects
congestion (e.g. receives a feedback packet that reports new packet
loss or a packet with a congestion marking), MUST immediately leave
the Quick-Start Mode or Validation Phase and enter the congestion
avoidance phase [RFC4341].
NEW:
A sender in the Quick-Start Mode that detects
congestion (e.g. receives a feedback packet that reports new packet
loss or a packet with a congestion marking), MUST immediately leave
the Quick-Start Mode and enter the congestion
avoidance phase, recalculating the cwnd as described in [RFC4341].
* Section 3.2.4: The third paragraph might state more clearly that
there is a parameter "Quick-Start Validation Time = 1.5 RTT".
Not sure what change is needed, but would like to also change:
s/Quick-Start validation time/Quick-Start Validation Time/
* 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.
Good idea, we will move here and delete this section.
I hope that these comments help...
Best regards
Michael
