tree 64768306c18b2d0f7294730600591238bd3b4e5b
parent 571c76e919c0c48219ced35bef83e1fc83b00eed
author David Benjamin <davidben@google.com> 1729634015 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1731368746 +0000

Use DTLS 1.3 ACKs to avoid retransmitting ACKed fragments

This implements the first part of ACK processing: track which parts of
each outgoing message have been ACKed, update when receiving an ACK, and
use it to reduce retransmits. To do this, we also need to track the last
handful of records we sent, and use that to correlate ACKs with packets.

Test this by extending the new retransmit fragment to manage ACKs. The
callback gets told record numbers, along with what message segments they
cover, and may choose to ACK them. If it does, the ReadRetransmit
expectations will be automatically updated.

For now, I've made no attempt to test or handle post-handshake messages.
That has a lot of subtle assumptions around there not being multiple
concurrent transactions, so I think we'll tackle this later.

This also does not handle:

- Triggering retransmits when we receive partial ACKs.
- Implicitly ACKing flights when we receive any part of the next flight.
- Any kind of sending ACKs.

Bug: 42290594
Change-Id: I9e81a7d5c8838d4d31fe828e9fd9871631fe38ed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72387
Reviewed-by: Nick Harper <nharper@chromium.org>
Commit-Queue: David Benjamin <davidben@google.com>