Re: Review draft-ietf-tsvwg-byte-pkt-congest-04 ?

[Fred Baker <[e-mail]>]

On Jul 28, 2011, at 11:14 PM, Bob Briscoe wrote:
> Would you be willing to review this, now it is well-baked?
> 
> It had wide review earlier in its life, but only 2 or 3 reviews since we reorganised it to make it easier to read (hopefully).

Sure Bob.

> Abstract
> 
>    This memo concerns dropping or marking packets using active queue
>    management (AQM) such as random early detection (RED) or pre-
>    congestion notification (PCN).

This sentence seems to mix apples and orangutans. RED is an AQM procedure, meaning that it decides by some mechanism what packets to do something to with a view to active queue management. The structure of the sentence would suggest that PCN is also an AQM procedure. I'll argue that either the AQM procedure uses dropping and/or PCN for signaling or the drop/mark mechanism uses AQM to decide what do affect and the signaling procedure to comminicate. While they both (RED/AQM and PCN, as well as dropping) merit mention in the abstract, I wouldn't put them parallel in the sentence. You can't really say "I think I'll turn off RED and turn on PCN".

>    We give three strong recommendations:
>    (1) packet size should be taken into account when transports read
>    congestion indications, (2) packet size should not be taken into
>    account when network equipment creates congestion signals (marking,
>    dropping), and therefore (3) the byte-mode packet drop variant of the
>    RED AQM algorithm that drops fewer small packets should not be used.

Wow. Before I go into the draft itself, let me comment on how I have historically come down on Van and Sally's debate here. 

If one is dropping traffic to signal congestion, the only loss that TCP or SCTP is cognizant of in that sense is the loss of data packets. Dropping a SYN, SYN-ACK, INIT, or whatever prevents a session from opening, dropping a FIN/RST/etc prevents it from closing, and dropping an ACK delays a signal releasing state in the transport and potentially triggering new transmissions. None of those have anything to do with the congestion window. Hence, if I could understand TCP traffic in the place that queues are managed (which I often cannot - the data is encrypted, or I'm on another card that simply doesn't have that visibility) I would restrict congestion-management signals in the form of loss to data segments.

Ditto if someone is marking TCP/SCTP traffic; ECN depends on a signal returning on data packets, and as a result is primarily implemented (by TCP) in data packets. One could argue that I could learn CE from an Ack or whatever, but I'm not sure why I would bother, as communicating it back requires saving it somewhere as opposed to simply including it in a reply I'm going to send anyway.

The question of doing it on bytes vs packets was never, to my knowledge, about preventing the loss of small packets. It was about working effectively with TCP's congestion control mechanisms and managing router resources. Van wanted us to integrate packet depth because router resources were measured in buffers, which are the same size regardless of how much data they contain (in some implementations), and Sally wanted it on bytes because that was a reasonable heuristic for identifying data segments, which interact better with TCP's mechanisms. 

Having for 30+ years worked on equipment that was able to chain relatively small buffers to store a larger message, Van's argument has always seemed incomplete to me, and Sally's makes sense mechanistically. So I have generally come down on the side of bytes...

But, whatever. On to your document...

I have dropped your entire document into my mail window. Text I don't have a problem with I will simply hack out, copying back text I have questions about. I assume that you can find it in the document by the markers I leave behind or by common search functions. I'm not going to say "[snip]"...

> 1.  Introduction

>    When notifying congestion, the problem of how (and whether) to take
                   ^...the participants in a session of the onset of...

>    packet sizes into account has exercised the minds of researchers and
>    practitioners for as long as active queue management (AQM) has been
>    discussed.  Indeed, one reason AQM was originally introduced was to
>    reduce the lock-out effects that small packets can have on large
>    packets in drop-tail queues.

True, but I'll note that large packets can have a lock-out effect on small packets as well. RFCs 896 and 970, at least, worried about small packets not because there were so many of them, but because they implied the presence of additional IP and TCP headers and as a result relatively inefficient use of the line.

>    The byte vs. packet dilemma arises at three stages in the congestion
>    notification process:
> 
>    Measuring congestion:  When the congested resource decides locally to
>       measure how congested it is, should the queue measure its length
>       in bytes or packets?
> 
>    Encoding congestion notification into the wire protocol:  When the
>       congested network resource decides whether to notify the level of
>       congestion by dropping or marking a particular packet, should its
>       decision depend on the byte-size of the particular packet being
>       dropped or marked?
> 
>    Decoding congestion notification from the wire protocol:  When the
>       transport interprets the notification in order to decide how much
>       to respond to congestion, should it take into account the byte-
>       size of each missing or marked packet?
> 
>    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.  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.

If you're recording a consensus for posterity, I think it needs to be more clearly stated. Do you mean "the consensus is that both choices are viable; the implementor or operator should choose to measure whatever is congesting his links"? I personally don't hear a clear statement here about (1).

>    The controversy is mainly around the last two stages: whether to
>    allow for the size of the specific packet notifying congestion i)
>    when the network encodes or ii) when the transport decodes the
>    congestion notification.
...
>    The primary purpose of this memo is to build a definitive consensus
>    against deliberate preferential treatment for small packets in AQM
>    algorithms and to record this advice within the RFC series.  It
>    recommends that (1) packet size should be taken into account when
>    transports read congestion indications, (2) not when network
>    equipment writes them.


I have read the rest of the paper, but let me stop here and make some generalizations.

First, I expected to find some data or pointers to data. There are in fact some pointers to other documents. The vast majority of the statements in the document that might be supported by data appear to say "80% of those we might have expected to respond didn't, but..." or something like that. I'd be a lot happier with statements of the form "we ran a test..." or "we were able to construct a proof that the mathematics tells us..."

Second, I disagree with the argument about a "perverse favoring of small packets". At least in implementations I'm familiar with, the policy isn't "drop only large packets"; it's "make the drop probability of a packet proportional to the ratio of its size to the bit rate of the link". If all packets are 9000 bytes and you're on an STM-4 link, the drop probability of a packet is proportional to (8*9000)/622000000. If all packets are 64 bytes, the drop probability of any given packet is proportional to (8*64)/622000000, which is smaller, but there are 9000/64 times as many to choose from. Any given bit on the wire has the same probability of being contained in a packet that got lost. On the other hand, if packets are variable in size and you're keying off packet depth, a bit on the wire that is contained in a small packet has a much greater proportional probability of being tagged than one in a large packet. I don't see that one is incented to send small packets; if the probability that a given bit gets lost is the same regardless of size, it seems to me that it takes size out of the discussion.

I'll go back and read the paper again a couple of times before commenting further.