Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates

From: Justin Uberti <[email-masked]>
Date: Mon, 2 Jul 2018 16:08:19 -0700

That's the approach we plan to take in Chrome. There is a substantial
amount of datachannel traffic, and a quick calculation suggests that most
of that is non-permissioned, so we should be able to measure the effects of
this change.

On Sat, Jun 30, 2018 at 5:44 AM Eric Rescorla <[email-masked]> wrote:

> I haven't thought about it too much, but I think that I would probably do
> is an A/B test where I randomly set clients to this strategy or the current
> strategy and measured success rates, time to connect, and (maybe) some sort
> of call quality stat. It's not going to be easy because I don't know how
> much non-permissioned WebRTC there is in the wild.
> -Ekr
>
>
> On Fri, Jun 29, 2018 at 6:06 PM, youenn fablet <[email-masked]> wrote:
>
>> A draft describing the Safari/WebKit approach is available at
>> https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt
>>
>> Eric, can you precise the kind of information you would like to have?
>> Some testing has been done to validate the approach but I do not think
>> this is representative of the actual state of the affair. Safari/WebKit is
>> not gathering any related statistic.
>>
>>    Y
>>
>> Le ven. 29 juin 2018 à 11:10, Justin Uberti <juberti=
>> [email-masked]> a écrit :
>>
>>> I believe such data will be forthcoming from the Safari team. We are
>>> also working on this.
>>>
>>> On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <[email-masked]> wrote:
>>>
>>>> It seems like this is something one could A/B test and measure
>>>> connection rates. Has someone done so?
>>>>
>>>> -Ekr
>>>>
>>>
>

---

From: youenn fablet <[email-masked]>
Date: Mon, 2 Jul 2018 17:04:37 -0700

Good to know that Chrome can do some measurements there.
>From the feedback I received from web developers, some applications that
care about this are games and applications like editors that exchange large
data between devices of a single user.
Some other applications like WebTorrent are less in need for host
candidates.

     Y

---

From: westhawk <[email-masked]>
Date: Tue, 3 Jul 2018 10:18:35 +0100

Slightly off topic - but if an origin was permissioned once but does not do GUM on this particular
page, which ruleset applies ?

> On 3 Jul 2018, at 00:08, Justin Uberti <juberti=[email-masked]> wrote:
> 
> That's the approach we plan to take in Chrome. There is a substantial amount of datachannel traffic, and a quick calculation suggests that most of that is non-permissioned, so we should be able to measure the effects of this change.
> 
> On Sat, Jun 30, 2018 at 5:44 AM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> I haven't thought about it too much, but I think that I would probably do is an A/B test where I randomly set clients to this strategy or the current strategy and measured success rates, time to connect, and (maybe) some sort of call quality stat. It's not going to be easy because I don't know how much non-permissioned WebRTC there is in the wild.
> -Ekr
> 
> 
> On Fri, Jun 29, 2018 at 6:06 PM, youenn fablet <[email-masked] <mailto:[email-masked]>> wrote:
> A draft describing the Safari/WebKit approach is available at https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt <https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt>
> 
> Some testing has been done to validate the approach but I do not think this is representative of the actual state of the affair. Safari/WebKit is not gathering any related statistic.
> 
>    Y
> 
> Le ven. 29 juin 2018 à 11:10, Justin Uberti <juberti=[email-masked] <mailto:[email-masked]>> a écrit :
> I believe such data will be forthcoming from the Safari team. We are also working on this.
> 
> On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> It seems like this is something one could A/B test and measure connection rates. Has someone done so?
> 
> -Ekr
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: youenn fablet <[email-masked]>
Date: Tue, 3 Jul 2018 08:53:58 -0700

If GUM is not used at least once for the lifetime of the page, WebKit is
currently using mode 3.

There is the possibility for a user to grant persistent access to
camera/microphone for an origin through Safari UI.
In that case, the user will no longer be prompted for any page of that
origin.
Mode 2 could be used by default for these pages since user actually opted
in.

Le mar. 3 juil. 2018 à 02:18, westhawk <[email-masked]> a écrit :

> On 3 Jul 2018, at 00:08, Justin Uberti <
> juberti=[email-masked]> wrote:
>

---

From: westhawk <[email-masked]>
Date: Tue, 3 Jul 2018 16:58:35 +0100

> On 3 Jul 2018, at 16:53, youenn fablet <[email-masked]> wrote:
> 
> If GUM is not used at least once for the lifetime of the page, WebKit is currently using mode 3.
> 
> There is the possibility for a user to grant persistent access to camera/microphone for an origin through Safari UI.
> In that case, the user will no longer be prompted for any page of that origin.
> Mode 2 could be used by default for these pages since user actually opted in.

In one of my workflows that would actually be quite useful. 
We scan a QR to establish an identity pairing, then subsequent connections don’t use the camera
just data and received video.

T.

> 
> Le mar. 3 juil. 2018 à 02:18, westhawk <[email-masked] <mailto:[email-masked]>> a écrit :
>> On 3 Jul 2018, at 00:08, Justin Uberti <juberti=[email-masked] <mailto:juberti=[email-masked]>> wrote:
>> 
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 17 Jul 2018 13:46:20 -0700

Where is the right place to comment on draft-mdns-ice-candidates?

I looked at it from an ICE WG perspective, and it seems to be that since
(in RFC 5245), the candidate address can be a FQDN (section 15.1) you don't
need the special steps you have in section 3.2, because a .local address is
a FQDN (isn't it?).  I think the only novel thing would be to perhaps make
it clear that mDNS should be used for the name resolution.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 Jul 2018 16:58:35 -0400

Tue, Jul 17, 2018 at 16:46 Peter said:

> it clear that mDNS should be used for the name resolution.

[BA] Using mDNS for resolution does introduce potential failure modes. For
example, in a multi-subnet enterprise network using private addresses,
10.1.1.1/24 and 10.2.1.1/24 could connect via a router whereas mDNS
resolution will fail in the absence of proxies. Whether this matters in
practice depends on the topologies where data channel applications are
deployed.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Jul 2018 18:10:32 -0400

> a FQDN (isn't it?).

The use of a .local signals that this is a special use name within the
context of multicast DNS (RFC 6762).  One key difference there is that the
uniqueness of a standard DNS name is derived from the hierarchical
delegation of the DNS.  Uniqueness in MDNS is achieved using a local probe
and announce method.  As Harald pointed out in the room, there are some
latency consequences to that; those might be avoided by generating probable
uniqueness in names via the UUID mechanism, but that still need to be
worked out.  That, I think means the work in 3.1 is definitely needed.

> I think the only novel thing would be to perhaps make it clear that mDNS
> should be used for the name resolution.
>
>
You might treat the special steps as redundant (since .local should signal
mDNS), but I personally think it is helpful, because it discourages
coalescing with standard DNS responses (which is permitted by 6762).

Just my personal opinion.

Ted

>> not gathering any related statistic..
>>
>>    Y
>>
>> Le ven. 29 juin 2018 à 11:10, Justin Uberti <juberti=40google.com@dmarc.
>> ietf.org> a écrit :
>>
>>> On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <ekr@rtfm..com
>>> <[email-masked]>> wrote:
>>>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 18 Jul 2018 07:17:54 -0700

Yeah, I think we just need to emphasize that the FQDN can be a mDNS name.
Here's my current suggestion for updates to S 4.1 in ice-sip-sdp
<https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-21#section-4.1>:

>
>
>
>
>
>
> *<connection-address>:  is taken from RFC 4566 [RFC4566].  It is theIP
address of the candidate.  When parsing this field, an agentcan
differentiate an IPv4 address and an IPv6 address by presenceof a colon in
its value -- the presence of a colon indicates IPv6.An agent MUST ignore
candidate lines that include candidates withIP address versions that are
not supported or recognized.  An IPaddress SHOULD be used, but an FQDN
(including a mDNS [RFC6762] name) MAY be used in place of an IP address. *

In the case of receiving an candidate containing a FQDN, the hostname is
> looked up via DNS or mDNS as appropriate, first using an AAAA record
> (assuming the agent
> supports IPv6), and if no result is found or the agent only
> *supports IPv4, using an A record.  *

---

From: Justin Uberti <[email-masked]>
Date: Wed, 18 Jul 2018 07:20:13 -0700

Note that we are going to discuss the particulars here in the mmusic WG
meeting on Thursday.

On Wed, Jul 18, 2018 at 7:17 AM Justin Uberti <[email-masked]> wrote:

>> You might treat the special steps as redundant (since .local should
>> signal mDNS), but I personally think it is helpful, because it discourages

---

From: youenn fablet <[email-masked]>
Date: Wed, 18 Jul 2018 10:48:53 -0400

Agreed that an explicit reference to MDNS would be good.
DNS resolution can be used for both candidates as well as STUN/TURN server
names.
The proposal so far is to ensure that MDNS be supported for candidates.

Le mer. 18 juil. 2018 à 10:20, Justin Uberti <[email-masked]> a écrit :

>>>> I looked at it from an ICE WG perspective, and it seems to be that
>>>> since (in RFC 5245), the candidate address can be a FQDN (section 15.1) you
>>>> don't need the special steps you have in section 3.2, because a .local
>>>> address is a FQDN (isn't it?).
>>>>
>>>
>>>> I think the only novel thing would be to perhaps make it clear that
>>>> mDNS should be used for the name resolution.
>>>>
>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Jul 2018 14:49:06 +0000

Does that mean that RTCWEB is actually going to reference ice-sip-sdp and ICEbis (instead of RFC 5245)?

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 18 July 2018 10:18
To: Ted Hardie <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates

Yeah, I think we just need to emphasize that the FQDN can be a mDNS name. Here's my current suggestion for updates to S 4.1 in ice-sip-sdp<https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-21#section-4.1>:

<connection-address>:  is taken from RFC 4566 [RFC4566].  It is the
IP address of the candidate.  When parsing this field, an agent
can differentiate an IPv4 address and an IPv6 address by presence
of a colon in its value -- the presence of a colon indicates IPv6.
An agent MUST ignore candidate lines that include candidates with
IP address versions that are not supported or recognized.  An IP
address SHOULD be used, but an FQDN (including a mDNS [RFC6762] name)
MAY be used in place of an IP address.

In the case of receiving an candidate containing a FQDN, the hostname is looked up via DNS or mDNS as appropriate, first using an AAAA record (assuming the agent
supports IPv6), and if no result is found or the agent only
supports IPv4, using an A record.

On Tue, Jul 17, 2018 at 3:11 PM Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Jul 17, 2018 at 4:46 PM, Peter Thatcher <pthatcher=[email-masked]<mailto:pthatcher=[email-masked]>> wrote:
Where is the right place to comment on draft-mdns-ice-candidates?

I looked at it from an ICE WG perspective, and it seems to be that since (in RFC 5245), the candidate address can be a FQDN (section 15.1) you don't need the special steps you have in section 3.2, because a .local address is a FQDN (isn't it?).

The use of a .local signals that this is a special use name within the context of multicast DNS (RFC 6762).  One key difference there is that the uniqueness of a standard DNS name is derived from the hierarchical delegation of the DNS.  Uniqueness in MDNS is achieved using a local probe and announce method.  As Harald pointed out in the room, there are some latency consequences to that; those might be avoided by generating probable uniqueness in names via the UUID mechanism, but that still need to be worked out.  That, I think means the work in 3.1 is definitely needed.

I think the only novel thing would be to perhaps make it clear that mDNS should be used for the name resolution.

You might treat the special steps as redundant (since .local should signal mDNS), but I personally think it is helpful, because it discourages coalescing with standard DNS responses (which is permitted by 6762).

Ted

On Fri, Jun 29, 2018 at 6:07 PM youenn fablet <[email-masked]<mailto:[email-masked]>> wrote:
A draft describing the Safari/WebKit approach is available at https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt

Eric, can you precise the kind of information you would like to have?
Some testing has been done to validate the approach but I do not think this is representative of the actual state of the affair. Safari/WebKit is not gathering any related statistic..

   Y

Le ven. 29 juin 2018 à 11:10, Justin Uberti <juberti=[email-masked]<mailto:[email-masked]>> a écrit :
I believe such data will be forthcoming from the Safari team. We are also working on this.

On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <ekr@rtfm..com<mailto:[email-masked]>> wrote:
It seems like this is something one could A/B test and measure connection rates. Has someone done so?

-Ekr
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Justin Uberti <[email-masked]>
Date: Wed, 18 Jul 2018 08:09:19 -0700

As these changes are essentially clarifications of existing 5245 text, I
don't see a need for existing docs (e.g. JSEP) to be updated.

On Wed, Jul 18, 2018 at 7:49 AM Christer Holmberg <
[email-masked]> wrote:

> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Justin
> Uberti
> *Sent:* 18 July 2018 10:18
> *To:* Ted Hardie <[email-masked]>
> *Cc:* RTCWeb IETF <[email-masked]>
> *Subject:* Re: [rtcweb] IP handling: Using mDNS names for host candidates
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Jul 2018 15:39:20 +0000

Hi,

As I have said before, I think we shall do the updates. For example, we DO reference trickle, which is based on bis procedures, so if you want to implement trickle following the spec you need to implement ICEbis.

Similarly, while ice-sip-sdp does clarify 5245 text, the procedures are based on ICEbis.

(And, ICEbis should be published as RFC any day now, so referencing it will not delay the publication of the RTCWEB specs).

Regards,

Christer

From: Justin Uberti [mailto:[email-masked]]
Sent: 18 July 2018 11:09
To: Christer Holmberg <[email-masked]>
Cc: Ted Hardie <[email-masked]>; RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates

As these changes are essentially clarifications of existing 5245 text, I don't see a need for existing docs (e.g. JSEP) to be updated.

On Wed, Jul 18, 2018 at 7:49 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Does that mean that RTCWEB is actually going to reference ice-sip-sdp and ICEbis (instead of RFC 5245)?

Regards,

Christer

From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Justin Uberti
Sent: 18 July 2018 10:18
To: Ted Hardie <[email-masked]<mailto:[email-masked]>>
Cc: RTCWeb IETF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates

Ted

   Y

-Ekr