netdev - RE: A Linux TCP SACK Question

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:	Mon, 14 Apr 2008 19:48:26 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Wenji Wu <wenji@...l.gov>
cc:	'Sangtae Ha' <sangtae.ha@...il.com>,
	'John Heffner' <johnwheffner@...il.com>,
	'Netdev' <netdev@...r.kernel.org>
Subject: RE: A Linux TCP SACK Question

On Mon, 14 Apr 2008, Wenji Wu wrote:

> The latest results have been posted to:
> 
> https://plone3.fnal.gov/P0/WAN/Members/wenji/tcp_dump_files_sack/
> 
> The kernel under test is: Linux-2.6.25-rc9. I have checked with its
> changelog, which shows that your latest fix is included.

Hmm, now there are even less retransmissions (barely some with
the SACK in the end).

I suppose the reordering detection is good enough to kill them. ...You 
could perhaps figure that out from MIBs if you would want to.

> In the tests, I vary the tcp_frto (0, 1, and 2) with SACK On/Off.

...I should have said it more clearly last time already that these are 
not significant with your workload.

> The experiment works as:
> 
>       Sender --- Router --- Receiver
> 
> Iperf is sending from the sender to the receiver. In between there is an
> emulated router which runs netem. The emulated router has two interfaces,
> both with netem configured.  One interface emulates the forward path and the
> other for the reverse path. Both netem interfaces are configured with 1.5ms
> delay and 0.15ms variance. No packet drops in tests and packet capturing.

...How about this theory:

Forward path reordering causes duplicate ACKs due to old segments. These 
are threated differently for NewReno and SACK:

NewReno => Sends new data out (limited xmit; it's not limited to two 
           segments in linux as per RFC, however, RFC doesn't consider
	   autotuning of DupThresh either)
SACK =>    No new SACK block discovered. Packets in flight remains the 
           same, and thus no new segment is sent.

...What do other think?

I guess it should be visible with fwd path reordering alone, though the 
added distance with reverse path reordering might act as amplifier 
because NewReno benefits from shorter RTTed packets when fwd path 
old segment arrived while SACK losses its ability to increase 
outstanding data...

...A quick look into it with tcptrace's outstanding date plot, it seems 
that NewReno levels ~100000 and SACK ~68000.

...I think SACK just knows too much? :-/

> All of these systems are multi-core platforms, with 2G+ CPU. I run
> TOP to verify, CPUs are idle most of time.

Thanks for adding this for other. I agree with you that this is not
an cpu horsepower issue.

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