Subject: [aqm] Notes

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 4 Mar 2014 17:53:57 +0000

First of all, thanks to the note takers.

We've had quite some discussion around the AQM evaluation guideline draft, and I believe the notes capture many of the points brought up.

If you have been up and made a comment on the Microphone, I would like you to check if the spirit of your comment has been properly captured in the notes:
http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-aqm

Richard Scheffenegger

NetApp
[email-masked]<mailto:[email-masked]>
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com<http://www.netapp.com>

EURO PLAZA
Gebäude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien

---

From: Dave Taht <[email-masked]>
Date: Tue, 4 Mar 2014 23:50:49 +0000

On Tue, Mar 4, 2014 at 5:53 PM, Scheffenegger, Richard <[email-masked]> wrote:
> We've had quite some discussion around the AQM evaluation guideline draft,
> and I believe the notes capture many of the points brought up.
>
> If you have been up and made a comment on the Microphone, I would like you
> to check if the spirit of your comment has been properly captured in the
> notes:

Not even close to what I said. Is it too much to request, that for
future meetings
that the proceedings be recorded and comments transcribed? The technology
exists...

"Dave Taht: Care a lot about inter-flow packet loss. Bursty is really
bad. Like to have a metric on inter flow loss"

This reminds me of an old far side joke.

http://hubpages.com/hub/Gary-Larson#slide209782

Substitute "Packet loss" for "Ginger" here.

What I said was:

"I care a lot about interflow latency, jitter, and packet loss. Only
bursty packet loss is really bad.  I'd like to have
a metric on interflow latency, jitter, and packet loss."

Of these, packet loss is the *least* of my concerns. Our protocols
recover from and compensate well
from non-bursty packet loss, and packet loss IS the most common signal
to tell protocols to slow down.
and thus desirable...

As an illustrative example, the cerowrt group has been working on ways
to make aqm and packet scheduling
technologies work well at rates well below 10Mbit, notably on the
768kbit uplinks common in the DSL world (which
also has weird framing derived from the bad olde days of ATM)

At below 100Mbit, TCP behavior is dominated by certain constants -
notably the initial window, be it 3,4 or 10, but also
MTU * IWx in relation to MSS, availability of pacing on on/off traffic
with a large cwnd, etc.

There are a string of recent tests put up here

http://richb-hanover.com/

The first graph shows bufferbloat in all its glory on the link - well
over 2secs of delay and goodput of
about 1.6Mbits on the download.

The remainder of the graphs are on variants of nfq_codel and fq_codel
setups, but the core result was
after applying the cerowrt SQM system (scheduling and aqm)
goodput was way, way, up and latency way, way, down compared to the
bufferbloat'd alternative,
nearly triple the download goodput, and 1/50th the latency. (The
debate is over how best to
get better interflow results and the differences in results not much
above a percentage point)

 - packet loss on this link after applying AQM was well over 35%! But
as it is not bursty, and latency is
held low, the link remains markedly useful, all the flows work pretty
well, and the low rate flows are
doing good...

Thread for ongoing discussion here:

https://lists.bufferbloat.net/pipermail/cerowrt-devel/2014-February/002370.html

Packet captures seem to show that MAC TCP is not reducing it's window
to a reasonable value,
nor is it reducing MSS to something more appropriate for the link
rate. I'd recomend looking at
the packet captures on that test to get a feel for how slow start,
fast recovery and dup acks are is
interact at these timescales.

Packet loss, particularly when taken as a pure percentage is not a
good metric for most measurements.
Most of the time, I don't give a rats arse about it.

> [email-masked]
> www.netapp.com
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Naeem Khademi <[email-masked]>
Date: Tue, 4 Mar 2014 23:51:39 +0000

Hi Richard

line 134: "???: does an AQM implementation must justify its cost. I don't
think you"

that's *probably* me trying to say that "it's up to the AQM designers to
justify the cost of their proposed AQM given a set of
scenarios/environments where their AQM is aimed to operate at. Q1: Is it
mandatory for them to design an AQM that is justified in cost for every
possible network scenario (e.g. w/ packet scheduling, etc.)? answer: no!
Q2: do we require them (or is it mandatory) to justify the cost of AQM
implementation in where they define their AQM to operate at? yes!"

The current draft actually have specifically covered that.

Cheers,
Naeem

On Tue, Mar 4, 2014 at 5:53 PM, Scheffenegger, Richard <[email-masked]>wrote:

> *http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-aqm*<http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-aqm>
>
>
>
> Richard Scheffenegger
>
> NetApp
> [email-masked]* <[email-masked]>
> *www.netapp.com* <http://www.netapp.com>
>
> EURO PLAZA

---

From: Andrew Mcgregor <[email-masked]>
Date: Wed, 5 Mar 2014 02:17:04 -0800

Andrew McGregor: If you find yourself in that situation, there are
approaches. In exists deploments where you have a different ECN inside the
DC then outside torward the internet.

Should read something like "If you're trying to enable ECN in a large
content provider, you can find the routers that cause you problems and
disable ECN toward the subnets behind them.  It can be a more serious issue
to deal with mark-equals-drop ECN on the outside and early-onset ECN on the
inside, since traffic often crosses the same switches in both cases."

Andrew McGregor: We can agree on algorithms that are disasterously bad
(laughter). I've had good results scatter-graphing input bandwidth with
delay.

A scatter plot of input bandwidth vs *packet loss* is very illuminating.
 On shallow-buffered fast equipment delay doesn't help you much.

My other point doesn't seem to have been captured at all:

We can also describe what the requirements for algorithms to be composable,
to avoid their control systems fighting each other.  It's not clear we know
exactly how to do that, but it is critical that we do this.

On 4 March 2014 15:51, Naeem Khademi <[email-masked]> wrote:

>> We’ve had quite some discussion around the AQM evaluation guideline
>> draft, and I believe the notes capture many of the points brought up.
>>
>> If you have been up and made a comment on the Microphone, I would like
>> you to check if the spirit of your comment has been properly captured in
>> the notes:

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 1071 2221

---

From: John Leslie <[email-masked]>
Date: Wed, 5 Mar 2014 06:08:39 -0500

Andrew Mcgregor <[email-masked]> wrote:
> disable ECN toward the subnets behind them.

   (I'm not arguing that you didn't say that...)

   "Finding" such routers isn't trivial. :^(

   Identifying subnets behind them is even less trivial. :^(

> It can be a more serious issue to deal with mark-equals-drop ECN on
> the outside and early-onset ECN on the inside, since traffic often
> crosses the same switches in both cases."

   I wish you'd find a clearer way of saying this -- in some follow-up
thread on this list. I am left scratching my head as to what you're
suggesting we _do_ about this (even if these cases were easy to
distinguish).

   I would like to simply enable ECN on a mostly-vanilla webserver;
and use packet-filtering _if_ I learn of a complete disaster somewhere:
otherwise letting the chips fall where they may.

   IMHO, a router which simply clears ECN isn't a problem I need to
worry about. Even a router which drops CE-marked packets isn't worth
worrying about for a vanilla web-page.

   OTOH, a router which drops all ECN-enabled packets is major damage
which needs public humiliation. (So I'm not in a big hurry to hide
its broken behavior.)

   This issue clearly deserves discussion (though I'm not in any
hurry to convert others to my views). Perhaps there is a better list
for such discussion, but it's not obvious where else to hold it...

--
John Leslie <[email-masked]>

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 5 Mar 2014 12:20:59 +0000

> that the proceedings be recorded and comments transcribed? The technology

Thank you for volunteering to take minutes next time.

Lars

---

From: Dave Taht <[email-masked]>
Date: Wed, 5 Mar 2014 13:47:10 +0000

> Thank you for volunteering to take minutes next time.

Touche'! :)

I am a bad choice in that I am partially deaf, and do my best work on
a model M keyboard,
which would be distracting to everyone  in the room.

I use transcription services all the time, from recordings. The cost
is 1 dollar per minute or so
through services like transcribr, and the results generally quite good.

Sometimes, particularly when I didn't understand the speaker clearly,
I'll do that on my own dime,
and there were a multitude of comments on fine points that it is
probable that I misunderstood.

There is a recording somewhere?

-- 
Dave Täht

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 5 Mar 2014 13:52:56 +0000

> There is a recording somewhere?

Yes: http://www.ietf.org/audio/ietf89/

(I don't think there was Meetecho for this session though.)

Lars