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-next>] [day] [month] [year] [list]
Date:	Tue, 1 Sep 2015 11:36:04 +0200
From:	Mohammad Rajiullah <mohammad.rajiullah@....se>
To:	netdev@...r.kernel.org
Subject: Unexpected loss recovery in TLP

Hi!

While measuring TLP’s performance for an online gaming scenario,  where both the client and the server send data, TLP 
shows unexpected loss recovery in Linux 3.18.5 kernel. Early retransmit fails in response 
to the dupack which is later resolved using RTO.  I found the behaviour consistent during the whole measurement period.
Following is an excerpt from the tcpdump traces (taken at the server) showing the behaviour:

0.733965    Client -> Server     HTTP 431 POST /Scores HTTP/1.1 
0.738355     Server -> Client HTTP 407 HTTP/1.1 200 OK 
0.985346     Server -> Client TCP 68 [TCP segment of a reassembled PDU]
0.993322     Client -> Server     HTTP 431 [TCP Retransmission] POST /Scores HTTP/1.1 
0.993352     Server -> Client TCP 78 [TCP Dup ACK 2339#1] 8081→45451 [ACK] Seq=186995 Ack=230031  Len=0   SLE=229666 SRE=230031
1.089327     Server -> Client TCP 68 [TCP Retransmission] 8081→45451 [PSH, ACK] Seq=186993 Ack=230031  Len=2  
1.294816     Client -> Server     TCP 78 [TCP Dup ACK 2340#1] 45451→8081 [ACK] Seq=230031 Ack=186652  Len=0   SLE=186993 SRE=186995
1.295018     Client -> Server     TCP 86 [TCP Dup ACK 2340#2] 45451→8081 [ACK] Seq=230031 Ack=186652  Len=0   SLE=186993 SRE=186995 SLE=186993 SRE=186995
1.541328     Server -> Client HTTP 407 [TCP Retransmission] HTTP/1.1 200 OK  

>From some kernel debug info (using printk ..) it appears that for some reason although the incoming dupack 
starts the early retransmit delay timer, it never expires. The above measurement was taken in a 
wireless environment. I also recreated the scenario in a wired network with synthetic traffic to have regular 
RTTs. The behaviour remains the same.  
0.287241     Client -> Server     TCP 316 58148 > colubris [PSH, ACK] Seq=251 Ack=501 Win=31744 Len=250 TSval=98871521 TSecr=98865126
0.287278     Server -> Client     TCP 316 colubris > 58148 [PSH, ACK] Seq=501 Ack=501 Win=31232 Len=250 TSval=98865134 TSecr=98871521
0.515351     Server -> Client     TCP 316 colubris > 58148 [PSH, ACK] Seq=751 Ack=501 Win=31232 Len=250 TSval=98865191 TSecr=98871521
0.518003     Client -> Server     TCP 316 [TCP Retransmission] 58148 > colubris [PSH, ACK] Seq=251 Ack=501 Win=31744 Len=250 TSval=98871579 TSecr=98865126
0.518021     Server -> Client     TCP 78 [TCP Dup ACK 12#1] colubris > 58148 [ACK] Seq=1001 Ack=501 Win=31232 Len=0 TSval=98865191 TSecr=98871579 SLE=251 SRE=501
0.518798     Server -> Client     TCP 316 [TCP Retransmission] colubris > 58148 [PSH, ACK] Seq=751 Ack=501 Win=31232 Len=250 TSval=98865192 TSecr=98871579
0.544700     Client -> Server     TCP 78 [TCP Window Update] 58148 > colubris [ACK] Seq=501 Ack=501 Win=32768 Len=0 TSval=98871585 TSecr=98865126 SLE=751 SRE=1001
0.549653     Client -> Server     TCP 86 [TCP Dup ACK 16#1] 58148 > colubris [ACK] Seq=501 Ack=501 Win=32768 Len=0 TSval=98871586 TSecr=98865126 SLE=751 SRE=1001 SLE=751 SRE=1001
0.778802     Server -> Client     TCP 316 [TCP Retransmission] colubris > 58148 [PSH, ACK] Seq=501 Ack=501 Win=31232 Len=250 TSval=98865257 TSecr=98871586



Cheers,
Mohammad


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

Powered by blists - more mailing lists