Agreed that the implementations should not do “magical” or unexpected things.
In the example question there are actually two elements at play:
- How to rank preferences and policies at connection establishment time
- How to treat path changes that may be disruptive to established connections
For the first case, current deployments avoid the issue by always prioritizing
path preference over protocol preference. Protocol preference only has
influence in the absence of a path preference, and for cases like costly LTE
and free Wi-Fi, the path preference is rather hard-coded. Between two free
ethernet interfaces, there is no particular preference. Should this be
codified? Perhaps, perhaps not. If it were, what would reflect current practice
is:
- If there is an explicit path preference, choose that first
- Within a given path, follow protocol preferences
- If there are no path preferences, use protocol preferences to guide path
preferences
- Within those selected paths, follow protocol preferences
For the second case, where there is a path change, a protocol like QUIC would
try to migrate. However, if it can’t, I don’t think the TAPS system can or
should seamlessly re-establish—there is new context! We would give a path
changed event to indicate that while you’re on a specific path (LTE), there is
a new, more preferred path (Wi-Fi), at which point the application can request
a new Connection (essentially cloning).
Thanks,
Tommy
> On Mar 21, 2018, at 2:20 PM, G Fairhurst <[email protected]> wrote:
>
> 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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
