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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
