| 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
| ||
|
Date: Tue, 01 Sep 2015 05:31:32 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Mohammad Rajiullah <mohammad.rajiullah@....se> Cc: netdev@...r.kernel.org Subject: Re: Unexpected loss recovery in TLP On Tue, 2015-09-01 at 11:36 +0200, Mohammad Rajiullah wrote: > 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 > Hello Mohammad It would be nice you reproduce the problem with packetdrill and possibly using a more recent kernel. Having a packetdrill test is easier to demonstrate the problem and testing a fix if needed. Thanks ! -- 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