Pasi Sarolahti wrote:
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..."
Change made
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.
Change made, this also required renumbering of sections.
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.
So, we replaced it by a constant declaration. We also added warnings
that teher is a MINIMUM value, and that QS routers could (perhaps) in
future police this.
Should QSPrev_Interval be set each time after setting the new
Quick-Start Interval? It would be good to say this for completeness.
Yes, but we then looked at this in detail, and decided the final
algorithm could avoid this extra confusing variable. The text was
updated to this effect (no change in intended behaviour).
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.
We think partially approved is OK, and have changed the text to say so.
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
Done.
(there is a misplaced underline in the end of para 2 in section 2.4.2)
This does not seem to be in our current source file.
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.
Added one small part on this, and referenced the QS RFC.
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"
Done.
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.
Done.
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)
Updated, this is now longer than I would have liked, but clear.
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)?
Yes -- that was a very good find! -- We shouldn't do this twice.
CCID-4 does the account of packet headers only
when it uses the throughput equation. If it was in slow-start it
doesn't. Whereas QS for CCID-4 specifies to use the packet header
accounting at all times.
We looked at various ways to change this, and finally concluded a
statement to this effect is best, rather than some complicated language.
Does the revised text in 3.3.3 seem OK:
"CCID 4 [RFC4828] specifies that the allowed transmit rate derived from
the TCP throughput equation is reduced by a factor that accounts for
packet header size.
A CCID 4 sender does not need to account for headers a second time when
translating the approved Quick-Start rate into an allowed sending rate
(as described in section 5 of [ID.CCID4]."
That's all, then it is fine by me to be moved forward.
- Pasi
We also changed "CCID-x" to "CCID x" throughout, to mtach other DCCP
documents.
Finally, in CCID-3/4. we note that if the feedback also reported loss
the sender should not enter the QS mode.
Two equations had minimum terms that could never occur in actual
running, we removed these (see change log). The was no change in
intended behaviour.
These changes will be reflected in rev -04, which we will publish now...
Gorry
