Repository navigation
DTLS should aggregate records #1487
Description
It looks like the BouncyCastle DTLS implementation doesn't aggregate multiple small DTLS records into a single UDP packet; instead it sends each record as a separate packet.
This is legal according to the spec, but inefficient, and makes DTLS more susceptible to packet loss.
How hard would it be to add this feature?
Activity
peterdettman commentedon Sep 13, 2023
Probably not a huge amount of work - up to a week or so for someone familiar with DTLS maybe. For handshake messages it's all internal stuff and should be straight forward. For application data packets there's the issue of how to do flushing without breaking backward compatibility, both in the API (if adding a method to an interface) and in default behaviour (probably need an auto-flush setting defaulting to true).
mondain commentedon Sep 12, 2026
This is addressed in #2440, which came out of the DTLS 1.3 work on #1468.
Handshake flights are now packed into as few datagrams as the MTU allows, for DTLS 1.2 as well as 1.3. On the existing aggregated-handshake test a client flight went from 5 datagrams to 3 for the same 1279 bytes.
Two details worth knowing. Only handshake records are packed: a non-handshake record flushes the buffer and leaves on its own, so write order is preserved, which matters for the implicit change_cipher_spec that must not overtake the flight it follows. And application data is deliberately untouched, one record per datagram as before; say the word if you would like that packed too.
One consequence for the test helpers:
MinimalHandshakeAggregatorandServerHandshakeDropperdecided what to do by inspecting only the first record of a datagram, which was exact while every datagram carried one record. Both now walk every record. There is a certain symmetry inMinimalHandshakeAggregatorhand-rolling the aggregation this issue asks the library to do, and the library now doing it natively.The PR stacks on #2439, so it is best read after that one.