Date: Wed, 16 Mar 2016 07:21:13 -0700 From: "Jonathan T. Looney" <jtl@freebsd.org> To: hiren panchasara <hiren@strugglingcoder.info>, <freebsd-transport@freebsd.org> Subject: Re: Updating send window (snd_wnd) Message-ID: <D30EAF68.553A1%jlooney@juniper.net> In-Reply-To: <20160316014647.GA93218@strugglingcoder.info> References: <20160316014647.GA93218@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/15/16, 6:46 PM, "hiren panchasara" <owner-freebsd-transport@freebsd.org on behalf of hiren@strugglingcoder.info> wrote: >While discussing an issue we are seeing in field, Jonathan pointed out >another issue where snd_wnd can underflow and he created a review for it >with a possible fix: https://reviews.freebsd.org/D5625 > >But he also raised a valid point of whether that specific logic is >correct/needed or not. I.e. should we decrement snd_wnd by number of bytes >acked when we are anyhow going to get window information from the >client? Hiren, Thanks for starting this discussion! I wrote the review to add underflow prevention with the idea that underflow prevention is "easy", while this discussion will probably be "harder". Partly, that was because I had begun to think further through my own question. :-) I think a summary of the way things *should* work today is: A. We should always trust the "current" window sent by the remote host. B. When we don't know the "current" window send by the remote host, we should decrement our local copy of the send window as we use window space. The trick here is the word I set off in quotes in (A): "current". If all packets are in order, this is easy: just always use the window in the ACK from the client. When packets arrive out-of-order, things become more tricky. Which window advertisement do you believe? I think that is the point of the "step6" logic Hiren quoted. (However, I'm not sure that the "step6" logic works correctly. For example, what if you have a retransmission from the remote side? In that case, a newer packet could have an older sequence number. But, let's leave that aside for the moment and assume it does work correctly.) I *believe* it is correct to say that we should always be able to trust the window advertised by any packet that ACKs new bytes. (In general, it should be true that any packet that moves the ACK was sent later than any other packet we've received so far.) And, we probably *should* trust any larger window advertisement that doesn't change the ACK. When we are between packets that authoritatively set the window, we can just keep decrementing our local copy of the window as the remote side ACKs more bytes. But, think closely about that last sentence: do we really ever need to worry about step (B)? When we get a packet which ACKs new bytes, isn't that packet - almost by definition - the latest packet? It seems to me that step (B) may have the greatest implications in a situation where we have lots of SACKs, etc. going on and you MAY be able to open the window slightly sooner if you can sift through that to discern which window advertisement is the latest. But, even that shouldn't require *decrementing* the window as the remote side ACKs new bytes. By definition, isn't the window advertised in a packet that ACKs new bytes the latest word on available space on the remote host? In short, I just don't see a use case for step (B) above. It seems to me that anytime we have a packet that ACKs new bytes, it - by definition - contains the "current" window, and we should just use it. Sorry for the long, convoluted email. But, like many things involving the decades-old TCP code, the very topic is long and convoluted. :-) Jonathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D30EAF68.553A1%jlooney>