Re: [PATCH] tcp: ack when we get an OOO/lost packet

[Andrei Borzenkov]

On 13.08.2015 16:59, Josef Bacik wrote:
> On 08/13/2015 04:19 AM, Andrei Borzenkov wrote:
> > On Wed, Aug 12, 2015 at 6:16 PM, Josef Bacik <address@hidden> wrote:
> > > While adding tcp window scaling support I was finding that I'd get
> > > some packet
> > > loss or reordering when transferring from large distances and grub
> > > would just
> > > timeout.  This is because we weren't ack'ing when we got our OOO
> > > packet, so the
> > > sender didn't know it needed to retransmit anything, so eventually it
> > > would fill
> > > the window and stop transmitting, and we'd time out.  Fix this by
> > > ACK'ing when
> > > we don't find our next sequence numbered packet.  With this fix I no
> > > longer time
> > > out.  Thanks,
> >
> > I have a feeling that your description is misleading. Patch simply
> > sends duplicated ACK, but partner does not know what has been received
> > and what has not, so it must wait for ACK timeout anyway before
> > retransmitting. What this patch may fix would be lost ACK packet
> > *from* GRUB, by increasing rate of ACK packets it sends. Do you have
> > packet trace for timeout case, ideally from both sides simultaneously?
>
> The way linux works is that if you get <configurable amount> of DUP
> ack's it triggers a retransmit.

Do you have pointers to documentation and code?

>                                I only have traces from the server
> since tcpdump doesn't work in grub (or if it does I don't know how to do
> it).

GRUB does not have tcpdump, but your switch quite likely has port mirroring.

>     The server is definitely getting all of the ACK's, and from my
> printf()'ing in grub we are either getting re-ordered packets (the most
> likely) or we are simply losing a packet here or there.  This is a
> pretty long distance and we have a lot of networking between Sweden and
> California so reordering or packet loss isn't out of the question.
>
> Regardless we definitely need to be ACK'ing packets that come in with
> the last seq we had as the spec says so the sender knows the last bit we
> had, otherwise we see timeouts once the window is full.

I'm fine with it, I just want to understand why it fixes anything and 
get commit message right.

> > Did you consider implementing receive side SACK BTW? You have the
> > right environment to test it :)
>
> So I found this bug while implementing SACK, and decided it was faster
> to just do this rather than add SACK.  This method is still exceedingly
> slow, I only get around 800kb/s over the entire transfer whereas I can
> sustain around 5.5 mb/s before we start losing stuff, so I'm definitely
> going to go back and try the timestamp echo stuff since the timeout
> stuff takes like 6 seconds, and then if that doesn't work bite the
> bullet and add SACK.
>
> But first I want to get my ipv6 patches right ;).  Thanks,
>
> Josef