[aqm] codel spelling nits

"Fred Baker (fred)" <fred@cisco.com> Thu, 02 April 2015 03:34 UTC

Return-Path: <fred@cisco.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324331A0378 for <aqm@ietfa.amsl.com>; Wed, 1 Apr 2015 20:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -112.612
X-Spam-Level:
X-Spam-Status: No, score=-112.612 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04iMVRU_8o8s for <aqm@ietfa.amsl.com>; Wed, 1 Apr 2015 20:34:16 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7671B2A0F for <aqm@ietf.org>; Wed, 1 Apr 2015 20:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9015; q=dns/txt; s=iport; t=1427945653; x=1429155253; h=from:to:cc:subject:date:message-id:mime-version; bh=38dZzwCMg9Xr5M5tG97kIJtfXZoMQibkVmwuLJHg7wg=; b=lDkAQOLd8+MWVs+2LDaS34FTNW3HKwIveZzaw9cEabcYJ3/N2lJC75uv MKiBvZCHFqKLJQlGe4rDUrlvo8/DZHyBWy/MJyS5lJCAP3VX7YBo9WHat wTvx5riyK7HprxNPWL9wXjVeNci9PbGGGndYRXWQoXWrL5zapvSCwYDl6 0=;
X-Files: signature.asc : 487
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DmBQDEtxxV/5xdJa1cgwhSXQSDEL9+gk+Fc4FMTAEBAQEBAX6EJSNWEgFKAjQfCAQOE4ghDbRemCwBAQEBAQEBAQEBAQEBAQEBAQEBGYoqhRUKBwECT4JvL4EWBZBkgWyBMlSGBJRBIoF/H4FQgXEJFwQefwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,507,1422921600"; d="asc'?scan'208";a="408568371"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 02 Apr 2015 03:34:13 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t323YC4Y027842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 03:34:12 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.67]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 22:34:12 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: "draft-ietf-aqm-codel.all@tools.ietf.org" <draft-ietf-aqm-codel.all@tools.ietf.org>
Thread-Topic: codel spelling nits
Thread-Index: AQHQbPXiqqnVGgRyH0eaSueIRNJeHw==
Date: Thu, 2 Apr 2015 03:34:11 +0000
Message-ID: <5F53F60C-8374-4A38-9D68-25647ED8428F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.117]
Content-Type: multipart/signed; boundary="Apple-Mail=_1178BEA6-4B98-43AB-97B1-DDD58C8F16D6"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/6TxkrVRoMKCPlqegLXas-Yz_08I>
Cc: "aqm@ietf.org list" <aqm@ietf.org>
Subject: [aqm] codel spelling nits
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2015 03:34:18 -0000

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/ .