Subject: [tsvwg] Comments on draft-ietf-tsvwg-byte-pkt-congest-01.txt (Oct 2009)

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 26 Oct 2009 11:52:46 +0000

Revived I-D: draft-ietf-tsvwg-byte-pkt-congest-01.txt

Bob,

I've been reading the recently revived draft. We seemed to have good 
consensus to update the recommendations for using byte and packet mode 
in the network for congestion notification.

I thought I had previously sent some top-level comments, but alas these 
seem to have gone amiss, so I'll combine my notes with a review of the 
current rev. This makes for a longer than normal set of comments, sorry. 
As usual, I have split top-level and editorial comments.

1) My summary is that most of the text is a summary review of the 
current state of the art. The aim is to clarify the implications of 
congestion reporting and then to make appropriate conditions for future 
work. Has the text been published in a technical paper?

2) There are important conclusions at the end, these are simple (as 
presented in an earlier TSVWG meeting) - but the current standards 
section seem to need some additional work to get the standards language 
correct and make sure they represent IETF consensus and not just the 
author's viewpoint.

3) There seems to be a need for some additional work to provide concrete 
recommendations on: "How to handle any legacy of AQM with byte-mode drop 
already deployed;" (section 7.1).

4) The text seems to use both "byte" and "bits" as measures of capacity, 
it could be better to just use bytes, perhaps, to be consistent with the 
language of RED.

5) Throughout the document there is reference to a survey. Is this 
survey performed outside the IETF? Does the WG know what was asked and 
how are we to understand the returns? I think we need to see the best 
way to include this survey detail.

6) I personally found the use of "resource" as an abstraction that made 
it harder to reader - rather than easier. (I wondered whether this was 
more suited to a scientific paper than a standards update?).

7) I think it could be nice to see a short section on middlebox/firewall 
implications. To me, the document would have been clearer if the core of 
the document focussed on AQM/RED in routers and then explicitly had a 
section for middleboxes, and whatever else that addresses the 
implications in these cases. I don't anticipate middlebox and 
applications developers parsing through the whole document to see what 
they should do.

8) I'll review the appendices and security considerations in the next 
revision.

9) Overall, I found the body of the current text to be quite hard to 
parse and many of my detailed comments relate to these aspects.  I 
suggest this still needs editorial work to distill this to the point at 
which it would be ready to get detailed comments on the recommendations 
from the WG.

Best wishes,

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 26 Oct 2009 11:57:22 +0000

Revived draft: draft-ietf-tsvwg-byte-pkt-congest-01.txt

Bob,

I've been reading the recently revived draft and sent some general 
comments and questions. This particular email contains some detailed 
comments on the current draft text, and in particular on the structure 
and clarity, suggesting that some reorganisation and reduction may 
clarify the IETF implications. I hope these are helpful in preparing 
your next revision of the draft.

Best wishes

Gorry

-----------------------------------------------------------------------------
Abstract:

- I found this hard to parse:
"Reducing drop
    of small packets has some tempting advantages: i) it drops less
    control packets, which tend to be small and ii) it makes TCP's bit-
    rate less dependent on packet size."
- Please could this be phrased easier for reading...
"There are advantages in a network dropping..." etc.
---
- This seems rather awkward and philosophical:
"However, there are ways of
    addressing these issues at the transport layer, rather than reverse
    engineering network forwarding to fix specific transport problems."
_ can you rephrase to say something like: "equivalent" methods at the 
transport layer that ...
---
- I agree, but this could also be clearer, because we don't say what 
fewer means:
"should not be used to drop fewer small packets"
- Are you saying should drop packets as an indication of congestion, and 
should not drop a higher proportion...
- That is recommend not to implement deliberate preferential treatment 
for small packets in AQM algorithms
---
I think it is traditional to say the RFC number that is to be updated if 
this is a specific update, but you can cite a reference in the abstract.
-----------------------------------------------------------------------------
Introduction:
---
- Could you simplify the start of this sentence?
"   Note that the byte vs. packet dilemma concerns congestion.."
---
- Resource here is normally router in an internet context?
"load on a resource depends"
---
- Buffers
"Some machine architectures.."
- I agree buffer memory may be managed in either way. I didn't see the 
reason for the word "machine" - could we say router? in this example?
---
   "Note that information is generally processed or transmitted with a
    minimum granularity greater than a bit (e.g. octets).  The
    appropriate granularity for the resource in question SHOULD be used,
    but for the sake of brevity we will talk in terms of bytes in this
    memo."
- Do you differentiate between bytes and octets here?
- This paragraph starts as a note and ends as a SHOULD. It seem odd to 
make a standards statement in the introduction, and to me the 
requirement is not clear.
----
     " Measuring congestion  When the congested resource decides locally how
       to measure how congested it is.  (Should the queue be measured in
       bytes or packets?);"
"In RED, whether to use packets or bytes when measuring queues"
"RED can measure the resource queue in units of bytes (byte-mode) or 
packets (packet-mode)"?

Can you think about whether you could simplify these phrases perhaps, to 
make it easier to read?
e.g. something like... Measuring congestion: The process by which a 
resource measures congestion in units of bytes or packets.
---
"The controversy is mainly around "
- I missed the controversy - is this still the dilemma, which I did not 
understand, or is it the design choice of what to signal? Consider 
simplifying English?
---
There is a list of motivations, please omit points, if not needed, e.g.:
(3) seems a repetition of (2)
(4) doesn't seem a strong actual reason to do this (could omit this?)
(5) Is rather awkwardly written, but seems valid to me.
(6) This is rather long, and the note does not seem clear to me.
----
"This memo is initially concerned with how we should correctly scale
    congestion control functions"
- This paragraph could be condensed and would be more readable.
---
- The final paragraph appears to use a paper structure, rather than 
appropriate to an RFC?
---
Section 2:
- This section seems verbose - Is it possible to reduce the length and 
also to tighten and simplify the language?
---
Section 3:
- I wonder if this section is needed?
- E/L is defined but not used.
- Can we omit this section completely?
---
Section 4:
- I'm not sure this discussion is needed in the body of the RFC.
4.1.1 para 2 could be made easier to read.
---
Section 5:
- I do not see the need for the current description here. Discussions on 
encoding are on-going within PCN, and I would rather not conflict with 
their charter. My own preference would be to drop this section, although 
you may wish to move some of this to the appendix to see if others wish 
to contribute on developing this?
---
Section 6:
- Please check the assertions, e.g.:
  " Any AQM
    ^^^
    algorithm on such a buffer will be oversensitive to high proportions
    of small packets, e.g. a DoS attack, and undersensitive to high
    proportions of large packets"
- I think there could be configurations that are not particularly 
sensitive, but I
could believe that AQM configurations may over estimate
---
- What is the guidance here:
   "But an operator can safely keep such a
    legacy buffer because any undersensitivity during unusual traffic
    ^^^^^^^^^^^^^
    mixes cannot lead to congestion collapse given the buffer will
    eventually revert to tail drop, discarding proportionately more large
    packets."
- What is a "legacy buffer", and are you saying such a buffer size 
distribution is safe in that it is unlikely to contribute to congestion 
collapse? - or something else?
---
- I'm not sure what this saying:
  " This may merely be an
    administrator-interface preference, not altering how the queue itself
    is measured but on some hardware it does actually change the way it
    measures its queue."
- I did not understand: Are you saying can determine the size of the 
allocated buffer, and on some platforms may also change the way the 
queue size is reported?
---
- Why is this implementation recommendation so strong:
   "Whether a resource is bit-congestible or packet-
    congestible is a property of the resource, so an admin SHOULD NOT
    ever need to, or be able to, configure the way a queue measures
    itself."
- I can think of cases where an upstream router directly feeds a layer 2 
interface that is bit-congestible, and other cases where it does not. 
Are you saying that the IETF should strongly discourage operators to 
allow me to set this?
---
- What does "fairly well understood" mean here - is there still some 
lack of consensus here that the IETF needs to ask about? I think we 
should change the language of this paragraph if the next sentence is true.
   "We believe the question of whether to measure queues in bytes or
    packets is fairly well understood these days. "
---
I found 6.2.1 and 6.2.2 (with the exception of the last para of 6.2.2 to 
be mainly a review of what others say, that could be OK,  but I think 
there are important lessons here.
- I wonder if the word "bias" in the section headings here, looks like 
an analysis, rather than justification for the later guidance.
- Encouraging the transport do the right thing seems a good goal.
- The earlier analogy to PMTUD could be useful?
---
6.2.3:
  " Although no proposals exist as far as we know, it would also be
    possible and perfectly valid to make control packets robust against
    drop by explicitly requesting a lower drop probability using their
    Diffserv code point [RFC2474] to request a scheduling class with
    lower drop."
- I wonder if this would also need an accompanying note that this could 
induce reordering between control and data packets?
---
6.2.3:
   " Although not brought to the IETF, a simple proposal from Wischik..."
- but if the WG chooses to highlight this, then we must also be careful 
to note that the increased level of control traffic could negatively 
impact some lower-layers, e.g. impacting dynamic bandwidth/channel 
assignment at layer 2.
---
6.2.4:
"A survey has been conducted of 84 vendors to assess how widely drop
    probability based on packet size has been implemented in RED."
If this is a WG draft, can we be sure that the interpretation here 
matches that of the WG. I'm a little worried whether the reported 
surveys leading to conclusions were conducted with visibility within the 
IETF or in some other process. What happened in this case?
- Para 3 of the conclusion follows this.
---
Section 7:
To me, this seems to be the work that the IETF needs to do.

    "We should also note that, strictly, packet-congestible resources are
    actually cycle-congestible because load also depends on the
    complexity of each look-up and whether the pattern of arrivals is
    amenable to caching or not."
- Is this always so? I'm not sure what this claims.

   "Further, this reminds us that any
    solution must not require a forwarding engine to use excessive
    processor cycles in order to decide how to say it has no spare
    processor cycles."
- Motherhood and apple pie?

  "The problem of signalling packet processing congestion is not
    pressing,"
- I'd agree in most cases for the general Internet, but I'd be hesitant to
make a claim for all network technologies. Do we need to be so general?

Section 8: Security - may need to be reviewed later.

Section 9: Conclusions
- Please remove strong - the IETF doesn't differentiate conclusions in 
this way.
- The current document says:
   "The strong conclusion is that AQM algorithms such as RED SHOULD NOT
    use byte-mode drop."
- To me this recommendation is to the Internet Area, please use 
packet-mode by default?
- Is this so, even if the network resource is specifically 
byte-congestible? i.e. are  in the specific case where the RED-queue 
being policed is byte-congestible, e.g. a low-speed link that is 
constrained by capacity, and not by forwarding rate.
---
- Is it possible that this is the same message that continues at the end 
of the second para?
   "But we SHOULD NOT hack the network
    layer to improve or fix certain transport protocols.  No matter how
    predominant a transport protocol is (even if it's TCP), trying to
    correct for its failings by biasing towards small packets in the
    network layer creates a perverse incentive to break down all flows
    from all transports into tiny segments."
---
- It currently says:
   "More generally, the Internet's congestion
    notification protocols (drop, ECN & PCN) SHOULD take account of
    packet size when the notification is read by the transport layer, NOT
    when it is written by the network layer."
- I think the SHOULD is directed at the transport area, that is we 
SHOULD design protocols that account for packet size.
- Could you please rephrase the second phrase with the "NOT"?
---
- It says:
   "This approach offers
    sufficient and correct congestion information for all known and
    future transport protocols"
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
- I may be persauded this is a safe basis for future transport protocol 
designs, but I'd be unhappy to say that it is sufficient for all 
yet-to-be-invented approaches. Please consider rephrasing.
---
Please consider if you could reorganize the text to provide a short 
section on middlebox/firewall implications. To me, the document would 
have been clearer if the core of the document focussed on AQM/RED in 
routers and then explicitly had a section for middleboxes, and whatever 
else that addresses the implications in these cases. I don't anticipate 
middlebox and applications developers parsing through the whole document 
to see what they should do.
---
I'll review the appendices and security considerations in the next revision.
---