Subject: [ledbat] The ICSI Netalyzr

From: Nicholas Weaver <[email-masked]>
Date: Mon, 8 Jun 2009 11:13:33 -0700

The public beta of the ICSI Netalyzr is now live at
http://netalyzr.icsi.berkeley.edu

This Java applet is designed to allow users to probe and discover
various properties about their network connection.  The many tests
include latency, bandwidth, and buffer size measurements.  Other, more
subtle tests detect port filtering and hidden proxies, the correct
operation of in-network HTTP caches, and the general health and
behavior of the DNS resolver.

In particular, the test includes buffer sizing and bandwidth, which  
directly relate to this working group.

---

From: Murari Sridharan <[email-masked]>
Date: Mon, 8 Jun 2009 11:43:03 -0700

This is great Nick, will try this out and get back to you. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicholas Weaver
Sent: Monday, June 08, 2009 11:14 AM
To: [email-masked]
Cc: Nicholas Weaver
Subject: [ledbat] The ICSI Netalyzr

_______________________________________________
ledbat mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 25 Jun 2009 05:26:25 -0700

Nick, do you have details on how you did the buffer measurements? I tried this on multiple modems (DSL, WiMAX clearwire) and almost always the buffering was ~4s. This may very well be the case but iw as a bit surprised to see the similar numbers across multiple access types. Has ton of useful info so I think this is very useful. 

Thanks
Murari

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 25 Jun 2009 05:43:34 -0700

On Jun 25, 2009, at 5:26 AM, Murari Sridharan wrote:

> Nick, do you have details on how you did the buffer measurements? I  
> tried this on multiple modems (DSL, WiMAX clearwire) and almost  
> always the buffering was ~4s. This may very well be the case but iw  
> as a bit surprised to see the similar numbers across multiple access  
> types. Has ton of useful info so I think this is very useful.

Its a very crude test:  It simply does a quiet (no traffic) ping to  
get the baseline RTT.  Then in blasts large UDP packets at full rate  
for 10 seconds.  During the 10 second sending interval, the last 5  
seconds are used to measure the RTT time for the packets received, and  
the difference is the estimated buffer size.

The packet rate during this 5 second period is used for the bandwidth  
estimation and reordering tracking.

It tends to produce somewhat weird results on wireless links where  
there is access control, so there may be delays in that case that  
would not be seen.  Or if there is a separate rate limit for UDP as  
well.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 25 Jun 2009 05:49:56 -0700

On Jun 25, 2009, at 5:43 AM, Nicholas Weaver wrote:

>> as a bit surprised to see the similar numbers across multiple  
>> access types. Has ton of useful info so I think this is very useful.
>
> seconds are used to measure the RTT time for the packets received,  
> and the difference is the estimated buffer size.

This also means that there is an effective max measured delay of <5  
seconds in practice, so this could easily be the phenomenon you are  
seeing.

Its really only designed to get ballpark-figures/feel: how many have  
annoying (>500ms) and bad (>1s) buffers.  From the point of view of  
LEDBAT, P2P designers, hardware designers, etc, its not the detailed  
figure but just the general ballpark thats of concern, because the  
details can vary so much by current conditions.