Comment on draft-ietf-tsvwg-byte-pkt-congest-05.txt

[Fred Baker <[e-mail]>]

May I make one more comment on this document?

I came into the twvwg meeting today to be present for the discussion, which turned out to mostly not happen - there was a slide and a comment from the mike, and that was the summary of the discussion.

So...

Grepping for the word "consensus", I find:

>    Consensus has emerged over the years concerning the first stage:
>    whether queues are measured in bytes or packets, termed byte-mode
>    queue measurement or packet-mode queue measurement.  Section 2.1 of
>    this memo records this consensus in the RFC Series.  In summary the
>    choice solely depends on whether the resource is congested by bytes
>    or packets.
> ...
>    The IRTF Internet congestion control research group (ICCRG) has set
>    itself the task of reaching consensus on generic forwarding
>    mechanisms that are necessary and sufficient to support the
>    Internet's future congestion control requirements (the first
>    challenge in [RFC6077]).  Therefore, we defer the question of whether
>    packet congestion might become common and what to do if it does to
>    the IRTF (the 'Small Packets' challenge in [RFC6077]).
> ...
>       *  Removed language about consensus

Did we really remove the language about consensus?

In the section pointed to, it reports this consensus:

> 2.1.  Recommendation on Queue Measurement
> 
>    Queue length is usually the most correct and simplest way to measure
>    congestion of a resource.  To avoid the pathological effects of drop
>    tail, an AQM function can then be used to transform queue length into
>    the probability of dropping or marking a packet (e.g.  RED's
>    piecewise linear function between thresholds).
> 
>    If the resource is bit-congestible, the implementation SHOULD measure
>    the length of the queue in bytes.  If the resource is packet-
>    congestible, the implementation SHOULD measure the length of the
>    queue in packets.  No other choice makes sense, because the number of
>    packets waiting in the queue isn't relevant if the resource gets
>    congested by bytes and vice versa.
> 
>    Corollaries:
> 
>    1.  A RED implementation SHOULD use byte mode queue measurement for
>        measuring the congestion of bit-congestible resources and packet
>        mode queue measurement for packet-congestible resources.
> 
>    2.  An implementation SHOULD NOT make it possible to configure the
>        way a queue measures itself, because whether a queue is bit-
>        congestible or packet-congestible is an inherent property of the
>        queue.
> 
>    The recommended approach in less straightforward scenarios, such as
>    fixed size buffers, and resources without a queue, is discussed in
>    Section 4.1.

I think the statement is fine as far as it goes, but it has two remaining issues. One is the question of when an interface is bit/byte congestible and when it is packet-congestible; I'm sure that means something specific to the authors, but will be far less clear to an implementer - every interface has a rate, and few if any measure their rates in packets per unit time, so specifically what is in view as a "packet-congestible interface"? The other is that it only really applies to interfaces to a unique and non-blocking channel, like a serial line. When the congestible interface or queue is on a shared resource such as the fabric in an input-queued switch, an 802.11 interface, etc, the mathematics really involves two queues - the interface queues (in a statistical sense if not a hardware version) for access to the channel, and the packet is enqueued toward the interface, and both arrival/departure distributions are important. 

Consider, for example, an AQM implementation on a WiFi channel. We have all been on busy 802.11 networks; we have this experience in our own history at the IETF. The dynamics are fairly strange. At the IP layer, sessions are generally between hosts on the WiFi network and hosts somewhere else. At the WiFi layer the AP is a proxy for the remote hosts, and is therefore in essence an extremely busy member of the WiFi system that otherwise operates in an approximation to a round-robin fashion. The effect is to build a bufferbloat scenario into the AP. Due to the shared nature of the medium and the fact that retransmissions are driven by absolute time (an RTO happens after a certain point in time), what one is really looking for is a packet's queue occupancy being measured in time. Bytes are a reasonable analog to time (which is what makes bytes reasonable for a bit-congestible interface) for noncontested interfaces, but a shared interface can fail to emit a transmission for an arbitrary time interval. So I might find myself, if some variant on Blue is in use, bumping the mark/drop probability when the queue becomes full and *also* any time one dequeues a packet that has been waiting longer than some time interval.

As to the "SHOULD NOT" regarding configuration, this probably makes a lot of sense in academic circles. Speaking as a vendor, I'm going to do what my customers tell me to. I'm happy enough with a default configuration following this recommendation, but if my customer wants it different, I'm not going to slap his hands.

As a side note, I would generally suggest that we step aside from "RED" and talk about "AQM". Blue, SFQ-Blue, and AVP are AQM algorithms that are likely superior to RED from an operational viewpoint.