Subject: [Taps] conflicting policies

From: "Roni Even (A)" <[email-masked]>
Date: Wed, 21 Mar 2018 11:34:44 +0000

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

---

From: G Fairhurst <[email-masked]>
Date: Wed, 21 Mar 2018 14:20:50 +0000

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:
> 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-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 21 Mar 2018 14:41:52 +0000

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-masked]> 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
>

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 21 Mar 2018 15:47:05 +0000

for historical perspective, this is similar to the problem of "feature
interaction" in old private phone exchanges 30 years back - its (in
general) quite a hard problem if you can't just order all the preferences...

On Wed, Mar 21, 2018 at 11:34 AM, Roni Even (A) <[email-masked]>
wrote:

> 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
>