Hello Gorry and Arjuna,
Here are a few comments, after reading draft-ietf-dccp-quickstart-02.
Please take into account that this is a review from somebody who
didn't read the DCCP or RFC4782 documents before ;-)
Regards,
Vincent.
Main comments:
---------------------
** 2.1 Sending a Quick-Start Request for a DCCP flow:
It is said:
"In contrast to most TCP applications, many DCCP applications have
the notion of a natural media rate that they wish to achieve. For
example, during the initial connection, a host may request a Quick-
Start Rate equal to the media rate of the application."
I understand that only a coarse grain target rate can be provided,
however I think that overlooking the packetisation, DCCP, and IPv4/v6
overheads is dangerous.
** 2.3 Receiving a Quick-Start Request for a DCCP flow:
It is said:
"...along with the value in the IP TTL field,..."
Well, this is only valid with IPv4. Will the Hop Limit field of IPv6
be used similarly? Similarly, you mention "IP option", which in IPv6
should be translated in IPv6 header extension.
BTW, IPv6 is mentioned only once in the whole document. It is not
clearly said that dccp-quickstart is meant to work on both versions
and text is ambiguous. An "Applicability" section in introduction to
clarify this aspect could help clarifying this once and for all.
** 2.3 Receiving a Quick-Start Request for a DCCP flow:
It is said:
"The Quick-Start Response MUST NOT be resent if it is lost in the
network [RFC4782]. "
How can the receiver detect that the QS Request has been lost? Of
course he shouldn't try to send extra copies of its QS Response to
add robustness.
Or do you mean that a receiver should not respond to QS Requests
from the same sender that arrive to closely? In theory the sender
should not do that, but who knows what may happen...
** 3.1.3 Using the Quick-Start Response with CCID-2:
It is said:
"If the approved Quick-Start rate is less than current sending rate,
the sender does not enter the Quick-Start Mode, and continues using
the procedure defined in CCID-2."
Conceptually, it is strange. We define a mechanism to identify an
appropriate initial sending rate, but we only trust it if the indication
is higher than the current rate, not if it is unfavourable. But maybe
the Congestion Control protocol is better aware of the situation than
the Quick Start scheme can be.
** 3.1.4 Quick-Start Validation Phase for CCID-2:
It is said:
"It leaves the Validation Phase on
receipt of an ACK that acknowledges the last Quick-Start Packet..."
Is it really the latest packet sent? The sender will probably continue
sending packets, and because of the extra delay (RTT) in getting the
ACK, this situation will rarely happen. Or maybe I misunderstood what
a "QS Packet" is.
Editorial aspects:
------------------
** titles 3.1.4 "Quick-Start Validation Phase for CCID-2" and 3.2.4
"The Quick-Start Validation Phase" are not coherent WRT one another.
** 1. Introduction:
It is said:
"If the Quick-Start Request is approved by all the routers along the
path..."
This is a little misleading WRT the previous paragraph. I suggest:
"If the Quick-Start Request is approved (possibly with a reduced rate)
by all the routers along the path..."
** 2. Quick-Start for DCCP:
it is strange to see the "MUST/MUST NOT/..." keywords clarification at
the beginning of this section. Why not using a dedicated
"1.1. Conventions and Terminology" section?
** 2.2 The Quick-Start Interval:
I'd prefer that the QS Interval be defined in a direct way, at the very
beginning of this section, e.g.:
The Quick-Start Interval is the minimum delay between two successive
transmissions of a Quick-Start Request. Indeed, an excessive use of
the Quick-Start mechanism is undesirable...
Later in this section (top of page 7) it is said:
"This value was chosen so that it is sufficiently ..."
This is an error: "These values were chosen..."
** Whole section 2.
Globally, I'm not satisfied with the way section 2 is currently
organized, namely:
section 2.1 is "Sending a QS Request"
section 2.2 is "The Quick-Start Interval"
section 2.3 is "Receiving a QS Request"
section 2.4 is "Receiving a QS Response"
section 2.5 is "Quick-Start Validation Phase"
I suggest that 2.2 (QS Interval) be a sub section of 2.1.
I also suggest that section 2.4 immediately clarifies the fact
that two states will be used after receiving the QS Response.
For instance:
2.4 Receiving a QS Response
Reception of a Quick-Start Response packet results in the sender
(1) entering the Quick-Start Mode and then (2) the QS Validation
Phase. The two states will last for a maximum of 3 RTTs.
2.4.1 The Quick-Start Mode
2.4.2 The Quick-Start Validation Phase
...
** 2.8 Interactions with Mobility and Signalled Path Changes:
It is said:
"In networks were there are expected to be large numbers of
senders impacted by the same signal, ..."
I'd rather say:
"In networks were a large number of senders may potentially be
impacted by the same signal, ..."
** There are two 2.8 sections!
** 3.2.5 Reported loss while using Quick-Start
This section defines the meaning of some of the variables that appear
in the formula, but not all of them (e.g., X_calc, s, t_mbi). But I
should probably give a look at RFC4342 first.
