|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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..."
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.
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.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.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 Nonceand 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)
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"
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)
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 onlywhen 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]."
We also changed "CCID-x" to "CCID x" throughout, to mtach other DCCP documents.That's all, then it is fine by me to be moved forward. - Pasi
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