Summary: The `AsyncSocket` suite of classes expect all accesses to occur in the IO threads driving the `EventBase` instances to which they are attached.
Reviewed By: hanidamlaj
Differential Revision: D70574137
fbshipit-source-id: 5d38a2a9bc5e78bf6f90466a90580ad4145a6b17
Summary:
The maximum inflight for acked packets in an ack event may not necessarily come from the same acked packet that produces the maximum bandwidth sample.
Previously we assumed they are the same, now we don't.
Reviewed By: ritengupta
Differential Revision: D70412764
fbshipit-source-id: 64f577d9b8f5251d237dfe07b6e3a6b2940f948b
Summary:
X-link: https://github.com/facebookincubator/zstrong/pull/1216
`str_to_floating_fast_float_from_chars` can be simplified using the new upstream option `allow_leading_plus`. It does mean that we also support parsing `+nan` and `+infinity` which we previously didn't.
Mapping to `Inf` is also handled by the parsing logic, so this custom branch can be removed.
Reviewed By: Gownta
Differential Revision: D70392258
fbshipit-source-id: 62972a6cadd1547d8ff0a3162510ae5e979d459f
Summary:
X-link: https://github.com/facebookincubator/zstrong/pull/1211
* Seems like rust-script is picky with the comment format for cargo dependencies. Switching from /* */ to //! allows is to correctly build the script.
* Remove Ubuntu 20.04 (gcc too old)
* Add Ubuntu 24.04 (latest LTS)
* Remove Fedora 36/37/38 (38 support ended 2024-05-21)
* Add Fedora 40/41/42 (42 to be released 2025-04-22)
X-link: https://github.com/facebook/watchman/pull/1275
Reviewed By: chadaustin
Differential Revision: D70350468
fbshipit-source-id: f5a29743da5b381fadeba2ed35a440b4054ca453
Summary: ACK_EXTENDED frames could also include recieve timestamps. We should not limit the use of receive timestamps to a certain frame type.
Reviewed By: sharmafb
Differential Revision: D70272387
fbshipit-source-id: dd89d4d6994ef17b0fdd50f894d3ccc9e1ce03cc
Summary:
The purpose of this is so that we can import this header from the WebTransport implementation and use the `ByteEventCallback` directly instead of creating a wrapper, thereby saving an allocation.
There's no functional change in this commit, it's just moving things around.
Relevant files:
* quic/api/QuicCallbacks.h
* quic/api/QuicSocketLite.h
Reviewed By: hanidamlaj
Differential Revision: D70000563
fbshipit-source-id: 9523cc788f50b4ba218be33e84f7d5b4f44a73c2
Summary: `messageSizes` is supposed to be the number of iovecs in each message, and not the length of the iovec. This was causing crashes in Edgeray (T215909454).
Reviewed By: jbeshay
Differential Revision: D70129535
fbshipit-source-id: 6d79e6ac0789402674e753297984b3691d371338
Summary: Cache the negotiated config for what ACK type to write and which fields to use once the peer transport parameters are available. This avoids computing the config with every ack frame being written.
Reviewed By: sharmafb
Differential Revision: D70004436
fbshipit-source-id: 79354f5137c77353c3a97d4c41782a700622e986
Summary: The logic for deciding which ACK type to write was duplicated in QuicPacketScheduler and QuicPacketRebuilder. This refactors the logic out into a separate QuicAckScheduler so it can be tested for correction and reused in both places.
Reviewed By: sharmafb
Differential Revision: D69933311
fbshipit-source-id: e4f45688a5d258dd2a57f9f7844407f3efad5f49
Summary:
Write the new ACK_EXTENDED frame. When any of the ACK_EXTENDED features are enabled locally and supported by the peer, this frame type will take precedence over ACK_ECN and ACK_RECEIVETIMESTAMPS. See first diff in the stack for the features.
Frame 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: D68931148
fbshipit-source-id: 0fb4bac23e121f82a11602daabc1ec7084db43dd
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: Bbr.cpp places the call to qlogger's addCongestionMetricUpdate in onPacketAcked in a SCOPE_EXIT macro, causing the qlog update to happen at the end of the method. Bbr2.cpp should do the same in onPacketAckOrLoss.
Reviewed By: jbeshay
Differential Revision: D69890778
fbshipit-source-id: 5492f7252605c680fd8e2d1a1c5a0278163ab0a5
Summary:
Refactored the existing benchmark to measure more of what is actually happening:
1. Insert writable streams
2. Get the head writable stream for a while
3. Erase the head stream
Addeed a few benchmarks for insert/erase and different queue sizes
Reviewed By: mjoras
Differential Revision: D69100615
fbshipit-source-id: 209a4d1eccf15b482fd1880a3f09706f1361c53b
Summary:
This is a reimplementation of the HTTP priority queue with the new API. The new design is:
A single vector-based heap for sequential streams across all levels and an array of 8 RoundRobin's that hold incremental streams.
Getting the highest priority element doesn't require iterating through empty levels - it's right at the front of `heap_` or `roundRobins_[lowestRoundRobin_]`.
There's an index map which incremental streams always use, the value is an index into roundRobins_. When there are a large number of sequential streams in the heap_, we also index those (with their array index).
The benchmarks (next diff) show that this is 2x faster for 8 streams and 20% slower for large numbers of sequential streams (96). The break-even point is 40 streams.
Reviewed By: mjoras
Differential Revision: D68641759
fbshipit-source-id: 30ea5c719e998ead20d8762ee5ddad10111ea7e5
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:
X-link: https://github.com/facebookincubator/fizz/pull/160
X-link: https://github.com/facebookincubator/zstrong/pull/1192
Fix case when testing a github repo checkout, wth tpx on path, where --no-testpilot not specified.
As workaround before this lands, if in this situation pass --no-testpilot
Reviewed By: bigfootjon
Differential Revision: D69852662
fbshipit-source-id: 5065cdf3acae3bc9c90df89ed96eab3fc3e19906
Summary: Updating the fullBw_ in the middle of the round means that the bandwidth plateau for exiting startup could be shorter than 3 full round trips.
Reviewed By: mjoras
Differential Revision: D69667059
fbshipit-source-id: 59b9aa035b6ff7465615a9404cb598ae8da4ff6a
Summary: This change adds a loss recovery approach similar to the one we're using in bbr1. It reduces the congestion window to inflight bytes and reduces it by lost bytes as long as losses continue. This is a configurable option that can be selectively enabled/disabled for both Startup and non-Startup states of bbr2.
Reviewed By: mjoras
Differential Revision: D69557715
fbshipit-source-id: 12ee20106e57af83a2b4e52caf6254204a91da6f
Summary:
Previously, bbr2 used its current app limited state to make decisions on advancing the state machine, this can lead to delayed responses to losses in some cases. This diff changes it to use the appLimited state from the last acked packet.
This diff also refactors how the state related to the current ackEvent is accessed in order to simply the code a little bit.
Reviewed By: mjoras
Differential Revision: D69199424
fbshipit-source-id: e66898cd2347e0d997479b5d50b825c242ef34aa
