Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?

[Roman Shpount <[e-mail]>]

The FQDN in c= line and candidate address where in specs for a really long
time (RFC 4566 and RFC 5245 both define them). This being said, FQDN in c=
line was very infrequently used and FQDN in ICE candidate was never used.
FQDN in ICE candidate was badly under defined and due to limited use there
is no established practice on how it should work. Using FQDN for mDNS ICE
candidates, as far as I know, is the first wide spread use of FQDN in ICE
candidates. Almost every ICE implementation outside of Chrome was never
tested against FQDN in c= lines and ICE candidates and likely would have
issues.

As it stands, ice-sip-sdp does not contradict using FQDN in ICE candidates,
but is specifically leaves a big hole in the document regarding how exactly
offers with FQDN are generated and how FQDN candidates are supposed to be
processed. The only thing current draft defines is absolute minimum of what
end point needs to do when receiving a session description with FQDN
candidates and safely ignoring them.Things like FQDN resolution procedures,
procedures for adding resolution results to the candidate list, and what is
supposed to go into the c= line for FQDN default candidate were
deliberately left out for the future document. If anybody wants to use FQDN
in ICE candidates, these things need to be defined and verified to cause
minimal disruption when deployed against existing end points. Since ICE and
ICE session description related issues are normally discussed in mmusic, it
probably should happen there to reach the proper audience.

I understand that running experiments before proposing a solution is
probably a good thing and this is what Chrome was doing up until this
point. At the same time, rolling this feature into production before at
least documenting it, will definitely cause interop problems. What we have
now is a fairly major feature with a fairly outdated specification where
all the interop issues weren't considered.

As far as connectivity impact of Chrome experiment goes, we do see it
causing issues with at least two scenarios:

1. Listen only connections to SBC/Media servers on public IP: We have a set
of services which run SBC or Media Servers on public IPs with ICE TCP
enabled. These services did not use STUN or TURN servers, since all the
communications are between the browser end point and the server on public
IP. In cases when microphone is not present on the client computer or
client denies microphone access, client is still offered to connect in
listen only mode. In this scenario, we ended up with FQDN in the c= line
and only FQDN based candidates. As a quick work around we added STUN
server, but this, in addition to slowing down the connection time, still
prevented connections from hosts where UDP was blocked. We had to update
software used to run our hosted services to support FQDN in c= line and ICE
candidates (which was actually done as a regex replacement). Our software
which is installed at client premises is still not updated and will likely
take our clients another 6 months to a year to update. As far as we could
see, before update, 2-3% of all listen only connections where affected.
This is not a huge number but caused customer complaints from clients who
were able to connect before the experiment started.

2. Peer-to-peer connections within enterprise: We are working with a
peer-to-peer web casting solution for webinars. We see the connectivity
rate reduction within large enterprises, where IP based connection between
two private IP is allowed but client browsers are not withing the same
broadcast domain. In this case mDNS connectivity check fails when direct IP
connectivity check would succeed. In these cases webcast client switches to
streaming from the server, so this does no result in total failure but does
decrease the P2P network efficiency. Having an ability to ask for
Peer-to-Peer connectivity permission would really help in this case.

Best Regards,
_____________
Roman Shpount


On Thu, Jul 4, 2019 at 1:41 AM Justin Uberti <[e-mail]> wrote:

> As I understand it, mdns in the c= line will only occur in edge cases,
> i.e., when there are no other candidates. As such I don’t see this as a
> showstopper.
>
> We have measured the connectivity impact of this change in significant
> detail and feel increasingly confident there are no egregious latent issues.
>
> On Wed, Jul 3, 2019 at 9:50 PM Nils Ohlmeier <[e-mail]>
> wrote:
>
>> Probably not the ideal forum to point this out, but I hope the Chrome
>> team is aware that rolling out this feature, assuming it includes using
>> mDNS in the connection line, will break interop with Firefox.
>> So I have to concur that rolling this out appears to be premature to me.
>>
>> Best
>>   Nils Ohlmeier
>>
>> On 3Jul, 2019, at 17:58, Justin Uberti <
>> juberti=[e-mail]> wrote:
>>
>> Hmm, that's unfortunate. I think this is a mistake, given that we are
>> about to throw the switch to enable mDNS for 100% of Chrome endpoints;
>> Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this
>> extension spec is written.
>>
>> ice-sip-sdp isn't published yet, so it seems an update to that document
>> could still be a possibility. If that's not an option, putting forth #1 as
>> a specific extension that allows FQDN candidates to be generated in certain
>> situations seems like the right path.
>>
>>
>>
>> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount <[e-mail]> wrote:
>>
>>> Part of the problem is that mmusic have decided to punt on the FQDN
>>> support. In the current mmusic-ice-sip-sdp the final language that was
>>> included:
>>>
>>> <connection-address>:  is taken from RFC 4566 [RFC4566].  It is the IP
>>> address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and
>>> fully qualified domain names (FQDNs).  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
>>> generating local candidates MUST NOT use FQDN addresses.  An agent
>>> processing remote candidates MUST ignore candidate lines that include
>>> candidates with FQDN *or IP address versions that are not supported or
>>> recognized.  *The procedures for generation and handling of FQDN
>>> candidates, as well as, how agents indicate support for such procedures,
>>> need to be specified in an extension specification.*
>>>
>>> So, at this point we have two options:
>>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and
>>> define how FQDN candidates generated by mdns are handled
>>> 2. write a new draft in mmusic which defines FQDN handling
>>>
>>> In any case some sort of mmusic discussion is needed to reconcile this.
>>>
>>> Best Regards,
>>> _____________
>>> Roman Shpount
>>>
>>>
>>> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <[e-mail]> wrote:
>>>
>>>> The problem this draft is trying to solve is fairly RTCWEB-specific. If
>>>> there are individual issues to resolve, we can send them out to mmusic for
>>>> discussion, but AFAIK no changes to existing ICE specs are needed.
>>>>
>>>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <[e-mail]> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?
>>>>> This entire draft seems to be ICE/SDP specific and not limited to rtcweb.
>>>>> Also, there are significant interop implications for this draft
>>>>> between browser and non-browser end points which probably warrant larger
>>>>> discussion outside of rtcweb group. I would think mmusic would be a much
>>>>> better place for this draft. I know there is an incentive to complete this
>>>>> draft quickly but this has a potential to break a lot of things (it already
>>>>> did break interop with almost every existing ICE implementation).
>>>>>
>>>>> Regards,
>>>>> _____________
>>>>> Roman Shpount
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>
>>>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>