enable QUIC PMTUD
Categories
(Core :: Networking, enhancement, P3)
Tracking
()
People
(Reporter: mail, Assigned: mail)
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
https://github.com/mozilla/neqo/pull/1903 added Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) to Neqo. It is disabled by default.
This Bugzilla Bug tracks the rollout of the feature to Firefox.
As a first step, I will propose a Phabricator Patch to enable the feature on Firefox Nightly.
Enable Path MTU Discovery (PMTUD) on QUIC on Firefox Nightly.
Updated•4 months ago
|
Updated•4 months ago
|
Comment 3•4 months ago
|
||
Backed out for causing webtransport related wpt failures.
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-TIMEOUT | /webtransport/datagrams.https.any.serviceworker.html | Sending and receiving datagrams is ready to use before session is established - Test timed out
Comment 4•4 months ago
|
||
What does the failing test try to do? Fail to transfer max-size+1 datagram
sounds like it should be failing?
From what I can tell, yes, it should fail, but it did not.
For the record, here is the test mentioned in the comment above.
The client uses the neqo_transport::Connection::max_datagram_size
function to get the current max-size.
The function calculates the max-size based on the current MTU.
A guess:
- The test gets the max-size through
max_datagram_size
. - The client's PMTUD increases the MTU.
- A single QUIC datagram can actually now fit more than
max-size + 1
. - Sending of
max-size + 1
succeeds and thus the test fails.
I can investigate this further. Though as discussed, I will prioritize https://bugzilla.mozilla.org/show_bug.cgi?id=1902065 for now.
Comment 6•4 months ago
|
||
Thanks for the analysis. That very likely is the cause, I agree. Any easy fix would be to try and send a datagram not just one byte larger, but much larger.
Enable Path MTU Discovery (PMTUD) on QUIC on Firefox Nightly.
Description
•