From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by huchra.bufferbloat.net (Postfix) with ESMTP id 7EE0621F6F4 for ; Fri, 1 Aug 2014 06:20:59 -0700 (PDT) Received: from sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id DA0AD220BF; Fri, 1 Aug 2014 09:20:58 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2C9B3CA0DB; Fri, 1 Aug 2014 00:40:18 -0400 (EDT) From: Michael Richardson To: Sebastian Moeller In-reply-to: References: Comments: In-reply-to Sebastian Moeller message dated "Sat, 26 Jul 2014 13:18:34 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Aug 2014 00:40:18 -0400 Message-ID: <12287.1406868018@sandelman.ca> Sender: mcr@sandelman.ca Cc: Wes Felter , cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration. X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 13:20:59 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sebastian Moeller wrote: >> The trouble is that to measure bandwidth, you have to be able to send >> and receive a lot of traffic. > Well that is what you typically do, but you can get away with less > measurement traffic: in an ideal quiescent network sending two packets > back to back should give you the bandwidth (packet size / incoming ti= me > difference of both packets), or send two packets of different size > (needs synchronized clocks, then difference of packet sizes / > difference of transfer times). Apparently common 802.1ah libraries in most routers can do speed tests at layer-2 for ethernet doing exactly this. (Apparently, one vendor's code is in 90% of equipment out there, cause some of this stuff invoves intimate knowledge of PHYs and MII buses, and it's not worth anyone's time to write the code over again vs licensing it...) > But this still requires some service on the other side. You could try > to use ICMP packets, but these will only allow to measure RTT not > one-way delays (if you do this on ADSL you will find the RTT dominated > by the typically much slower uplink path). If network equipment would And correct me if I'm wrong, if you naively divide by two, you wind up overestimating the uplink speed. >> you can't just test that link, you have to connect to something beyo= nd >> that. > So it would be sweet if we could use services that are running on the > machines anyway, like ping. That way the =E2=80=9Cload=E2=80=9D of al= l the leaf nodes > of the internet continuously measuring their bandwidth could be handl= ed > in a distributed fashion avoiding melt-downs by synchronized > measurement streams=E2=80=A6 sadly, ICMP responses are rate limited, even when they are implemented in t= he fast path. PPP's LCP is not, AFAIK. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJT2xotAAoJEKD0KQ7Gj3P2CVEIAIxqcJsCeVEIbsrfx9PCe48f oBOua5QUAsqFI6xRzqImCXnKMNEryn2op32AeGIRIv4HrKtvGBZqYK4oQiwdvxt5 gOVFg7D5OR7VyjKbxfVTcDLTidztrUct9C+kLZW3gGol3uvVDDB0Qu6YBxc306E+ a6t8LwwzqWI9ya0CJBUk/jVpp6phxA14juIsfG9ZdgebOqj1RmC8R2sngyYecgFK Zvy3yFMBJlFOv5AvMelGoizP357FyDGMZ1+9jihzbnEWNtAPhm/uF+EDe8YW5g4m E4ruXUigM0IONrdz4/tenQ4cvFgQNDQBBKEAh+RNgBsnGGcnScfuYE+Eel7TIkg= =m6v7 -----END PGP SIGNATURE----- --=-=-=--