Measure the performance impact if a transaction can't be dispatched until HTTPS RR is available
Categories
(Core :: Networking: HTTP, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox91 | --- | fixed |
People
(Reporter: kershaw, Assigned: kershaw)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
2.42 KB,
text/plain
|
chutten
:
data-review+
|
Details |
Currently, a transaction is dispatched without waiting for HTTPS RR. When ECH is enabled in the future, the transaction needs to wait before dispatching. In this bug, we'd like to know what's the performance impact caused by encoring a transaction to wait for HTTPS RR.
|
Assignee | |
Comment 1•3 years ago
|
||
|
|
Assignee | |
Comment 2•3 years ago
|
||
|
||
Comment 3•3 years ago
|
||
Comment on attachment 9227357 [details]
bug1714506_telemetry_data_review.txt
DATA COLLECTION REVIEW RESPONSE:
Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?
Yes.
Is there a control mechanism that allows the user to turn the data collection on and off?
Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.
If the request is for permanent data collection, is there someone who will monitor the data over time?
No. This collection will expire in Firefox 93.
Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, Technical.
Is the data collection request for default-on or default-off?
Default on for all channels.
Does the instrumentation include the addition of any new identifiers?
No.
Is the data collection covered by the existing Firefox privacy notice?
Yes.
Does the data collection use a third-party collection tool?
No.
Result: datareview+
Pushed by kjang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/adf68ff22830 Force a transaction to wait for HTTPS RR, r=necko-reviewers,valentin
|
||
Comment 5•3 years ago
|
||
| bugherder | ||
|
||
Comment 6•3 years ago
|
||
I've just wasted the best part of an afternoon running through mozregression to find this change following my report in BZ 1717214.
The performance impact seemingly for me is that "it makes web browsing completely unusable". Requests regularly spend 20-50 seconds stuck in the "Blocked" phase. I'm not sure if this is down to me using TRR or not, but it's so bad that I worry it will put people off testing Nightly to find other bugs.
Can we please consider reverting this before 93?
I'm all for the security benefits of ESNI (or ECH nowadays) but if this is the impact then I can't see how it can be shipped.
Description
•