Add estimatedSendRate to stats. #494
Conversation
index.bs
Outdated
| This rate applies to all streams and datagrams that share a [=WebTransport session=] | ||
| and is calculated by the congestion control algorithm (potentially chosen by | ||
| {{WebTransport/congestionControl}}). If this [=WebTransport session=] is | ||
| pooled with others in a shared [=connection=], the value is undefined. |
There was a problem hiding this comment.
I gather this is to satisfy @martinthomson's concern in #421 (comment)?
This might limit media ingest to non-pooled connections. Are we OK with that? Is there no strategy a user agent could employ instead (e.g. divide 50/50 and omit other traffic from the result)?
Or perhaps this is fine?
There was a problem hiding this comment.
To start with, this speaks to the feature detection angle more strongly.
The primary concern here is with cross-origin WebTransport sessions. That is, when example.com establishes a session toward https://wt.example/upload and wants to know stuff about that connection. If that connection is used to load stuff for other purposes that wt.example might have (within the same top-level browsing context), then information about size and timing might leak through. We might assume that example.com is not already in a position to observe that much and so adding this new information would be irresponsible.
After getting more comfortable with my own understanding of this situation, I believe that it is already the case that sites that can make queries of cross-site content can learn stuff about how the connection is being used. So we're just changing the fidelity of the measurements and maybe changing/constraining how the browser might be able to act to protect that information from observation. For instance, in the current regime, a browser could isolate requests from different sources in time, so that requests never contend for capacity, at the cost of timing contention; WebTransport might make that sort of trick harder to pull off.
I'm almost at the point where I would instead say that this requirement can be removed, though perhaps we can do that in a follow-up.
There was a problem hiding this comment.
I propose that we merge this PR with this stat not being available for pooled connection, and then make a tasks to continue the discussion about pooled connections. Perhaps we solve it, as you and Martin suggest. But I'd like to not have the stat blocked as a whole while we figure it out.
Co-authored-by: Jan-Ivar Bruaroey <jan-ivar@users.noreply.github.com>
|
Meeting:
|
SHA: b20068d Reason: push, by jan-ivar Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Fixes #484.
Preview | Diff