Subject: Re: [aqm] New Version Notification for draft-baker-aqm-recommendation-00.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 16 Mar 2013 01:51:43 +0000

Somewhat with my heart in my hands, given discussion on this list about text I botched and about RFC 2309's recommendation of RED, I have taken it upon myself to do a wholesale replacement of RFC 2309. I'd appreciate people's comments - especially from the original authors of RFC 2309.

For comparison and review purposes, you may like to look at a diff from RFC 2309. If so, go to
    http://tools.ietf.org/rfcdiff
and give it two URLs:
    http://www.rfc-editor.org/rfc/rfc2309.txt
    http://www.ietf.org/id/draft-baker-aqm-recommendation-00.txt

> 
> A new version of I-D, draft-baker-aqm-recommendation-00.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Filename:	 draft-baker-aqm-recommendation
> Revision:	 00
> Title:		 IETF Recommendations Regarding Active Queue Management
> Creation date:	 2013-03-15
> Group:		 Individual Submission
> Number of pages: 17
> URL:             http://www.ietf.org/internet-drafts/draft-baker-aqm-recommendation-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-baker-aqm-recommendation
> Htmlized:        http://tools.ietf.org/html/draft-baker-aqm-recommendation-00
> 
> 
> Abstract:
>   This memo presents recommendations to the Internet community
>   concerning measures to improve and preserve Internet performance.  It
>   presents a strong recommendation for testing, standardization, and
>   widespread deployment of active queue management in routers, to
>   improve the performance of today's Internet.  It also urges a
>   concerted effort of research, measurement, and ultimate deployment of
>   router mechanisms to protect the Internet from flows that are not
>   sufficiently responsive to congestion notification.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Dave Taht <[email-masked]>
Date: Fri, 15 Mar 2013 19:23:04 -0700

>     http://www.ietf.org/id/draft-baker-aqm-recommendation-00.txt

Fred:

wow. you are fast.

I like your new term "lemmings". I have been using ANTs a lot in my
own talks, so I'd add ants to list of terms. These were defined in a
long discussion on the bloat mailing list a year and a half ago. I'll
find a link.

There is obviously a lot more to revise and add here, but thank you
for making such a great start at it. I'd hoped to have got a chance to
talk to you in person this week, but was buried.

For those newly joining the effort, there is an enormous archive of
discussions going back ~2 years on the "bloat", "codel", and
"cerowrt-devel" mailing lists.

I understand that "aqm" is to be a list discussing standardization
efforts, but I also expect some cross pollination and discussion
crossing over/back and forth from the 400+ people that have been
participating on those lists.

https://lists.bufferbloat.net/pipermail/bloat/

I will do an announcement of this new list over there shortly.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 16 Mar 2013 03:11:54 +0000

> I will do an announcement of this new list over there shortly.

Agreed. That said, please encourage them to join and post here. There are a lot of lists in the world. To do anything focused, we kind of need to pick one.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 18 Mar 2013 14:07:09 +0000

I like the new document.

Only two nits:

In section 2, it states " The next section
   introduces RED, an active queue management mechanism that solves both
   problems listed above (given responsive flows)." 

But this document really isn't a detailed discussion about RED, but the motivation of and requirements to an AQM in general..

In section 4, typo ("dos not").

In section 4.6, the last sentence has a question mark to it, albeit the sentence does not pose a question. Introducting additional descriptive traffic types (mice, elephants, lemmings, ants...) in order to have a common understanding of use-cases is beneficial... It should just be avoided to end up with a zoo of classifications in the end, though. Or is this intended to mark space for expansion?

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred
> Baker (fred)
> Sent: Samstag, 16. März 2013 02:52
> To: [email-masked]
> Subject: Re: [aqm] New Version Notification for draft-baker-aqm-
> recommendation-00.txt
> 
> Somewhat with my heart in my hands, given discussion on this list about
> text I botched and about RFC 2309's recommendation of RED, I have taken it
> upon myself to do a wholesale replacement of RFC 2309. I'd appreciate
> people's comments - especially from the original authors of RFC 2309.
> 
> > has been successfully submitted by Fred Baker and posted to the IETF
> > repository.
> >
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 19 Mar 2013 16:33:37 +0000

> But this document really isn't a detailed discussion about RED, but the motivation of and requirements to an AQM in general..

grump. I thought I had found all the references to RED and replaced them with "AQM". Thanks for pointing that out.

> In section 4.6, the last sentence has a question mark to it, albeit the sentence does not pose a question. Introducting additional descriptive traffic types (mice, elephants, lemmings, ants...) in…

I think Map/Reduce applications are an opportunity to expand our thinking, and an argument for both maintaining queues as shallow as possible (to increase the available queue space for bursts when they come) and signaling without loss. The fundamental question is (I'm quoting a specific customer use case, although I decline to identify the network): what happens when you ask O(5000) of your best friends a question and they all answer more or less simultaneously with a "mouse"? The particular network maintains standing TCP sessions between cache servers and compute servers (to avoid the additional RTTs of SYN/SYN-ACk and FIN/FIN-ACK), so a drop results in head-of-line blocking at the compute server and *also* denies the TCP session to subsequent possible users until the retransmission happens, which is another form of head-of-line blocking.

I'll take a look at the sentence, however; it sounds like a place where I didn't finish my thought.