Figure out better confirmation process for TRR
Categories
(Core :: Networking: DNS, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox88 | --- | fixed |
People
(Reporter: valentin, Assigned: valentin)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(7 files)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
Currently a lot of TRR requests are skipped (>10%) because the TRR service is not confirmed.
This may happen because of intermittent networking issues, coming back from suspension, startup, etc.
What we should try to do is:
- see if increasing the number of failed requests before we go into not_confirmed state helps.
- use normal TRR responses as confirmation (that means doing TRR requests immediately and depend on the 1.5s timeout to cancel them if the network isn't up yet leading to falling back to DNS)
- do TRR requests in parallel, until confirmation is done. That way, when we get the confirmation response back, we can start using the other responses immediately, instead of incurring another round-trip delay.
Assignee | ||
Comment 1•4 years ago
|
||
multiple-failures / context change
+-------------------------------------------+
| |
| |
| |
+----------------+ +------v---------+ +----------------+
| | TRR turned on | | confirm ok | |
| OFF +---------------------------> TRY-OK +------------------------> OK |
| | | | | |
+-------^--------+ +--^-------------+ +-------^--------+
| | | |
| | | |
|TRR turned off +---------+ |confirm fail |confirm ok
| | | |
+----------------+ network| | |
| | change | +-------v--------+ +----------------+
| ANY-STATE | | | | timer | |
| | +------+ FAIL +------------------------> TRY-FAIL |
+----------------+ | | | |
+------^---------+ +----------------+
| |
| |
| |
+------------------------------------------+
confirm fail
This is our new design for the confirmation. It separates the trying state into TRY_OK and TRY_FAIL
This way we can more easily determine if we should make the TRR attempt or not.
Assignee | ||
Comment 3•4 years ago
|
||
Assignee | ||
Comment 4•4 years ago
|
||
Depends on D107664
Assignee | ||
Comment 5•4 years ago
|
||
TODO: explain
Depends on D107665
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Also adds nsIDNSService.currentTrrConfirmationState IDL method for test use
Depends on D107666
Assignee | ||
Comment 7•4 years ago
|
||
We now pass a map object instead multiple arguments.
This way if we need to add/remove/change something we don't need to worry
about backwards compatibility and having to change all the callsites as
we do in this patch :)
Depends on D108999
Assignee | ||
Comment 8•4 years ago
|
||
Depends on D109000
Assignee | ||
Comment 10•4 years ago
|
||
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2d8c8e2d2e6a
https://hg.mozilla.org/mozilla-central/rev/6630ba532e23
https://hg.mozilla.org/mozilla-central/rev/7c05c181ad22
https://hg.mozilla.org/mozilla-central/rev/216852c6cf14
https://hg.mozilla.org/mozilla-central/rev/75da5d4751d1
https://hg.mozilla.org/mozilla-central/rev/4e6e499248e5
https://hg.mozilla.org/mozilla-central/rev/e8ee87ef82c3
Description
•