Re: [Bloat] Background Bufferbloat Detector

[d@taht.net (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)