Re: [Bloat] Background Bufferbloat Detector

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