From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by huchra.bufferbloat.net (Postfix) with ESMTP id 2FE4121F70A for ; Thu, 28 Aug 2014 09:36:28 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s7SGaMtP006401; Thu, 28 Aug 2014 10:36:23 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 28 Aug 2014 10:36:22 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 10:36:22 -0600 From: Greg White To: Jerry Jongerius , "'Rich Brown'" Thread-Topic: [Bloat] The Dark Problem with AQM in the Internet? Thread-Index: Ac++/TegXjuC8IrxQVm08Xz1mNtBdAAQhxeAAFIm54AAm0Z9AAACxZcAAAOHnAD//5/qAA== Date: Thu, 28 Aug 2014 16:36:21 +0000 Message-ID: References: <000001cfbefe$69194c70$3b4be550$@duckware.com> <000901cfc2c2$c21ae460$4650ad20$@duckware.com> <2A5BB518-351B-4598-AF79-7088D640AA06@gmail.com> <000301cfc2db$f655d3c0$e3017b40$@duckware.com> In-Reply-To: <000301cfc2db$f655d3c0$e3017b40$@duckware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.4.11.37] Content-Type: multipart/alternative; boundary="_000_D024B3E63C335gwhitecablelabscom_" MIME-Version: 1.0 Cc: "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 16:36:28 -0000 --_000_D024B3E63C335gwhitecablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable And again, AQM is not causing the problem that you observed. As Jonathan i= ndicated, it would almost certainly make your performance better. I can'= t speak for Comcast, but AFAIK they are on a path to deploy AQM. If their = customers start raising FUD that could change. TCP requires congestion signals. In the vast majority of cases today (and = for the foreseeable future) those signals are dropped packets. Going on a = witch hunt to find the evildoer that dropped your packet is counter product= ive. I think you should instead be asking "why didn't you drop my packet e= arlier, before the buffer got so bloated and power boost cut the BDP by 60%= ?" -Greg From: Jerry Jongerius > Date: Thursday, August 28, 2014 at 10:20 AM To: 'Rich Brown' > Cc: "bloat@lists.bufferbloat.net" > Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? It add accountability. Everyone in the path right now denies that they cou= ld possibly be the one dropping the packet. If I want (or need!) to address the problem, I can=92t now. I would have t= o make a change and just hope that it fixed the problem. With accountability, I can address the problem. I then have a choice. If = the problem is the ISP, I can switch ISP=92s. If the problem is the mid-le= vel peer or the hosting provider, I can test out new hosting providers. - Jerry From: Rich Brown [mailto:richb.hanover@gmail.com] Sent: Thursday, August 28, 2014 10:39 AM To: Jerry Jongerius Cc: Greg White; Sebastian Moeller; bloat@lists.bufferbloat.net Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? Hi Jerry, AQM is a great solution for bufferbloat. End of story. But if you want to= track down which device in the network intentionally dropped a packet (whe= n many devices in the network path will be running AQM), how are you going = to do that? Or how do youpropose to do that? Yes, but... I want to understand why you are looking to know which device d= ropped the packet. What would you do with the information? The great beauty of fq_codel is that it discards packets that have dwelt to= o long in a queue by actually *measuring* how long they've been in the queu= e. If the drops happen in your local gateway/home router, then it's interestin= g to you as the "operator" of that device. If the drops happen elsewhere (p= erhaps some enlightened ISP has installed fq_codel, PIE, or some other zoom= y queue discipline) then they're doing the right thing as well - they're ma= naging their traffic as well as they can. But once the data leaves your gat= eway router, you can't make any further predictions. The SQM/AQM efforts of CeroWrt/fq_codel are designed to give near optimal p= erformance of the *local* gateway, to make it adapt to the remainder of the= (black box) network. It might make sense to instrument the CeroWrt/OpenWrt= code to track the number of fq_codel drops to come up with a sense of what= 's 'normal'. And if you need to know exactly what's happening, then tcpdump= /wireshark are your friends. Maybe I'm missing the point of your note, but I'm not sure there's anything= you can do beyond your gateway. In the broader network, operators are cont= inually watching their traffic and drop rates, and adjusting/reconfiguring = their networks to adapt. But in general, it's impossible for you to have an= y sway/influence on their operations, so I'm not sure what you would do if = you could know that the third router in traceroute was dropping... Best regards, Rich --_000_D024B3E63C335gwhitecablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
And again, AQM is not causing the problem that you observed.  As = Jonathan indicated, it would almost certainly make your performance better.=    I can't speak for Comcast, but AFAIK they are on a path to de= ploy AQM.  If their customers start raising FUD that could change.

TCP requires congestion signals.  In the vast majority of cases t= oday (and for the foreseeable future) those signals are dropped packets. &n= bsp;Going on a witch hunt to find the evildoer that dropped your packet is = counter productive.  I think you should instead be asking "why didn't you drop my packet earlier, before the buffer g= ot so bloated and power boost cut the BDP by 60%?"

-Greg

From: Jerry Jongerius <jerryj@duckware.com>
Date: Thursday, August 28, 2014 at = 10:20 AM
To: 'Rich Brown' <richb.hanover@gmail.com>
Cc: "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] The Dark Probl= em with AQM in the Internet?

It add accountability.  Everyo= ne in the path right now denies that they could possibly be the one droppin= g the packet.

 

If I want (or need!) to address the= problem, I can=92t now.  I would have to make a change and just hope = that it fixed the problem.

 

With accountability, I can address = the problem.  I then have a choice.  If the problem is the ISP, I= can switch ISP=92s.  If the problem is the mid-level peer or the hosting provider, I can test out new hosting providers.

 

- Jerry

 

 

 

From: Rich Brown [mailto:richb.hanover@gmail.com]
Sent: Thursday, August 28, 2014 10:39 AM
To: Jerry Jongerius
Cc: Greg White; Sebastian Moeller; bloat@lists.bufferbloat.net
Subject: Re: [Bloat] The Dark Problem with AQM in the Internet?=

 

Hi Jerry,

 

AQM is<= /b> a great solution for = bufferbloat.  End of story.  But if you want to track down which device in the network intentionally dropped a packet (when many= devices in the network path will be running AQM), how are you going to do that?  Or how do youpropose to = do that?

 

Yes, but... I want to understand why you are looking= to know which device dropped the packet. What would you do with the inform= ation?

 

The great beauty of fq_codel is that it discards pac= kets that have dwelt too long in a queue by actually *measuring* how long t= hey've been in the queue. 

 

If the drops happen in your local gateway/home route= r, then it's interesting to you as the "operator" of that device.= If the drops happen elsewhere (perhaps some enlightened ISP has installed = fq_codel, PIE, or some other zoomy queue discipline) then they're doing the right thing as well - they're managing their traffi= c as well as they can. But once the data leaves your gateway router, you ca= n't make any further predictions.

 

The SQM/AQM efforts of CeroWrt/fq_codel are designed= to give near optimal performance of the *local* gateway, to make it adapt = to the remainder of the (black box) network. It might make sense to instrum= ent the CeroWrt/OpenWrt code to track the number of fq_codel drops to come up with a sense of what's 'normal'. A= nd if you need to know exactly what's happening, then tcpdump/wireshark are= your friends. 

 

Maybe I'm missing the point of your note, but I'm no= t sure there's anything you can do beyond your gateway. In the broader netw= ork, operators are continually watching their traffic and drop rates, and a= djusting/reconfiguring their networks to adapt. But in general, it's impossible for you to have any sway/influen= ce on their operations, so I'm not sure what you would do if you could know= that the third router in traceroute was dropping...

 

Best regards,

 

Rich

 --_000_D024B3E63C335gwhitecablelabscom_--