Summary: inspect PN, and when it reaches 2^62 -2 trigger a transport close through a pending event.
Reviewed By: yangchi
Differential Revision: D18239661
fbshipit-source-id: 1a218678099016693149e12ff121e2a39b95aecc
Summary: This fixes an issue with rtt computation. The first rtt sample was incorrect because minrtt gets set to the first rtt sample, hence ack delay never get subtracted. This diff allows ack delay to be subtracted if the minrtt is the first one.
Reviewed By: yangchi
Differential Revision: D17610197
fbshipit-source-id: 3e7087f37ef14848d80c0ab33094834a4fc8974b
Summary: Centralize this logic into the pacer interface. But instead of having an explicit canBePaced() function (and we already have a dozen other canBePaced functions or boolean flags in other layers), the pacer just use 0us and default write batch size per loop to answer pacing rate queries when it doesn't meet the condition to properly pace the transport writes.
Reviewed By: mjoras
Differential Revision: D16912631
fbshipit-source-id: 0343b126ca5de315af6823067316526b1004cc6c
Summary: Add transportStateUpdate event so it can be part of qlog.
Reviewed By: mjoras
Differential Revision: D16342467
fbshipit-source-id: 109189275d44996850b82646bab4a733a3a4c7a1
Summary:
Currently we handle crypto timer before loss timer. And currently loss
time is for AppData only since for the other two Packet Number spaces, crypto
timer will take care of it. This diff extends loss times to 3 loss times, and
handle them before handle crypto timer. The rational here is that loss time is
shorter than crypto timer, so this will make retransmission during crypto
handshake more aggressive. For app data, this diff doesn't change anything.
Reviewed By: sharma95
Differential Revision: D15552405
fbshipit-source-id: bd5c24b0622c72325ffdea36d0802d4939bae854
Summary: Replace hard coded stateless reset token with a token from the stateless reset token generator.
Reviewed By: yangchi
Differential Revision: D15481858
fbshipit-source-id: 30c96843c38c616600466b2fabb6defd5fcc5799
Summary: This is no longer part of the spec. It's up to the application how to handle reset
Reviewed By: lnicco
Differential Revision: D15107164
fbshipit-source-id: 2a1fe0c552bd7f054e84ef86a01a78c379b0a483
Summary: This is step 1 for removing reset on reset, since the send side may need to transition to waiting for a reset ack while the read side is an any state.
Reviewed By: lnicco
Differential Revision: D15075849
fbshipit-source-id: 1e094942a8a1ca9a01d4161cd6309b4136a9cfbf
