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

[Lennart Grahl <[e-mail]>]

On 15.04.2018 15:09, Justin Uberti 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 have run into some edge cases where not having a) is an issue:

1. Testing data channel implementations over a separate network where
delay, packet loss, etc. can be applied without affecting the signalling
network or access to the internet. The only solution I was able to come
up with was temporarily changing the default route until the peer
connection is set up (and I can't use getUserMedia because I don't
always control the test scripts).

2. Sitting in the German high speed train (called "ICE" btw. ;)) and
using the hotspot (default route) as well as being connected to the
smartphone via another interface and using Threema Web to connect to the
smartphone app. This is exactly where WebRTC should shine but it doesn't
because the default route lead to both devices talking via TURN since
network policies in the train prevent the devices from talking to each
other directly. And you can imagine how well TURN works in a high speed
train, especially with the horrible network coverage in Germany...

3. Tim brought up another example: "So if my phone is acting as a
hotspot for my drone, and connecting to 4g. The phone's 4g is the
default route for the browser - but I actually want the traffic to go
over the wifi interface."

I realise these examples are very specific but I would not be surprised
if this is something that happens in large corporate networks as well
(peers technically being able to talk to each other via a different
network but not via the one with the default route).

Cheers
Lennart

> 
> 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.
> 
> 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.
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>