Re: [Bloat] Background Bufferbloat Detector

["Richard Scheffenegger" <rscheff@gmx.at>]

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" <sean@conman.org>
To: <bloat@lists.bufferbloat.net>
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