Benjamin Saunders

Interesting. I concur with your analysis that the pacer isn't a relevant bottleneck. 7 is unremarkable: a configuration which already saturates the path shouldn't change if we remove even more...

For case 4, was the "fixed value" `usize::MAX` (i.e. CC effectively disabled)? If so, the fact that 4 is slower than 6/7 suggests that flow control is a significant bottleneck....

Summarizing chat discussion: - Looks like we're filling the cwnd correctly 🎉 - With an exception in the simulated network, where the sender is probably CPU-limited and computing an inaccurate...

Makes sense, thanks. My guess would be that #1576 is the next low hanging fruit here, then.

https://github.com/quinn-rs/quinn/pull/2292 fixes the `key_update_reordered` case. I wouldn't be surprised if `key_update_simple` was a variation on the same root cause. I don't immediately see how `single_ack_eliciting_packet_triggers_ack_after_delay` could be related, but it...

`Incoming` is too early: it is yielded before the endpoint even decrypts first packet, and a `ClientHello` might span multiple packets. I think your use case is worth supporting, but...

`Connecting::handshake_data` is async. If your Client Hello has not been fully received, it won't be ready yet.

> We already have a Connecting stage, so this might fit in there? I'm not sure if this would be feasible. The motivation here is to make the connection's configuration...

That could work. I think it'd need about the same changes at the proto layer: we still want decode a Client Hello but defer all other work, and unless the...

I'm glad you found a satisfactory solution! I'm not categorically opposed to exposing more granular data, but indeed it's a difficult API design problem to come up with something that's...