[Bloat] Bloat Digest, Vol 2, Issue 25
Rupert Lloyd
rlloyd at metricowireless.com
Wed Feb 16 16:03:16 EST 2011
"bloat-request at lists.bufferbloat.net" <bloat-request at lists.bufferbloat.net> wrote:
Send Bloat mailing list submissions to
bloat at lists.bufferbloat.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.bufferbloat.net/listinfo/bloat
or, via email, send a message with subject or body 'help' to
bloat-request at lists.bufferbloat.net
You can reach the person managing the list at
bloat-owner at lists.bufferbloat.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bloat digest..."
Today's Topics:
1. new members, welcome! (Dave =?utf-8?Q?T=C3=A4ht?=)
2. Background Bufferbloat Detector (Sean Conner)
3. Re: Background Bufferbloat Detector (Dave =?utf-8?Q?T=C3=A4ht?=)
4. Re: Background Bufferbloat Detector (Richard Scheffenegger)
----------------------------------------------------------------------
Message: 1
Date: Wed, 16 Feb 2011 07:56:03 -0700
From: d at taht.net (Dave =?utf-8?Q?T=C3=A4ht?=)
To: bloat at lists.bufferbloat.net
Subject: [Bloat] new members, welcome!
Message-ID: <87ei78kozg.fsf at cruithne.co.teklibre.org>
Content-Type: text/plain; charset=us-ascii
We hit a milestone sometime early this morning. There are now 100
people on this mailing list!
New members, welcome! I'd love it if we/you'd could circle back to some
earlier threads in conversation[1], in particular I'd like to see the
glossary of agreed upon terms expanded. [2]
I'd like the "dark buffers" concept expanded [3] to include retransmits
or a new term invented.
If any of the 28 that have signed up for the wiki do not have editing
privs, please contact me off list.
Also we had much discussion, since fizzled out, on a good introductory
analogy to how the internet actually works. [4]
I confess that I'm a little buried right now in trying to assemble
additional hardware resources worldwide, while working at layers 8 & 9 of
the stack on the background bufferbloat detector idea. [5]. I just got a
large data set to play with.
Nathaniel's iwl patches look promising (only minor quibbles on the
Linux-wireless list[6] -
I am editing down a recorded conversation with Felix Fietkau (one of the
main openwrt & wireless developers and author of the minstrel rate
control algorithm) that started as a discussion of my
latency-smashing-yet-horrifying-to-him ath9k patch[7].
It later turned into a marvelous indepth discussion of how 802.11n
wireless actually works and some possible solutions[8], down to a low
level. I think it is well worth understanding for people more familiar
with wires or higher levels of the stack [9]. I like the concept of
"Bufferbloat Public Radio" in that sometimes it's just nice to get away
from the computer and listen to something while doing something else,
but that's me. Do others like this idea? We had a LOT of downloads
(probably over a 1000 by now) of jg's mp3.
Thanks everybody for your concern and interest in fixing bufferbloat.
1: https://lists.bufferbloat.net/pipermail/bloat/2011-February/thread.html
2: http://www.bufferbloat.net/projects/bloat/wiki/Glossary
3: http://www.bufferbloat.net/projects/bloat/wiki/Dark_buffers
4: https://lists.bufferbloat.net/pipermail/bloat/2011-February/000050.html
5: https://github.com/dtaht/Cosmic-Background-Bufferbloat-Detector
I also ran into data representation issues - perhaps postgres isn't
the right thing.
6: http://thread.gmane.org/gmane.linux.kernel.wireless.general/64733
7: https://github.com/dtaht/Cruft/blob/master/bloat/558-ath9k_bufferbloat.patch
8:
https://lists.bufferbloat.net/pipermail/bloat-devel/2011-February/thread.html
9: Would people mind if it was more of a 1HR podcast than 30 minute
exposition? We diverged off the bufferbloat/wireless topic several
times, in interesting ways, and editing it down will take more time than
I would like.
--
Dave Taht
http://nex-6.taht.net
------------------------------
Message: 2
Date: Wed, 16 Feb 2011 12:46:27 -0500
From: Sean Conner <sean at conman.org>
To: bloat at lists.bufferbloat.net
Subject: [Bloat] Background Bufferbloat Detector
Message-ID: <20110216174627.GA20215 at brevard.conman.org>
Content-Type: text/plain; charset=us-ascii
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)
------------------------------
Message: 3
Date: Wed, 16 Feb 2011 11:48:56 -0700
From: d at taht.net (Dave =?utf-8?Q?T=C3=A4ht?=)
To: Sean Conner <sean at conman.org>
Cc: bloat at lists.bufferbloat.net
Subject: Re: [Bloat] Background Bufferbloat Detector
Message-ID: <87k4gzke7b.fsf at cruithne.co.teklibre.org>
Content-Type: text/plain; charset=us-ascii
Sean Conner <sean at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
--
Dave Taht
http://nex-6.taht.net
------------------------------
Message: 4
Date: Wed, 16 Feb 2011 20:03:49 +0100
From: "Richard Scheffenegger" <rscheff at gmx.at>
To: "Sean Conner" <sean at conman.org>, <bloat at lists.bufferbloat.net>
Subject: Re: [Bloat] Background Bufferbloat Detector
Message-ID: <6F4E15F3B5314030A7C34DCC49395D8B at srichardlxp2>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
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 at conman.org>
To: <bloat at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
------------------------------
_______________________________________________
Bloat mailing list
Bloat at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
End of Bloat Digest, Vol 2, Issue 25
************************************
The information contained in this e-mail is intended only for the individual or entity to whom it is addressed. Its contents (including any attachments) may contain confidential and/or privileged information. If you are not an intended recipient, you must not use, disclose, disseminate, copy or print its contents. If you receive this e-mail in error, please notify the sender by reply e-mail and delete the message
More information about the Bloat
mailing list