Date: Wed, 21 Oct 2015 16:22:10 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: transport@FreeBSD.org Subject: Re: Correct inflight/pipe calculation Message-ID: <20151021232210.GL28288@strugglingcoder.info> In-Reply-To: <20151007172610.GA42742@strugglingcoder.info> References: <20151007172610.GA42742@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
--nrM5Z5VIJgwP9LWp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/07/15 at 10:26P, hiren panchasara wrote: > Randall and I have been poking at different ways to improve FreeBSD > tcp's reaction to loss. One of the major issue we found is that we do > not use information provided by SACK efficiently even though we do keep > the SACK scoreboard well in shape. Knowing amount of data in flight can > be really crucial and can help us use available capacity of the path > more efficiently. We currently do not have an accurate way of knowing > this information. >=20 > For example, inside tcp_do_segment(), while processing duplicate acks, > we try to compute amount of data inflight with: > awnd =3D (tp->snd_nxt - tp->snd_fack) + > tp->sackhint.sack_bytes_rexmit; >=20 > Which is incorrect as it doesn't take into account whats been already > sacked by the receiver. > There are definitely other places in the stack where we do this > incorrectly. >=20 > RFC 6675 provides guidance on how to implement calculations for > bytes in flight at any point in time. Randall and I came to a conclusion > that following can provide us inflight information almost(!) accurately > with least amount of code changes: >=20 > pipe =3D snd_max - snd_una - sackhint.sacked_bytes + sackhint.sack_bytes_= rexmit; >=20 > here, > snd_max: highest sequence number sent > snd_una: lowest sequence number sent but not yet cumulatively acked > sacked_bytes: total bytes sacked by receiver reported via SACK holes > sack_bytes_rexmit: total bytes retransmitted from holes in this recovery > period >=20 > Only missing piece in FreeBSD is sackd_bytes. This is basically total > bytes sacked by the receiver and it can be extracted from SACK holes > reported by the receiver. The approach we've decided to take is pretty > simple: we already process each ACK with sack holes in=20 > tcp_sack_doack() and extract sack blocks out of it. We'd now also track > this new variable there which keeps track of total sacked bytes > reported. >=20 > The downside with this approach is: > There is no persistent information about sacked bytes. We recalculate > it every time we get an ACK with sack holes in it. So if, for any > reason, receiver decides to drop sack info than we get incorrect > value for inflight. This may be also true when there are more holes but > receiver can only report 3 at a time. >=20 > I have actual code that I've been testing and if people see no major prob= lem > with this approach, I can put it up for review in phabricator. Well, I didn't receive any replies so here it is: https://reviews.freebsd.org/D3971 Please take a look at that. Cheers, Hiren --nrM5Z5VIJgwP9LWp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWKB4fXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l6qoH/097Rf3e5qQmlsjESRVr8+lh 8GQ+jaZ1kUh+YRcjq7yJpPhsyY8gdGYkzfDR9/rYrP2obuCT1f7IeoUftVZvUAtM sx0/NP6laikisEr8po+ndBRttJ/nSzKPYb0gx67Txhv0ydiNDzY/FQEgMjp9z9m5 0vJX/9hwrl7edUaotpbm8pugIkrLcAW2QDJuCPZws7/W6ZeQjBtoczwcw745pI8c K+mgbAYChEJOsW0tlF2Wp23BxjLoTPWr5ixIgGLVCQbCA0EPIG9CYYyN2aB4NRbC kIxwIZ9rt+3HrauV22yIyoJUkgEdrLNA256dU53qQkKhOr5cc3B6djPIFrH58ak= =Xze1 -----END PGP SIGNATURE----- --nrM5Z5VIJgwP9LWp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151021232210.GL28288>