lkml.org 
[lkml]   [2020]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: RE: [PATCH 0/3] Fix reconnection latency caused by FIN/ACK handling race
    Date
    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)

    \
     
     \ /
      Last update: 2020-01-31 16:06    [W:3.162 / U:0.204 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site