netdev - Re: setsockopt()

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]

Message-ID: <1e41a3230807081210m7b2816eeyb83ba0ab1937b50b@mail.gmail.com>
Date:	Tue, 8 Jul 2008 12:10:26 -0700
From:	"John Heffner" <johnwheffner@...il.com>
To:	"Rick Jones" <rick.jones2@...com>
Cc:	netdev@...r.kernel.org
Subject: Re: setsockopt()

On Tue, Jul 8, 2008 at 11:16 AM, Rick Jones <rick.jones2@...com> wrote:
> John Heffner wrote:
>> Jerry's optimization is a sender-side change.  The fact that the
>> receiver announces enough window is almost certainly the right thing
>> for it to do, and (I hope) this will not change.
>
> It just seems to be so, well, trusting of the sender.

Really, it's not trusting the sender at all.  The way it works is that
a receiver sizes its buffer based strictly on *how much its
application has read in an RTT*.  It the application reads slowly, it
uses a small buffer.  If it reads quickly, it increases the size so
that the TCP buffer is big enough to not be the limiting factor (if
system limits allow).  That's about all there is to it.

The only effect the sender has is that it it sends slowly, it bounds
the rate at which the receiver can read, and consequently results in
an appropriately small receive buffer.

The issue you're talking about is when the RTT gets inflated by
filling a buffer somewhere in that path -- in your case specifically
in the sender's interface queue.  When the RTT gets inflated, the
receiver will continue to track it, and continue announcing a window
large enough that it doesn't limit the sender's window.  In this case,
it is not really paying a penalty, since it's keeping up and it
doesn't actually have to buffer any data.  It will happily let the
sender continue to fill its own buffers, and the sender will pay the
penalty.

The receiver *can* try to do something about this situation, basically
by seeing that the RTT is increasing, and not using the higher RTT
values in its calculation.  However, this is a very dangerous game,
and comes with all the issues of delay-based congestion control.
(Basically, you can't tell if your flow is the one causing the queuing
or if it's cross/reverse-path traffic.  Or if increased delay is
caused by a routing change.  Or wireless link layer games.)  If you're
going to try to solve this problem, the sender is the better place to
do it, because it has better information, and because it pays the
higher cost.

  -John
--
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