On 9/21/2021 9:37 AM, Spencer Dawkins at IETF wrote:
I have been maintaining a collection of various goals for path selection
(most recently, in
https://datatracker.ietf.org/doc/html/draft-dawkins-quic-multipath-selection-01#section-3).
It's not a short list.
If we're also including user preferences that would include knowing the
difference between cellular connections that are metered, cellular
connections that are unmetered but being throttled, and cellular
connections that are unmetered and unthrottled, and cross-matching them
with wifi connections that are likely to work better than cellular
connections vs. wifi connections that are only intermittently performing
well, that's not a small amount of complexity.
This leads to the problem of asymmetric knowledge between client and
server. On the client, applications can use system APIs and user
preferences to identify which connections are "metered, cellular
connections that are unmetered but being throttled, and cellular
connections that are unmetered and unthrottled." But the server side
does not know that. Yet in many scenarios most of the traffic volume
originates from the server, and the scheduling choices of the server may
cause increased bills or exhaustion of quotas for the client. Which
implies that there should be some way for the client to signal how the
server shall consider connection.
I think this "knowledge sharing" is independent from "application
preferences". The work at Ali Baba shows that there is a lot of benefits
in incorporating application states in scheduling decisions. For
example, if the video streaming application notices that the video
buffers are emptying too fast, it might tell the server to start using
more bandwidth, even if that means using metered connections. But that
application state, "video buffers are emptying", is not the same as the
network state, "path 3 is on a metered connection".
I don't think that we will be able to fully standardize the way
applications pass their preferences. That's why in draft-liu the
"QOE_CONTROL_SIGNALS" is mostly used to pass application-defined
signals. But we might be able to have a reasonable set of codes (or
priorities) explaining the "state of a path", and use that in the
"PATH_STATUS" frame.
-- Christian Huitema
