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

[Neal Cardwell <[e-mail]>]

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