Hi,
On May 11, 2009, at 16:21, ext Phelan, Tom wrote:
This is to announce the start of working group last call for
draft-ietf-dccp-quickstart-03.txt. Please send comments to the list
or
directly to me and/or the authors.
I think the draft looks very good. Some minor comments below, still in
the working group attendee role.
Section 1, para 5:
"It answers some of the issues that were raised..." => "This document
answers some of the issues that were raised..."
Location of Terminology section at 2.1: I think it would be more
logical to have this as subsection of section 1, or a separate top-
level section 2, because it concerns also other parts of the document
than just section 2.
Section 2.2.1, para 2:
Quick-Start Interval is initialized to 6 seconds. Hard-wired constants
are always difficult, but I understand that something needs to be
selected for initialization. How about specifying a variable such as
"Initial_QSI" and say that Initial_QSI SHOULD be set to 6 seconds.
This might then hint that later research may (or may not) find other
ways of determining this variable. The 6-second constant is appearing
in many places, so this would need to be replaced in all of those, if
you agree.
Should QSPrev_Interval be set each time after setting the new Quick-
Start Interval? It would be good to say this for completeness.
Section 2.2.1, last para:
"Whenever a Quick-Start Request is approved, the Quick-Start Interval
and the previous Quick-Start interval are reset" -- it might be good
to clarify if this means both QS request being fully approved and
partially approved.
Section 2.3.1, last para:
"Bytes 5-8 of the DCCP option contain the 30-bit Quick-Start Nonce
and a two-bit Reserved field." -- again, for completeness, there
could be few words referring to RFC4782, as done in the previous field
descriptions
(there is a misplaced underline in the end of para 2 in section 2.4.2)
It would be good to say something about QS Approve already in Section
2.4, because it is shown in Fig. 2. The process of sending QS Approve
is same for all CCIDs, so it would be easy to explain it here, too.
Section 2.4.2, last para:
"no packets were lost or marked since that time" => "no packets were
lost or ECN-marked since that time"
Section 2.7 uses the 6-second constant in few places. If you agree
that a named constant/variable should be used insted, it should be
used here, too.
Section 3.2.5. title: "Reported loss during Quick-Start Mode or
Validation Phase" => "Reported loss or congestion during Quick-Start
Mode or Validation Phase" (indent of section title is a little off, too)
Section 3.3.3 on using QS Response with CCID-4 says that procedure is
same as for CCID-3, with the additional RFC 4828 rules. One additional
rule in RFC 4828 is about taking packet headers into account [ X := X
* s_true / (s_true + H) ]. Setting QS_sendrate at Sec. 3.2.3 already
includes packet headers. Should the text make a point here that the
header adjustment doesn't need to be done twice (which might be an
easy, though not major bug to make here)?
That's all, then it is fine by me to be moved forward.
- Pasi
