netdev - Re: Unexpected loss recovery in TLP

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]

Message-ID: <1441110692.8932.168.camel@edumazet-glaptop2.roam.corp.google.com>
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