Subject: [aqm] working group LAST CALL on recommendations draft

From: Wesley Eddy <[email-masked]>
Date: Wed, 09 Apr 2014 11:35:04 -0400

We didn't receive any comments yet on the updated recommendations
draft, which we were trying to have a working group last call on
per Richard's email to the list on 3/5.

Since we think people might not have noticed the last call, we're
re-announcing it.

In the next two weeks, please review this document:

https://datatracker.ietf.org/doc/draft-ietf-aqm-recommenda
tion/

and relay any comments, questions, corrections, words of support,
etc. to this AQM mailing list.

Thanks for your help in finishing this document!

-- 
Wes Eddy
MTI Systems

---

From: Dave Taht <[email-masked]>
Date: Wed, 9 Apr 2014 10:33:06 -0700

I still don't support wglc.

a) Nit: "Network Working Group"?

b) I have given up on using the term "AQM" to describe anything other
than Active Queue "Length" Management algorithms.

What I wrote about "SQM" is mostly outside the scope of the AQM
guidelines document, but it's here:

http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management

but I can live with the broad definition as used in this document.

c) I also don't just mean "fair or flow queuing" when I say packet
scheduling, we've identified an elephant in the room as is actually
rate limiting (tbf, htb), or hybrid rate limiting/scheduling (hfsc),
or powerboost style rate limiting/expansion....

Moving on:

d) "The traditional technique for managing the queue length in a network
   device is to set a maximum length (in terms of packets)" - well,
bytes is common on many devices like dlsams and cmts and modems...

substitute: packets or bytes

e) "  2.  Provide a lower-delay interactive service"

I tend to regard dns traffic also as rather significant and telnet is
rather obsolete. ssh.

f) "3.  Non-TCP-friendly Transport Protocols"

There's also the problem of DDOS attacks.

g) "Another topic requiring consideration is the appropriate granularity
   of a "flow" when considering a queue management method.  There are a
   few "natural" answers: 1) a transport (e.g. TCP or UDP) flow (source
   address/port, destination address/port, Differentiated Services Code
   Point - DSCP); 2) a source/destination host pair (IP addresses,
   DSCP); 3) a given source host or a given destination host.  We
   suggest that the source/destination host pair gives the most
   appropriate granularity in many circumstances. "

I don't suggest the last, as I have no data that backs it up.

and my request to include a 5 tuple address/port destination
address/port and protocol isn't in here,
although the MF classifier is mentioned later on in section 4.4.
Elsewhere (in webrtc) there is an assumption that the 5 tuple is
addr/port daddr/dport protocol.

I don't actually think doing a 5 tuple including the dscp rather than
the protocol is a very good idea given the amount of misclassified
flows I see transiting site boundries. I do think moving out dscp
flows into their own queues and then 5 tupling with protocol
is not a bad idea.

As for the final recomendations:

h) "   4.  AQM algorithms SHOULD respond to measured congestion, not
       application profiles."

I'm not sure if this precludes active classification and optimization measures?

http://www.smallnetbuilder.com/lanwan/lanwan-features/32297-does-qualcomms-streamboost-really-work

"   Not all applications transmit packets of the same size.  Although
   applications may be characterized by particular profiles of packet
   size this should not be used as the basis for AQM (see next section)."

>From a packet scheduling perspective I strongly support using some
differentiation based on packet size at low bandwidths. 300 bytes
works well.

for AQM, don't care, just care about latency no matter if it comes
from a pps problem or a packet size problem. I didn't mind pie's
increasing probability of a drop based on packet size (Which so far
as I know is still in cablemodem pie, and: it helps on competing voip traffic)

i) 4.5

might want to also mention more modern protocols like uTP and QUIC

"  In 2013, an obvious example of further research is the need to
   consider the use of Map/Reduce applications in data centers; do we
   need to extend our taxonomy of TCP/SCTP sessions to include not only
   "mice" and "elephants", but "lemmings".  "Lemmings" are flash crowds
   of "mice" that the network inadvertently try to signal to as if they
   were elephant flows, resulting in head of line blocking in data
   center applications."

I like to talk about ANTS.  Can suggest some language if you want.

On Wed, Apr 9, 2014 at 8:35 AM, Wesley Eddy <[email-masked]> wrote:
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: John Leslie <[email-masked]>
Date: Wed, 9 Apr 2014 20:33:47 -0400

> per Richard's email to the list on 3/5.

   Not sure how I missed that; but alas I did.

> etc. to this AQM mailing list.

   First pass comments:

   This document is not ready for WGLC. A number of suggestions which
seemed headed towards consensus have not been integrated.

   The questions put to the WG have been too limited, and also too
general. We have mostly responded to them as motherhood and apple pie,
without enough discussion of the actual wording -- least of all seeking
consensus on the underlying principles we're trying to state.

   We have a number of areas outside of Section 4 which deserve our
consideration. The whole "TCP-friendly" terminology is so 1998. ;^)
Any meaning it may have had in 1998 has dissipated beyond recovery.
We _really_ should come up with another way to say what we mean.

   I don't see discussion of multiple queues for different flows,
which IMHO is necessary for effective Active Queue Management.

   We haven't discussed the misinterpretation of "congestion collapse".
Congestion collapse came from re-transmitting dropped packets. A
"non-responsive" flow _cannot_ lead to congestion collapse unless it
increases its sending rate in response to congestion (packet drop,
usually). It certainly _can_ lead to Denial of Service, but not
congestion collapse.

   For that matter, we don't discuss denial-of-service, which is a
very real issue, except for a brief mention in Security Considerations.
I don't expect to solve that issue in this document, but I do believe
we can say something about how Active Queue Managment might evolve to
alleviate denial-of-service problems. (They're alarmingly common today!)

   Personally, I am not willing to let this document go without _some_
treatment of the issues raised by Bob Briscoe's proposal for "Immediate
ECN". I don't mean that we must rubber-stamp Bob's text -- goodness
knows I disagree with him about half the time -- but _sometime_ we
have to escape the totally irrational belief that ECN can be "the same
as" packet drop. (I would suggest placing this in the section 4.2.)

   In Section 4.2, I have a problem with the glib way we call "delaying
packets in flight" a reasonable congestion signal. While I do not deny
that some transports use delay as a signal, it's a dreadful signal and
should be discouraged for AQMs going forward. (It will still be there
as an incidental indicator for a long time; and I don't mean to forbid
its use -- merely to encourage other mechanisms instead.)

   I'd like to see a presentation of how the services expected of the
Internet have evolved: that we are now dominated by interactive uses,
from web-browsing all the way to real-time conferencing. This will
make it clear _why_ it's important to have a way to minimize delay;
and will inform discussion of how to make the Internet more responsive
to web-browsing while at the same time serving real-time speech.

   As I said, these are first-pass comments. I'll stop here.

--
John Leslie <[email-masked]>