Re: [tcpm] Possible deadlock scenario with retransmission on both sides at the same time

[Neal Cardwell <[e-mail]>]

On Mon, Aug 15, 2016 at 6:39 PM, Yoshifumi Nishida
<[e-mail]> wrote:
> Hello,
> I personally think this is an interesting corner case for discussion.
> It looks a minor one, but I'm not not very sure if we can leave it for each
> implementation.
> I also guess a question would be if the BSD's fix is the best way for the
> issue.

Yes, I agree this is an interesting case for discussion.

FWIW, as a point of comparison for discussion, Linux's approach is a
little different: in Linux, the sender does not rewind SND.NXT on
retransmissions (RTO or Fast Recovery). Then the sender usually uses
SND.NXT for the seq field of outgoing pure ACKs. I say "usually"
because the Linux code has some code to deal with the case where the
receiver has withdrawn the receive window, so that SND.NXT is now
beyond the receive window. The code tcp_send_ack() uses to pick a seq
for outgoing pure ACKs looks like:

/* SND.NXT, if window was not shrunk.
 * If window has been shrunk, what should we make? It is not clear at
all.
 * Using SND.UNA we will fail to open window, SND.NXT is out of
window. :-(
 * Anything in between SND.UNA...SND.UNA+SND.WND also can be already
 * invalid. OK, let's make this for now:
 */
static inline __u32 tcp_acceptable_seq(const struct sock *sk)
{
        const struct tcp_sock *tp = tcp_sk(sk);

        if (!before(tcp_wnd_end(tp), tp->snd_nxt))
                return tp->snd_nxt;
        else
                return tcp_wnd_end(tp);
}

neal