[aqm] codel spelling nits

["Fred Baker (fred)" <[e-mail]>]

I’m in the process, as I volunteered to do, of reviewing the Codel draft. It is very well and readably written, so I don’t expect to have a lot to complain about. I do have three points, though.

One is a few spelling errors, noted in this email.

A second is the matter of marking and dropping. The world “drop” is used in one or another of its forms 120 times, and ECN marking twice, both times in passing. I’d like to understand better how ECN is handled, if only to have a statement that it is handled the same way as dropping.

The third is the definition of a “normal TCP session”, which is referred to a number of times but not nailed down that I have found other than that it appears to have a less than 100ms RTT. Later in the draft, it talks about accommodations for data center use, which tells me (consistent with our testing) that there is a lower bound below which is is less than optimal, and in our testing RTTs greater than 100 ms didn’t behave so well. The sweet spot might have been around 25 ms, with minor degradation at 50 ms, and more degradation at longer RTTs.

I’ll come back if I find more issues,

*** draft/draft-ietf-aqm-codel-00.txt	Fri Oct 24 08:58:40 2014
--- draft-ietf-aqm-codel-00.txt	Wed Apr  1 18:43:33 2015
***************
*** 104,111 ****
      5.1.  Data Types  . . . . . . . . . . . . . . . . . . . . . . .  18
      5.2.  Per-queue state (codel_queue_t instance variables)  . . .  19
      5.3.  Constants . . . . . . . . . . . . . . . . . . . . . . . .  19
!      5.4.  Enque routine . . . . . . . . . . . . . . . . . . . . . .  19
!      5.5.  Deque routine . . . . . . . . . . . . . . . . . . . . . .  19



--- 104,111 ----
      5.1.  Data Types  . . . . . . . . . . . . . . . . . . . . . . .  18
      5.2.  Per-queue state (codel_queue_t instance variables)  . . .  19
      5.3.  Constants . . . . . . . . . . . . . . . . . . . . . . . .  19
!      5.4.  Enqueue routine . . . . . . . . . . . . . . . . . . . . . .  19
!      5.5.  Dequeue routine . . . . . . . . . . . . . . . . . . . . . .  19



***************
*** 283,289 ****


    is much slower than the link that feeds it (say, a high-speed
!    ethernet link into a limited DSL uplink) a 20 packet buffer at the
    bottleneck might be necessary to temporarily hold the 20 packets in
    flight to keep the utilization high.  The burst of packets should
    drain completely (to 0 or 1 packets) within a round trip time and
--- 283,289 ----


    is much slower than the link that feeds it (say, a high-speed
!    Ethernet link into a limited DSL uplink) a 20 packet buffer at the
    bottleneck might be necessary to temporarily hold the 20 packets in
    flight to keep the utilization high.  The burst of packets should
    drain completely (to 0 or 1 packets) within a round trip time and
***************
*** 326,332 ****

    The use of queue length is further complicated in networks that are
    subject to both short and long term changes in available link rate
!    (as in wifi).  Link rate drops can result in a spike in queue length
    that should be ignored unless it persists.  The length metric is
    problematic when what we really want to control is the amount of
    excess delay packets experience due to a persistent or standing
--- 326,332 ----

    The use of queue length is further complicated in networks that are
    subject to both short and long term changes in available link rate
!    (as in WiFi).  Link rate drops can result in a spike in queue length
    that should be ignored unless it persists.  The length metric is
    problematic when what we really want to control is the amount of
    excess delay packets experience due to a persistent or standing
***************
*** 455,461 ****
    As Kleinrock observed, the best operating point, in terms of
    bandwidth / delay tradeoff, is the peak power point since points off
    the peak represent a higher cost (in delay) per unit of bandwidth.
!    The power vs. _f_ curve for any AIMD TCP is monotone decreasing.  But
    the curve is very flat for _f_ < 0.1 followed by a increasing
    curvature with a knee around .2 then a steep, almost linear fall off
    [TSV84] [VJTARG14].  Since the previous equation showed that goodput
--- 455,461 ----
    As Kleinrock observed, the best operating point, in terms of
    bandwidth / delay tradeoff, is the peak power point since points off
    the peak represent a higher cost (in delay) per unit of bandwidth.
!    The power vs. _f_ curve for any AIMD TCP is monotonically decreasing.  But
    the curve is very flat for _f_ < 0.1 followed by a increasing
    curvature with a knee around .2 then a steep, almost linear fall off
    [TSV84] [VJTARG14].  Since the previous equation showed that goodput
***************
*** 929,935 ****
    management as described here or to adapt its principles to other
    applications.

!    Implementors are strongly encouraged to also look at Eric Dumazet's
    Linux kernel version of CoDel - a well-written, well tested, real-
    world, C-based implementation.  As of this writing, it is at:

--- 929,935 ----
    management as described here or to adapt its principles to other
    applications.

!    Implementers are strongly encouraged to also look at Eric Dumazet's
    Linux kernel version of CoDel - a well-written, well tested, real-
    world, C-based implementation.  As of this writing, it is at:

***************
*** 999,1006 ****

    "packet_t*" is a pointer to a packet descriptor.  We assume it has a
    tstamp field capable of holding a time_t and that field is available
!    for use by CoDel (it will be set by the enque routine and used by the
!    deque routine).



--- 999,1006 ----

    "packet_t*" is a pointer to a packet descriptor.  We assume it has a
    tstamp field capable of holding a time_t and that field is available
!    for use by CoDel (it will be set by the enqueue routine and used by the
!    dequeue routine).



***************
*** 1033,1039 ****
    u_int maxpacket = 512; // Maximum packet size in bytes
                     // (should use interface MTU)

! 5.4.  Enque routine

    All the work of CoDel is done in the deque routine.  The only CoDel
    addition to enque is putting the current time in the packet's tstamp
--- 1033,1039 ----
    u_int maxpacket = 512; // Maximum packet size in bytes
                     // (should use interface MTU)

! 5.4.  Enqueue routine

    All the work of CoDel is done in the deque routine.  The only CoDel
    addition to enque is putting the current time in the packet's tstamp
***************
*** 1046,1052 ****
        queue_t::enque(pkt);
    }

! 5.5.  Deque routine

    This is the heart of CoDel.  There are two branches: In packet-
    dropping state (meaning that the queue-sojourn time has gone above
--- 1046,1052 ----
        queue_t::enque(pkt);
    }

! 5.5.  Dequeue routine

    This is the heart of CoDel.  There are two branches: In packet-
    dropping state (meaning that the queue-sojourn time has gone above
***************
*** 1260,1266 ****

    An experiment by Stanford graduate students successfully used the
    linux CoDel to duplicate our published simulation work on CoDel's
!    ability to following drastic link rate changes which can be found at:
    http://reproducingnetworkresearch.wordpress.com/2012/06/06/solving-
    bufferbloat-the-codel-way/ .

--- 1260,1266 ----

    An experiment by Stanford graduate students successfully used the
    linux CoDel to duplicate our published simulation work on CoDel's
!    ability to follow drastic link rate changes which can be found at:
    http://reproducingnetworkresearch.wordpress.com/2012/06/06/solving-
    bufferbloat-the-codel-way/ .