Re: [aqm] working group last call on CoDel drafts

"Bless, Roland (TM)" <roland.bless@kit.edu> Fri, 04 December 2015 10:16 UTC

To: aqm@ietf.org, Wesley Eddy <wes@mti-systems.com>
References: <565F11FD.3070405@mti-systems.com>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <566167EB.3060502@kit.edu>
Date: Fri, 04 Dec 2015 11:16:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <565F11FD.3070405@mti-systems.com>
Content-Type: multipart/alternative; boundary="------------030906070308060603040904"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/t7j0NamebotHz8qmj1dne5iDeIQ>
Subject: Re: [aqm] working group last call on CoDel drafts
Precedence: list

Dear all,

we believe that the Codel specification
https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ needs at least
one major clarification.

The following lines are present in the draft's pseudo-code, but are not
explained further anywhere in the document text, and moreover differ
from the Linux implementation [*], that the document also suggests as
reference implementation.

           // If min went above target close to when it last went
           // below, assume that the drop rate that controlled the
           // queue on the last cycle is a good starting point to
           // control it now. ('drop_next' will be at most 'interval'
           // later than the time of the last drop so 'now - drop_next'
           // is a good approximation of the time from the last drop
           // until now.)
*count_ = (count_ > 2 && now - drop_next_ < 8*interval_)? count_ - 2 : 1; *

This line makes sure, that when two dropping states are entered within a
short interval from each other, the variable /count/ is not reset (to
zero), but is rather changed somehow. In this document, /count/ is
decreased by two, while in the Linux version, /count/ is set to the
number of packets, that were dropped in the previous dropping state.

Based on the email-thread that was started from these messages ...
     http://www.ietf.org/mail-archive/web/aqm/current/msg00376.html
        http://www.ietf.org/mail-archive/web/aqm/current/msg01250.html
            http://www.ietf.org/mail-archive/web/aqm/current/msg01455.html

... one can infer, that:
1) the case where /count/ is not reset is not an exception, but rather a
common case (that we can confirm from our measurements),
2) several options for this behavior were described on the mailing list
some time ago,

Since it is the most common case, this part of the algorithm should be
explained in the specification.
If the two versions will continue to differ, both algorithms (and their
difference in behavior) should be explained,
but in order to avoid confusion for implementers/operators we believe
that specification of a single algorithm is preferable .

Regards,
  Roland and Polina

[*] https://github.com/torvalds/linux/blob/master/include/net/codel.h#L341

Am 02.12.2015 um 16:45 schrieb Wesley Eddy:
> These both have the intended status designated as "Informational".
> Similar to the questions asked for PIE, we/chairs need to understand
> if there's consensus on:
> - Are these specifications are clear and sufficient quality to publish?
> - Should the status of the RFCs be "Experimental", "Proposed
> Standard", or "Informational"?
>

[aqm] working group last call on CoDel drafts Wesley Eddy
Re: [aqm] working group last call on CoDel drafts Bless, Roland (TM)
Re: [aqm] working group last call on CoDel drafts Dave Taht