From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5D13321F311 for ; Mon, 1 Sep 2014 04:54:12 -0700 (PDT) Received: from srichardlxp2 ([213.143.107.142]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MKu9E-1XOQBU3F7g-0005Oi; Mon, 01 Sep 2014 13:54:08 +0200 Message-ID: <838C4FB37516464BA5434E82BD0CE8CC@srichardlxp2> From: "Richard Scheffenegger" To: "Jerry Jongerius" , "'Rich Brown'" References: <000001cfbefe$69194c70$3b4be550$@duckware.com><000901cfc2c2$c21ae460$4650ad20$@duckware.com><2A5BB518-351B-4598-AF79-7088D640AA06@gmail.com> <000301cfc2db$f655d3c0$e3017b40$@duckware.com> Date: Mon, 1 Sep 2014 13:47:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CD_01CFC5EB.51B1B1A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Provags-ID: V03:K0:xTv+QvUSFHISWfD934Nyd/o2jjNblsRHw+R1JMRFD840/X4u1gd qw3sLhGg/m/GKLiZjBC9V/dnku9drHerSUplrycIfu77fNh0jK1L6MzYm9XjIS/Xt6efG58 hPaqM16bygMozqI/P+PAE/VpJxp91RRVmJ8QUz6aHaDgCHr7HaFZTJFOoJkviAp0zxkbH+J 57canqRKCA1STBIe9W6nQ== X-UI-Out-Filterresults: notjunk:1; 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: Mon, 01 Sep 2014 11:54:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02CD_01CFC5EB.51B1B1A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jerry, isn't this the problem statement of Conex? Again, you at the end host would gain little insight with Conex, but = every intermediate network operator can observe the red/black marked = packets, compare the ratios and know to what extent (by looking at = ingress vs egress into his network ) he is contributing... Best regards, Richard ----- Original Message -----=20 From: Jerry Jongerius=20 To: 'Rich Brown'=20 Cc: bloat@lists.bufferbloat.net=20 Sent: Thursday, August 28, 2014 6:20 PM Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? It add accountability. Everyone in the path right now denies that = they could possibly be the one dropping the packet. =20 If I want (or need!) to address the problem, I can't now. I would = have to make a change and just hope that it fixed the problem. =20 With accountability, I can address the problem. I then have a choice. = If the problem is the ISP, I can switch ISP's. If the problem is the = mid-level peer or the hosting provider, I can test out new hosting = providers. =20 - Jerry =20 =20 =20 From: Rich Brown [mailto:richb.hanover@gmail.com]=20 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? =20 Hi Jerry, =20 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 (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? =20 Yes, but... I want to understand why you are looking to know which = device dropped the packet. What would you do with the information? =20 The great beauty of fq_codel is that it discards packets that have = dwelt too long in a queue by actually *measuring* how long they've been = in the queue.=20 =20 If the drops happen in your local gateway/home router, 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 traffic as well as they can. But once the = data leaves your gateway router, you can't make any further predictions. =20 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 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.=20 =20 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 continually watching their traffic and drop rates, and = adjusting/reconfiguring their networks to adapt. But in general, it's = impossible for you to have any 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... =20 Best regards, =20 Rich -------------------------------------------------------------------------= ----- _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat ------=_NextPart_000_02CD_01CFC5EB.51B1B1A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jerry,
 
isn't this the problem statement of=20 Conex?
 
Again, you at the end host would gain = little=20 insight with Conex, but every intermediate network operator can observe = the=20 red/black marked packets, compare the ratios and know to what extent (by = looking=20 at ingress vs egress into his network ) he is = contributing...
 
Best regards,
  Richard
 
----- Original Message -----
From:=20 Jerry=20 Jongerius
Sent: Thursday, August 28, 2014 = 6:20=20 PM
Subject: Re: [Bloat] The Dark = Problem=20 with AQM in the Internet?

It=20 add accountability.  Everyone in the path right now denies that = they=20 could possibly be the one dropping the packet.

 

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

 

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

 

-=20 Jerry

 

 

 

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

 

Hi Jerry,

 

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

 

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

 

The great beauty of fq_codel is that it discards = packets=20 that have dwelt too long in a queue by actually *measuring* how long = they've=20 been in the queue. 

 

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

 

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

 

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

 

Best regards,

 

Rich

_______________________________________________
Bloat = mailing=20 = list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/list= info/bloat
------=_NextPart_000_02CD_01CFC5EB.51B1B1A0--