From jg at freedesktop.org  Wed Apr  9 12:23:40 2014
From: jg at freedesktop.org (Jim Gettys)
Date: Wed, 9 Apr 2014 15:23:40 -0400
Subject: [Netalyzr] Error reported on test...
Message-ID: <CAGhGL2CXmOyvQ8oPyC_CsVb5rczgO7F6TfaX8FtgAqffE4ZO4w@mail.gmail.com>

On testing today, netalyzr says:

Internal Server Error on Test Report

On the DNS tests.

Interestingly, it looks like one of the root servers isn't signed.

Nor is netalyzr.icsi.berkeley.edu signed :-(.

http://n1.netalyzr.icsi.berkeley.edu/restore/id=43ca253f-21232-e25490b9-5947-4036-9417/rd


Any progress on adding a test for whether flow queuing is enabled?  There
are commercial routers out there shipping fq_codel, and it would be
interesting to be able to watch it deploy.
                                         - Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20140409/80beedfc/attachment.html 

From nweaver at ICSI.Berkeley.EDU  Mon Apr 14 09:03:03 2014
From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver)
Date: Mon, 14 Apr 2014 09:03:03 -0700
Subject: [Netalyzr] Error reported on test...
In-Reply-To: <CAGhGL2CXmOyvQ8oPyC_CsVb5rczgO7F6TfaX8FtgAqffE4ZO4w@mail.gmail.com>
References: <CAGhGL2CXmOyvQ8oPyC_CsVb5rczgO7F6TfaX8FtgAqffE4ZO4w@mail.gmail.com>
Message-ID: <803AC204-47AA-44AB-8CA8-9BCF6759404E@icsi.berkeley.edu>

I responded just to Jim and not the group.  

But I should add some on the latter comment by Jim, as I didn't answer in as much detail and its probably of interest to the general group as well, and starting a discussion here would be good.


On Apr 9, 2014, at 12:23 PM, Jim Gettys <jg at freedesktop.org> wrote:
> Any progress on adding a test for whether flow queuing is enabled?  There are commercial routers out there shipping fq_codel, and it would be interesting to be able to watch it deploy.

This has been on our todo list for a while, but we haven't implemented it yet, and we are looking for feedback before we start coding.  

Our thoughts are as follows:

Create a "load traffic" that is 3 TCP streams.  3 seems to be a good consensus load value for bandwidth testing (its what speedtest.net uses).

In parallel, use our UDP ping test (the one we use just before to generate the quiescent latency) and use that to determine the RTT.

In cases where there is no smart queuing, this should get the same results as before, as 3 streams should start quickly enough that the 5 second rampup should leave things in steady state.

But if there is smart queueing, the UDP packets should (hopefully) be given enough priority to not see queuing delays.  Since UDP, rather than TCP, is used for the interactive tasks most affected by buffering issues, if the UDP is not given priority in the queueing delay, then this isn't an effective solution for the problem.


But overall we'd appreciate any thoughts others on this list would have in how to conduct a buffer-measurement experiment that is better than our current UDP-only test.

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver at icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20140414/3ae3ec16/attachment.bin 

From jg at freedesktop.org  Mon Apr 14 09:10:44 2014
From: jg at freedesktop.org (Jim Gettys)
Date: Mon, 14 Apr 2014 12:10:44 -0400
Subject: [Netalyzr] Error reported on test...
In-Reply-To: <803AC204-47AA-44AB-8CA8-9BCF6759404E@icsi.berkeley.edu>
References: <CAGhGL2CXmOyvQ8oPyC_CsVb5rczgO7F6TfaX8FtgAqffE4ZO4w@mail.gmail.com>
	<803AC204-47AA-44AB-8CA8-9BCF6759404E@icsi.berkeley.edu>
Message-ID: <CAGhGL2DN4o7yErCRffaiT6J-RnQe52BUmv5wm9bRCrLAeAyXeg@mail.gmail.com>

On Mon, Apr 14, 2014 at 12:03 PM, Nicholas Weaver <nweaver at icsi.berkeley.edu
> wrote:

> I responded just to Jim and not the group.
>
> But I should add some on the latter comment by Jim, as I didn't answer in
> as much detail and its probably of interest to the general group as well,
> and starting a discussion here would be good.
>
>
> On Apr 9, 2014, at 12:23 PM, Jim Gettys <jg at freedesktop.org> wrote:
> > Any progress on adding a test for whether flow queuing is enabled?
>  There are commercial routers out there shipping fq_codel, and it would be
> interesting to be able to watch it deploy.
>
> This has been on our todo list for a while, but we haven't implemented it
> yet, and we are looking for feedback before we start coding.
>
> Our thoughts are as follows:
>
> Create a "load traffic" that is 3 TCP streams.  3 seems to be a good
> consensus load value for bandwidth testing (its what speedtest.net uses).
>
> In parallel, use our UDP ping test (the one we use just before to generate
> the quiescent latency) and use that to determine the RTT.
>
> In cases where there is no smart queuing, this should get the same results
> as before, as 3 streams should start quickly enough that the 5 second
> rampup should leave things in steady state.
>
> But if there is smart queueing, the UDP packets should (hopefully) be
> given enough priority to not see queuing delays.  Since UDP, rather than
> TCP, is used for the interactive tasks most affected by buffering issues,
> if the UDP is not given priority in the queueing delay, then this isn't an
> effective solution for the problem.
>
>
?This will work. Doesn't matter whether you use a UDP ping test or not; you
could just as well arrange a ping operation on a separate TCP flow that you
are not driving to saturation. ?if the bottleneck link identifies it as a
separate flow and implements flow queuing, the observed time should not
significantly increase (or will only increase to the remaining uncontrolled
buffering at the bottleneck, a common situation since drivers may have
buffering out of control of a flow queuing algorithm).

Dave, any other suggestions?
                        - Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/netalyzr/attachments/20140414/2cf230c9/attachment.html 

From dave.taht at gmail.com  Mon Apr 14 10:48:40 2014
From: dave.taht at gmail.com (Dave Taht)
Date: Mon, 14 Apr 2014 10:48:40 -0700
Subject: [Netalyzr] Error reported on test...
In-Reply-To: <CAGhGL2DN4o7yErCRffaiT6J-RnQe52BUmv5wm9bRCrLAeAyXeg@mail.gmail.com>
References: <CAGhGL2CXmOyvQ8oPyC_CsVb5rczgO7F6TfaX8FtgAqffE4ZO4w@mail.gmail.com>
	<803AC204-47AA-44AB-8CA8-9BCF6759404E@icsi.berkeley.edu>
	<CAGhGL2DN4o7yErCRffaiT6J-RnQe52BUmv5wm9bRCrLAeAyXeg@mail.gmail.com>
Message-ID: <CAA93jw7hL61YOXXnfjZqTos0=TWxJFkm1AqteCJePP=CTrtUHg@mail.gmail.com>

On Mon, Apr 14, 2014 at 9:10 AM, Jim Gettys <jg at freedesktop.org> wrote:
>
>
>
> On Mon, Apr 14, 2014 at 12:03 PM, Nicholas Weaver
> <nweaver at icsi.berkeley.edu> wrote:
>>
>> I responded just to Jim and not the group.
>>
>> But I should add some on the latter comment by Jim, as I didn't answer in
>> as much detail and its probably of interest to the general group as well,
>> and starting a discussion here would be good.

I am inclined to let you independently come up with ideas and not say anything
in the interest of you folk finding newer and more creative analysis methods.

But, oh, well, here goes...

please take a look at netperf-wrapper's test and analysis suite.

While it's sprouted a gui and a ton of new tests and plots, it's still
only a tool
a professional could love. Do something simpler please. :) Suggestions
as to better plotting mechanisms and tests highly desired.

>>
>> On Apr 9, 2014, at 12:23 PM, Jim Gettys <jg at freedesktop.org> wrote:
>> > Any progress on adding a test for whether flow queuing is enabled?
>> > There are commercial routers out there shipping fq_codel, and it would be
>> > interesting to be able to watch it deploy.

I'd be happy to have any data on what extent sfq, drr, and sqf are deployed.

free.fr (the biggest fq_codel deployment I know of) deployed sfq 7+
years back and
it still runs on most of their older cpe that can't do fq_codel. Over
5 mil users in total.

sfq is not only fq but has a fairly low (127) packet limit by default.

I'd love to know if the existing netalyzer tests of stuff from their AS number
showed anything interesting, be that measured buffer size or other behaviors.

SFQ had a problem in that permutation of the
hash happened every 10 seconds, which would reorder and frequently reset
big tcp flows (which was part of it's hidden advantages). You can clearly
see this SFQ behavior in longer term flow data.

Free's fq_codel enabled revolution v6 box started to deploy in august 2012.
optimized on the upload only.

Sadly, in very few cases I expect to see much except policing on the
download side.

Perhaps by developing a new test that tests for fq techniques, older data can be
reanalyzed?

>> This has been on our todo list for a while, but we haven't implemented it
>> yet, and we are looking for feedback before we start coding.
>>
>> Our thoughts are as follows:
>>
>> Create a "load traffic" that is 3 TCP streams.  3 seems to be a good
>> consensus load value for bandwidth testing (its what speedtest.net uses).

I assume this is a test that does upload + measurement, and then download
+ measurement, not all 3 at the same time?

Scaling up tcp is a function of the RTT and bandwidth to the test
server, as well as other factors,
like tcp itself.

RRUL does all three tests at the same time, and tosses in
classification as well.

For example it took 15 seconds at a 65ms baseline RTT to get the worst
case behavior
out of a cable modem and CMTS in this test series using the rrul test.

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

At a 15ms RTT you'd think it'd be faster to peak, right? No... roughly
same cable modem,
same service, different tcp, 1/4 the RTT.

http://snapon.lab.bufferbloat.net/~cero2/armory.com/unshaped/149.20.63.30.tcp_download.comcast_unshaped.svg

There are a ton of other plots and data from that test series you can
browse through and reparse through netperf-wrapper's gui

http://snapon.lab.bufferbloat.net/~cero2/armory.com/

>> In parallel, use our UDP ping test (the one we use just before to generate
>> the quiescent latency) and use that to determine the RTT.

I have seen qos systems that blithely optimize all udp traffic over tcp traffic.

So I might argue for an additional ping-like over over tcp...

I'd also prefer a voip-like flow (20ms interval independent
isochronous streams),
rather than "ping".

>> In cases where there is no smart queuing, this should get the same results
>> as before, as 3 streams should start quickly enough that the 5 second rampup
>> should leave things in steady state.

For TCP depends on the RTT and bandwidth and other factors per above.

>> But if there is smart queueing, the UDP packets should (hopefully) be
>> given enough priority to not see queuing delays.  Since UDP, rather than
>> TCP, is used for the interactive tasks most affected by buffering issues, if
>> the UDP is not given priority in the queueing delay, then this isn't an
>> effective solution for the problem.

Reasoning is slightly flawed, but I can live with it as a simple test. We test
both udp and icmp at the same time with different classifications in
the rrul suite.

Plug - a simple test for e2e (in both directions) diffserv
preservation would be nice.

I ran out of time funding and inspiration to get "twd" off the ground.

https://github.com/dtaht/twd/blob/master/rfc/middle.mkd#tos-field-preservation-tests

>>
>
> This will work. Doesn't matter whether you use a UDP ping test or not; you
> could just as well arrange a ping operation on a separate TCP flow that you
> are not driving to saturation. if the bottleneck link identifies it as a
> separate flow and implements flow queuing, the observed time should not
> significantly increase (or will only increase to the remaining uncontrolled
> buffering at the bottleneck, a common situation since drivers may have
> buffering out of control of a flow queuing algorithm).
>
> Dave, any other suggestions?

Well, moving forward, netanlyzer detecting the codel portion of the algorithm
would be nice - seeing a drop rate increase along a rough invsqrt interval would
be good detection mechanism. You can see codel's drop behavior vs tail
drop here:

http://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf

I have had plenty of users saying the codel wasn't working that they
were detecting
500ms worth of buffering....

>                         - Jim
>



-- 
Dave T?ht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article