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

[Joe Touch <[e-mail]>]

Hi, Fred,

On 11/13/2011 11:52 PM, Fred Baker wrote:
...
(existing text about bit/byte vs. packet congestion)
> 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"?

Some examples in the text might be useful.

Bit/byte congestion:
	- storage that assigns space based on the packet size
	- interfaces whose output bandwidth is overloaded
	- processing that is length-dependent (e.g., full packet
	hashes or encryption)

Packet congestion:
	- storage that assigns space on a per-packet basis,
	i.e., that has fixed slots (for max packets)
	- interfaces whose output slots are overloaded
	(with fixed slots per packet)
	- processing that is per-packet dependent (e.g.,
	header processing, header hashing, tunneling)

It is useful to note that there are some variants of these, e.g., where 
there are a small number of different buffer sizes (coarsely 
per-bit/byte), or ones with combined bottlenecks (there can be multiple 
places where resources are under contention!)

It's useful to explain what to do when there are combined bottlenecks in 
both places (alleviating only one might not suffice). I wonder what the 
algorithm should be in that case...

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

This is the combined example I suggested above AFAICT.

Joe

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