From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-01-ewr.dyndns.com (mxout-052-ewr.mailhop.org [216.146.33.52]) by lists.bufferbloat.net (Postfix) with ESMTP id EF2C02E0226 for ; Wed, 16 Feb 2011 13:03:20 -0800 (PST) Received: from scan-01-ewr.mailhop.org (scanner [10.0.141.223]) by mail-01-ewr.dyndns.com (Postfix) with ESMTP id 3EE201F56A6 for ; Wed, 16 Feb 2011 21:03:20 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 207.5.72.94 Received: from exhub015-2.exch015.msoutlookonline.net (exhub015-2.exch015.msoutlookonline.net [207.5.72.94]) by mail-01-ewr.dyndns.com (Postfix) with ESMTP id 9243F1F51F2 for ; Wed, 16 Feb 2011 21:03:18 +0000 (UTC) Received: from EXVMBX015-6.exch015.msoutlookonline.net ([207.5.72.76]) by exhub015-2.exch015.msoutlookonline.net ([207.5.72.94]) with mapi; Wed, 16 Feb 2011 13:03:18 -0800 From: Rupert Lloyd To: "bloat@lists.bufferbloat.net" Date: Wed, 16 Feb 2011 13:03:16 -0800 Thread-Topic: Bloat Digest, Vol 2, Issue 25 Thread-Index: AcvOFBqqHNHhZJAyQqCxFcrUE3OlZgACNQBX Message-ID: <75474angn67muh1yduob53bb.1297890207043@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Bloat] Bloat Digest, Vol 2, Issue 25 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: Wed, 16 Feb 2011 21:03:21 -0000 "bloat-request@lists.bufferbloat.net" = wrote: Send Bloat mailing list submissions to bloat@lists.bufferbloat.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.bufferbloat.net/listinfo/bloat or, via email, send a message with subject or body 'help' to bloat-request@lists.bufferbloat.net You can reach the person managing the list at bloat-owner@lists.bufferbloat.net When replying, please edit your Subject line so it is more specific than "Re: Contents of Bloat digest..." Today's Topics: 1. new members, welcome! (Dave =3D?utf-8?Q?T=3DC3=3DA4ht?=3D) 2. Background Bufferbloat Detector (Sean Conner) 3. Re: Background Bufferbloat Detector (Dave =3D?utf-8?Q?T=3DC3=3DA4ht?= =3D) 4. Re: Background Bufferbloat Detector (Richard Scheffenegger) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Feb 2011 07:56:03 -0700 From: d@taht.net (Dave =3D?utf-8?Q?T=3DC3=3DA4ht?=3D) To: bloat@lists.bufferbloat.net Subject: [Bloat] new members, welcome! Message-ID: <87ei78kozg.fsf@cruithne.co.teklibre.org> Content-Type: text/plain; charset=3Dus-ascii We hit a milestone sometime early this morning. There are now 100 people on this mailing list! New members, welcome! I'd love it if we/you'd could circle back to some earlier threads in conversation[1], in particular I'd like to see the glossary of agreed upon terms expanded. [2] I'd like the "dark buffers" concept expanded [3] to include retransmits or a new term invented. If any of the 28 that have signed up for the wiki do not have editing privs, please contact me off list. Also we had much discussion, since fizzled out, on a good introductory analogy to how the internet actually works. [4] I confess that I'm a little buried right now in trying to assemble additional hardware resources worldwide, while working at layers 8 & 9 of the stack on the background bufferbloat detector idea. [5]. I just got a large data set to play with. Nathaniel's iwl patches look promising (only minor quibbles on the Linux-wireless list[6] - I am editing down a recorded conversation with Felix Fietkau (one of the main openwrt & wireless developers and author of the minstrel rate control algorithm) that started as a discussion of my latency-smashing-yet-horrifying-to-him ath9k patch[7]. It later turned into a marvelous indepth discussion of how 802.11n wireless actually works and some possible solutions[8], down to a low level. I think it is well worth understanding for people more familiar with wires or higher levels of the stack [9]. I like the concept of "Bufferbloat Public Radio" in that sometimes it's just nice to get away from the computer and listen to something while doing something else, but that's me. Do others like this idea? We had a LOT of downloads (probably over a 1000 by now) of jg's mp3. Thanks everybody for your concern and interest in fixing bufferbloat. 1: https://lists.bufferbloat.net/pipermail/bloat/2011-February/thread.html 2: http://www.bufferbloat.net/projects/bloat/wiki/Glossary 3: http://www.bufferbloat.net/projects/bloat/wiki/Dark_buffers 4: https://lists.bufferbloat.net/pipermail/bloat/2011-February/000050.html 5: https://github.com/dtaht/Cosmic-Background-Bufferbloat-Detector I also ran into data representation issues - perhaps postgres isn't the right thing. 6: http://thread.gmane.org/gmane.linux.kernel.wireless.general/64733 7: https://github.com/dtaht/Cruft/blob/master/bloat/558-ath9k_bufferbloat.p= atch 8: https://lists.bufferbloat.net/pipermail/bloat-devel/2011-February/thread.ht= ml 9: Would people mind if it was more of a 1HR podcast than 30 minute exposition? We diverged off the bufferbloat/wireless topic several times, in interesting ways, and editing it down will take more time than I would like. -- Dave Taht http://nex-6.taht.net ------------------------------ Message: 2 Date: Wed, 16 Feb 2011 12:46:27 -0500 From: Sean Conner To: bloat@lists.bufferbloat.net Subject: [Bloat] Background Bufferbloat Detector Message-ID: <20110216174627.GA20215@brevard.conman.org> Content-Type: text/plain; charset=3Dus-ascii I've been thinking about this background bufferbloat detector, and I am wondering why you are bothering with NTP? I understand about the timestamps, but wouldn't it be easier if you had a program that sent packet= s at a known fixed rate? I wrote a simple program that sends a UDP packet every 20ms; the receiver (same program, different options) records when it received the packet (which should be 20ms since the last packet received). It then records the actual delta to a file (which can later be graphed). Running it I do see variations in the timings; I'm wondering if what I di= d is actually relevent to detecting bufferbloat? -spc (Also, just to mention: it can be used on an IPv6 network, and can handle multicast addresses for sending and receiving) ------------------------------ Message: 3 Date: Wed, 16 Feb 2011 11:48:56 -0700 From: d@taht.net (Dave =3D?utf-8?Q?T=3DC3=3DA4ht?=3D) To: Sean Conner Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Background Bufferbloat Detector Message-ID: <87k4gzke7b.fsf@cruithne.co.teklibre.org> Content-Type: text/plain; charset=3Dus-ascii Sean Conner writes: > I've been thinking about this background bufferbloat detector, and I > am wondering why you are bothering with NTP? I understand about the > timestamps, but wouldn't it be easier if you had a program that sent > packets at a known fixed rate? I wrote a simple program that sends a > UDP packet every 20ms; the receiver (same program, different options) > records when it received the packet (which should be 20ms since the > last packet received). It then records the actual delta to a file > (which can later be graphed). We can do the same with voip or tcp connections that are also timestamped. The problem is that it requires active measurement, and both ends to be co-operating. The NTP idea: NTP is a "background" process, one that uses statistically sparse data spread across millions of machines, that can be cut up in a dozen different interesting ways. There are only 10s of thousands of NTP servers in the world. Nearly every vendor configures their own NTP server choice for their OS or platform. Nearly ever ISP provides NTP servers. And they are all mostly slaved to atomic clocks. NTP also is sourced on port 123 and dest 123 - so we can tell the difference between NATTed and non-natted hosts I obviously am loving this idea... But it involves building a tool that the ISP or pool operator can run, in order to detect it server side. > Running it I do see variations in the timings; I'm wondering if what I = did > is actually relevent to detecting bufferbloat? Might be. > > -spc (Also, just to mention: it can be used on an IPv6 network, and ca= n > handle multicast addresses for sending and receiving) > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Taht http://nex-6.taht.net ------------------------------ Message: 4 Date: Wed, 16 Feb 2011 20:03:49 +0100 From: "Richard Scheffenegger" To: "Sean Conner" , Subject: Re: [Bloat] Background Bufferbloat Detector Message-ID: <6F4E15F3B5314030A7C34DCC49395D8B@srichardlxp2> Content-Type: text/plain; format=3Dflowed; charset=3D"iso-8859-1"; reply-type=3Doriginal Hi Sean, the ingenous idea of Dave was to exactly NOT have to deploy custom software across the ENTIRE internet to measuer bufferbloat. Furthermore, if you deploy custom software everywhere (remember that not even ECN made it into widespread deployment in the last decade, despite clear benefits to the global internet - not "just" measuring something), you'd even be better off measuring "real" traffic instead of some aritificial additional (side-band) traffic. Ie. there are a few vendors, wh= o have default QoS settings to make ICMP appear "good" (no bufferbloat), whil= e TCP and regular UDP traffic is clearly affected... NTP is one of ony a few protocols in wide-spread use, which actually allows some time-measurments from regular (already deployed, in wide-spread use) clients. And, like DNS, you only need to look at a couple of servers, instead of touching literally tens and hundreds of thousands of hosts, just to get a first glimpse... And yes, any custom protocol can clearly measure stuff much nicer and cleaner - but since you can NOT touch the other side (modify the TCP/IP stack, remotely launch custom software to send out funny traffic etc), you need to use what's already there. BTW: One additional idea which might be worthwhile to investigate: Perhaps Bittorrent Clients can be used to export the one-way delay, as measured by the ?TP protocol, to build an complementary background bufferbloat detector - uTP is currently the only protocol in wide-spread use, which measures one-way delay (instead of RTT), and automagically probe= s a wide swath of the internet. However, uTP also uses the one-way delay measurements in it's congestion control scheme, so it may "pollute" the measurements by itself... But if a TCP session is running in parallel and filling buffers, that should be a clear signal. And, hosting legal content on one's own Bittorrent Client should provide ample opportunity to get decent measurements, without the need to negotiate with someone else about taking readings off some debug-log from an NTP server.... Best regards, Richard ----- Original Message ----- From: "Sean Conner" To: Sent: Wednesday, February 16, 2011 6:46 PM Subject: [Bloat] Background Bufferbloat Detector > > I've been thinking about this background bufferbloat detector, and I am > wondering why you are bothering with NTP? I understand about the > timestamps, but wouldn't it be easier if you had a program that sent > packets > at a known fixed rate? I wrote a simple program that sends a UDP packet > every 20ms; the receiver (same program, different options) records when i= t > received the packet (which should be 20ms since the last packet received)= . > It then records the actual delta to a file (which can later be graphed). > > Running it I do see variations in the timings; I'm wondering if what I > did > is actually relevent to detecting bufferbloat? > > -spc (Also, just to mention: it can be used on an IPv6 network, and can > handle multicast addresses for sending and receiving) > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ------------------------------ _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat End of Bloat Digest, Vol 2, Issue 25 ************************************ The information contained in this e-mail is intended only for the individua= l or entity to whom it is addressed. Its contents (including any attachmen= ts) may contain confidential and/or privileged information. If you are not= an intended recipient, you must not use, disclose, disseminate, copy or pr= int its contents. If you receive this e-mail in error, please notify the s= ender by reply e-mail and delete the message