Cameron Bytheway

I've got a PR that does exactly that https://github.com/aws/s2n-tls/pull/3118

One thing we need to call out is after enabling this, there will be data stored in the connection's buffer and may need to be flushed, even though we indicated...

In #886, the `ipv6` feature flag was removed from platform so I think core should do the same and configure this value based on the actual IP address for the...

Since the qlog spec is currently in draft, this should be a separate crate from the main `s2n-quic` as I don't want to break applications when things change. Probably something...

[This issue](https://github.com/rust-lang/rust-semverver/issues/41) makes the output pretty noisy.

The place to do this would be in the close sender. Right now we're setting transmission immediately https://github.com/awslabs/s2n-quic/blob/7b872e70f044ecc89d37a2ebc0290c3cb9ea04f2/quic/s2n-quic-transport/src/connection/close_sender.rs#L34 It would be better to set it after a timer expiration

It's unlikely we'll enable dynamic limits at arbitrary points in the connection lifecycle, as we quickly run into accounting issues. For example, what happens when the limits drop which causes...

Application-level framing isn't really in scope of s2n-quic. If you're sending multiple protobuf messages on a single stream, I would recommend looking at [`tokio_util::codec`](https://docs.rs/tokio-util/latest/tokio_util/codec/index.html) to implement a solution. All streams...

Without seeing the code I can really only speculate what the source of the slowdown is. Did you compile in release mode? What network are you testing on? Is the...

The code you shared isn't reproducible so I'm not sure what issue you're seeing. If you make a repo for the minimal amount of code it takes to reproduce this,...