Summary:
This change just adds a (currently no-op) flag that will be used in diffs up the stack.
The idea here is that I'll add split QUIC connection callback interfaces that will live side by side with existing single monolithic callback for now. We will experiment with split callbacks on small scale to see that there is no regressions and then will phase out the old callback gradually.
This flag is to control which callback(s) to use.
Reviewed By: mjoras
Differential Revision: D30399667
fbshipit-source-id: 8fc4e4a005e93cf6d48a987f49edee33b90dbbf1
Summary:
These are either no longer relevant, are unlikely to be done, or are spculative enough that they don't deserve code space.
Hope here is to make our search for TODOs higher signal.
Reviewed By: lnicco
Differential Revision: D29769792
fbshipit-source-id: 7cfa62cdc15e72d8b7b0cd5dbb5913ea3ca3dc5a
Summary: Add a new transport knob (MAX_PACING_RATE_KNOB) to allow the client to suggest a limit on the pacing rate used by the server, if it has pacing enabled.
Reviewed By: mjoras
Differential Revision: D29335469
fbshipit-source-id: 8f0a881e8235e0d787ea86ba1e268a36eecf6151
Summary:
This function actually assumes both are there. This mostly happens in unit tests anyway.
(Note: this ignores all push blocking failures!)
Reviewed By: yangchi
Differential Revision: D29187689
fbshipit-source-id: a7ca516c18de4f0261ffec985f1d4e9f63b071d9
Summary:
Add a new transport knob `NOTSENT_BUFFER_SIZE_KNOB` that will allow us to run quick experiments for different buffer sizes on the server side.
## Background
In TCP, the send buffer accounts for both the unacked and unsent data. SO_SNDBUF is the sum of both and is statically configured for the socket. TCP_NOTSENT_LOWAT only limits the unsent data which still allows the SO_SNDBUF to still accommodate a big BDP.
In mvfst, the buffer usage we currently track (sumCurStreamBufferLen) is only for unsent data. Its size is controlled by the TransportSetting totalBufferSpaceAvailable. Unacked packets are tracked as outstanding packets and do not count toward that buffer space. Effectively, a limit on this buffer achieves the same effect as TCP's NOTSENT_LOWAT socket option.
Reviewed By: mjoras, yangchi
Differential Revision: D28843244
fbshipit-source-id: 3b61619038f3b41508fe76c2873e41486ae97739
Summary:
add 3 new transport knobs:
1. set congestion control algorithm (string algorithm name)
2. set pacing rtt factor to be used during "startup" phase of congestion control, right now only used by bbr and copa
3. set pacing rtt factor to be used by default during congestion control, right now only used by bbr and copa
Reviewed By: yangchi
Differential Revision: D28462540
fbshipit-source-id: 2c861885e472cb2bce0b51daeef2b143e9628080
Summary: make space for backend subdir
Reviewed By: mjoras
Differential Revision: D27999777
fbshipit-source-id: 1d270b8ce3349980a1e4c68035a1f39c095237b5
Summary:
This diff hooks the DSR write function into QuicServerTransport's
write path.
Reviewed By: mjoras
Differential Revision: D27890711
fbshipit-source-id: ac4452373c0baafe091f93fb54fccf87be604a9c
Summary: as title, this is a testing only API
Reviewed By: mjoras
Differential Revision: D27746039
fbshipit-source-id: cf87836810a4579f622152ccb17aca49a0d605e3
Summary:
as title. This also moves a FizzCryptoTestFactory from FizzCryptoFactoryTest to TestUtils so that it can be used in other test code
This change has an unfortunate side-effect that cryptoFactory_ in both client and server will be moved from stack to heap.
Reviewed By: mjoras
Differential Revision: D27264488
fbshipit-source-id: febc307fb02cb136d58fe70bee648d35431acff0
Summary: This seems to cause some issues with CGNAT type networks where the client is actually using v6 or v4.
Reviewed By: yangchi
Differential Revision: D27772485
fbshipit-source-id: ac118441caad38301f2a22e657cefb398a5210da
Summary:
As before we will now aggressively send probes on all spaces with probes available when the PTO timer fires.
This time with more unit tests and some bug fixes.
Reviewed By: yangchi
Differential Revision: D27338523
fbshipit-source-id: 8a9ccb90ed691e996fab4afa2f132c0f99044fbc
Summary: As in title. There's a bug here somewhere with empty write loops we need to find.
Reviewed By: yangchi
Differential Revision: D27279100
fbshipit-source-id: e1d26fbf8d6df1590d464a6504a8b940b46794e0
Summary:
Previously we would only send probes for the first space which had one available, i.e. Initial before Handshake before AppData. Since we only have one PTO timer this can lead to situations where we perpetually probe with only Initials, which can significantly delay the handshake if we should have probed with Handshakes.
With this diff we will keep the single PTO timer but aggressively write more probes from all spaces if they are available.
Additionally this refactors some counters into EnumArrays
Reviewed By: yangchi
Differential Revision: D27235199
fbshipit-source-id: ef3614a833bf0f02f5806846a1335fa7ac2a4dc8
Summary:
Before the change, there's no good way to recreate Cubic CC instance with custom CC factory, because Cubic is created by default.
On client side this requires calling setCongestionControl() or setTransportSettings() after calling setCongestionControllerFactory(), which is normally the case.
Reviewed By: yangchi
Differential Revision: D26401996
fbshipit-source-id: dfda39be835c67b9db42f726b3ac64c7b3d37c2f
Summary: Adding QuiConnectionStats to client transport. Moving getConnectionsStats() logic from server worker into transport base class.
Reviewed By: lnicco
Differential Revision: D26316635
fbshipit-source-id: a384eee5d1bc7b23d908e0b03fafcc4ee962b0b9
Summary:
Given the large number of callbacks that are being triggered from the Observer
this change makes it possible to enable through a simple config, just the
subset of callbacks that a consumer is interested in receiving.
Observer and Socket Lifecycle callbacks are enabled by default, they are not
configurable.
Reviewed By: bschlinker
Differential Revision: D25879382
fbshipit-source-id: abe79ed92e958ddc96475c347f8ec7204400cdfa
Summary:
We were using the LifecycleObserver and InstrumentationObserver classes
separately, to generate and receive callbacks.
This change migrates both these to use the unified Observer callback class and
adjusts the unit tests.
Reviewed By: bschlinker
Differential Revision: D25845845
fbshipit-source-id: c489400f5d70bccadbcc1d957136c5ade36b65ff
Summary:
This adds visibility over the transport knobs. Will be helpful when we add more knobs (e.g. canary token).
I'll remove them for the sake of storage once we're sure the plumbing works.
Reviewed By: avasylev
Differential Revision: D24929923
fbshipit-source-id: a64bb6e613f3a69a47bf9b32e8c31890ad1afdfc
Summary: Adds another knob param to enforce udp payload size. This is basically a "canIgnorePathMTU" knob that client has.
Reviewed By: mjoras
Differential Revision: D24586165
fbshipit-source-id: befb265a24fae8f450f323cf2d652a8b448e698c
Summary: Blackhole detection has quite a lot false positives, we want to have a way to run d6d without it.
Reviewed By: mjoras
Differential Revision: D24584357
fbshipit-source-id: ab27655ec38d62fd6deffe41cb156de0c981cf6d
Summary: To scale well when we have more transport knob params, server can maintain a map from param id -> handler function. The handler function should avoid storing states / perform proper checking if it does. Most use cases should be covered by the "server_conn" param.
Reviewed By: mjoras
Differential Revision: D24584358
fbshipit-source-id: e45da50deb6ebd385b6a71e1b48f4650bc6ace91
Summary: Temporarily, we use a simple json-format for transport knob. Currently it's limited to a single packet, but that should be enough for current usage.
Reviewed By: mjoras
Differential Revision: D24584261
fbshipit-source-id: f51ed0fb7560cda2ca447a49d9ad6575c1b2a59f
Summary: The D6DEnabled integration test was flaky because of a race condition between stats callback and client's transportReady callback. Simple fix by ~~send some data and wait for echo~~ calling terminateLoopSoon in onConnectionD6DStarted. Still, it makes sense to make transportReady the last callback in server so I switched the order.
Reviewed By: yangchi
Differential Revision: D24198017
fbshipit-source-id: 36a7b6377c970b2f2f5d072f03d8bc8b0837fd79
Summary: This reduces dependencies for both testing and instrumentation.
Reviewed By: mjoras
Differential Revision: D23997313
fbshipit-source-id: 5eb3a790c7bb2569dc1e941e3911ad4aac4e9258
Summary:
After some experiments where probes are obviously causing congestion, it now
makes sense to pose some delay before sending the next probe. This is not
mentioned in the d6d spec, but in a related spec rfc4821 iirc, where consecutive
probes should have 1sec delay.
Reviewed By: mjoras
Differential Revision: D23910766
fbshipit-source-id: dcf5d05c4590489be503563c98144e12c3987cff
Summary: As a drive-by: fixed a bug where I didn't cancel the pending event when timeouts expire.
Reviewed By: mjoras
Differential Revision: D23910767
fbshipit-source-id: 233e590c17a6c6b7a5f4a251bd8f78f6dfae3c0b
Summary:
This glues together the d6d lifecycle via probe timeout and raise timeout.
Had to put these two timeouts in the base transport because it has all the
necessary accountings (e.g. check close state, process callbacks) that should
happen before scheduling timeouts.
Other notable changes (included here because code is simple):
- Keep track of d6d probes in loss state. Upon second thought, it makes more
sense because we are reducing the available bandwidth as a result of sending
probes anyway. And not tracking them imposes a delay on congestion controller.
I think this does not violate the d6d spec's point of not penalizing congestion
window for d6d probes, because
- 1. we don't put losses of d6d probes in loss event. Therefore from the POV of
congestion controller, d6d probes never get lost.
- there will be at most kDefaultD6DMaxOutstandingProbes losses (i.e. 2)
that we don't tell congestion controller about. Even if those are actually
caused by congestion, it should have minimal impact because 2 is small and if there's really a congestion, the loss of normal packets should provide the signal.
- Pacing d6d probes
- Kick off d6d after a delay of 1s. This should filter out short-lived connections where probing is relatively expensive and less useful.
Reviewed By: mjoras
Differential Revision: D23736656
fbshipit-source-id: 8121fa8bcebab10a56a4e046c32c4e99ed6c3013
Summary:
This is one of the pre-condition of starting d6d probing. Starting d6d once
hasWriterCipher() is too early becaue an overlarge PMTU could potentially
cause the server to send oversized handshake packet and disrupt handshake.
Reviewed By: yangchi
Differential Revision: D23698784
fbshipit-source-id: f18824a8ef516421832d8cc769f4880a0841e492
Summary:
This is following a similar pattern than what was done for the client side.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/160
Reviewed By: yangchi
Differential Revision: D23560951
Pulled By: xttjsn
fbshipit-source-id: 351417cbfa3230112fff4c4de59b307f88389cf6
Summary: This diff adds an API to expose client certificate from QuicSocket.
Reviewed By: mjoras, lnicco
Differential Revision: D20374792
fbshipit-source-id: 1b0691bba49ef57cb824aba8563644afc7b1962b
Summary:
First step towards d6d. Semantically we need to separate the old `udpSendPacketLen` into `peerMaxPacketSize` as well as `currPMTU`. The former is directly tied to the peer's max_packet_size transport parameter whereas the second is controlled by d6d. To get the actual udp mss, call `conn_->getUdpSendPacketLen()`, which will use the minimum of the two if d6d is enabled, otherwise it will fallback to use `peerMaxPacketSize` only.
During processClientInitialParams and processServerInitialParams, we no longer need to check whether `canIgnorePathMTU` is set because that logic is moved to `setUdpSendPacketLen`. If d6d is enabled, we set both `peerMaxPacketSize` and `currPMTU` to `packetSize` because receiving an initial packet of size x indicates both that the peer accepts x-sized packet and that the PMTU is at least x.
Many call sites and tests are changed.
Faebook:
For now, d6d is considered enabled if `canIgnorePathMTU==false` and `turnoffPMTUD==true`. Down the road, from semantic & practical POV at least one of them should be renamed to something like `enableD6D`, since enabling d6d implies turning off PMTUD and that we should not ignore PMTU. We can keep one for the sake of testing.
Reviewed By: mjoras
Differential Revision: D22049806
fbshipit-source-id: 7a9b30b7e2519c132101509be56a9e63b803dc93
Summary:
The way libccp is structured, it requires each instance of the QuicCCP cc algorithm to access a field (`ccpDatapath`) from the corresponding ServerWorker handling that connection. However, the constructor for cc algorithms only takes a single input, a `QuicConnectionStateBase`. So, the only way to pass it through without changing the API is to add it as a field to this struct.
On the server, the QCSB will always be an instance of the subclass `QuicServerConnectionState` -- since CCP will only ever be used on the server side, we can add `ccpDatapath` to QSCS and then in QuicCCP we can `static_cast` the `QCSB` to a `QSCS` to access it. This makes it possible to build the client without any dependency on CCP related things.
Reviewed By: udippant
Differential Revision: D21854348
fbshipit-source-id: a1f44ac177459880d850660039ce7477e6f57132
Summary:
On loss timer, currently we knock all handshake packets out of the OP
list and resend everything. This means miss RTT sampling opportunities during
handshake if loss timer fires, and given our initial loss timer is likely not a
good fit for many networks, it probably fires a lot.
This diff keeps handshake packets in the OP list, and add packet cloning
support to handshake packets so we can clone them and send as probes.
With this, the handshake alarm is finally removed. PTO will take care of all
packet number space.
The diff also fixes a bug in the CloningScheduler where we missed cipher
overhead setting. That broke a few unit tests once we started to clone
handshake packets.
The writeProbingDataToSocket API is also changed to support passing a token to
it so when we clone Initial, token is added correctly. This is because during
packet cloning, we only clone frames. Headers are fresh built.
The diff also changed the cloning behavior when there is only one outstanding
packet. Currently we clone it twice and send two packets. There is no point of
doing that. Now when loss timer fires and when there is only one outstanding
packet, we only clone once.
The PacketEvent, which was an alias of PacketNumber, is now a real type that
has both PacketNumber and PacketNumberSpace to support cloning of handshake
packets. I think in the long term we should refactor PacketNumber itself into a
real type.
Reviewed By: mjoras
Differential Revision: D19863693
fbshipit-source-id: e427bb392021445a9388c15e7ea807852ddcbd08
Summary:
Now we won't have a zero PTO and we will properly clear out the outstanding packets.
Note that this cipher dropping is not what the draft prescribes, instead dropping both the initial and handshake ciphers when we know 1-rtt communication is functioning.
Reviewed By: yangchi
Differential Revision: D20388737
fbshipit-source-id: 0b89eb80c8faa796ab09eda3eaa10a00dcf7bae9
