On 10/11/2011 02:13 PM, Eric Dumazet wrote:
> Le mardi 11 octobre 2011 à 13:58 +0200, Steinar H. Gunderson a écrit :
>> On Tue, Oct 11, 2011 at 12:27:17PM +0200, David Täht wrote:
>>> On my list already would be "an analysis of the effects of broken sack
>>> processing on linux 2.4.24-3.1", of which I *think* I've captured
>>> multiple examples of in the raw traces I've been collecting for
>>> months... (so if anyone is interested in the raw data, I can provide)
>> Do you have any more information? The only thing I could find online was that
>> there were SACK issues that were supposed to be fixed by 2.6.16; nothing
>> about a fix in 3.1 or post-3.1.
>>
> Of course, instead of discussing all linux stuff privately, it would be
> good to discuss with linux network maintainers.
>
> Or is the goal is to provide nice papers only ?

hmm?

0) I know there are enough linux network maintainers on the bloat list
for me to not consider anything typed here private! If you would prefer
that the previous message had been sent more broadly (netdev?) please
feel free to forward.

1) Lord, no, I'm far more interested in Linux working well, and having a
short diagnose, fix, test cycle, than having nice papers. Staying within
2 kernel release cycles is fastly superior to dozens.

Having nice papers helps, however, particularly on problems that have
existed a long time, and can be analyzed - in particular - as to the
effect on what other datasets that occurred during this period. On my
bad days I think we're going to have to re-run the last decade's worth
of experiments on ECN, congestion control, AQMs, and wireless across
every protocol that has ever been experimented with until the
bufferbloat problem is thoroughly licked.

on my good days... well, I don't have a lot of good days

2) My problem with publishing data collected from various tcp traces
I've been collecting is that of preserving privacy and anonymity to the
end user from where I collected the traces. For example, I got a very
interesting trace today showing very interesting ipv6 sack-related
behavior from a friend of mine's home over free.fr - but I'd be very
reluctant to make that widely available without permission.

Now, I don't have that restriction on data collected from more public
places, or in my own tests of cerowrt - but I have to say that I have
mostly only seen lots of sacks over the LFN, where my data sets are more
limited, at present.

If you are interested in collecting your own data set,
jupiter.lab.bufferbloat.net is a cerowrt router located in bloatlab 1 at
ISC.org in san francisco.

http://www.bufferbloat.net/projects/cerowrt/wiki/BloatLab_1

and is running linux 3.04, with netperf 2.5 enabled for both IPv6 and
ipv4, with all the cerowrt related configuration changes to date. High
on my list is measuring lfn performance with the vastly decreased amount
of buffering presently in that system both for single and multiple
streams - and then move on to analyzing the newer AQMs now in Linux.

io.lab.bufferbloat.net is an x86 netsonar box, running 2.6.16 - netperf
2.5 as well - configured as per the shipping linux defaults.

I hope fairly soon, to update another router (europa) to the latest and
greatest tcp/sack code now that the kernel.org problems are settling
down. It is my hope that this is the last tcp-related issue that can
skew the results - and for all I know, without analysis, may not skew
the results...

We are still playing with nuttcp and iperf, and there are several
bufferbloat related changes in the next version of netperf's svn tree
that need to settle down some.

If there is more I can do in providing test facilities and valuable
feedback to the networking maintainers, please let me know.

4) I personally find sack very interesting in the case of wireless as it
could be used very effectively (or so I think) in reducing the amount of
needed packet aggregation in wireless-n - and thus retries and
buffering, and I'm glad to see people working on improving it.

-- 
Dave Täht