netdev - Re: TCP IPv4 strange retransmits

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0803052124570.11034@kivilampi-30.cs.helsinki.fi>
Date:	Wed, 5 Mar 2008 21:32:27 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Arnd Hannemann <hannemann@...s.rwth-aachen.de>
cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: TCP IPv4 strange retransmits

On Wed, 5 Mar 2008, Arnd Hannemann wrote:

> Ilpo Järvinen wrote:
> > On Wed, 5 Mar 2008, Arnd Hannemann wrote:
> > 
> >> Ilpo Järvinen wrote:
> > 
> > ...
> > /* Heurestics to calculate number of duplicate ACKs. There's no dupACKs
> 
> Great :-) But shouldn't it read "heuristics" ?

Sure, a Finnish vovel leaked into it. If somebody would have asked,
I wouldn't even have known which was the right form in English.

> > Another thing you should consider is reordering detection which hopefully 
> > worked at 13:08:20.667529 through the newly discored SACK block which is 
> > _lower_ than the highestmost SACK block received so far. That results in 
> > FACK -> RFC3517, FACK is built on inorder assumptions and whenever we find 
> > that untrue, e.g., due to SACK/ACK for non-rexmit when something larger 
> > has been confirmed received we disable it. Ah, but this was 2.6.24.y? It 
> 
> Yes, it was 2.6.24.2. Actually you can see reordering detection at work here[3],
> the tool[4] we are using to measure TCP throughput samples the tcp_info struct and the
> column #reor should reflect tp->reordering.
> First it is 3 then it grows up to 16. Off course this is only a hint because
> tcp_info is only sampled every 50ms in this example, but at least it shows that some
> reordering detection took place...

Ok. I usually can determine exact events from tcpdump, too used to
them... :-)

> > doesn't yet do RFC3517 IIRC, but has something remotely resembling 
> > newreno, but only for the first packet because the next cumulative ACK may 
> > often trigger timedout loop which basically marks everything lost (I don't 
> > remember if the latter was changed to occur only with FACK ages ago or 
> > not).
> 
> Not sure if I understood this. Will have to look into this some more.

Before 2.6.25, the non-FACK SACK was quite strange mixture of things. 
It won't resemble anything RFCish by any means, unless timedout loop 
(see the loop that plays with scorboard_skb_hint) was already changed to 
be used with FACK only in 2.6.24 or before it (I don't remember if I ever 
submitted that because making non-FACK SACK behave very close to what 
RFC3517 does was just around the corner as well).


-- 
 i.