Subject: [rtcweb] two questions about draft-ietf-rtcweb-return

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 08 Jul 2015 20:34:15 -0600

First, this is a great document - very clear and easy to read. Kudos to 
the authors!

I have two questions.

1. Section 4.2 states:

    A virtual interface can produce
    "host", "server-reflexive", and "relay" candidates, but may be
    restricted to only some type of candidate (e.g.  UDP-only).

How does that restriction work? Is it effected by the nature of the 
firewall (e.g., Section 6.1 mentions the possibility of a firewall that 
blocks all UDP traffic), by the configuration of the TURN proxy, by 
local policy in the WebRTC user agent, or by some other method?

2. Section 5.1 states:

    When a proxy is configured, by Auto-Discovery or a proprietary means,
    the browser MUST NOT report a "relay" candidate representing the
    proxy.  [...]

    For a virtual interface representing a TURN proxy, this means that
    the browser MUST report the public-facing IP address and port
    acquired through TURN as a "host" candidate....

Have the authors considered how that rule might interact with the known 
(although poorly documented) improvement in call setup time that results 
from communicating only relayed candidates in the initial offer?

Thanks!

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Benjamin Schwartz <[email-masked]>
Date: Thu, 9 Jul 2015 10:21:34 -0400

]On Wed, Jul 8, 2015 at 10:34 PM, Peter Saint-Andre - &yet <[email-masked]
> wrote:

Thanks!

> blocks all UDP traffic), by the configuration of the TURN proxy, by local
> policy in the WebRTC user agent, or by some other method?
>

I would say "by the configuration of the TURN proxy".  This statement was
intended to be just a helpful reinforcement of the obvious: if a virtual
interface represents paths through a TURN proxy, and the proxy is UDP-only
(like most TURN implementations), then no TCP candidates will be generated
for that interface.

As always, language improvements welcome.

> from communicating only relayed candidates in the initial offer?

My impression is that this improvement is only true when there are no
publicly routable "host" candidates.  If the proxy has a publicly routable
external interface (as seems likely to be the common case), then I expect
there should be no performance issue.

This does suggest a discussion of how best to compute priority of these
candidates, but I view that kind of performance tuning as a secondary
concern.

>
> Thanks!
>
> Peter
>
> --
> Peter Saint-Andre
> https://andyet.com/
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Jul 2015 10:53:19 -0400

Le 2015-07-09 10:21, Benjamin Schwartz a écrit :
>     firewall (e.g., Section 6.1 mentions the possibility of a firewall
>     that blocks all UDP traffic), by the configuration of the TURN
>     proxy, by local policy in the WebRTC user agent, or by some other
>     method?
> 
> 
> I would say "by the configuration of the TURN proxy".  This statement
> was intended to be just a helpful reinforcement of the obvious: if a
> virtual interface represents paths through a TURN proxy, and the proxy
> is UDP-only (like most TURN implementations), then no TCP candidates
> will be generated for that interface.
> 

Ok then here's one: "TURN server" is the preferred term, instead of
"TURN proxy". :)

>     Have the authors considered how that rule might interact with the
>     known (although poorly documented) improvement in call setup time
>     that results from communicating only relayed candidates in the
>     initial offer?
> 
> 
> publicly routable "host" candidates.  If the proxy has a publicly
> routable external interface (as seems likely to be the common case),
> then I expect there should be no performance issue.

I don't think that this is even true. I bet that most of the time when
you have a publicly routable "host" candidate you will still be behind a
NAT or a stateful firewall, and inbound connections will still be
denied. The IP address range means very little.

The fact is that we have ICE prioritization completely wrong. See RFC
5245 section 4.1.2.2 and note that the guidelines listed there relate to
steady-state performance. That is worthless. Nomination is what is
concerned with steady-state performance. Prioritization should only be
concerned with how long it takes until I have a working candidate pair.
This means that candidates with the highest chance of working and the
lowest expected setup time should be tried first. That's probably TURN
candidates. As soon as you have something that works you can start using
it. Then you can take your time and evaluate the other candidate pairs
more-or-less in depth, perhaps do some actual measurements, then
nominate the candidate pair that has the best steady-state performance.

Simon