Currently, if we receive a transport message for a non-established session, the packets are dropped. Apparently, the Go implementation buffers those packets for some amount of time, to allow for a reordered handshake packet to establish the session without packet loss.
We should consider doing the same. I need to think about the potential scope for reordering here, and how robust we want to be against that vs. the additional resource consumption from buffering these packets.
Additionally, we should look at what the send-side buffer size is, and consider adjusting it. Currently in rust it's 32 packets, picked somewhat arbitrarily as a reasonable amount of buffering in the happy path, without causing a ton of resource bloat in the unhappy path. The Go implementation is apparently much more generous with its buffering here, although the spec doesn't specify a required amount of buffering.
Currently, if we receive a transport message for a non-established session, the packets are dropped. Apparently, the Go implementation buffers those packets for some amount of time, to allow for a reordered handshake packet to establish the session without packet loss.
We should consider doing the same. I need to think about the potential scope for reordering here, and how robust we want to be against that vs. the additional resource consumption from buffering these packets.
Additionally, we should look at what the send-side buffer size is, and consider adjusting it. Currently in rust it's 32 packets, picked somewhat arbitrarily as a reasonable amount of buffering in the happy path, without causing a ton of resource bloat in the unhappy path. The Go implementation is apparently much more generous with its buffering here, although the spec doesn't specify a required amount of buffering.