public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Per Hurtig <per.hurtig@kau•se>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: "Nandita Dukkipati" <nanditad@google•com>,
	Netdev <netdev@vger•kernel.org>,
	"Anna Brunström" <anna.brunstrom@kau•se>,
	mohammad.rajiullah@kau•se, "Neal Cardwell" <ncardwell@google•com>,
	"Sergei Shtylyov" <sergei.shtylyov@cogentembedded•com>
Subject: Re: [PATCH] tcp: fixing TLP's FIN recovery
Date: Mon, 09 Jun 2014 17:56:39 +0200	[thread overview]
Message-ID: <5395D937.5060801@kau.se> (raw)
In-Reply-To: <1402326259.3645.374.camel@edumazet-glaptop2.roam.corp.google.com>



On mån  9 jun 2014 17:04:19, Eric Dumazet wrote:
> On Mon, 2014-06-09 at 16:42 +0200, Per Hurtig wrote:
>> Tried to run the script, but I don't have the "common/defaults" and the
>> test scripts from the git repository fails on all TCP tests for Linux.
>> The results I listed in the enclosed packet traces are from two real
>> machines communicating with each other (with fresh net-next kernels and
>> TLP without the zero probe check), so I tend to rely more on those
>> results.
>
> Do not top post on netdev.
>
> We at Google run about 1000 packet drill tests for any functional change
> in TCP stack. This is the only way we can scale.
>
> We are not 'studying by hand' various tcpdumps when a tool can do it
> properly.
>
> Nandita asked you give a pointer to the source code explaining how fast
> retransmit was done for this specific case, but you provided a tcpdump,
> which hardly can be reproduced and be the answer to the question.
>
> So now, we are trying to have a test to reproduce the issue and check
> the fix is complete.
>
> So far, I am not really convinced. It seems the FIN _is_ retransmitted,
> but I do not see the SACK for this RTX is properly handled in time.
>
> Its one thing checking the FIN is retransmitted, its another to check
> that the SACK will trigger sensible behavior.
>
> If you carefully check your tcpdump, you'll see there is the same
> problem, and you missed it, while packetdrill exactly pointed it.
>
> Thanks
>
>

Ok, I guess you mean that the retransmission was not fast enough? But 
will the same not happen if the original FIN is not lost and triggers a 
SACK (i.e., if the two last data segments are still lost)?

Cheers,
Per

  reply	other threads:[~2014-06-09 15:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-06 18:46 tcp: fixing TLP's FIN recovery Per Hurtig
2014-06-06 19:07 ` Eric Dumazet
2014-06-07 11:10   ` [PATCH] " Per Hurtig
2014-06-07 13:56     ` Sergei Shtylyov
2014-06-07 14:34       ` Per Hurtig
2014-06-08  2:58         ` Eric Dumazet
2014-06-08  7:41           ` Per Hurtig
2014-06-08 16:35             ` Eric Dumazet
2014-06-09  7:04               ` Nandita Dukkipati
2014-06-09  7:02             ` Nandita Dukkipati
2014-06-09 13:13               ` Per Hurtig
2014-06-09 14:33                 ` Eric Dumazet
2014-06-09 14:39                   ` Eric Dumazet
2014-06-09 14:42                   ` Per Hurtig
2014-06-09 15:04                     ` Eric Dumazet
2014-06-09 15:56                       ` Per Hurtig [this message]
2014-06-09 16:15                         ` Eric Dumazet
2014-06-09 16:24                           ` Eric Dumazet
2014-06-09 18:33                             ` Eric Dumazet
2014-06-12 14:21               ` Weiping Pan
2014-06-12 14:32                 ` Eric Dumazet
2014-06-12 15:08                   ` [PATCH v2 1/1] " Per Hurtig
2014-06-12 15:28                     ` Eric Dumazet
2014-06-12 17:36                       ` Nandita Dukkipati
2014-06-12 17:46                         ` Neal Cardwell
2014-06-12 18:06                     ` David Miller
2014-10-07 15:03                       ` Josh Hunt
2014-10-07 20:17                         ` David Miller

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=5395D937.5060801@kau.se \
    --to=per.hurtig@kau$(echo .)se \
    --cc=anna.brunstrom@kau$(echo .)se \
    --cc=eric.dumazet@gmail$(echo .)com \
    --cc=mohammad.rajiullah@kau$(echo .)se \
    --cc=nanditad@google$(echo .)com \
    --cc=ncardwell@google$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=sergei.shtylyov@cogentembedded$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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