Many thanks,
Reviews are always welcome, and you raise some good issues that we shall
address in the next rev. Please see replies below,
Gorry
Vincent Roca wrote:
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.
Oh, I see. Yes the application should request a rate *based* on the
media rate, but accounting for packet overheads. For small packet sizes
the overhead can indeed be non-trivial, and the rate should be larger by
a factor that accounts for packet header size (e.g. IP, DCCP, and RTP
headers).
I suggest:
"For example, during the initial connection, a host may request a
Quick-Start Rate equal to the media rate of the application,
appropriately increased to account for the size of packet headers."
** 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.
Well spotted. All this can and should be said. We will ensure the
language is applicable to both versions of IP.
** 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.
Since the option is sent with a DCCP packet, the DCCP protocol provides
the loss detection.
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...
I think the receiver should respond to each request, but the sender
needs to refrain from sending a retransmission, when it retransmits a
DCCP packet that originaly carried the IP QS Option.
** 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.
I see, but recall that QS is not a reservation protocol, although it
does declare a chosen rate. So, an endpoint using QS may continue to
send using whatver capacity it already has.
Put a differemt way, a router can decline or lower the QS rate
using whatever algorithm the router chooses to assess the available
(unused capacity). It is not required to track individual flow rates, so
the router may well not know (or care) which source is consuming its
capacity - hence it only reports on the availability of new capacity,
and therefore reducing the rate suggests the router may be near
congestion, and so using a lower rate may be OK. We do not seek precise
resource sharing, just to know if its safe to start faster than usual.
** 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.
QS Packets are specially noted data packets sent for 1 RTT that enable
the path capacity to be validated. I think Sally's change to Fig. 2
helps explain this.
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.
Done, both 3.1.4 and 3.2.4 now have the same style of title.
** 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..."
Done.
** 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?
I created a section 2.1 for this purpose.
** 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...
Excessive use of the Quick-Start mechanism is undesirable. This document
defines an enhancement to RFC4782 to update the use of Quick-Start after
a DCCP flow has started, by introducing the concept of the Quick-Start
Interval. The Quick-Start Interval specifies a period of time during
which a Quick-Start Request SHOULD NOT be sent. The Quick-Start Interval
is measured from the time of tranmission of the previous Quick-Start
Request (section 2.1). The Quick-Start Interval MAY be overidden as a
result of a network path change (section 2.7).
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..."
We changed this to:
The initial Quick-Start Interval was chosen so that it is sufficiently
large to prevent excessive router processing over typical Internet paths.
** 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.
Yes good idea.
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
...
Much better, I think this organisation is a good improvement.
** 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, ..."
Done.
** There are two 2.8 sections!
Fixed.
** 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.
We will define all of them.
Thanks again,
Gorry
