netdev - Re: delayed ack timer, slow start and LRO

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:	Wed, 23 Jul 2008 15:01:44 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	jean-pascal billaud <billaud@...are.com>
cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: delayed ack timer, slow start and LRO

On Tue, 22 Jul 2008, jean-pascal billaud wrote:

Some corrections to assumptions below...

> I have a question related to the interaction between the delayed ack
> timer, slow start and LRO.
> 
> If the sender is doing a slow start, it is going to send one packet. The
> receiver's delayed ack timer is going to
> kick in and when it expires it will send a ack.
>
> Then the sender is going to send 2 packets now. LRO will aggregates them
> and the receiver's delayed ack timer is going
> to kick in, hoping another packet will arrives which is not going to be
> the case. When the timer expires it is going to
> send a ack.

What makes you think so? ...please see conditions in 
__tcp_ack_snd_check(). ...and like somebody else mentioned, there are 
quickacks in the picture as well (aka. Delayed ACK After Slow-Start, 
DAASS).

> The sender is now going to send 4 packets. LRO will aggregate them and
> the receiver's delayed ack timer is going to
> kick in, hoping another packet will arrives which is not going to be the
> case. When the timer expires it is going to
> send a ack.

Likewise, though in here tcp_max_burst would prevent as large growth as 
without lro (in other slow-starts than the initial one).

> The sender is now going to send ... So I am under the impression that
> due to the fact that LRO is aggregating packets,
> the delayed ack timer will kick in every single time.
> 
> So how is this fixed in linux ? I believe that ABC implementation will
> fix this issue even if I am not completely sure
> about that ?

ABC is nowadays disable by default because it was found to annoy small
segment sending folks enough for them to periodically to come up 
complaining with that "discovery" on netdev... :-) ...ABC is not 
that necessary in Linux anyway because Linux' segment based counting is 
not vulnerable to same kind of problems that byte-based approach would
be. Faster window growth during slow-start could be done without ABC 
though nobody has yet stepped in to do that (though I just got an idea 
while writing how to do that cleanly :-)).

> Also as LRO adds some latency, it seems possible to me that the sender
> retransmission timer will expires before the
> delayed ack timer expires.

In theory yes, but in reality that shouldn't happen since RTT is 
calculated so that it would include the delayed ACK delays.

> In this case, how is this gonna work ? Is it
> possible that the sender will stay stuck in
> its slow start trying to retransmit endlessly the same n packets ?

It wouldn't anyway, because receiver would ACK out-of-order (a duplicate 
below window) segments immediately. ...And we would resort FRTO in between 
too and RTO would be declared spurious and TCP would continue sending 
new data.

-- 
 i.
--
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