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

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

 




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




[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