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:
The idea here is to make it so we can swap out the type we are using for optionality. In the near term we are going to try swapping towards one that more aggressively tries to save size.
For now there is no functional change and this is just a big aliasing diff.
Reviewed By: sharmafb
Differential Revision: D57633896
fbshipit-source-id: 6eae5953d47395b390016e59cf9d639f3b6c8cfe
Summary: This enables the server to include a cwnd hint in the 0-rtt ticket it sends to the client.
Reviewed By: mjoras
Differential Revision: D43131826
fbshipit-source-id: 742e4e531027ec6618a1b761c450b507368e5a2f
Summary:
Also move encoding/decoding of the AppToken to be transmitted via fizz in its own file.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/175
Reviewed By: yangchi
Differential Revision: D23681956
Pulled By: mjoras
fbshipit-source-id: dc98d0b4ba2bee4a05ae8832d36ff4a116cfbd0d
Summary:
The transport parameters format changed in draft 27. It is now self describing via varints.
This diff retains support for the old encoding and does not iterate the mvfst version.
Reviewed By: lnicco
Differential Revision: D20149977
fbshipit-source-id: c6fa9c226f859ed81ca83ada5a8bc5832b4a3388
Summary:
This eliminatees some tech debt by completely removing the notion of version from the core transport parameters structure and the app token for zero rtt.
Note that for the draft-27 changes we will need to temporarily re-introduce it, but to a different layer (the extension encoding itself).
Reviewed By: JunqiWang
Differential Revision: D20073578
fbshipit-source-id: 2b55af621566bf1c20e21dd17251116de1788fa0
Summary:
This moves the fizz specific part of the handshake into its own folder and library.
There is a bit of smurf naming going on as a result, not sure it is worth fixing or not at this stage. Maybe this code should be a in namespace named quic::fizz .
This should be doable with the client as well as soon as the key cache situation is figured out.
---
## Proxygen Canary
Reviewed By: yangchi
Differential Revision: D19290919
fbshipit-source-id: 48d7f7c70db42c65f7dffe3256805c268a481198
Summary:
This allows to get rid of an unnecessary dependency on fizz. The values are generated using `folly::IOBuf::create` anyways, so it's not like it is adding a dependency that isn't there.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/46
Reviewed By: yangchi
Differential Revision: D17581353
Pulled By: sharma95
fbshipit-source-id: 87e1022c75e6643a8b2a11e9e6f280fe2f247d1d
Summary:
Draft-22 onwards uses two one byte length fields to encode connection ID length instead of one one byte length field.
To support this without disrupting existing clients we need to make our parsing version dependent. This diff accomplishes it by special casing the existing Facebook client QUIC version (0xfaceb000), and changing the default Facebook client version going forward to 0xfaceb001.
Note that this diff also changes the behavior of the ticket transport parameters. When we changed from draft-18 to draft-19 transport parameters I apparently forgot to update the ticket transport parameters to the new format.
Reviewed By: yangchi
Differential Revision: D16205090
fbshipit-source-id: e74a92fa959d308f4bb43bad76e58d4b58d07322
