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

[Yoshifumi Nishida <[e-mail]>]

Hi Neal,

Oh. I see. Thanks for the explanation.
I'd like to think about it a bit more.
Thanks,
--
Yoshi

On Sun, Aug 21, 2016 at 12:44 PM, Neal Cardwell <[e-mail]>
wrote:

> I am pretty sure Linux does not have the issue Kobby pointed out in this
> thread.
>
> At a high level Linux should be OK because it follows the principle
> David Borman laid out in his August 16 email: "ACK-only packets should
> be sent with the largest in-window sequence number that has ever been
> sent."
>
> Linux obeys that principle by using tp->snd_nxt to store the largest
> sequence number that has ever been sent, and having
> tcp_acceptable_seq() use tp->snd_nxt but clamp the outgoing sequence
> number to make sure it is in-window. To be able to do this, in Linux,
> the sender does not rewind tp->snd_nxt on retransmissions.
>
> neal
>
> On Sun, Aug 21, 2016 at 1:25 PM, Yoshifumi Nishida
> <[e-mail]> wrote:
> > 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
> >
> >
>