I personally think this is an important topic. The topic also appeared
in the TAPS chartering, and my thoughts are currently:
- I think we should ensure that the decisions made by TAPS systems are
evident, at least in the logging. Implementations should not just
provide "magic".
- I'd expect the "standard" API produces deterministic outcomes. This
seems to be helped by the app either asking high-level path properties:
"give me an interactive treatment" or alternatively the API requesting
specific network path properties: "do not use wifi", "prefer low
latency", "interface must be > x Mbps", "mark as DSCP=x", etc.
I'd argue that characterising the App, rather than the network treatment
e.g., "I'm a video conf App", "I wish to send x MB", etc, is much less
helpful for this "standard" TAPS interface.
I am not against a developer or vendor utilising a range of "additional"
properties which aply for a specific system and then can inform specific
decisions. To me, at least, this sort of optimisation requires more
"understanding" to interpret how to match the connection to set of
candidate paths.
Gorry
On 21/03/2018, 11:34, Roni Even (A) wrote:
Hi,
I made this comment in the past in QUIC when discussing migration.
One policy may be prefer wifi over cellular network,
Second policy prefers quic cove TCP
Now I walk into my house and my cellphone has HTTP over QUIC.
At home will switch to wifi but quic is not supported on the wifi so
will fall back to TCP. This contradicts the second policy. So two
options wifi TCP or cellular QUIC , how to decide?
Roni Even
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
