netdev - Re: Socket buffer sizes with autotuning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Apr 2008 20:59:45 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	johnwheffner@...il.com
Cc:	rick.jones2@...com, netdev@...r.kernel.org
Subject: Re: Socket buffer sizes with autotuning

From: "John Heffner" <johnwheffner@...il.com>
Date: Tue, 22 Apr 2008 19:17:39 -0700

> On Tue, Apr 22, 2008 at 5:38 PM, Rick Jones <rick.jones2@...com> wrote:
> >  oslowest:~# netstat -an | grep ESTAB
> >  ...
> >  tcp    0 2760560 10.208.0.1:40500    10.208.0.45:42049   ESTABLISHED
> >  ...
> >
> >  Is this expected behaviour?
> 
> What is your interface txqueuelen and mtu?  If you have a very large
> interface queue, TCP will happily fill it up unless you are using a
> delay-based congestion controller.

Yes, that's the fundamental problem with loss based congestion
control.  If there are any queues in the path, TCP will fill them up.

Vegas and other similar techniques are able to avoid this, but come
with the fundamental flaw that it's easy to get them into situations
where they do not respond to increases in pipe space adequately, and
thus underperform compared to loss based algorithms.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html