Summary: When there is not enough space in the QUIC packet to write a datagram frame, we should not dequeue the datagram
Reviewed By: mjoras
Differential Revision: D33109603
fbshipit-source-id: 937a5a0ffe55c7f88e39faf224e7ad06ca599708
Summary:
Adds stream specific details to `AckEvent` for each ACKed packet, including:
- the number of stream frame bytes newly ACKed
- the number of stream frame bytes newly ACKed by a packet containing a retransmission of said frames (meaning that the original packet was lost, or that the packet with the retransmission arrived at the receiver and corresponding ACK arrived at the sender faster (unlikely), or that the receiver ACK including the original packet was lost, and the ACK interval was pruned too quickly)
- the change in the stream delivery offset for each stream triggered by ACK arrival (if any)
- the stream intervals (and more specifically, the stream frames) that were "dupacked" by the ACK of this packet, meaning that ACK of some other packet had already marked those frames / stream bytes as delivered
Information about "dupacked" packets will not be available until processing of ACKs for packets spuriously marked as lost is enabled; this will come in a follow up diff.
Reviewed By: mjoras
Differential Revision: D31915844
fbshipit-source-id: b8056ea1b5f6093b61e5463c6b4c11cd83bd2916
Summary:
Introduces `QuicTypedTransportTest`, a `TYPED_TEST` that will enable us to test various implementations of `QuicTransportBase` with only one set of tests.
Today, we write separate tests in `QuicClientTransportTest` and `QuicServerTransportTest` for the same functionality. Due to this overhead, I've noticed that in some cases we don't have proper test coverage, and this leads to bugs (see the off by one issue with ACK byte events).
`QuicTypedTransportTest` is an effort to fix this by making it easier to write tests that all transports should be able to support. `QuicTypedTransportTestBase` serves as a shim layer between the test and the specific test transport implementation. In following diffs, I extend the functionality of `QuicTypedTransportTest` further to make it easier to test cases where packets arrive from the remote (peer), including stream and reset packets.
Reviewed By: mjoras
Differential Revision: D32560835
fbshipit-source-id: e08387364f614c37ed2126dbfb91b30230d116a0
Summary: Making it possible to reuse the foundation of `QuicClientTransportTest` elsewhere. Will be building a test that uses `TYPED_TEST` to test against both transports.
Reviewed By: jbeshay
Differential Revision: D31886977
fbshipit-source-id: a9d9a335aaa0c5f5ea6cd2249fe23b35d926b5c9
Summary:
## Issue
When we enabled the JK to set QUIC server's rate limit to zero (D30703498), causing it to send retry packets to all incoming client hellos, we found that android clients were crashing (T99705615).
We were able to reproduce the bug with LigerIntegrationTest and HQClient backed by HQServer, causing the clients to hang.
## Fix
- When receiving a retry packet from the server, migrate the outstandings, stream manager, among other required fields to the new connection state.
- QuicStreamManager & QuicStreamState constructors to facilitate migrating to a new connection state.
Reviewed By: kvtsoy
Differential Revision: D31006905
fbshipit-source-id: 0490ceee1bef52b94c91019426d791e212820508
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:
Update QUIC to V1 and HTTP/3 to h3. In order to support interop, hq-interop ALPN has been added too.
This change maintains support for draft-27 and draft-29 implementations.
Reviewed By: mjoras
Differential Revision: D29714556
fbshipit-source-id: 0685928ef4bede0b5511e59572e9c86ccc867320
Summary:
This is Linux specific stuff.
(Note: this ignores all push blocking failures!)
Reviewed By: lnicco
Differential Revision: D29188261
fbshipit-source-id: 711fcf79c1eb2ef78a02945f395c39880f4fa61e
Summary:
If some 0RTT packets are lost we will not detect the loss until we get a short header ACK from the server or the loss timeout expires. This could potentially take a long time.
This adds an option which will optionally retransmit any 0RTT data as soon as the handshake is complete.
Reviewed By: lnicco
Differential Revision: D29111647
fbshipit-source-id: 3c1924ce178a01eaa20a94561df82a59733b8b71
Summary: Prior to this any socket level error message would kill the connection. This doesn't make sense when happy eyeballs is ongoing.
Reviewed By: jbeshay
Differential Revision: D28979505
fbshipit-source-id: 29d1a3b3f0db56a073433a04b888241fe7b91767
Summary: Without this we won't actually retransmit the 0RTT data on the second socket until they are declared lost after the handshake is done.
Reviewed By: JunqiWang
Differential Revision: D28942340
fbshipit-source-id: 192c9ca0544bfde9610720ca1b02322709f0e61e
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 is another bandaid around our incorrect not updating of 0-RTT transport parameters on the client. The long term fix requires us to update all the parameters based on the final ones from the server. This will require a bit of a refactor to this area of the code as well.
Until we do that, manually set the stateless reset token so that 0-RTT clients can actually parse server stateless resets.
Reviewed By: yangchi
Differential Revision: D27875279
fbshipit-source-id: 1d08a53f2a9d876635dcd884b6bba316224543dd
Summary: Keep on server for now but disallow it in code for the client.
Reviewed By: yangchi
Differential Revision: D27726584
fbshipit-source-id: c567d9db82c36b6e60d438d839709f0330b8db50
Summary:
This can happen when we don't get the server handshake data in time, but it is especially bad with 0RTT when it is potentially a full flight of 1RTT data that is dropped while we wait for the handshake PTO.
Note this leverages the existing CipherUnavailable mechanism, but processes them in a much more simple way than the server side. Additionally, only 1-RTT packets need to be buffered.
Reviewed By: yangchi, lnicco
Differential Revision: D27634184
fbshipit-source-id: db5ba0b9f07176d106f709c7a11d83d0fc8281b7
Summary:
On receiving a QUIC packet, if the packet has no frames we should end the connection with PROTOCOL_VIOLATION.
This fixes the error reported by h3spec test `/QUIC servers/MUST send PROTOCOL_VIOLATION on no frames [Transport 12.4]/`
This change adds the check right after a packet is successfully parsed for both the client and server.
Reviewed By: mjoras
Differential Revision: D27483874
fbshipit-source-id: 9b648709e6985f151ba0ffc973aa05c28683fbe9
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: This change is needed so that `conn.transportStats` is defined when a new congestion controller is created (so we can update cc_type counters).
Reviewed By: lnicco
Differential Revision: D27156542
fbshipit-source-id: 8dd7613c4ea1f0e70aefc4a135a8c7f1d102fee2
Summary: they need to be prioritized together
Reviewed By: mjoras
Differential Revision: D26918282
fbshipit-source-id: 061a6135fd7d31280dc4897b00a17371044cee60
Summary: The new controller happens to be the exact same address
Reviewed By: lnicco
Differential Revision: D26566423
fbshipit-source-id: 88fa04d2cf8b02ef20e7979f0055ee84903d33e9
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: this param is passed to transport then ignored
Reviewed By: avasylev
Differential Revision: D26133327
fbshipit-source-id: 459dd0132185513215ba034f213d4137d7b56ba1
Summary:
(1) Receiving a valid retry packet is a HappyEyeballs signal. We should
use that to update the happy eyeballs state.
(2) HappyEyeballs state should also be preserved when we undo client connection
state for retry.
Reviewed By: mjoras
Differential Revision: D25728713
fbshipit-source-id: 4ff06879f5a05e6fb4faeb1e9f330e251d3dbcb6
Summary:
I think this should just work without the trailing `_E`. It was added
when we mixed up our own union based variant and boost::variant. Some compiler
flags didn't like that. Now we no longer have mixed up cases, this should be
fine
Reviewed By: lnicco
Differential Revision: D25589393
fbshipit-source-id: 6430dc20f8e81af0329d89e6990c16826da168b8
Summary:
The test case relies on the client transport hits max PTO within 10s
to trigger a read error callback. Sometimes, it takes longer than 10s to hit
max PTO under stress runs
Reviewed By: mjoras
Differential Revision: D25065653
fbshipit-source-id: c728084178126452d0c7c885cb7215878cf4e3b7
Summary: Adds a top level API to set stream priorities, mirroring what is currently proposed in httpbis. For now, default all streams to the highest urgency, round-robin, which mirrors the current behavior in mvfst.
Reviewed By: mjoras
Differential Revision: D20318260
fbshipit-source-id: eec625e2ab641f7fa6266517776a2ca9798e8f89
Summary:
When I tested against picoquic, I found that an exception was thrown here: https://fburl.com/diffusion/qsnzingx.
The reason is that we modify `conn.initialDestinationConnectionId` in the event of a retry, so it's no longer the original destination connection id. By separately keeping track of the original destination connection id, we can solve this issue.
Reviewed By: mjoras
Differential Revision: D23722127
fbshipit-source-id: 94be08812e675feaf46f5af86e7304af84c1910c
Summary: This switches the client to use the FizzRetryIntegrityTagGenerator and the PseudoRetryPacketBuilder, to avoid duplication of a lot of the work.
Reviewed By: mjoras
Differential Revision: D21489881
fbshipit-source-id: 8aa3af26f1090eeb9f2f04eb4defd785ad555df1
Summary: It's useful to be able to use the v4-mapped addresses sometimes.
Reviewed By: avasylev
Differential Revision: D24371807
fbshipit-source-id: 74fe13fa4bef9c77cc51a18137559facda9bdbeb
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: We need to increase those parameter Ids above 0xFF00, and xmit them.
Reviewed By: mjoras
Differential Revision: D24115117
fbshipit-source-id: cf8b4970ba8640a83bde22c1f9fdfa1d3e53e3f9
Summary: Since the DCID is often empty for clients, this is otherwise not a very useful field.
Reviewed By: yangchi
Differential Revision: D23998639
fbshipit-source-id: b8949ca6913ed270e5ebd0a0c5335b224f817774
Summary:
There is a pretty tight coupling between ClientHandshake and FizzClientHandshake . The later can mess up pretty bad with the former's state, especially since th code has quite a lot of temporal dependencies and is very stateful.
This constraint he API through which the subclass can interact with the parent class and prevent some obviously bad misuses. It also make it clear when something is to made available for testing exclusively.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/182
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
---
## Traffic Canary
https://our.intern.facebook.com/intern/traffic/canary?fbid=119893296332660
* elb.prod.hel3c01 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/q948xh5b
* flb.prod.fgdl1c03 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/1p582qcv
* olb.prod.rftw0c01.p2 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/h23ldteg
* slb.prod_regional.rash0c00 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/6cjn5fxn
* slb.regional.rash0c01.p2 - binary - 2020-09-24 23:01 - https://fburl.com/dyndash/kadbkkdf
---
Reviewed By: mjoras
Differential Revision: D23816801
Pulled By: bschlinker
fbshipit-source-id: 52c7fa3e3f436d3317f2a13bef8ae4d596f6a25b
Summary: This is a temporary hack until we properly implement 0-rtt transport parameter updating. Now after 0-rtt we will use the packet size from the peer as the max packet size, if the can ignore setting is set.
Reviewed By: xttjsn
Differential Revision: D23690019
fbshipit-source-id: b4dbf5702e81e52ccd437e0fa68f4d156c7123be
Summary: This was probably a premature optimization and introduces complexity for dubious gain. Additionally a sequence of losses could potentially cause multiple updates to be delayed.
Reviewed By: yangchi
Differential Revision: D23628058
fbshipit-source-id: d6cf70baec8c34f0209ea791dadc724795fe0c21
