Subject: [aqm] Fwd: New Version Notification for draft-baker-aqm-recommendation-01.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 23 Apr 2013 23:03:17 +0000

FYI, I have posted an update version of the draft we discussed last month. One thing I would appreciate is comments from those who commented before; did my updates address your concerns?

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification for draft-baker-aqm-recommendation-01.txt
> Date: April 23, 2013 3:59:41 PM PDT
> To: Fred Baker <[email-masked]>
> 
> 
> A new version of I-D, draft-baker-aqm-recommendation-01.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Filename:	 draft-baker-aqm-recommendation
> Revision:	 01
> Title:		 IETF Recommendations Regarding Active Queue Management
> Creation date:	 2013-04-23
> Group:		 Individual Submission
> Number of pages: 17
> URL:             http://www.ietf.org/internet-drafts/draft-baker-aqm-recommendation-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-baker-aqm-recommendation
> Htmlized:        http://tools.ietf.org/html/draft-baker-aqm-recommendation-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-baker-aqm-recommendation-01
> 
> 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 note largely repeats the recommendations of RFC 2309, updated
>   after fifteen years of experience and new research.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 23 Apr 2013 16:57:56 -0700

Hi Fred,

Is there a preferred scheme for a self-tuning AQM?  I'm a bit out of
touch with the work in the area, but when I hear AQM, all think of
is RED (which is what most switches implement), but when I hear
self-tuning AQM, nothing comes to mind (and I'm not aware of anything
that's reasonably widely implemented or available).

I want to make sure I understand the requirements that this imposes
on switches and routers.

Thanks,
Anoop

On Tue, Apr 23, 2013 at 4:03 PM, Fred Baker (fred) <[email-masked]> wrote:

> FYI, I have posted an update version of the draft we discussed last month.
> One thing I would appreciate is comments from those who commented before;
> did my updates address your concerns?
>
> Begin forwarded message:
>
> > URL:
> http://www.ietf.org/internet-drafts/draft-baker-aqm-recommendation-01.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-baker-aqm-recommendation
> > Htmlized:
> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01
> > Diff:
> http://www.ietf.org/rfcdiff?url2=draft-baker-aqm-recommendation-01
> >
> > Abstract:
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 24 Apr 2013 01:20:34 +0000

On Apr 23, 2013, at 4:57 PM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Fred,

ICCRG is hashing that discussion now. There are at least two technologies that could be applied, which are CoDel and PIE, and I think I could convince myself that AVQ fit the mould. That, in part, is why in this document I am focusing more on how the technology in question should behave than what the One Blessed technology should be. Who knows, fifteen years from now there might be a better algorithm available than we have now.

Thanks,
Anoop

On Tue, Apr 23, 2013 at 4:03 PM, Fred Baker (fred) <[email-masked]<mailto:[email-masked]>> wrote:
FYI, I have posted an update version of the draft we discussed last month. One thing I would appreciate is comments from those who commented before; did my updates address your concerns?

Begin forwarded message:

> From: <[email-masked]<mailto:[email-masked]>>
> To: Fred Baker <[email-masked]<mailto:[email-masked]>>
>
>

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

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

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 23 Apr 2013 18:51:54 -0700

Thanks Fred

On Tue, Apr 23, 2013 at 6:20 PM, Fred Baker (fred) <[email-masked]> wrote:

>
>  ICCRG is hashing that discussion now. There are at least two
> technologies that could be applied, which are CoDel and PIE, and I think I
> could convince myself that AVQ fit the mould. That, in part, is why in this
> document I am focusing more on how the technology in question should behave
> than what the One Blessed technology should be. Who knows, fifteen years
> from now there might be a better algorithm available than we have now.
>

I think once we have a better understanding of what it means and what the
benefits are, then the RFC can always be updated.  If we put something in
the list of recommendations that is not well-understood it creates a
problem for equipment vendors when their customers put the RFC in an RFP.

Anoop

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 25 Apr 2013 21:58:25 +0000

Fred,

I am late to the game. I've seen a lot of messages regarding to AQM. I just get around to read the draft and have a few questions. I apologize if those questions have been asked and answered in previous email exchanges.

-        Today's internet is different from 1998 when RFC2309 was published.

o   Today's network consists of many  layers of tunnels (some of them are TE based). Routers in the core manage tunnels that could aggregate  tens of thousands of end user flows. So each user's TCP flow is very insignificant in core routers' queues.

o   Virtually everyone's internet access is provided by ISPs with pre-negotiated rate (including burst traffic, etc). Therefore, the ISP's access nodes' traffic shaping and policing may play a much bigger part in end to end delay than the Queue sizes in the Core routers.

-        I do think that the Active Congestion Management is very important because the source nodes may have multiple paths to destinations. It is very common for an enterprise to buy connections from two different service providers.

o   Therefore, ECN marking or sending explicit congestion message to the source is more effective.

o

o   Why not add an extra field to the Ping reply to indicate congestion? especially the congestion is caused by hardware failure (e.g. N links in a LAG reduced to N-1 links in a LAG, or microwave transport drop bandwidth due to weather). Source node uses Ping to detect connectivity. Today's Ping reply only says "yes" or "no". But today with  LAG widely deployed, link bandwidth could fluctuate causing pre-longed congestion, which really need source nodes to throttle back for network to perform.

Therefore I feel that the benefit of refining router queue management may not provide any real improvement to end to end user sessions in today's grand internet network.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Tuesday, April 23, 2013 8:21 PM
To: Anoop Ghanwani
Cc: [email-masked]
Subject: Re: [aqm] Fwd: New Version Notification for draft-baker-aqm-recommendation-01.txt

Hi Fred,

Thanks,
Anoop

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 25 Apr 2013 23:23:21 +0000

On Apr 25, 2013, at 2:58 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Fred,

I am late to the game. I’ve seen a lot of messages regarding to AQM. I just get around to read the draft and have a few questions. I apologize if those questions have been asked and answered in previous email exchanges.

-        Today’s internet is different from 1998 when RFC2309 was published.
o   Today’s network consists of many  layers of tunnels (some of them are TE based). Routers in the core manage tunnels that could aggregate  tens of thousands of end user flows. So each user’s TCP flow is very insignificant in core routers’ queues.

In the core, that's true.

o   Virtually everyone’s internet access is provided by ISPs with pre-negotiated rate (including burst traffic, etc). Therefore, the ISP’s access nodes’ traffic shaping and policing may play a much bigger part in end to end delay than the Queue sizes in the Core routers.

In the core, that may be true.

-        I do think that the Active Congestion Management is very important because the source nodes may have multiple paths to destinations. It is very common for an enterprise to buy connections from two different service providers.
o   Therefore, ECN marking or sending explicit congestion message to the source is more effective.
o
o   Why not add an extra field to the Ping reply to indicate congestion? especially the congestion is caused by hardware failure (e.g. N links in a LAG reduced to N-1 links in a LAG, or microwave transport drop bandwidth due to weather). Source node uses Ping to detect connectivity. Today’s Ping reply only says “yes” or “no”. But today with  LAG widely deployed, link bandwidth could fluctuate causing pre-longed congestion, which really need source nodes to throttle back for network to perform.

This wouldn't be too hard to prototype. I do wonder about the relationship to Source Quench; the reason that we abandoned Source Quench way back when was that while it might correctly detect that congestion was happening and send a message to somebody, it was difficult to get it sent to the guy that was causing the problem. If, for example, session #1 is using CUBIC and as a result keeping the queue at a bottleneck within epsilon of "full", and someone else fires off an IW=10 burst, it would be pretty easy to imagine the packet most likely to be hit being the last packet in the second session's slow-start.

The most important question would be "so what". Ping is not something systems usually do automatically, it's something operators do when something has been bad for several minutes. What would you like a given end user session to do in the meantime? How does the operator use the information returned by ping?.

Therefore I feel that the benefit of refining router queue management may not provide any real improvement to end to end user sessions in today’s grand internet network.

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Fred Baker (fred)
Sent: Tuesday, April 23, 2013 8:21 PM
To: Anoop Ghanwani
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [aqm] Fwd: New Version Notification for draft-baker-aqm-recommendation-01.txt

Hi Fred,

Thanks,
Anoop

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 26 Apr 2013 14:43:01 +0000

Fred,

Thank you very much for the detailed reply. A few more questions inserted below:

o

[[Linda] Why not send the notification of "hard degradation" (e.g. LAG link bandwidth reduction due to some member link failure or Microwave links bandwidth reduction due to weather) to the "Ingress nodes" of the domain ? so that the "Ingress nodes" can choose different route or reduce the ingress rate? The notification doesn't have to be sent all the way to the hosts who initiate the traffic.

[Linda] Agree with you that "Ping" might not the best way. What do you think of encoding some bits in  the OAM frames traversing by (e.g. IP PM, BFD, ECN, etc) to reflect "hard degradation"?  Those "hard degradation" really need source nodes or Ingress nodes to throttle back traffic.

Linda

Hi Fred,

Thanks,
Anoop