Tom - could you forward this and the previous mails to the dccp list
(the IETF mail server is bouncing me due to a local DNS problem, which
has just been fixed but may taked a week to reach all DNS caches!)
Gorry
---
Michael, see some new suggestions in-line from Arjuna and me:
Michael Scharf wrote:
Some minor comments inline
On Wed, 20 Aug 2008 at 17:01:10, Gorry Fairhurst wrote:
* 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.,
Wouldn't it be worth to just mention this rough granularity somewhere
in the text? I mean, the rate to request for is an important aspect
for a user of Quick-Start, and some guidance on its choice would be
nice - even if the message is finally: "don't worry too much about
it".
OLD:
For
example, during the initial connection, a host may request a Quick-
Start rate equal to the media rate of the application.
Is suggest adding a comment:
(Note that Quick-Start only provides a course-grain indication of the
desired rate that is expected to be sent in the next RTT.)
* 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.
Yes, but, as far as I understand it, these are two different aspects.
Section 3.1.1 defines an upper bound for what the sender is allowed to
_request_ for, whereas section 3.2.1 is about what the sender is
allowed to _send_. The quoted text from Section 3.2.1 does not speak
about requests. Maybe I miss the point, but then at least the wording
of these sections should be improved.
The section is meant to be the corresponding one for CCID-3, the para says:
OLD:
The requested rate specified in a Quick-Start Request must consider
the current loss event rate (if any), either from calculation at the
sender or from feedback received from the receiver. CCID-3 requires
that a sender must not send more than the upper bound dictated by
the loss event rate. This rate offers a safe response in the
presence of expected congestion.
NEW:
The requested rate specified in a Quick-Start Request MUST NOT exceed
the TFRC-controlled send rate [RFC4342] when this is bounded by the
current loss event rate (if any), either from calculation at the sender
or from feedback received from the receiver. CCID-3 considers this rate
is a safe response in the presence of expected congestion.
* 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/
It took me some time to understand that a sender probably needs to
implement an additional timer because of this paragraph, and that 1.5
RTT is its initial value. For an implementor of the spec, this might
be a quite important detail, and my comment is just about making this
piece of information a little bit more explicit.
- I think I see now.... We should add something exactly on this, I suggest:
OLD:
The sender SHOULD exit the Quick-Start Validation Phase on receipt
of feedback that acknowledges all packets sent in the Quick-Start
Mode (i.e. all Quick-Start Packets). It MUST exit this phase on
expiry of the Quick-Start validation time. The Quick-Start
Validation Phase is limited to the Quick-Start Validation Time (a
maximum of 1.5 RTTs).
NEW:
The sender SHOULD exit the Quick-Start Validation Phase on receipt
of feedback that acknowledges all packets sent in the Quick-Start
Mode (i.e. all Quick-Start Packets). The duration of the Quick-Start
Validation Phase is limited to the Quick-Start Validation Time (a
maximum of 1.5 RTTs). Implementations may set a timer (initialised
to the Quick-Start Validation Time) to detect the end of this phase.
Michael
