Re: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-discovery

[Simon Perreault <[e-mail]>]

Le 2016-11-27 à 15:00, Karl Stahl a écrit :
> I just looked into the GUI of a Cisco 14890/Linksys EA2700 WiFi Router
> having a single subnet for wireless and its 4 LAN ports. In a data crowded
> environment it is in need of a paralleled TURN server for a path to the high
> quality voip pipe in my triple play network access, especially with WebRTC
> voice+video wanting 2.5 mbps through the access for one session.
> 
> Finding "Single Port Forwarding" in the router GUI, it should be able to
> forward all STUN and TURN packets to a TURN server at the LAN,

I'm not following, sorry. Why would you want to use port forwarding and
have to deal with NAT issues, while there are much simpler mechanisms
available to you?

> but I could
> not find the routing table for adding a static anycast route, nor could I
> find a way to create an extra subnet on the LAN side (or at all).

http://www.linksys.com/us/support-article?articleNum=135048

Step 5 shows how to configure static routing table entries.

This is a super common feature on home routers. As another example, I'm
currently using an Asus RT-AC66U and it also has that feature:

http://www.asus.com/us/support/FAQ/1011706/

Note however that the preferred deployment scenario here would be to
have the TURN server be embedded on the home router so as to have one
leg on the LAN and another on the WAN and thus avoid NAT. No need for
manual routing setup in this case, and the current anycast discovery
method would work perfectly.

> The
> Binding anycast discovery method should work, but not the discussed
> separating between TWO TURN addresses.

See above. In addition, your proposed alternative would require NAT,
which is a non-starter.

> And thinking further, will we not just delay this highly needed RFC further
> by more demonstrations?...

(This discussion is not delaying anything. The DTLS one is.)

I will not respond to the paragraphs below because they ask questions
that are premature. Again with my chair hat on, problems with the
current mechanism need to be demonstrated before a solution can be
proposed. This has not yet happened.

Simon

> The more I look into this, and even if I would agree to all your
> comments/answers below, we cannot accept a discovery draft that is highly
> unclear, on what it is we are able to discover (TWO TURN servers or combined
> into ONE, listening to TWO IP addresses, not described here or in RFC5766
> (TURN protocol not being changed is no excuse)) and with a method
> description that even qualified members of this WG have discussed in terms
> of using DTLS for the anycast-addressed Allocate or Binding request packets
> (anycast packets *are over UPD*) and similarly confused by the lack of
> distinction between discovery and usage in the draft.
> 
> I understand and share the opinion that it is urgent to now finally get this
> draft into place, but accepting the anycast method as it is in this version,
> may add another decade to finally resolve the NAT/Firewall traversal problem
> that has plagued real-time communication since SIP was introduced in early
> 2000, when we now are about to complete the ICE/STUN/TURN suit into
> something deployable (as we know, instead of ICE, SBCs are still what is
> used for NAT/Firewall traversal - we make them :-) - but SBCs are not usable
> with WebRTC. 
> 
> The magic of exchanging the anycast addressed Allocate request to a Binding
> request for getting the IP address of *the TURN server* is a resolution, and
> the text for that update is already suggested. This method was proposed
> already in October 2013 after detailed discussion on the RTCWEB list after
> which the TRAM WG was formed
> https://www.ietf.org/mail-archive/web/tram/current/msg00132.html
> You Simon, already then, pointed out the two relevant issues/problems, 
> https://www.ietf.org/mail-archive/web/tram/current/msg00138.html 
> which I also in the suggested "Deployment Considerations for TURN Servers
> Provided by the Local or Access Network" to be added, now have spelled out
> the full solutions to (including the "leakage-problem" that is related to
> your second issue raised at that time).
> 
> So, I think we safely and quickly can fix up this draft for becoming the
> long awaited RFC that gets us an anycast method that at least works for
> detecting "a TURN server" (OK, not "ordinary TURN server" and absolutely not
> un-described "anycast TURN server"). And without having to bother about how
> the then anycast addressed Binding arrives at *the TURN server*, we can
> remove the "not all TURN servers may support anycast" under section 3 and
> have no worries over that ">Anycast *is* difficult to implement in many
> real-world scenarios,".
> 
> /Karl
> 
> PS: I don't agree to the "you'd be shooting yourself in the foot" comment,
> which you made on a quote from draft-ietf-rtcweb-return-00, which this
> specification should service with a working and deployable discovery method
> (which I believe will be done by the changes suggested). Then there will be
> no need to ">NAT to a different UDP port, so that you are able to
> differentiate unicast and anycast traffic". I said something about "robust"
> in my suggested deployment considerations to add to this draft - Robustness
> must also be a goal for successful deployment and for this draft.
> 
> And, since the configuration described in draft-ietf-rtcweb-return-00, is
> for USAGE of the TURN server paralleling the default gateway, those authors
> could/should not foresee that we come up with a DISCOVERY method that will
> complicate deployment configuration by requiring an extra subnet on the LAN
> side (that may not be supported by the default gateway router). Using DHCP
> for discovery, one would not have thought of this as a
> shoot-yourself-in-the-foot deployment.
> 
> But DHCP is unfortunately not commonly available on many of the access
> networks we use today (LTE.., IPv6) (and the DHCP discovery is also
> unnecessarily complicated by going via domain name + DNS rather than
> defining a new IANA DHCP option (but I not going to request such change :-)
> since we cannot use DHCP discovery on all networks a WebRTC browser is
> commonly used from anyway). We simply need the anycast discovery method for
> WebRTC browsers' general usage.
> 
> The anycast discovery method must be clear, well defined and understood by
> readers of the draft, and with the aim to work in all deployment scenarios
> (for USAGE of such TURN server) and to be as robust and tolerant as
> possible.
> 
> Let's do it! That is also faster and simpler than just making current method
> clearly defined and understood.
> (We are just making a small change to the method: Allocate -> Binding in the
> DISCOVERY package to get all these advantages.)

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | [phone] ext. 1241 | [e-mail]