Summary:
This introduces a new frame type for acks (ACK_EXTENDED) that can carry optional fields depending on the features supported by the peer. The currently supported features set will include ECN count fields, and Receive Timstamp fields. This enables a quic connection to report both ECN counts and receive timestamps, which is not possible otherwise because they use different frame types.
Support for the extended ack as well as the set of features that can be included in it is negotiated through a new transport parameter (extended_ack_supported = 0xff0a004). Its value indicates which features are supported by the local transport. The value is an integer which is evaluated against the following bitmasks:
```
ECN_COUNTS = 0x01,
RECEIVE_TIMESTAMPS = 0x02,
```
This diff introduces the transport parameter and negotiates the supported features between the peers of the connection. The parameter is cached in the psk cache so the client can remember the server config. It is also encoded inside the 0-rtt ticket so the server can reject it if its local config has changed.
The following diffs add reading and writing the frame itself.
The ACK_EXTENDED frame itself will have the following format
```
ACK_EXTENDED Frame {
Type (i) = 0xB1
// Fields of the existing ACK (type=0x02) frame:
Largest Acknowledged (i),
ACK Delay (i),
ACK Range Count (i),
First ACK Range (i),
ACK Range (..) ...,
Extended Ack Features (i),
// Optional ECN counts (if bit 0 is set in Features)
[ECN Counts (..)],
// Optional Receive Timestamps (if bit 1 is set in Features)
[Receive Timestamps (..)]
}
// Fields from the existing ACK_ECN frame
ECN Counts {
ECT0 Count (i),
ECT1 Count (i),
ECN-CE Count (i),
}
// Fields from the existing ACK_RECEIVE_TIMESTAMPS frame
Receive Timestamps {
Timestamp Range Count (i),
Timestamp Ranges (..) ...,
}
Timestamp Range {
Gap (i),
Timestamp Delta Count (i),
Timestamp Delta (i) ...,
}
```
Reviewed By: sharmafb
Differential Revision: D68931151
fbshipit-source-id: 44c8c83d2f434abca97c4e85f0fa7502736cddc1
Summary:
Remove headers flagged by facebook-unused-include-check over fbcode.quic.
+ format and autodeps
This is a codemod. It was automatically generated and will be landed once it is approved and tests are passing in sandcastle.
You have been added as a reviewer by Sentinel or Butterfly.
Autodiff project: uiq
Autodiff partition: fbcode.quic
Autodiff bookmark: ad.uiq.fbcode.quic
Reviewed By: hanidamlaj
Differential Revision: D69864370
fbshipit-source-id: fb8f85599e1e12429f00dc2817dfc5ecf55bc482
Summary: We need to reset the buf accessor here as well.
Reviewed By: sharmafb
Differential Revision: D67472070
fbshipit-source-id: 1700b38e448ca6194a7bd9c034cbbfb6bad727d5
Summary: This diff adds the reliable_stream_reset transport parameter to mvfst.
Reviewed By: hanidamlaj
Differential Revision: D65383676
fbshipit-source-id: cb2f6a1a90004ea489447b67ed3cfc12ca90b804
Summary:
Ack Rx timestamps are currently disabled on 0-rtt connections, which is enabled on mvfst for all non-video connections.
This is because the timestamp config is negotiated with transport settings during handshake which doesn't happen on a new 0-rtt connection (resumption).
Solution:
Store the peer's rx timestamp config in PSKCache on the client. On 0-rtt resumption of the connection, this peer config is restored and used to send Rx timestamps (if enabled).
Note that if the server had changed its timestamp config during this period (through configerator) then the server needs to reject this 0-rtt connection and start anew. Server code changes to support this will be in a followup diff. With this client diff though, server will drop the Rx timestamps if its own config is suddenly disabled (this is a waste of network resource).
Reviewed By: jbeshay
Differential Revision: D58572572
fbshipit-source-id: d95720c177ac4bc8dcbe40362f19b279b3f8e708
Summary: Add another QUIC version alias
Reviewed By: sharmafb
Differential Revision: D57233430
fbshipit-source-id: 7536e5bb13b84ca3e2de818fdc05adf894831ccb
Summary: We currently cap the max send size at the default instead of the max we support (1452). This is pretty conservative and I don't think it's needed, and causes issues when trying to use MASQUE + UDP proxying with QUIC.
Reviewed By: hanidamlaj
Differential Revision: D53440189
fbshipit-source-id: 1d5bbdbb4cc1abb677f85dff6bdf2841cb01c5e1
Summary: Update flow control settings names to reflect that these are indeed flow control
Reviewed By: jbeshay
Differential Revision: D48137685
fbshipit-source-id: a48372e21cdd529480e25785a9bd5de456427ef3
Summary:
change signature of both `ClientHandshake::getServerTransportParams` & `ClientTransportParametersExtension::getServerTransportParams`
from:
```
folly::Optional<ServerTransportParameters> getServerTransportParams()
```
to:
```
const folly::Optional<ServerTransportParameters>& getServerTransportParams()
```
previously this would `std::move(serverTransportParameters_)` after reading it, effectively making it possible to only read the value once.
Reviewed By: kvtsoy
Differential Revision: D48356933
fbshipit-source-id: deddd9101979c1ef30d540b67216dc9611ced713
Summary:
Previously, the maximum stored rx timestamps was controlled by a constant `kMaxReceivedPktsTimestampsStored`. Make this programmable via MC so different values can be pushed based on server and client criteria (via GK groups).
(Note: this ignores all push blocking failures!)
Reviewed By: mjoras
Differential Revision: D45343231
fbshipit-source-id: aafa799925da2c11e14394d11fa4855f7107daf4
Summary:
This removes the older method of deciding whether knob frames should be sent using the QuicVersion. With this change, the client can only send knobs when the server has signaled support using the `knob_frames_supported` transport parameter.
To make sure that knobs can be sent in 0-rtt connections, the transport parameter is now included in the client's cache of server transport parameters.
Reviewed By: mjoras
Differential Revision: D43014893
fbshipit-source-id: 204dd43b4551cd1c943153a3716e882fc80e6136
Summary: Decide if knob frames are supported based upon a transport parameter instead of relying on the QUIC version. This is a cleaner approach, at the cost of an additional transport parameter.
Reviewed By: mjoras
Differential Revision: D42465442
fbshipit-source-id: bfd1d177bdbe198e5eb47e63113410b5738dcede
Summary: This is a cosmetic change to make the naming consistent for all the advertised* variables in the transport settings.
Reviewed By: sharmafb
Differential Revision: D42465443
fbshipit-source-id: d570cbb1a2ca017105ac335b8efc404cb73f3c57
Summary: Use TransportParameterId enum as the source of truth for all the parameter ids. This basically moved the stream groups enabled parameter to the enum.
Reviewed By: kvtsoy
Differential Revision: D42465425
fbshipit-source-id: 94f9968326ac61f92587ef380a7288dd8ab38eef
Summary:
We don't need to carry these states after the handshake is confirmed, so make them pointers instead. This will facilitate adding a structure to the AckState for tracking duplicate packets.
(Note: this ignores all push blocking failures!)
Reviewed By: hanidamlaj
Differential Revision: D41626895
fbshipit-source-id: d8ac960b3672b9bb9adaaececa53a1203ec801e0
Summary:
- Use varint reordering threshold (this is still being discussed, using varint until a decision is made)
- Track server's minAckDelay on client
- Track ack frequency frame sequence number
- Improve frame parsing error logs
- Add some unit tests
Reviewed By: hanidamlaj
Differential Revision: D38289108
fbshipit-source-id: 274e45115022ffd4e15b60dc57f77f1cce69bd82
Summary:
Pass max stream group parameter on handshake
The parameter conveys max number of stream groups a peer wishes to support. Note that the number/param is exchanged during handshake and currently there is now way to bump it later in connection. We can add something like MAX_STREAM_GROUP frame later.
Reviewed By: mjoras
Differential Revision: D36415454
fbshipit-source-id: 9d1c8fca7efa4adfb67fdeef859c47a3f50a67ef
Summary:
This diff is part of larger change to switch to using `folly::ObserverContainer` (introduced in D27062840).
This diff:
- Changes `LegacyObserver` to inherit from the new `Observer` class by adding a compatibility layer. This compatibility layer enables existing observers to continue to be supported.
- Changes generation of observer events so that they are routed through `ObserverContainer::invokeInterfaceMethod`
- Temporarily removes some of the reentrancy protection that previously existed, as it was not being applied consistently — some events had reentrancy protection, some did not. This will be reintroduced in the next diff.
- Improves some unit tests for observers during the transition process.
Differential Revision: D35268271
fbshipit-source-id: 5731c8a9aa8da8a2da1dd23d093e5f2e1a692653
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:
- Count QUIC v1 stats separately so they don't end up in the UNKNOWN bucket. This was missing after v1 was introduced.
- Add three references to QUIC_V1 that were missing while verifying the transport settings.
Reviewed By: mjoras, lnicco
Differential Revision: D30934880
fbshipit-source-id: 9a0e0793fbd37f12f5d756022f4ac809d8dc14d4
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:
make getDatagramSizeLimit return the maximum datagram payload size that the
peer can accept.
This is currently the most conservative length, considering the maximum length
of a QUIC short header packet and a datagram frame header
Reviewed By: mjoras
Differential Revision: D28784866
fbshipit-source-id: cce8944a77f6f7b2d3535758c3c29ad88382710f
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:
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:
(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:
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 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 in the right spirit, but doesn't work because we don't actually update the transport parameters if 0-rtt was accepted, so this ends up being the packet size in perpetuity.
Reviewed By: lnicco, xttjsn
Differential Revision: D23689185
fbshipit-source-id: c45eca1e388534f07eeafbb2c075e133bac071f8
Summary:
This is a bug, for 0rtt, even if the can ignore flag is set, we shouldn't trust the old max packet size. If it has changed then the peer will fail to decrypt anything.
There are open questions here around the PMTU we use for the handshake/0rtt, but let's just punt on those for now.
Reviewed By: udippant, xttjsn
Differential Revision: D23641082
fbshipit-source-id: aba93713091805e9498ab2c14b24bccf18192c02
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:
This implements the connection ID validation via transport parameters. Note we don't do anything with the retry transport parameter yet.
This will probably require further surgery to tests when we want the MVFST version to do this, but for now I'm punting on that test plumbing.
This retains support for h3-27.
Reviewed By: yangchi
Differential Revision: D22045631
fbshipit-source-id: e93841e734c0683655c751d808fd90b3b391eb3e
Summary: The spec suggests doing this, and it is a better semantic than only considering the local one.
Reviewed By: yangchi
Differential Revision: D21433433
fbshipit-source-id: c38abc04810eb8807597991ce8801d81f9edc462
Summary: This will limit us to standard Ethernet MTU (1500) for now, but I think that is fine. This will allow us to experiment with packet size from the client more easily.
Reviewed By: yangchi
Differential Revision: D20709146
fbshipit-source-id: 608463de53d4520a257052491683263e14fc9682
Summary:
This ensures they are available to the whole stack rather than the transport only. The validator needs it in the server case, and will soon need it in the client case, so that seems appropriate to make it available.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/117
Reviewed By: yangchi
Differential Revision: D20536366
Pulled By: mjoras
fbshipit-source-id: a76d369c0a82b9be1f985aed1f33f7a6b338a2ae
