[Bloat] Background Bufferbloat Detector

[Bloat] Background Bufferbloat Detector

[Sean Conner]

  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)

  

Re: [Bloat] Background Bufferbloat Detector

[Dave Täht]

Sean Conner <sean@conman.org> 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 can
> 	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

Re: [Bloat] Background Bufferbloat Detector

[Richard Scheffenegger]

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 

Re: [Bloat] Background Bufferbloat Detector

[Jesper Louis Andersen]

On Wed, Feb 16, 2011 at 20:03, Richard Scheffenegger <rscheff@gmx.at> wrote:
>
> 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 [..]
>
> 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....
>

The only "slight" problem is that not all clients support µTP. You are
limited to hacking either KTorrent 4.0+ (C++) or Vuze (Java). There
are C clients in progression however (Transmission, libtorrent). My
"own" client (in Erlang) has been putting off the implementation,
mostly because I'd rather see TCP fixed :) But perhaps this could be a
good opportunity to just hack up that protocol :)

BitTorrent also has the advantage that it often connects to hosts from
all over the world, so if there is any indication in the data, it
should definitely be able to see a trend.


-- 
J.

Re: [Bloat] Background Bufferbloat Detector

[Juliusz Chroboczek]

> There are C clients [implementing µTP] in progression however
> (Transmission, libtorrent).

FWIW, the µTP branch of Transmission is rock solid; the only known issue
is that the upload bandwidth control is broken for µTP.  We're planning
to merge it into trunk before the end of the week.

--Juliusz

Re: [Bloat] Background Bufferbloat Detector

[Dave Täht]

Jesper Louis Andersen <jesper.louis.andersen@gmail.com> writes:

> On Wed, Feb 16, 2011 at 20:03, Richard Scheffenegger <rscheff@gmx.at> wrote:
>>
>> 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 [..]
>>
>> 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....
>>
>
> The only "slight" problem is that not all clients support µTP. You are
> limited to hacking either KTorrent 4.0+ (C++) or Vuze (Java). There
> are C clients in progression however (Transmission, libtorrent). My
> "own" client (in Erlang) has been putting off the implementation,
> mostly because I'd rather see TCP fixed :) But perhaps this could be a
> good opportunity to just hack up that protocol :)
>
> BitTorrent also has the advantage that it often connects to hosts from
> all over the world, so if there is any indication in the data, it
> should definitely be able to see a trend.

This is one of the coolest applications of bittorrent technology I've
ever heard of. 

I was basically going through /etc/services, and /etc/protocols while
thinking about this.

I thought DNS might be an answer but it didn't contain enough
information... Snmp data contains a MIB that ostensibly reports on queue
size, but no time related info...

I only got as far as port 123 (NTP) which thus far seems a win. The
progress over on comp.protocols.time.ntp is also promising...

A problem in using bittorrent is in reporting, in that a bufferbloat
detecting torrent client or server would have to phone home somehow. On
the other hand, that could also be interestingly anonymized[1]

/me girds up to get through the remaining protocols - I am stopped at
port 179 right now, thinking hard....

-- 
Dave Taht
http://nex-6.taht.net

1: (Bt the solution is too long to fit into the margins of this email)

Re: [Bloat] Background Bufferbloat Detector

[Richard Scheffenegger]

FYI

http://www.ispreview.co.uk/story/2011/02/18/bittorrent-considers-release-of-world-broadband-isp-p2p-performance-report.html

Perhaps Simon Morris can be asked, if latency information can be released 
together with the bandwidth data taken off the global population of 
bittorrent clients...

Best regards,
   Richard Scheffenegger 

Re: [Bloat] Background Bufferbloat Detector

[Dave Täht]

"Richard Scheffenegger" <rscheff@gmx.at> writes:

> FYI
>
> http://www.ispreview.co.uk/story/2011/02/18/bittorrent-considers-release-of-world-broadband-isp-p2p-performance-report.html
>
> Perhaps Simon Morris can be asked, if latency information can be
> released together with the bandwidth data taken off the global
> population of bittorrent clients...

Tweeted @bittorrent. Got an email address? If so, please forward him the
thread.

http://bit.ly/hWJ5DQ

>
> Best regards,
>   Richard Scheffenegger 
>

-- 
Dave Taht
http://nex-6.taht.net

Re: [Bloat] Background Bufferbloat Detector

[Juliusz Chroboczek]

> Perhaps Simon Morris can be asked, if latency information can be
> released together with the bandwidth data taken off the global
> population of bittorrent clients...

Having the µTorrent clients spy on their users and phone home with the
information is not something the BTI managers are likely to feel good
about, no matter how inncocuous the information.  (Recall that their
user-base tends to be paranoid, and rightly so, and that µTorrent is not
open-source.)

On a related note, please feel free to develop a prototype based on
Transmission -- we've just finished merging µTP into the trunk:

  https://forum.transmissionbt.com/viewtopic.php?f=1&t=11130#p52594

--Juliusz