Subject: Re: [rtcweb] WG adoption call: draft-mdns-ice-candidates

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Aug 2018 07:52:11 +0000

Hi,

> Regarding DNS resolution and associated complexity, I think we can sidestep most of that here in rtcweb given
> that we will be mandating 1:1 mapping between foo.local names and IP addresses.

If that’s the case, it should be explicitly indicated.

Others (Cullen etc) also raised issues in MMUSIC, but I'll let them speak for themselves whether they think it affects the RTCWEB usage.

Regards,

Christer

On Sat, Jul 28, 2018 at 3:10 AM Christer Holmberg <[email-masked]> wrote:
Hi,

In Montreal this was discussed in MMUSIC, and the outcome was that this will require more work, in MMUSIC or ICE.

I have also given some input why I think ICE support of FQDNs in general (not specific to mDNS) requires more work.

For example, as an FQDN can be associated with multiple IP addresses, does that mean that the endpoint providing the FQDN will create separate "sub candidates" for each IP address that the FQND can resolve to (as a candidate per definition is associated with ONE transport (IP address + port + protocol))?. If so, each of those local candidates may end up in different foundations, some may be pruned (or removed because of other reasons). In addition, is the endpoint supposed to send checks on each of these candidates? For how long will it maintain them? Etc etc etc.

The concept of "multi-address candidates" is a new thing, currently not covered by the ICE specifications.

Now, IF we assume a "FQDN candidate" will only resolve to one IP address, the issue is easier to solve, but based on comments from others we cannot make that assumption.

So, while I do not object to working on support of mDNS in ICE, my suggestion would be that the ADs, and the RTCWEB/MMUSIC/ICE chairs, discuss on how to move forward, before we adopt this draft.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: 28 July 2018 03:43
To: RTCWeb IETF <[email-masked]>
Subject: [rtcweb] WG adoption call: draft-mdns-ice-candidates

The consensus in the RFCWEB@IETF102 room was that the WG should adopt  https://datatracker.ietf.org/doc/draft-mdns-ice-candidates/ as a WG item. But, we need to confirm this on list.  If you would like for this draft to become a WG document and you are willing to review it as it moves through the process, then please let the list know by 2359UTC 20180810.  If you are opposed to this being a WG document, please say so (and say why).

Note that the draft has been marked as a “Call for Adoption by WG Issued” in the datatracker.

Thanks - spt
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Lennart Grahl <[email-masked]>
Date: Wed, 1 Aug 2018 13:27:52 +0200

Same here.

Cheers
Lennart

On 28.07.2018 05:59, Nils Ohlmeier wrote:
> I support adoption as a WG document and I’m willing to review.
> 
>   Nils Ohlmeier
> 
>> On Jul 27, 2018, at 17:42, Sean Turner <[email-masked]> wrote:
>>

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 1 Aug 2018 10:37:36 -0400

RTCWeb may mandate one IP address per FQDN, but a WebRTC implementation can’t guarantee that the author of its remote description is always a WebRTC implementation.

The other complexity of DNS resolution is that you don’t want to require that all DNS lookups be complete before connectivity checking is started.  

RTCWeb mandates trickle so you can treat DNS resolution completing as though the candidate was trickled in at that point, but this will need to be specified somewhere.  Again, I think MMusic is the right place.

I think an MMusic or ICE draft on FQDN handling in ICE, and an RTCWeb draft recommending mDNS, should proceed in parallel. I don’t see them taking appreciably different amounts of time.

> On Jul 31, 2018, at 8:03 PM, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Regarding DNS resolution and associated complexity, I think we can sidestep most of that here in rtcweb given that we will be mandating 1:1 mapping between foo.local names and IP addresses.
> 
> IOW, the mDNS name is simply an alias for the IP, and therefore the questions noted below are answered easily for this particular situation. 
> 
> We can continue to discuss the general case of this problem in mmusic.
> 
> On Sat, Jul 28, 2018 at 3:10 AM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> From: rtcweb [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Sean Turner
> Sent: 28 July 2018 03:43
> To: RTCWeb IETF <[email-masked] <mailto:[email-masked]>>
> The consensus in the RFCWEB@IETF102 room was that the WG should adopt  https://datatracker.ietf.org/doc/draft-mdns-ice-candidates/ <https://datatracker.ietf.org/doc/draft-mdns-ice-candidates/> as a WG item. But, we need to confirm this on list.  If you would like for this draft to become a WG document and you are willing to review it as it moves through the process, then please let the list know by 2359UTC 20180810.  If you are opposed to this being a WG document, please say so (and say why).
> 
> [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: Justin Uberti <[email-masked]>
Date: Wed, 1 Aug 2018 10:53:25 -0700

On Wed, Aug 1, 2018 at 7:37 AM Jonathan Lennox <[email-masked]> wrote:

> RTCWeb may mandate one IP address per FQDN, but a WebRTC implementation
> can’t guarantee that the author of its remote description is always a
> WebRTC implementation.
>
> The other complexity of DNS resolution is that you don’t want to require
> that all DNS lookups be complete before connectivity checking is started.
>
> RTCWeb mandates trickle so you can treat DNS resolution completing as
> though the candidate was trickled in at that point, but this will need to
> be specified somewhere.  Again, I think MMusic is the right place.
>
> I think an MMusic or ICE draft on FQDN handling in ICE, and an RTCWeb
> draft recommending mDNS, should proceed in parallel. I don’t see them
> taking appreciably different amounts of time.
>

Agreed on this distribution of work.

>
> On Jul 31, 2018, at 8:03 PM, Justin Uberti <
> juberti=[email-masked]> wrote:
>
> Regarding DNS resolution and associated complexity, I think we can
> sidestep most of that here in rtcweb given that we will be mandating 1:1
> mapping between foo.local names and IP addresses.
>
> IOW, the mDNS name is simply an alias for the IP, and therefore the
> questions noted below are answered easily for this particular situation.
>
>> In Montreal this was discussed in MMUSIC, and the outcome was that this
>> will require more work, in MMUSIC or ICE.
>>
>> I have also given some input why I think ICE support of FQDNs in general
>> (not specific to mDNS) requires more work.
>>
>> For example, as an FQDN can be associated with multiple IP addresses,
>> does that mean that the endpoint providing the FQDN will create separate
>> "sub candidates" for each IP address that the FQND can resolve to (as a
>> candidate per definition is associated with ONE transport (IP address +
>> port + protocol))?. If so, each of those local candidates may end up in
>> different foundations, some may be pruned (or removed because of other
>> reasons). In addition, is the endpoint supposed to send checks on each of
>> these candidates? For how long will it maintain them? Etc etc etc.
>>
>> Now, IF we assume a "FQDN candidate" will only resolve to one IP address,
>> the issue is easier to solve, but based on comments from others we cannot
>> make that assumption.
>>
>> So, while I do not object to working on support of mDNS in ICE, my
>> suggestion would be that the ADs, and the RTCWEB/MMUSIC/ICE chairs, discuss
>> on how to move forward, before we adopt this draft.
>>
>> Regards,
>>
>> Christer
>>
>>
>> The consensus in the RFCWEB@IETF102 room was that the WG should adopt
>> https://datatracker.ietf.org/doc/draft-mdns-ice-candidates/ as a WG
>> item. But, we need to confirm this on list.  If you would like for this
>> draft to become a WG document and you are willing to review it as it moves
>> through the process, then please let the list know by 2359UTC 20180810.  If
>> you are opposed to this being a WG document, please say so (and say why).
>>

---

From: Sean Turner <[email-masked]>
Date: Thu, 2 Aug 2018 15:26:20 -0400

tl;dr: the MMUSIC chairs are happy figuring out the work-split later

After consultation with the MMUSIC chairs, we think a workable way forward is to let this WG call for adoption run.  If MMUSIC (or any other WG for that matter) decides later to takes up some of the work, then we can ask the draft-mdns-ice-candidates authors to create a new RTCWEB draft that contains the RTCWEB-specific information.  draft-mdns-ice-candidates could then also be used as a successor document for any draft-ietf-mmusic (or other WG) draft.  Note that this also allows ip-handling to proceed with an informative pointer to draft-mdns-ice-candidates (or more likely draft-rtcweb-ice-candidates).

spt

> On Aug 1, 2018, at 13:53, Justin Uberti <juberti=[email-masked]> wrote:
> 
> 
> 
>> On Jul 31, 2018, at 8:03 PM, Justin Uberti <juberti=40google.com@dmarc..ietf.org> wrote:
>>