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

[Yoshifumi Nishida <[e-mail]>]

Hi Neal,

Thanks for the info.
So, it seems to me that the linux code has the issue Kobby pointed out.
Or, am I missing something?
--
Yoshi


On Mon, Aug 15, 2016 at 6:18 PM, Neal Cardwell <[e-mail]> wrote:

> 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
>