Re: WGLC for draft-ietf-dccp-quickstart-03.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux