Subject: Additional comments on draft-ietf-tsvwg-byte-pkt-congest-04 (mostly editorial)

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 28 Mar 2011 15:56:48 +0200

I enclose additional (mostly editorial) comments of the above draft.

S 1 para 1
/long term. But it also/long term. It also/

S 1 para 2
- thus concludes: /deployments we have already/
- this could be read as to refer to networks operated by the authors or 
IETF community, a better choice is /existing deployments/.

p6
/problems of one specific transport, as byte-mode variant of RED was 
designed to do/problems of one specific transport./
- This point us covered elsewhere.

p6
/The primary purpose of this memo is to build a definitive consensus
    against deliberate preferential treatment for small packets in AQM
    algorithms and to record this advice within the RFC series./
- This may have been true of the draft, would you consider rewording 
this, e.g.:
/This memo documents a consensus
    against deliberate preferential treatment for small packets in AQM
    algorithms./

S 1.1
- Please expand /RED/ when defining the term.

S 2.2
- This section concludes by a one para reference to the review. This 
seemed an unnecessary para. Please consider if you can simply point to 
this section rather than summarising the results and reiterating points 
noted elsewhere. e.g.

/   The byte mode packet drop variant of RED was recommended in the past
    (see Section 4.2.1 for how thinking evolved).  However, our survey of
    84 vendors across the industry (Section 4.2.5) has found that none of
    the 19% who responded have implemented byte mode drop in RED.  Given
    there appears to be little, if any, installed base it seems we can
    deprecate byte-mode drop in RED with little, if any, incremental
    deployment impact./
    A survey [XREF] showed that there appears to be little, if any,
    installed base of byte-mode drop using RED. This suggests that
    deprecate byte-mode drop will have little, if any, incremental
    deployment impact./

S 3.1
- This section discusses interpretation of loss. RFC 5348's 
interpretation seems different to that discussed here - where congestion 
is characterised by a Loss Event Rate (p). Is it worth saying a few 
words also about this?

S 3.1
This section introduces a new term that I don't feel happy about: 
"Congestion excursion"
- Is there an alternative term that could be used, I see section 1.1 
defines the term "Congestion Notification" to cover the concept of 
indicating congestion to a transport. I strongly suggest the document 
sticks to this term.

S 4
- The intro to this section appears to review/repeat other material. 
Could the set of paragraphs be removed? - If not please rework these 
more concisely and remove the reference to the "paper" - or state what 
this is intended to refer to.

S 4.1.1
- para 1, first sentence is long and hard to read. please rephrase, and 
please use alternate words instead of: /is fairly well understood these 
days/

S 4.1.2
- This makes a conclusion for all wireless spectrum, which is not true 
for all cases and is probably a function of the design of the physical 
layer and medium access method:

/ For instance,
    wireless spectrum is bit-congestible (for a given coding scheme), /
-is it possible to say, in /most cases/ or /is usely regarded as/

S 4.2.1
/But it went on to give advice we now disagree with./
- Who is the we… tsvwg?
- Is it possible to instead say the offered advice is updated by this memo.

S.4.2.1
/But it is not consistent with the
    present recommendations of Section 2./
- Is it possible to instead say this memo makes different 
recommendations in section 2.

S 4.2.1
   /No-one seems to have pointed out that this changed algorithm
    can often lead to drop probabilities of greater than 1 (which should
    ring alarm bells hinting that there's a mistake in the theory
    somewhere)./
- Is it please possible to rephrase this?

S 4.2.2
/   The above proposals to alter the network equipment to bias towards
    smaller packets have largely carried on outside the IETF process
    (unless one counts a reference in an informational RFC to an archived
    email!).  /
- I'd recommend that you delete the part in parenthesis - If not, you 
need to justify this and explain fully the context.

S 4.2.2
- final para of section needs to be rewritten. This refers to PCN as a 
proposal. This is now an IETF work item documents have been produced 
defining marking algorithms.

S 4.2.3
/Although no proposals exist as far as we know/
- Avoid "we", e.g. /Although there are no known proposals.../

S 4.2.3
/are there are bound to still exist/
- please rephrase.

S 5.1
/we believe the recommended position is now inarguably clear ---/
- This para needs to be rewritten. Once published this memo will specify 
this, it will not then be a matter of argument.

S 5.1
/  The sample of returns from our vendor survey Section 4.2.4 suggest
    that byte-mode packet drop seems not to be implemented at all let
    alone deployed, or if it is, it is likely to be very sparse.
    Therefore, we do not really need a migration strategy from all but
    nothing to nothing./
- This should be said simpler, or preferably removed. It's not essential 
to restate this here.

S6
/This draft/This memo/

S6
/  Of course, if
    transports really want to make the greatest gains, they don't have to
    respond to congestion anyway.  But we don't want applications that
    are trying to behave to discover that they can go faster by using
    smaller packets. /
- I think this could be misread, could we remove the first sentence or both?

S7
- I'm not sure the document needs a conclusion section. There is an 
abstract and a clear summary of recommendations. The conclusion does not 
appear to intend to further add to these. I'd rather keep all the 
recommendations in section 2.
- If a revised conclusion seems necessary, please omit /strongly/ from 
the wording.
( The current conclusion specifically delegates an issue to ICCRG on the 
final line. I don't think this is strictly necessary. A better phrase 
may be /ICCRG is currently chartered to work on these issues./)

Refs:
/RFC4348/ was obsoleted by /RFC5348/
- Is there a specific need to cite the obsolete spec.?

---

From: Jukka Manner <[email-masked]>
Date: Tue, 29 Mar 2011 22:53:28 +0300

Hi Gorry,

Thank you for a detailed review. I'll fix those together with Bob.

regards,
Jukka

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+470 22481
Aalto University                  Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+470 22474
and Networking (Comnet)           Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto   E-mail: [email-masked]
Finland                           WWW:    www.comnet.tkk.fi