From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "rcdn-iport.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AF41421F708 for ; Thu, 28 Aug 2014 09:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18881; q=dns/txt; s=iport; t=1409243750; x=1410453350; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/gNH0Lk1qcfWvDnq9kEJoUyEv5QNxumt/5Z+6WfyTqk=; b=itZeij2A0akNBQwbFVT0ywfODmH72iqf69iE0lCiJPHuGeyhiy6bSUJg B39TRKH4LDsjJScfuLrETX/jz6GIeY3vXNx6ghrxxCR7qBNO73I8Jgq4C Hp/eq+AhuzKTkLCtQomBfGG7zfXyUJQGTf9tyTCL+/Vc4dwtxz/ulLh9D k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJBZ/1OtJV2S/2dsb2JhbABbgkdGU1cEzB4BCYdPAYEbFneEAwEBAQMBAQEBawsFCwIBCBEEAQEoByEGAQoUCQgCBA4FDg2IEwMJCA26Jg2FLhMEiX+DIIItBgEGgymBHQWRL4IGgUpeg3pzghCOZoY3g15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,418,1406592000"; d="asc'?scan'208,217";a="350972837" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 28 Aug 2014 16:35:48 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7SGZlHi022532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 16:35:47 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 11:35:47 -0500 From: "Fred Baker (fred)" To: Jerry Jongerius Thread-Topic: [Bloat] The Dark Problem with AQM in the Internet? Thread-Index: Ac++/TegXjuC8IrxQVm08Xz1mNtBdAAObqaAAF652oAAjrOJAAACxZgAAAOHnAAAAInWgA== Date: Thu, 28 Aug 2014 16:35:46 +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: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_3578BD67-602D-46F0-81C6-F2D4398A01E7"; protocol="application/pgp-signature"; micalg=pgp-sha1 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:35:49 -0000 --Apple-Mail=_3578BD67-602D-46F0-81C6-F2D4398A01E7 Content-Type: multipart/alternative; boundary="Apple-Mail=_814717E8-6D27-4EBB-BF8F-BA1CF6559B79" --Apple-Mail=_814717E8-6D27-4EBB-BF8F-BA1CF6559B79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 28, 2014, at 9:20 AM, Jerry Jongerius = wrote: > 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=92t 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=92s. If the problem is the = mid-level peer or the hosting provider, I can test out new hosting = providers. =20 May I ask what may be a dumb question? All communications has some probability of error. That=92s the reason we = have CRCs on link layer frames; to detect and discard errored packets. = The probability of such an error varies by media type; it=92s relatively = uncommon (O(10^-11)) on fiber, a little more common (perhaps O(10^-9)) = on wired Ethernet, likely on Wifi (O(1p^-7 or so), which is why Wifi = incorporates local retransmission), and very likely (O(10^-4)) on = satellite links, which is why they use forward error correction. Errors are not usually single bit errors. They are far more commonly = block errors, especially if trellis coding is in use, as once there is = an error the entire link goes screwy until it works out where the data = is going. Such block errors might consume entire messages, or sets of = messages, including not only the messages but the gaps between them. When a message is lost due to an error, how do you determine whose fault = it is? > - 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 --Apple-Mail=_814717E8-6D27-4EBB-BF8F-BA1CF6559B79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 28, 2014, at 9:20 AM, Jerry = Jongerius <jerryj@duckware.com> = wrote:

It add accountability.  Everyone in the path = right now denies that they could possibly be the one dropping 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.
 
May I ask what may be a dumb = question?

All communications has some probability of error. That=92s the = reason we have CRCs on link layer frames; to detect and discard errored = packets. The probability of such an error varies by media type; it=92s = relatively uncommon (O(10^-11)) on fiber, a little more common (perhaps = O(10^-9)) on wired Ethernet, likely on Wifi (O(1p^-7 or so), which is = why Wifi incorporates local retransmission), and very likely = (O(10^-4)) on satellite links, which is why they use forward error = correction.

Errors are not usually = single bit errors. They are far more commonly block errors, especially = if trellis coding is in use, as once there is an error the entire link = goes screwy until it works out where the data is going. Such block = errors might consume entire messages, or sets of messages, including not = only the messages but the gaps between them.

When a message is lost due to an error, how = do you determine whose fault it is?

- 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?
_____________________= __________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
=
= --Apple-Mail=_814717E8-6D27-4EBB-BF8F-BA1CF6559B79-- --Apple-Mail=_3578BD67-602D-46F0-81C6-F2D4398A01E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFT/1pdbjEdbHIsm0MRAusEAKDYvu/h/6ZG++TbB2TnLIxM0W+QRQCg90ik 5KxsCOFKP6kkHSwTUVc/5dw= =7/S3 -----END PGP SIGNATURE----- --Apple-Mail=_3578BD67-602D-46F0-81C6-F2D4398A01E7--