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

Justin Uberti <juberti@google.com> Sun, 15 April 2018 13:09 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A341200FC for <rtcweb@ietfa.amsl.com>; Sun, 15 Apr 2018 06:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vhgWKwLqj9t for <rtcweb@ietfa.amsl.com>; Sun, 15 Apr 2018 06:09:36 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F971200C5 for <rtcweb@ietf.org>; Sun, 15 Apr 2018 06:09:35 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id r184so7931793vke.11 for <rtcweb@ietf.org>; Sun, 15 Apr 2018 06:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h7NvPbDOLj1JDrKA5FqnZQMYJbYeo8ij7Psq/2m/Ymc=; b=RTV9KBPdHEX2eUm1xcOAeRQIhppUlLxci+76sAS4p25kplvdLtmCnYa5CBui/2Y7kO o1XeMom0JOjIYNInzHN/AKCymyDup0ss+rGqE3EpCXyMT1VYxiimRZg4mVteTX4JkMu/ zzuLy1lLmdJTizFnrQMgd0cVNzJIy+COa4Bosw/eRMZ9kMM60W8+Ba4Wdi54kBxtRVpH HehAxMVRsFpetsSSog9C34jsgpEMWE0xfHTIvZCfp+RySlB4tyFsBDWwLkLRJpOSt7Wh 2VpPxlrODSBrUYVxRHwJVnUXE1YL15JaTF2W13sBEYRRwMH+vrhMTs9rSdPN/mBc1htl ql9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h7NvPbDOLj1JDrKA5FqnZQMYJbYeo8ij7Psq/2m/Ymc=; b=DmH6fymq3UOnqsqFZYwc0h1LoMrMyvxlaD0wP+6TlB4BrFHptjDWtft64gn6V9A/PV lr3xhgtdufThjz6z2gwNMRQq4ViWbf/qiyhrA5I8FaBILjrEa8rVByDbS4FhbkGpIMXW hLXnaz5taskHU2gf3Pbt2Y0sNlQxcLNn7f8wNZrGhIIX3byUVcgeGTsvuXLMCcE0xR0Z LXZIP2Qdz8hAkXx9XC0/I7NSHWDUTwilK8O+9DrvEqDhxFktkALBnWWxlOmXj6TGZ0h3 o/8nW7RlQUHMPq9ezrpejDRRwsoYJTHY/WWFDFrqW0hlmbyPf5onpBlWZBDxG8XNP0oe 1NUA==
X-Gm-Message-State: ALQs6tC68n46RPkgpFJOzii2hkb81yeg8xc1xgTTS2DZa8C0DA3Wg57P RKTPvxxeRmIpTSsMgpN+PxJ6KofgS1b7WXtMYaR04ykr
X-Google-Smtp-Source: AIpwx49VpbP7SWxLuSqLINMBO4q+MFVnLt+3lW9uJbP6xL3unGMZ7wW5Lh4u8Hro1shYvZXpfVIQZ8o6S3ZhYprsvpQ=
X-Received: by 10.31.147.212 with SMTP id v203mr8412435vkd.39.1523797774237; Sun, 15 Apr 2018 06:09:34 -0700 (PDT)
MIME-Version: 1.0
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <CAOJ7v-1gTq+EEjb+-q-T-pABBW--rpNGegoj_d2_7f7AKGksCA@mail.gmail.com> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <CAOJ7v-0ED-FK=JmSxBJYfM=PCdgY6kmbiq6aFLcP7OXugG07EA@mail.gmail.com> <e6938f7d-542d-736b-0a3d-9269d7dd06e5@cs.tcd.ie> <CAOW+2dv1ORz2tEkgDTvdM1DtgyOdgXqKU30T4QhLAp1NT+rirg@mail.gmail.com> <CAOJ7v-0tCcg3FdzyfSJ6Y3JaH-TivFf-Sey6+tD8BANJKsjqtQ@mail.gmail.com> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <b5d323ac-2205-2aee-05c9-f270e80215f5@gmail.com> <CAOJ7v-0+hr-NddbLCwgjkfyEFEzoLYW8BcE5OYZ+HUiqDRnarg@mail.gmail.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com> <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com> <914e0220-e3cc-00d7-0925-e5deb8b07e75@nostrum.com> <AFDFD3F3-4798-4716-B26C-A67457BF2C65@sn3rd.com> <e5e2a517-d29a-117c-ab79-6f01fa62b843@gmail.com> <20180412144158.44733ac7@lminiero> <b767da79-7678-2a1c-ecb0-46a9a3bd9129@gmail.com> <CAOJ7v-2gmxpsGp=25pcJmnkYmipZdCFOqU4nLtAVSznLsZo9rQ@mail.gmail.com> <4902F7BF-0D20-4EA6-9E78-D22C90EFCE22@westhawk.co.uk> <CAOJ7v-3NsqD6pq-kkMw81+2n_D8qf558CKeCE76ZypyxwCgs9g@mail.gmail.com>
In-Reply-To: <CAOJ7v-3NsqD6pq-kkMw81+2n_D8qf558CKeCE76ZypyxwCgs9g@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Sun, 15 Apr 2018 13:09:21 +0000
Message-ID: <CAOJ7v-2NJ1vhVUerZ1cn8MP9hD_vgAYBurjeQKMx76Aa_U=n=Q@mail.gmail.com>
To: Tim Panton <thp@westhawk.co.uk>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140f7020baf100569e2d1a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/RSos-NunQP9yrSgVJmyZB5o0yaQ>
Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Apr 2018 13:09:38 -0000

On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti <juberti@google.com> wrote:

>
>
> On Thu, Apr 12, 2018 at 11:59 PM westhawk <thp@westhawk.co.uk> wrote:
>
>>
>>
>> > On 13 Apr 2018, at 02:22, Justin Uberti <juberti=
>> 40google.com@dmarc.ietf.org> 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.

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.