From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-04-iad.dyndns.com (mxout-214-iad.mailhop.org [216.146.32.214]) by lists.bufferbloat.net (Postfix) with ESMTP id 59E362E0226 for ; Wed, 16 Feb 2011 11:08:42 -0800 (PST) Received: from scan-01-iad.mailhop.org (scan-01-iad.local [10.150.0.206]) by mail-04-iad.dyndns.com (Postfix) with ESMTP id 8EFAC833769 for ; Wed, 16 Feb 2011 19:08:42 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 213.165.64.23 Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mail-04-iad.dyndns.com (Postfix) with SMTP id E76A1833732 for ; Wed, 16 Feb 2011 19:08:41 +0000 (UTC) Received: (qmail invoked by alias); 16 Feb 2011 19:08:39 -0000 Received: from unknown (EHLO srichardlxp2) [213.143.107.142] by mail.gmx.net (mp047) with SMTP; 16 Feb 2011 20:08:39 +0100 X-Authenticated: #20720068 X-Provags-ID: V01U2FsdGVkX1+IhrBrQq2IetkIRs9HV9H4SMbHMW8nbadP7MuPZR ES/RQlGBTiKg37 Message-ID: <6F4E15F3B5314030A7C34DCC49395D8B@srichardlxp2> From: "Richard Scheffenegger" To: "Sean Conner" , References: <20110216174627.GA20215@brevard.conman.org> Date: Wed, 16 Feb 2011 20:03:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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.5994 X-Y-GMX-Trusted: 0 Subject: Re: [Bloat] Background Bufferbloat Detector 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 19:08:42 -0000 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, who have default QoS settings to make ICMP appear "good" (no bufferbloat), while 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 probes 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 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 > 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