Summary:
- Wrap the TokenLength in a QuicInteger
- Validate token written by server equals token parsed by client codec
Reviewed By: mjoras
Differential Revision: D33134186
fbshipit-source-id: fc003979d9bacdb9ab9bb563a300cedd7a99d58a
Summary:
- Issuing NewTokenFrames to clients, allowing them to verify their address in subsequent connections by including the token.
- add NewTokenFrame struct in the union type QuicSimpleFrame.
- Issued only once when the crypto handshake is complete.
- Testing includes validating token serialization & deserialization and asserting that the NewTokenFrame is only issued once on handshake completeness.
Reviewed By: mjoras
Differential Revision: D31673160
fbshipit-source-id: 9401ab1a4b878d8b4380d55afa531ec768f5f4cd
Summary:
Providers observers with insight into ACKs received. Works for both client and server transport.
Attempts to prevent wasted memory by removing any allocated memory for ACK events if no packets in flight. In tandem, reduces allocs by _not_ removing allocated memory when packets are in flight (as this means more ACK events will occur soon...).
Reviewed By: jbeshay
Differential Revision: D31221280
fbshipit-source-id: 64b73aa74c757ebbfc27bb9c2a047d08dc7a77ca
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: Revert the experimental change for the server to use an initial cwnd 30 MSS.
Reviewed By: hanidamlaj
Differential Revision: D32173456
fbshipit-source-id: 13ed4f4c1b11ab9c1dc0da1904be3eb5c564e2d8
Summary: Set the experimental version of Mvfst to use an initial cwnd of 30 MSS instead of 10.
Reviewed By: mjoras, lnicco
Differential Revision: D31553957
fbshipit-source-id: 8aa4f0596dbedbea0922afa13de0631c1b898f53
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:
- The current mvsft implementation only checks against the duration threshold to establish persistent congestion. However, according to the spec, persistent congestion should only be established if both the threshold duration is exceeded and there are no acked packets between the send times of the lost packets.
- In addition to the logic already present in `isPersistentCongestion()`, `isPersistentCongestionExperimental()` validates that no acked packet exists between the send times of the two lost ack-eliciting packets.
Reviewed By: mjoras
Differential Revision: D30117835
fbshipit-source-id: 8809ccda761fe67b4cf51abbf2d5c0d5a4ed2b38
Summary:
- Removed packetNum field from CipherUnavailable struct.
- Removed all instances referring to the field and fixed tests accordingly.
Reviewed By: mjoras
Differential Revision: D29968168
fbshipit-source-id: 9802b8cd66f43f2a8d54340f2d00639ee4679aaf
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 default we are using, 11, is probably excessive.
Reviewed By: yangchi
Differential Revision: D29273970
fbshipit-source-id: 24605e7d8feec43ee9b53880e8c510d1ca376d75
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:
Added code for remaining transport parameter validation. These errors are covered by these changes
MUST send TRANSPORT_PARAMETER_ERROR if original_destination_connection_id is received [Transport 18.2] FAILED [2]
MUST send TRANSPORT_PARAMETER_ERROR if preferred_address, is received [Transport 18.2] FAILED [3]
MUST send TRANSPORT_PARAMETER_ERROR if retry_source_connection_id is received [Transport 18.2] FAILED [4]
MUST send TRANSPORT_PARAMETER_ERROR if stateless_reset_token is received [Transport 18.2] FAILED [5]
MUST send TRANSPORT_PARAMETER_ERROR if max_ack_delay >= 2^14 [Transport 7.4 and 18.2] FAILED [6]
Reviewed By: yangchi
Differential Revision: D28266216
fbshipit-source-id: f0e935f9158554c4a5b6922a8ee1453ebabfab25
Summary: This diff is the encode and decode support of Datagram frame.
Reviewed By: mjoras, yangchi
Differential Revision: D20983883
fbshipit-source-id: 1a72a87e6ce3601b71fececca872a9d20bf7820e
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 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:
as title
(Note: this ignores all push blocking failures!)
Reviewed By: mjoras
Differential Revision: D25772188
fbshipit-source-id: aa466539d301ba913ceb78d717f53ca31dbd4644
Summary:
well, the previously added log was wrong in the reset path. it should
be in the stop sending path
Reviewed By: avasylev
Differential Revision: D25724136
fbshipit-source-id: e6cec3c225e066d16c09da895356578cd6ec6808
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: Speed up the experiment by disabling blackhole detection all together temporarily.
Reviewed By: mjoras
Differential Revision: D24997566
fbshipit-source-id: 2781e586f5ba9896633ab0716e78cfc49e0e34a4
Summary: Adds another knob param to enforce udp payload size. This is basically a "canIgnorePathMTU" knob that client has.
Reviewed By: mjoras
Differential Revision: D24586165
fbshipit-source-id: befb265a24fae8f450f323cf2d652a8b448e698c
Summary: Accomplished by setting it very high.
Reviewed By: yangchi
Differential Revision: D24656684
fbshipit-source-id: 97120b867b659f1ef6ff46ea23de0db672e36948
Summary: This is potentially a better min interval for the TokenlessPacer, as event loops can often take > 200us.
Reviewed By: yangchi
Differential Revision: D24123176
fbshipit-source-id: 21b023925d331b196676a71a3a2eb3bc8e62df6c
Summary: This reduces dependencies for both testing and instrumentation.
Reviewed By: mjoras
Differential Revision: D23997313
fbshipit-source-id: 5eb3a790c7bb2569dc1e941e3911ad4aac4e9258
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:
Here are some of the questions I guess we'd like to answer regarding d6d:
- How long, and how many probes does d6d take to find the PMTU upper bound for a
given connection?
- If PMTU blackhole is detected, what's the packet size that triggers the
signal? And what's the state of d6d when that happens? Also, if there's issue
with the PMTU stability in the path, in what frequency does it oscillate?
This adds some meta data in d6d's lifecycle in order to provide info when those
events happen.
Reviewed By: mjoras
Differential Revision: D23972069
fbshipit-source-id: f6a2d1d656b33d94b41ecfbb0c06bdaf299caa8b
Summary: We have this counter but don't increment it, might as well.
Reviewed By: yangchi
Differential Revision: D23916621
fbshipit-source-id: 0a8cb947f1941e04789a0144a4fec87239caef50
Summary:
Due to high number of RTT samples I refactored the OutstandingPacket to
split the packet data and packet metrics. We know have access to metrics
without the need of saving the packet data.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/178
Reviewed By: mjoras
Differential Revision: D23711641
Pulled By: bschlinker
fbshipit-source-id: 53791f1f6f6e184f37afca991a873af05909fbd2
Summary:
This glues together the d6d lifecycle via probe timeout and raise timeout.
Had to put these two timeouts in the base transport because it has all the
necessary accountings (e.g. check close state, process callbacks) that should
happen before scheduling timeouts.
Other notable changes (included here because code is simple):
- Keep track of d6d probes in loss state. Upon second thought, it makes more
sense because we are reducing the available bandwidth as a result of sending
probes anyway. And not tracking them imposes a delay on congestion controller.
I think this does not violate the d6d spec's point of not penalizing congestion
window for d6d probes, because
- 1. we don't put losses of d6d probes in loss event. Therefore from the POV of
congestion controller, d6d probes never get lost.
- there will be at most kDefaultD6DMaxOutstandingProbes losses (i.e. 2)
that we don't tell congestion controller about. Even if those are actually
caused by congestion, it should have minimal impact because 2 is small and if there's really a congestion, the loss of normal packets should provide the signal.
- Pacing d6d probes
- Kick off d6d after a delay of 1s. This should filter out short-lived connections where probing is relatively expensive and less useful.
Reviewed By: mjoras
Differential Revision: D23736656
fbshipit-source-id: 8121fa8bcebab10a56a4e046c32c4e99ed6c3013
Summary:
This should be a noop in our current set up. I added some comments to clarify
the logic. Put it in another way,
- `udpSendPacketLen = f(max_packet_size, kDefaultMaxUDPPayload, canIgnorePathMTU)`
- `d6d.maxPMTU = g(max_packet_size, kDefaultMaxUDPPayload, d6dConfig.enabled)`
`f` and `g` are what the code does.
Reviewed By: mjoras
Differential Revision: D23745844
fbshipit-source-id: bc8c38a8a9086fe31e5f367d01737f360c403353
Summary:
Similar to raise timeout, client can choose the probe timeout via transport
parameter. This timeout might not end up being useful because by the time the
recommended timeout (15s) expires, either:
i. the probe gets acked, d6d send a larger probe or sleeps if the upper bound
is found
ii. the probe is lost, then quic will likely determine its loss faster than
15s, upon which a PMTU blackhole is recognized
So adding this is mostly for mvfst to be compliant with the d6d spec, and
potentially useful if we want to control probe sending rate upon ack, e.g. send
the next probe after 1s upon ack instead of immediately.
Reviewed By: yangchi
Differential Revision: D23700182
fbshipit-source-id: 18b740d05343591d6afa086b9fae746e6c71aca5
