Correct inflight/pipe calculation

[hiren panchasara]

On 10/21/15 at 04:22P, hiren panchasara wrote:
> 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.
> > 
> > For example, inside tcp_do_segment(), while processing duplicate acks,
> > we try to compute amount of data inflight with:
> > awnd = (tp->snd_nxt - tp->snd_fack) +
> > 	tp->sackhint.sack_bytes_rexmit;
> > 
> > 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.
> > 
> > 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:
> > 
> > pipe = snd_max - snd_una - sackhint.sacked_bytes + sackhint.sack_bytes_rexmit;
> > 
> > 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
> > 
> > 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 
> > 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.
> > 
> > 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.
> > 
> > I have actual code that I've been testing and if people see no major problem
> > 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.

Closing the loop. This has been committed:
https://svnweb.freebsd.org/changeset/base/290122

Cheers,
Hiren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-transport/attachments/20151028/ffafe538/attachment.bin>