Sebastian Moeller <moeller0@gmx.de> 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 time
    > 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 beyond
    >> that.

    > 	So it would be sweet if we could use services that are running on the
    > machines anyway, like ping. That way the “load” of all the leaf nodes
    > of the internet continuously measuring their bandwidth could be handled
    > in a distributed fashion avoiding melt-downs by synchronized
    > measurement streams…

sadly, ICMP responses are rate limited, even when they are implemented in the
fast path.  PPP's LCP is not, AFAIK.

-- 
Michael Richardson
-on the road-