| 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
| ||
|
Message-Id: <0022CCFF-AA6E-4CB1-BEEF-D5B88CACA365@kau.se> Date: Tue, 1 Sep 2015 11:00:49 +0200 From: Mohammad Rajiullah <mohammad.rajiullah@....se> To: netdev@...r.kernel.org Cc: Anna Brunstrom <anna.brunstrom@....se>, Per Hurtig <per.hurtig@....se>, eric.dumazet@...il.com, ncardwell@...gle.com 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 Mohammad Rajiullah Ph.D student Dept. of CS Karlstad University 054 700 1758 http://www.cs.kau.se/moharaji/ -- 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