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

[Justin Uberti <[e-mail]>]

On Sun, Apr 15, 2018 at 8:15 AM Lennart Grahl <[e-mail]>
wrote:

> 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).
>
>
Right, I agree these edge cases are reasonable illustrations of the general
case - "use another interface if my primary interface is crap".

My overall point is that we might be able to consider using multiple
non-virtual interfaces as part of Mode 2, or perhaps an in-between "Mode
1.5", since HTTP traffic could conceivably do the same in the near future
(via MPTCP <https://support.apple.com/en-us/HT201373> or QUIC connection
migration
<https://datatracker.ietf.org/meeting/100/materials/slides-100-quic-sessb-connection-migration-01>).
IOW, a) could be handled separately from this complex "consent" discussion
(and the consent discussion would be focused on b)).