Summary:
Store timestamps/packet numbers of recently received packets in AckState.
- The maximum number of packets stored is controlled by kMaxReceivedPktsTimestampsStored.
- The packet number of entries in the deque is guarenteed to increase
monotonically because an entry is only added for a received packet
if the packet number is greater than the packet number of the last
element in the deque (e.g., entries are not added for packets that
arrive out of order relative to previously received packets).
Reviewed By: bschlinker
Differential Revision: D37799023
fbshipit-source-id: 3b6bf2ba8ea15219a87bbdc2724fe23eebe66b70
Summary:
The current logic for handling the ACK_FREQUENCY frame mistakenly uses the frame's reorderThreshold for deciding losses, rather than triggering immediate acknowledgements.
This change fixes the logic by tracking the out-of-order distance and comparing that against the reorderThreshold.
Reviewed By: mjoras
Differential Revision: D39331920
fbshipit-source-id: 125fd99dce9b2725ea0d5b26236f48f72db53c48
Summary: Make `min(minRTT - ACK delay)` obsered so far over the life of the connection available in `TransportInfo`. In addition, expose the last RTT and last RTT's AckDelay value as well.
Reviewed By: mjoras
Differential Revision: D28385923
fbshipit-source-id: a58000ac8bd9fdc63caa0b636bdb83905cd6b448
Summary:
RFC9002 states the following in section 5.3
> 5.3. Estimating smoothed_rtt and rttvar
> Therefore, when adjusting an RTT sample using peer-reported acknowledgment delays, an endpoint [...] MUST NOT subtract the acknowledgment delay from the RTT sample if the resulting value is smaller than the min_rtt. This limits the underestimation of the smoothed_rtt due to a misreporting peer
However, today we subtract the ACK delay from an RTT sample used to estimate `smoothed_rtt` if it is the first RTT sample, as we will not yet have a minimum. This can lead to underestimation of `smoothed_rtt` if the peer is misreporting, and furthermore can create a situation during which `smoothed_rtt` is lower than `min_rtt`.
Resolving by not allowing `smoothed_rtt` to be adjusted by ACK delay for the first RTT sample, since doing so would lead to `smoothed_rtt` being lower than `min_rtt`.
Reviewed By: jbeshay
Differential Revision: D34792648
fbshipit-source-id: e0d6207ff73cdc13e0b40193abd27abce7142499
Summary:
- Skip ACK-only response to initial crypto data from client
- Enabled through experimental transport settings
Reviewed By: mjoras
Differential Revision: D31863653
fbshipit-source-id: b290db0399dd7a3be41078c4a839b484da864f2f
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:
The goal of this change is to fix the bug that ```ackState.needsToSendActImmediately``` can be set to false even if it has been set to true. It leads to an issue when a batch of packets are consumed.
**Changes**
1. No longer set **false** for ```ackState.needsToSendAckImmediately```. If it is ever set to **true**, it continues to be **true**. Otherwise, it sticks to the default value of **false**.
1. Set ```ackState.scheduleAckTimeout``` to **true** only if ```ackState.needsToSendAckImmediately``` is **false**.
1. Always set ```ackState.numRxPacketsRecvd``` and ```ackState.numNonRxPacketsRecvd``` to **0** if ```ackState.needsToSendAckImmediately``` is **true**.
Reviewed By: yangchi
Differential Revision: D28241894
fbshipit-source-id: 988ac973beaa6b4348d99aa0bd6036318a6e1778
Summary: As in title. This doesn't actually send any frames, but implements basic support for the transport parameter and responding to the frames.
Reviewed By: yangchi
Differential Revision: D26134787
fbshipit-source-id: 2c48e01084034317c8f36f89c69d172e3cb42278
Summary:
It is useful to be able to account for when we detect packets as lost but actually receive an ACK for them later. This accomplishes that by retaining the packets in the outstanding packet list for a certain amount of time (1 PTO).
For all other purposes these packets are ignored.
Reviewed By: yangchi
Differential Revision: D22421662
fbshipit-source-id: 98e3a3750c79e2bcb8fcadcae5207f0c6ffc2179
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:
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
Summary: This implements the handshake done signal and also cipher dropping.
Reviewed By: yangchi
Differential Revision: D19584922
fbshipit-source-id: a98bec8f1076393b051ff65a2d8aae7d572b42f5
Summary:
This diff:
1) introduces `EnumArray` - effectively an `std::array` indexed by an enum
2) changes loss times and `lastRetransmittablePacketSentTime` inside `LossState` to be an `EnumArray` indexed by `PacketNumberSpace`
3) makes the method `isHandshakeDone()` available for both client and server handshakes.
4) uses all those inputs to determine PTO timers in `earliestTimeAndSpace()`
Reviewed By: yangchi
Differential Revision: D19650864
fbshipit-source-id: d72e4a0cf61d2dcb76f0a7f4037c36a7c8156942
Summary:
It is useful to be able to control the ACK generation frequency based on how many packets have been received. This adds 3 tunables: a threshold, and an ACK frequency below and above that thresold.
Note this keeps the default so there is no behavior change.
Reviewed By: yangchi
Differential Revision: D19455514
fbshipit-source-id: 53b765d4c872bc6b7c19d5ea859f8eee86d9b5ff
Summary: inspect PN, and when it reaches 2^62 -2 trigger a transport close through a pending event.
Reviewed By: yangchi
Differential Revision: D18239661
fbshipit-source-id: 1a218678099016693149e12ff121e2a39b95aecc
Summary: This fixes an issue with rtt computation. The first rtt sample was incorrect because minrtt gets set to the first rtt sample, hence ack delay never get subtracted. This diff allows ack delay to be subtracted if the minrtt is the first one.
Reviewed By: yangchi
Differential Revision: D17610197
fbshipit-source-id: 3e7087f37ef14848d80c0ab33094834a4fc8974b
Summary:
We erase packets from outstandingPackets list during ack handling.
Currently we handle acks in ascending order of the acked packet number, then
erase() the acked packet. Each erase() call only erase one packet, and it can
potentally make std::deque to move a few elements following the erased one.
This diff changes it to handle acks in descending order, and also erase acked
packets in continuous groups. This reduces erase() calls, and also reduces the
possibility that std::deque needs to move following elements in the erase().
Reviewed By: mjoras
Differential Revision: D17579683
fbshipit-source-id: 8bc11f6a7875beb70dc46c497857ab694df7b6a5
Summary:
Make a custom variant type for PacketHeader. By not relying on boost::variant
this reduces the code size of the implementation.
This uses a combination of a union type as well as a enum type to emulate a variant
Reviewed By: yangchi
Differential Revision: D17187589
fbshipit-source-id: 00c2b9b8dd3f3e73af766d84888b13b9d867165a
Summary:
Use the new Pacer interface in the transport where we currently
directly use CongestinoController interrace for paciner related APIs.
Reviewed By: mjoras
Differential Revision: D16918672
fbshipit-source-id: 410f72d567e71bdd3279e344f6e9abf5e132518e
Summary: Centralize this logic into the pacer interface. But instead of having an explicit canBePaced() function (and we already have a dozen other canBePaced functions or boolean flags in other layers), the pacer just use 0us and default write batch size per loop to answer pacing rate queries when it doesn't meet the condition to properly pace the transport writes.
Reviewed By: mjoras
Differential Revision: D16912631
fbshipit-source-id: 0343b126ca5de315af6823067316526b1004cc6c
Summary:
Currently we handle crypto timer before loss timer. And currently loss
time is for AppData only since for the other two Packet Number spaces, crypto
timer will take care of it. This diff extends loss times to 3 loss times, and
handle them before handle crypto timer. The rational here is that loss time is
shorter than crypto timer, so this will make retransmission during crypto
handshake more aggressive. For app data, this diff doesn't change anything.
Reviewed By: sharma95
Differential Revision: D15552405
fbshipit-source-id: bd5c24b0622c72325ffdea36d0802d4939bae854
Summary:
There is a bug in how we decide if we should schedule a write loop due
to sending Acks. Currently if one PN space has needsToWriteAckImmediately to
true and another PN space has hasAcksToSchedule to true, but no PN space
actually has both to true, we will still schdeule a write loop. But that's
wrong. We won't be able to send anything in that case. This diff fixes that.
Reviewed By: JunqiWang
Differential Revision: D15446413
fbshipit-source-id: b7e49332dd7ac7f78fc3ea28f83dc49ccc758bb0
