Re: [rtcweb] [tram] Payload Types assignments

["Karl Stahl" <[e-mail]>]

Hi Harald,

 

The answer to your question 26 of February:
> Karl, what on Earth does TRAM milestone 3 have to do with whatever it is
you're proposing?
TRAM milestone 3 is: Sep 2014 - Send new proposed standard TURN server
discovery mechanism for enterprises and ISPs to IESG
> There's no (zero, nada, none) mention of QoS within that charter.



--- I didn’t mention “QoS” (*I want the QoS methods out!*), in my
protest/request 

http://www.ietf.org/mail-archive/web/tram/current/msg00304.html “It must be
a clear objective of the TRAM WG that ISPs/NSPs are allowed and encouraged
to route quality demanding WebRTC media into their IP pipes that are capable
of transporting real-time traffic without quality issues, using TURN
servers. 

 

The subject from the TRAM mailing initiation spells out:

*Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs*

The TRAM WG must assure that TURN servers offered by ISPs/NSPs can be used
for the above purpose.

(The objective of the TRAM WG milestone 3 is *not only* to resolve
restrictive enterprise NAT/firewall traversal problem using TURN servers.)”

 

However, it is a way of "Interfacing to QoS", A level 3-5
IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff, which I
now have started under 

 <http://www.ietf.org/mail-archive/web/tram/current/msg00331.html>
http://www.ietf.org/mail-archive/web/tram/current/msg00331.html

The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to
interface to lower level's QoS-stuff

 

You were September 20 actually the first to answer my request for a DHCP
provided turn server address (which I withdraw in favor of the anycast
method, which is highly preferable):

http://www.ietf.org/mail-archive/web/rtcweb/current/msg08920.html 

 

There I said:

>There are several reasons for a network service provider to supply a TURN

server as part of his offered access:

- to keep media paths short, specifically not sending media outside its own

network to some distant application provided TURN server

- to support mobility, i.e. you may want to move from a LAN with a

configured TURN server to accessing via WiFi or 3G/4G OTT channels

- to offer a media path with better quality (than best effort data traffic).

Getting a “WebRTC-ready” access and we can look forward to telepresence for

everyone.

 

I don’t really see anyone objecting to those objectives, and I don’t think
you do either.

 

The Anycast method were suggested October 22 (without further discussions)

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html 

and thereafter brought into TRAM WG list February 8 

http://www.ietf.org/mail-archive/web/tram/current/msg00132.html 

 

It took me some time to find the relevant emails from the discussions in
September and October which ended up with my entry to the [tram]-list
February 8, which is copied in full below, where I still say it was 95%
ready (There are a few relevant points from Simon that I will address
later). Thereafter, the QoS diversion and confusion started around February
12th in what looks to me as effort to make it a “Mission Impossible”.

 

I don’t know how the TRAM WG was created, but I thought Milestrone 3 was a
result of Cullen’s. See next email in response to Cullen’s questions and
requests.

 

/Karl

 

Footnote:

[1] I think both you (Harald) and Cullen, are good, have the best intentions
and integrity, but no one of us have infinite memory capacity (especially
when the VP8/H.264 flooding came in between). I only learned “by accident”
that the TRAM WG was in progress at the November WebRTC conference” and
should handle the Auto Discovery of TURN-servers.

 

 

Från: Karl Stahl [mailto:[e-mail]] 
Skickat: den 8 februari 2014 14:11
Till: '[e-mail]'; '[e-mail]'; 'Simon Perreault'
Ämne: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

 

Karl from Ingate and Intertex just added himself to this list for exactly
the purpose of the subject of Milestone 3 above 

 

I welcome this initiative that I saw yesterday after being reminded by China
Mobile Research Institute who had seen the previous October discussion on
the WebRTC-list, parts of which are inserted below. Large carriers have also
expressed the importance of this milestone.

--------------------

We are working on this draft, will publish it next week.

-Tiru.

 

Great, please consider the input and suggestions below:

 

> -----Original Message-----

> From: tram [ <mailto:tram-bounces> mailto:tram-bounces at ietf.org] On
Behalf Of Simon Perreault

> Sent: Friday, February 07, 2014 7:58 PM

> To: tram at ietf.org

> Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for

> enterprise and ISPs

> 

…

> Enterprises or ISPs wishing to provide

> their own TURN server, in an attempt to reduce so-called "triangle
routing",

> need a new auto-discovery mechanism.

--- There are more reasons heard for auto-discovery of a network provided
TURN server:

 

- NSPs (Network Service Providers) want to provide a path where the
bandwidth of WebRTC is better coped with.

- NSPs or Enterprises want to offer an Internet access quality pipe for
prioritized RTC (Real Time Communication) traffic. 

- Enterprises having restrictive firewalls, want to provide a UDP-path for
WebRTC and possibly also for better quality where RTC do not compete with
data traffic. 

- Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G
OTT channels, all should be able to automatically offer their own optimal
TURN server

 

- Note that to achieve some of the above points, TURN must be favored over
STUN to enforce that the TURN-path actually is used. (The Anycast method
suggested below, “automatically” does this.) 

 

-- In my view, a TURN server is the network providers’ responsibility to
provide (just like the IP address, the default gateway, the DNS etc.) –
rather than the application provider’s. Our current Internet accesses may
not cope with or be optimized for WebRTC usage – The NSP (or Enterprise LAN
administrator) should then be able to fix the access (here by offering a
TURN server). 

 

> IMHO this is also a top-priority milestone. We need to quickly have a

> mechanism that people can implement in WebRTC browsers now, while

> there is still frenetic development happening. 

--- Agree

I don't foresee actual server-

> side deployment happening quickly though. But as soon as clients are
ready,

> any ISP or enterprise can deploy and immediately benefit.

- There is a definitive interest among forward SPs already, especially
carriers owning the network.

(They have learned that their networks (especially mobile) seem to become
data crowded no matter how much bandwidth they invest in.)

 

> I imagine that the solution will be fairly simple, spec- and
implementation-

> wise. 

--- Agree that such solution should and could be found, but it is not
obvious. Below you find 3 proposals (initiated by me or colleagues, where I
see flaws in the two first and now only suggest the third (the Anycast
mechanism). From below:

 

- 1st: … withdraw my suggestion to use DHCP to find a network provider
offered TURN server in favor of the DNS-Based Service Discovery method
(inserted last below). The major problem with the DHCP usage was that you
then also have to do something similar for: RA - Router Advertisement - in
IPv6, addition to the IPCP protocol for PPPoE and something for the mobile
OTT channel – wherever DHCP is NOT the method to give you an IP address.
(There were also concerns whether OSs actually supports forwards such
extended DHCP information for the browser to use.)

 

- 2nd Reverse DNS-Based Service Discovery method:

Justin Uberti pointed out:  How does this get bootstrapped? That is, how is
the STUN server found?

[Karl] Oops, that got lost when leaving the DHCP track, and is a problem
when using DNS discovery.

(There were also hesitations of having to provision this special reverse DNS
for every access.)

 

- 3rd The Anycast method below – I see no problem

It also has the advantage of encouraging (but not requiring) the STUN/TURN
to be built in the default gateway or NAT/firewall/access router itself,
with a second interface to a public IP address on the WAN side. (Current
volume deployed, low cost NSP triple play modems usually have a quality
assured level 2 or level 3 WAN pipe for just voice (and another for IPTV) –
The anycast discovered TURN-server can be the access gateway to such quality
pipe for WebRTC media, in a single NSP provided CPE, scaling from
residential and up.)

 

So I think we can finish this very quickly once we have a candidate

> draft. We just need authors. So I would target not long after Toronto.

> 

> Simon

 

WEB BROWSER BEHAVIOUR:

 

Network provided TURN servers will not appear over night, applications may
for long provide a TURN server address, and there are exceptions where the
TURN server address is preferred to be “manually” configured. It is
previously suggested, and to some extent discussed, that the WebRTC browser
should select the TURN server to use in the following priority order, where
ICE would assure that you get some connectivity if several candidates are
found and needs to be tested:

 

1) TURN server address configured in the browser by the user (special cases,
normally not used, but handy for testing)

2) TURN server address configured by the network administrator via an “admin
policy template” or a WPAD method as mentioned below

3) TURN server address auto-discovered by the mechanism discussed here

4) TURN server address being supplied by the web application

 

With a good step 3), step 2) becomes obsolete since the network
administrator e.g. simply can set a route in the enterprise firewall to use
the Anycast mechanism instead. 

 

Even if the need for auto-discovery of the TURN server comes from WebRTC
usage, a general mechanism that also can be used by SIP clients (and other
protocols using TURN via ICE) is preferable. The anycast method has no
application dependence, but e.g. WPAD has (a SIP Client typically does not
have the luxury of a JS engine…)

 

/Karl

 

Från: tram [mailto:[e-mail]] För Harald Alvestrand
Skickat: den 26 februari 2014 04:49
Till: Colin Perkins; Karl Stahl
Kopia: Magnus Westerlund; [e-mail]; [e-mail]
Ämne: Re: [tram] [rtcweb] Payload Types assignments

 

Karl,

what on Earth does TRAM milestone 3 have to do with whatever it is you're
proposing?

TRAM milestone 3 is: 

Sep 2014 - Send new proposed standard TURN server discovery mechanism for
enterprises and ISPs to IESG

There's no (zero, nada, none) mention of QoS within that charter.