[124269] in North American Network Operators' Group
Re: things to test
daemon@ATHENA.MIT.EDU (Simon Leinen)
Sun Mar 28 15:08:13 2010
From: Simon Leinen <simon.leinen@switch.ch>
To: Mikael Abrahamsson <swmike@swm.pp.se>
In-Reply-To: <alpine.DEB.1.10.1003280822110.28550@uplift.swm.pp.se> (Mikael
Abrahamsson's message of "Sun, 28 Mar 2010 08:32:08 +0200 (CEST)")
Date: Sun, 28 Mar 2010 21:07:30 +0200
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
[on residential broadband connections]
Mikael Abrahamsson writes:
> Some things that comes to mind:
> speed
> latency to some points geographically near the user
> MTU of the connection
> If PMTUD works or not
> queueing (FIFO or something "better")
> antispoofing (BCP38) compliance
> filtering (IPv6 transition protocols for instance, lots more possible)
> buffer depth ingress/egress
> ECN
> ISP provided DNS resolver properties (DNSSEC, EDNS etc)
That's an excellent start. I would add
* availability of global IP addresses (0-n)
* ability to connect to "unusual" ports (falls under "filtering")
* ability to accept connections
* interception of common TCP ports such as 80 and 25
* transparency for various header fields (addresses & ports=C2=B8 DSCP...)
* rate-limits for specific protocols (ICMP, BitTorrent...)
* latency and throughput for some popular sites/resources, including
those using CDNs, at various times of day/week
...and of course...
* availability of IPv6
> I'm sure there are lots more, and this could probably not be done
> using a web browser driven application, but instead would have to be
> an application, thus harder to get people to use generally.
> Any work being done in this area already that someone can point to?
Check out M-Lab - http://www.measurementlab.net/
--=20
Simon.
