All of lore.kernel.org
 help / color / mirror / Atom feed
From: <sjpark@amazon.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'sjpark@amazon.com'" <sjpark@amazon.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"sj38.park@gmail.com" <sj38.park@gmail.com>,
	"aams@amazon.com" <aams@amazon.com>,
	SeongJae Park <sjpark@amazon.de>
Subject: Re: RE: [PATCH 0/3] Fix reconnection latency caused by FIN/ACK handling race
Date: Fri, 31 Jan 2020 16:05:44 +0100	[thread overview]
Message-ID: <20200131150544.26333-1-sjpark@amazon.com> (raw)
In-Reply-To: <dc37fb0dad3c4a5f9fd88eea89d81908@AcuMS.aculab.com> (raw)

On Fri, 31 Jan 2020 14:00:27 +0000 David Laight <David.Laight@ACULAB.COM> wrote:

> From: sjpark@amazon.com
> > Sent: 31 January 2020 12:24
> ...
> > The acks in lines 6 and 8 are the acks.  If the line 8 packet is
> > processed before the line 6 packet, it will be just ignored as it is not
> > a expected packet, and the later process of the line 6 packet will
> > change the status of Process A to FIN_WAIT_2, but as it has already
> > handled line 8 packet, it will not go to TIME_WAIT and thus will not
> > send the line 10 packet to Process B.  Thus, Process B will left in
> > CLOSE_WAIT status, as below.
> > 
> > 	 00 (Process A)				(Process B)
> > 	 01 ESTABLISHED				ESTABLISHED
> > 	 02 close()
> > 	 03 FIN_WAIT_1
> > 	 04 		---FIN-->
> > 	 05 					CLOSE_WAIT
> > 	 06 				(<--ACK---)
> > 	 07	  			(<--FIN/ACK---)
> > 	 08 				(fired in right order)
> > 	 09 		<--FIN/ACK---
> > 	 10 		<--ACK---
> > 	 11 		(processed in reverse order)
> > 	 12 FIN_WAIT_2
> 
> Why doesn't A treat the FIN/ACK (09) as valid (as if
> the ACK had got lost) and then ignore the ACK (10) because
> it refers to a closed socket?

Because the TCP protocol (RFC 793) doesn't have such speculation.  TCP is
stateful protocol.  Thus, packets arrived in unexpected state are not required
to be respected, AFAIU.

> 
> I presume that B sends two ACKs (06 and 07) because it can
> sit in an intermediate state and the first ACK stops the FIN
> being resent?

I think there is no such presume in the protocol, either.

> 
> I've implemented lots of protocols in my time, but not TCP.

If you find anything I'm misunderstanding, please don't hesitate to yell at me.
Hope the previous discussion[1] regarding this issue to be helpful.


Thanks,
SeongJae Park

[1] https://lore.kernel.org/bpf/20200129171403.3926-1-sjpark@amazon.com/

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)

      reply	other threads:[~2020-01-31 15:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 12:24 [PATCH 0/3] Fix reconnection latency caused by FIN/ACK handling race sjpark
2020-01-31 12:24 ` [PATCH 1/3] net/ipv4/inet_timewait_sock: Fix inconsistent comments sjpark
2020-01-31 14:54   ` Eric Dumazet
2020-01-31 15:09     ` sjpark
2020-01-31 12:24 ` [PATCH 2/3] tcp: Reduce SYN resend delay if a suspicous ACK is received sjpark
2020-01-31 15:01   ` Eric Dumazet
2020-01-31 16:12     ` sjpark
2020-01-31 16:55       ` Eric Dumazet
2020-01-31 17:05         ` sjpark
2020-01-31 17:08           ` Eric Dumazet
2020-01-31 15:10   ` Neal Cardwell
2020-01-31 18:12     ` Eric Dumazet
2020-01-31 22:11       ` Neal Cardwell
2020-01-31 22:17         ` SeongJae Park
2020-02-01  3:55           ` Neal Cardwell
2020-02-01  6:08             ` SeongJae Park
2020-02-01 13:30               ` Neal Cardwell
2020-01-31 22:53         ` Eric Dumazet
2020-02-03 15:40           ` David Laight
2020-02-03 15:54             ` Eric Dumazet
2020-01-31 12:24 ` [PATCH 3/3] selftests: net: Add FIN_ACK processing order related latency spike test sjpark
2020-01-31 14:56   ` Eric Dumazet
2020-01-31 15:13     ` sjpark
2020-01-31 14:00 ` [PATCH 0/3] Fix reconnection latency caused by FIN/ACK handling race David Laight
2020-01-31 15:05   ` sjpark [this message]

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=20200131150544.26333-1-sjpark@amazon.com \
    --to=sjpark@amazon.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=aams@amazon.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=sj38.park@gmail.com \
    --cc=sjpark@amazon.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.