linux-kernel - Strange TCP SACK behaviour in Linux TCP

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-next>] [day] [month] [year] [list]

Message-ID: <44BD0A5F.4090001@kom.aau.dk>
Date:	Tue, 18 Jul 2006 18:20:47 +0200
From:	Oumer Teyeb <oumer@....aau.dk>
To:	linux-kernel@...r.kernel.org
Subject: Strange TCP SACK behaviour in Linux TCP

Hello Guys,

I have some questions regarding TCP SACK implementation in Linux .
As I am a subscriber, could you please cc the reply to me? thanks!

I am doing these experiments to find out the impact of reordering. So I 
have different TCP versions (newReno, SACK, FACk, DSACK, FRTO,....) as 
implemented in Linux. and I am trying their combination to see how they 
behave. What struck me was that when I dont use timestamps, introducing 
SACK increases the download time but decreases the total number of 
retransmissions.
When timestamps is used, SACK leads to an increase in both the download 
time and the retransmissions.

So I looked further into the results, and what I found was that when 
SACK  is used, the retransmissions seem to happen earlier .
at www.kom.auc.dk/~oumer/first_transmission_times.pdf
you can find the pic of cdf of the time when the first TCP 
retransmission occured for the four combinations of SACK and timestamps 
after hundrends of downloads of a 100K file for the different conditions 
under network reordering...

This explains the reason why the download time increases with SACK, 
because the earlier we go into fast recovery the longer the time we 
spend on congestion avoidance, and the longer the download time....

...but I couldnt figure out why the retransmissions occur earlier for 
SACK than no SACK TCP. As far as I know, for both SACK and non SACK 
cases, we need three (or more according to the setting) duplicate ACKs 
to enter the fast retransmission /recovery state.... which would have 
resulted in the same behaviour to the first occurance of a 
retransmission..... or is there some undocumented enhancment in Linux 
TCP when using SACK that makes it enter fast retransmit earlier... the 
ony explanation I could imagine is something like this

non SACK case
=============
1 2 3 4 5 6 7 8 9 10..... were sent and 2 was reorderd....and assume we 
are using delayed ACKs...and we get a triple duplicate ACK after pkt#8 
is received. (i.e 3&4--first duplicate ACK, 5&6..second duplicate ACK 
and 7&8...third duplicate ACK.....)...

so if SACK behaved like this...

3&4 SACKEd.... 2 packets out of order received
5&6 SACKEd....4 packets out of order received.... start fast 
retransmission....as reorderd is greater than 3.... (this is true when 
it comes to marking packets as lost during fast recovery, but is it true 
als for the first retransmission?)

.. any ideas why this is happening???

Thanks in advance,
Oumer

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/