Subject: draft-ietf-tsvwg-byte-pkt-congest -04 (second review)

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 23 Jul 2011 20:04:26 +0100

I've read this draft again, and have the following additional comments 
(some of which overlap the comments I sent on 29/03/2011, please can you 
revise the I-D and issue a revision -05 that includes your responses to 
these sets of comments and any others that you have received.

best wishes,

Gorry

NiTs:

" Fortunately all
    the RED implementers who responded to our survey (Section 4.2.4) have
    not followed the earlier advice to use byte-mode drop, so the
    consensus this memo argues for seems to already exist in
    implementations."
- I mentioned before that the survey was not performed by the IETF, and 
therefore this should be rephrased so that it can't be interpreted as 
IETF thought. It could for instance be sufficient to say something like 
  "A survey described in section 4.2.4 concluded..."
- It was suggested at the IETF TSVWG meeting in Prague that the survey 
could be placed in an appendix to clarify that this was a welcome 
contribution from the authors, rather than an IETF-lead activity.

Style: I'd personally prefer "most TCP implementations" to "most TCPs"

"But, as we design new
    congestion controls, we should build in scaling with packet size
    rather than assuming we should follow TCP's example."

- This seems like a "hidden" recommendation. I assume here this is meant 
to be a statement from the IETF TSVWG, so could the document say that 
the current recommendation is ...

Section 2,1 Corollaries - first in list doe snot have quotes, the second 
does. Please clarify the term "admin";-)

Allowance for packet
    size is only appropriate when the transport responds to congestion
                             ^
- is it better to insert "the time" before when, so we can see that this 
does not mean a type of transport that responds (all should).

"it is strongly RECOMMENDED that it SHOULD"
- this is an inappropriate form of wording, I think the IETF consensus 
is that "vendors SHOULD".

"ever, our survey of"
        ^^^
- again, recommend the editors change the wording to directly refer to 
the survey in section XXX.

" it seems we can deprecate byte-mode drop"
- "it is expected that byte mode drop can be depecrated ..."

"as proportionate to the size in octets of the missing or marked
    packet."
- could be useful to add "(bytes)" given that the document speaks a lot 
about bytes v. packets.

Section 3 reads:
"   In this section, we evaluate the topic of packet vs. byte based
    congestion notifications and motivate the recommendations given in
    this document."
- I think the section is informative and *ALL* the recommendations are 
in section 2, if this is correct, it would be really helpful to the 
reader to be told this.

" No matter how convenient it is, we SHOULD
    NOT hack the network solely to allow for omissions from the design of
    one transport protocol, even if it is as predominant as TCP."

- This doesn't seem to be a standard-stack IETF recommendation. Is the 
capitilisation correct? To whom is the advice directed to?

"the bit rate the RED queue aims to
    pass to the line will be 750Kbit the bit rate the RED queue aims to
    pass to the line will be 750Kbit for the flow of larger packet but
    990Kbit"
- Is this a volume - Kbit or is this a rate - per second?

4.1.2

"   because interference increases with the rate at which bits are"
- not quite, the effect of interference and/or noise is larger as the 
rate of transmission increases... The actual interference (if any) does 
not change.

"Turning to our more formal survey (Table 2),"
- should probably be rephrased.

" We have established
    that Linux does not implement RED with packet size drop bias,
    although we have not investigated a wider range of open source code."
" This claim seems hard to substantiate, if you refer to a specific 
release, or say at the time of writing that your survey showed..., it 
seems hard to make conclusive claims in this space.

"Finally, we repeat that RED's byte mode drop SHOULD be disabled, but
    active queue management such as RED SHOULD be enabled wherever
    possible"
- This repetition of the standards language at the end of section 4 
seems necessary, the document could simply have referred back to section 
2 for the RFC2119 text.

"   (BT) has widely deployed RED, but many tail-drop queues are there are
    bound to still exist, particularly in access network equipment and "
- It seems like too many "are"s.

"security and policability."
               ^^^^^^^^^^^^
- is this the intended word?