netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mohammad Rajiullah <mohammad.rajiullah@kau.se>
To: netdev@vger.kernel.org
Cc: Anna Brunstrom <anna.brunstrom@kau.se>,
	Per Hurtig <per.hurtig@kau.se>,
	eric.dumazet@gmail.com, ncardwell@google.com
Subject: Unexpected loss recovery in TLP
Date: Tue, 1 Sep 2015 11:00:49 +0200	[thread overview]
Message-ID: <0022CCFF-AA6E-4CB1-BEEF-D5B88CACA365@kau.se> (raw)

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/

             reply	other threads:[~2015-09-01  9:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-01  9:00 Mohammad Rajiullah [this message]
2015-09-01  9:36 Unexpected loss recovery in TLP Mohammad Rajiullah
2015-09-01 12:31 ` Eric Dumazet
2015-09-02  8:54   ` Mohammad Rajiullah
2015-09-02 13:34     ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0022CCFF-AA6E-4CB1-BEEF-D5B88CACA365@kau.se \
    --to=mohammad.rajiullah@kau.se \
    --cc=anna.brunstrom@kau.se \
    --cc=eric.dumazet@gmail.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=per.hurtig@kau.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).