Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

[Justin Uberti <[e-mail]>]

On Sun, Apr 15, 2018 at 7:40 AM westhawk <[e-mail]> wrote:

>
>
> On 15 Apr 2018, at 15:09, Justin Uberti <[e-mail]> wrote:
>
>
>
> On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti <[e-mail]> wrote:
>
>>
>>
>> On Thu, Apr 12, 2018 at 11:59 PM westhawk <[e-mail]> wrote:
>>
>>>
>>>
>>> > On 13 Apr 2018, at 02:22, Justin Uberti <juberti=
>>> [e-mail]> wrote:
>>> >
>>> > Being non-interactive, it's not clear that those cases require Mode 1
>>> though; they should work well even in Mode 2. I also don't think that
>>> suggesting "more appropriate means" is useful when we as a WG haven't been
>>> able to come up with any.
>>>
>>> Whoa there! Non interactive, that’s a big step from non-conversational !
>>> So one current use-case is adjusting room lights over the data channel.
>>> You can literally see latency - an unnecessary cloud round-trip is entirely
>>> visible.
>>>
>>> Another is driving a droid over the datachannel using it’s camera to
>>> feed live video to see where it is going
>>> - again totally interactive, just not using local media at the user’s
>>> end (although we do use the
>>> motion sensors to give a steering wheel feel) - latency here causes
>>> crashes!
>>>
>>> A third one is baby cams, where again the video feed is one-way but
>>> you’d really like to keep the media on the home wifi
>>> if possible for cost (and privacy) reasons.
>>>
>>> In all these I’ll have to introduce an otherwise needless GUM request to
>>> get the network behaviour I want.
>>>
>>> Perhaps I should present some of these non-call based usecases at a
>>> future F2F so that folks get a sense of the possibilities.
>>>
>>
>> The original comment from Lorenzo that I was responding to specifically
>> cited one-way media broadcasts.
>>
>> Regardless, I contend that those cases as well as your scenarios should
>> all work as desired in Mode 2, which allows direct connections.
>>
>
> Now, one might reasonably ask: if this is the case, what's the benefit of
> Mode 1?
>
> Simply stated, Mode 1 allows the client to pick whatever network interface
> works best, and this provides two key benefits:
> a) handoff or multipath between interfaces (e.g. wired/wifi or wifi/cell)
> b) use of non-VPN interfaces when a VPN exists
>
> I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC
> will already have to solve this, and it's also not clear that this
> situation actually presents an issue.
>
>
> I’m not sure I agree - or disagree - yet.
> Here are a couple of sources of my uncertainty:
>
> SCTP has also has multipath/multihome capabilities which ICE is
> effectively obscuring in the current setup.
> Given this is the 1.0 spec, we also have SRTP to worry about which isn’t
> capable of multipath (as far as I’m aware).
>

SCTP is a non-issue here; as you point out, it's being tunneled over
DTLS/ICE, so it's whatever ICE chooses to do (which is the core issue).
SRTP similarly follows what ICE does. And ICE, in Mode 1, can use whatever
interface it wants; it can choose a different interface for every packet,
as long as it has a valid pair on that interface.

>
> An example of this may be an LTE phone that has a ‘data bearer channel’
> and a ‘media bearer channel’ - the billing routability and QoS behaviour of
> these
> two interfaces will be different. I could imagine that a carrier app might
> want to use the media bearer for a voice call. (Sorry for my 3GPP
>  semi-ignorance).
>

I don't think this is relevant to this discussion; since this isn't
surfaced upwards as different interfaces to the OS, any behavior here is
the same as you would get in Mode 2 when using the cellular interface.

>
>
> Therefore, the problem seems to reduce to b), and this may be a much more
> tractable situation. If a user is using a VPN to access a web application
> (i.e., the 'default' route that would be chosen by WebRTC is for a VPN
> adapter), one could imagine the browser asking permission to use non-VPN
> interfaces.
>
>
> Is it possible to tell if an interface is a VPN ? I’m not convinced I know
> how to reliably distinguish between a VPN and a multi-bearer LTE
> config.
>

You can easily tell those apart via OS interface properties. For example,
Windows allows one to determine the type of an interface, e.g. physical or
tunnel (
https://msdn.microsoft.com/en-us/library/windows/desktop/aa814491(v=vs.85).aspx).
Now,
there are multiple possible types of tunnel, but even just knowing tunnel
vs non-tunnel might be sufficient.

>
>
> This could still be too complicated for typical users to understand (as I
> still don't know what the prompt text should say), but the key point here
> would be that only VPN users (who presumably are somewhat more savvy) would
> have to see this prompt.
>
> Thoughts? If we like this formulation, we could redefine Mode 1
> accordingly, and cite the mechanism above as a potential alternative to
> getUserMedia.
>
> I like this in principle. But I also feel that the prompt would include
> the concept of revealing location/service provider.
>

That seems entirely reasonable, especially the "service provider" angle,
which is more accurate and likely understandable than "location".