Subject: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Sep 2018 00:09:38 -0700

While I understand the overall goal of this document,  it strikes me as
suffering from two major problems:

a. Introduction of backwards compatibility problems and potential
additional delays due to utilization of name resolution mechanisms in ICE,
with a corresponding benefit (successful connectivity checks between host
candidates on the same network) which is only a marginal improvement over
mode 3 (no host candidates).

b. Over-reliance on permission mechanisms which have already been stretched
to the breaking point, leaving the potential for collateral damage in data
channel-only scenarios. Due to limitations in the current permissions
mechanisms, it is not currently practically impossible to distinguish
legitimate data channel applications that would obtain permissions if there
were usable means to do so from illegitimate applications attempting to
compromise user privacy.

Data-channel only scenarios that would be impacted include those where:

1. Permissions cannot be obtained (e.g. where there is no microphone or
camera attached to the device so that getUserMedia will always fail).

2. Low latency communications is a requirement so that TURN server
traversal is unacceptable (e.g. in financial applications where there may
be regulatory requirements relating to allowable delays).

3. TURN traversal would impose an unacceptable financial cost, such as in
branch office scenarios where a TURN servers is not provided in each branch
office, and branch office connectivity may be constrained (still an issue
for branch offices located on other continents).

Essentially, the problem is that these scenarios may have valid reasons why
they cannot utilize or do not wish to utilize getUserMedia as a
permission-granting mechanism.

---

From: youenn fablet <[email-masked]>
Date: Fri, 14 Sep 2018 10:44:49 -0700

Thanks for the review Bernard,

Agreed that this proposal does not solve all cases.
But it does so in a number of cases like home/small office scenarios.

In general, I do not think there is a guarantee to successfully connect
without sometimes relying on TURN servers.
This proposal and other solutions should allow reducing the need to use
TURN.

Describing precisely the problematic scenarios is useful as we can find
additional means specific to those scenarios.
For instance, can it be envisioned to deploy STUN servers inside the user
network for the financial applications/branch offices scenarios you are
mentioning?

Le ven. 14 sept. 2018 à 00:10, Bernard Aboba <[email-masked]> a
écrit :

> b. Over-reliance on permission mechanisms which have already been
> stretched to the breaking point, leaving the potential for collateral
> damage in data channel-only scenarios. Due to limitations in the current
> permissions mechanisms, it is not currently practically impossible to
> distinguish legitimate data channel applications that would obtain
> permissions if there were usable means to do so from illegitimate
> applications attempting to compromise user privacy.
>
> Essentially, the problem is that these scenarios may have valid reasons
> why they cannot utilize or do not wish to utilize getUserMedia as a
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: westhawk <[email-masked]>
Date: Fri, 14 Sep 2018 18:47:59 +0100

> On 14 Sep 2018, at 08:09, Bernard Aboba <[email-masked]> wrote:
> 

I’d argue  that sendonly video is also impacted - things like town-hall meetings etc
T.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Sep 2018 11:55:44 -0700

Good point. In that scenario (where getUserMedia isn’t called) the current permissions model wouldn’t even allow presentation of alternative output audio devices (e.g. speaker or headphones). 

> On Sep 14, 2018, at 10:47 AM, westhawk <[email-masked]> wrote:
>

---

From: youenn fablet <[email-masked]>
Date: Fri, 14 Sep 2018 12:49:01 -0700

Le ven. 14 sept. 2018 à 11:56, Bernard Aboba <[email-masked]> a
écrit :

> Good point. In that scenario (where getUserMedia isn’t called) the current
> permissions model wouldn’t even allow presentation of alternative output
> audio devices (e.g. speaker or headphones).
>

Is that an issue though? How is it different than viewing regular DASH/HLS
content?
I would hope that the browser makes a good job at selecting the right
output in such case.
If it does not do so, maybe that is a browser bug. Or maybe the page could
provide hints so that the browser does the right selection.

To return to the initial question, in the sendonly/town-hall meeting
scenario, what is the configuration that mandates exposing host candidates?
How common is it?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Sep 2018 13:00:58 -0700

On Sep 14, 2018, at 12:49 PM, youenn fablet <[email-masked]> wrote:
> To return to the initial question, in the sendonly/town-hall meeting scenario, what is the configuration that mandates exposing host candidates? How common is it?

[BA] Assuming that WebRTC is used instead of streaming media, the scenario often involves communication within an enterprise network, such as a group, divisional or campus-wide company meeting. getUserMedia is only called when an employee needs to ask a question (or sometimes questions are pre-selected).  Employees watch the meeting at their desks.

In these scenarios, media often flows directly on the multi-segment corpnet between host candidate pairs without a relay.

---

From: westhawk <[email-masked]>
Date: Fri, 14 Sep 2018 21:09:10 +0100

> On 14 Sep 2018, at 20:49, youenn fablet <[email-masked]> wrote:
> 
> Le ven. 14 sept. 2018 à 11:56, Bernard Aboba <[email-masked] <mailto:[email-masked]>> a écrit :
> Is that an issue though? How is it different than viewing regular DASH/HLS content?
> I would hope that the browser makes a good job at selecting the right output in such case.
> If it does not do so, maybe that is a browser bug. Or maybe the page could provide hints so that the browser does the right selection. 
>  

I don’t know - but here are the cases I’ve come across:

1) Burning man video relay - There is often decent bandwidth across the playa on a segmented class B but 
terrible connectivity to the outside world. If you want to relay audio and video from an art performance you
 _really_ want to keep the media  within the class B. MDNS won’t do the trick because of the segmentation.

I imagine there are corporate networks that look like this too.

2) (I need to test the MDNS properties of this one) - Drone wifi tethered to a smartphone, with the smartphone on 4g.
You want video from the drone (and control data channel) to use the wifi link for the webRTC connection.

Tim.

> 
> 
> > On Sep 14, 2018, at 10:47 AM, westhawk <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: youenn fablet <[email-masked]>
Date: Fri, 14 Sep 2018 14:20:53 -0700

Le ven. 14 sept. 2018 à 13:01, Bernard Aboba <[email-masked]> a
écrit :

> [BA] Assuming that WebRTC is used instead of streaming media, the scenario
> often involves communication within an enterprise network, such as a group,
> divisional or campus-wide company meeting. getUserMedia is only called when
> an employee needs to ask a question (or sometimes questions are
> pre-selected).  Employees watch the meeting at their desks.
>
> In these scenarios, media often flows directly on the multi-segment
> corpnet between host candidate pairs without a relay.

Is the sender a web browser?
Is the sender sending the media to each receiver or are there some
receivers acting as senders to other receivers?

---

From: T H Panton <[email-masked]>
Date: Fri, 14 Sep 2018 23:02:04 +0100

> On 14 Sep 2018, at 22:20, youenn fablet <[email-masked]> wrote:
> 
> 
> 
> Le ven. 14 sept. 2018 à 13:01, Bernard Aboba <[email-masked] <mailto:[email-masked]>> a écrit :
> On Sep 14, 2018, at 12:49 PM, youenn fablet <[email-masked] <mailto:[email-masked]>> wrote:

In the Drone case no. 
In the Town hall case probably not - there will be some sort of camera/MUX device if there are more than a few users.

> Is the sender sending the media to each receiver or are there some receivers acting as senders to other receivers?

In the problematic scenarios I'm looking at things are either senders or receivers, never both.

T.

---

From: youenn fablet <[email-masked]>
Date: Fri, 14 Sep 2018 17:42:02 -0700

Le ven. 14 sept. 2018 à 15:02, T H Panton <[email-masked]> a écrit :

>> [BA] Assuming that WebRTC is used instead of streaming media, the
>> scenario often involves communication within an enterprise network, such as
>> a group, divisional or campus-wide company meeting. getUserMedia is only
>> called when an employee needs to ask a question (or sometimes questions are
> In the Town hall case probably not - there will be some sort of camera/MUX
> device if there are more than a few users.
>

In that case, the camera/MUX device might act as a STUN/TURN server.

It will probably expose all of its host candidates. Ditto if sender is a
browser since getUserMedia is on.
I would think the connection to be feasible through peer reflexive
candidates without the receiver to expose its own host candidates to
JavaScript.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Sep 2018 18:00:00 -0700

> In that case, the camera/MUX device might act as a STUN/TURN server.

[BA] In the usage I have seen the sender is a PC or Mac brought in to run
the meeting; STUN/TURN servers are run by an infrastructure group and are
separate.

> candidates without the receiver to expose its own host candidates to

[BA] The STUN/TURN servers are often placed in the DMZ rather than on the
corpnet so using addresses other than host candidates will result in
hairpinning or unnecessary relaying.

>> receivers acting as senders to other receivers?
[BA] For a large meeting, there is typically a conference server (SFU)
which forwards video and mixes or forwards audio to the receivers, most of
whom never send.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Sep 2018 18:12:43 -0700

> On Sep 14, 2018, at 1:09 PM, westhawk <[email-masked]> wrote:
> 

I think the majority of large enterprise networks have weird and interesting forwarding and filtering of MDNS. Particularly over the the WiFI portion of the network. Be worth understanding the impact of that a bit.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Sep 2018 23:21:19 -0700

>From what I have seen, relaying of mDNS is rare in enterprise WiFi networks
because of the effect of multicast on overall throughput. Even if lower
rates (e.g. < 11 Mbps) are disallowed, the effect on available time slots
can be substantial, particularly with 802.11ac deployed and higher speeds
coming.

So we should assume that mDNS is link-local scope.

On Wed, Sep 19, 2018 at 18:15 Cullen Jennings <[email-masked]> wrote:

> I think the majority of large enterprise networks have weird and
> interesting forwarding and filtering of MDNS. Particularly over the the
> WiFI portion of the network. Be worth understanding the impact of that a
> bit.

---

From: Lennart Grahl <[email-masked]>
Date: Thu, 20 Sep 2018 10:07:28 +0200

> I think the majority of large enterprise networks have weird and interesting forwarding and filtering of MDNS. Particularly over the the WiFI portion of the network. Be worth understanding the impa…

Also for home/small office WiFi access points. I'm not sure they all
forward multicast packets and mDNS as expected.

Cheers
Lennart

---

From: Lennart Grahl <[email-masked]>
Date: Thu, 20 Sep 2018 10:19:24 +0200

On 14.09.18 19:44, youenn fablet wrote:
> [...]

The problem I see is that the document deteriorates the default
situation while it only levels it out for home/small office scenarios.
For the majority of implementations (which use mode 2 by default) the
host-to-host connections will less likely succeed than previously.

> network for the financial applications/branch offices scenarios you are

Perhaps its feasible for those use cases where the administrator is
already aware of the software but definitely not for small applications
such as sharedrop.io, Threema Web whose main use case is the direct
connection in same network environments and its significant benefits
regarding throughput.

Cheers
Lennart

---

From: youenn fablet <[email-masked]>
Date: Mon, 24 Sep 2018 22:13:45 -0700

> connection in same network environments and its significant benefits

I agree this is the most likely scenario where host candidates are actually
useful: two web browsers doing pure data channel on a managed/complex
network, and no coordination between the network admin being and the app.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 27 Sep 2018 16:10:12 -0700

I suggest that we hold off on assessing what this might mean for data
channel and related applications until we have data from browsers showing
the actual connectivity/traffic impact of mDNS.

We should have initial data on this topic from Chrome by EOY.

On Mon, Sep 24, 2018 at 10:14 PM youenn fablet <[email-masked]> wrote:

> I agree this is the most likely scenario where host candidates are
> actually useful: two web browsers doing pure data channel on a
> managed/complex network, and no coordination between the network admin
> being and the app.
>

---

From: youenn fablet <[email-masked]>
Date: Thu, 27 Sep 2018 22:01:40 -0700

FYI, we are tracking the feedback from this thread and last IETF meeting at
https://github.com/youennf/mdns-ice-candidates/issues.
   Y

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 28 Sep 2018 13:06:32 +0200

How will that data be gathered? Is anyone else gathering data? Safari?

Cheers
Lennart

---

From: Justin Uberti <[email-masked]>
Date: Fri, 28 Sep 2018 23:16:00 -0700

We will turn it on for N% of Chrome instances and observe the connection
success rate and setup time versus control.

---

From: Lennart Grahl <[email-masked]>
Date: Sat, 29 Sep 2018 12:25:30 +0200

I would suggest observing the connection success rate of

* host-to-host candidate pairs only,
* without getUserMedia (on the local side), and
* only if the remote peer also takes part in the mDNS test (should be
easy to recognise by looking at the remote's host candidates but doesn't
work if the remote peer uses getUserMedia... perhaps signal it via an
SDP attribute)

in comparison to as it is now. All of the above conditions should be
required for reporting results because this is the case that we want to
observe.

Cheers
Lennart