Re: Review of draft-ietf-dccp-quickstart-00.txt

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

 




We 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
>
>

[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