Subject: [rtcweb] Transports: RFC 6062 support

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 15:02:29 +0000

>From the transports draft, Section 3.4:

   TURN TCP candidates [RFC6062 <http://tools.ietf.org/html/rfc6062>]
SHOULD be supported; this allows
   applications to achieve peer-to-peer communication when both parties
   are behind UDP-blocking firewalls using a single TURN server.  (In
   this case, one can also achieve communication using two TURN servers
   that use TCP between the server and the client, and UDP between the
   TURN servers.)

I don't think we want to do this. The optimization of having a single
vs two TURN servers in the .09% case is not worth the implementation
or runtime cost of allocating TURN TCP candidates. It requires a TCP
connection to the TURN server, which we would otherwise not do except
in fallback cases.

---

From: Gil Zino <[email-masked]>
Date: Wed, 5 Mar 2014 10:26:19 -0500

Agree on the cost concern.  Not sure I fully understand the context though.
 Is ~.09% the estimated percentage of times that TCP will be the only way
to get through UDP-blocking firewalls, or am I mis-understanding the use
case?

If it does refer to the UDP-blocking, what data is it based on?  I do know
large enterprise firewalls skew significantly higher on UDP blocking, but I
suspect SMB and residential perhaps are more UDP-permissive by default (but
have never seen extensive data that is not biased by the sampling).

On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti <[email-masked]> wrote:

>    TURN TCP candidates [RFC6062 <http://tools.ietf.org/html/rfc6062>] SHOULD be supported; this allows
> I don't think we want to do this. The optimization of having a single vs two TURN servers in the .09% case is not worth the implementation or runtime cost of allocating TURN TCP candidates. It requires a TCP connection to the TURN server, which we would otherwise not do except in fallback cases.
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 15:31:30 +0000

I am assuming 3% as the case where TCP is needed to get through
UDP-blocking firewalls, based on empirical data from QUIC testing in Chrome
over a very large population.

Since TURN TCP candidates (not to be confused with TURN/TCP to connect to
the TURN server) are only useful in the case where BOTH sides are behind
such firewalls, 3% * 3% == .09% is the fraction of calls where TURN TCP
candidates are useful. As an optimization, I don't think this is worth
worrying about.

On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino <[email-masked]> wrote:

> Agree on the cost concern.  Not sure I fully understand the context
> though.  Is ~.09% the estimated percentage of times that TCP will be the
> only way to get through UDP-blocking firewalls, or am I mis-understanding
> the use case?
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 5 Mar 2014 15:55:22 +0000

+1 given that it still works for those 0.9%, it just hits two TURN servers... And with luck, that actually is better because if they each select TURN servers well you get TCP on the short legs and UDP on the long leg.

Matthew Kaufman

Sent from my iPad

On Mar 5, 2014, at 7:32 AM, "Justin Uberti" <[email-masked]<mailto:[email-masked]>> wrote:

I am assuming 3% as the case where TCP is needed to get through UDP-blocking firewalls, based on empirical data from QUIC testing in Chrome over a very large population.

Since TURN TCP candidates (not to be confused with TURN/TCP to connect to the TURN server) are only useful in the case where BOTH sides are behind such firewalls, 3% * 3% == .09% is the fraction of calls where TURN TCP candidates are useful. As an optimization, I don't think this is worth worrying about.

On Wed, Mar 5, 2014 at 3:26 PM, Gil Zino <[email-masked]<mailto:[email-masked]>> wrote:
Agree on the cost concern.  Not sure I fully understand the context though.  Is ~.09% the estimated percentage of times that TCP will be the only way to get through UDP-blocking firewalls, or am I mis-understanding the use case?

If it does refer to the UDP-blocking, what data is it based on?  I do know large enterprise firewalls skew significantly higher on UDP blocking, but I suspect SMB and residential perhaps are more UDP-permissive by default (but have never seen extensive data that is not biased by the sampling).

>From the transports draft, Section 3.4:

   TURN TCP candidates [RFC6062<http://tools.ietf.org/html/rfc6062>] SHOULD be supported; this allows

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 16:27:55 +0000

Good point on isolating TCP to the short legs.

On Wed, Mar 5, 2014 at 3:55 PM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

>  +1 given that it still works for those 0.9%, it just hits two TURN
> servers... And with luck, that actually is better because if they each
> select TURN servers well you get TCP on the short legs and UDP on the long
> leg.
>
> Matthew Kaufman
>
>  Sent from my iPad
>
> On Mar 5, 2014, at 7:32 AM, "Justin Uberti" <[email-masked]> wrote:
>
>  Since TURN TCP candidates (not to be confused with TURN/TCP to connect
> to the TURN server) are only useful in the case where BOTH sides are behind
>>  If it does refer to the UDP-blocking, what data is it based on?  I do
>> know large enterprise firewalls skew significantly higher on UDP blocking,
>> but I suspect SMB and residential perhaps are more UDP-permissive by
>> default (but have never seen extensive data that is not biased by the
>> sampling).
>>
>>
>>
>>
>>  On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti <[email-masked]>wrote:
>>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 Mar 2014 16:30:19 +0000

Justin said:

"Since TURN TCP candidates (not to be confused with TURN/TCP to connect to
the TURN server) are only useful in the case where BOTH sides are behind
such firewalls, 3% * 3% == .09% is the fraction of calls where TURN TCP
candidates are useful. As an optimization, I don't think this is worth
worrying about."

[BA] +1.

If TURN/TCP isn't sufficient to traverse the firewall then you've typically
got a problem that TURN TCP candidates won't solve either.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 17:04:15 +0000

> select TURN servers well you get TCP on the short legs and UDP on the long

Agree.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Mar 2014 19:26:22 +0000

Le 2014-03-05 15:55, Matthew Kaufman (SKYPE) a écrit :
> if they each select TURN servers well you get TCP on the short legs and
> UDP on the long leg.

How would they "select TURN servers well"?

We have a milestone for solving that problem in TRAM, and no draft
currently adopted for it.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 5 Mar 2014 20:39:00 +0000

TRAM is solving the "without the assistance of the JavaScript" case (finding corporate servers or ISP servers)... I'm sure that some of the larger RTCWEB application providers will be more than capable of figuring out which TURN servers will be best to assign to their customers.

Matthew Kaufman

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Simon
> Perreault
> Sent: Wednesday, March 5, 2014 7:26 PM
> To: [email-masked]
> Subject: Re: [rtcweb] Transports: RFC 6062 support
> 
> > if they each select TURN servers well you get TCP on the short legs
> > and UDP on the long leg.
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Mar 2014 09:11:23 +0000

> TRAM is solving the "without the assistance of the JavaScript" case (finding corporate servers or ISP servers)... I'm sure that some of the larger RTCWEB application providers will be more than cap…

Right. So the "TCP on the short legs, UDP on the long leg" argument
currently only holds for large application providers.

Simon

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Mar 2014 13:11:22 +0000

I would expect that corp or ISP servers would also be located very close to
the endpoint.

On Thu, Mar 6, 2014 at 9:11 AM, Simon Perreault <[email-masked]
> wrote:

> > TRAM is solving the "without the assistance of the JavaScript" case
> (finding corporate servers or ISP servers)... I'm sure that some of the
> larger RTCWEB application providers will be more than capable of figuring
> out which TURN servers will be best to assign to their customers.
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Mar 2014 13:14:12 +0000

Le 2014-03-06 13:11, Justin Uberti a écrit :
> I would expect that corp or ISP servers would also be located very close
> to the endpoint.

Right, but my point is that we still don't have a way for those corp- or
ISP-provided servers to be discovered by the endpoint. We had a draft
presented in TRAM yesterday, but it was not adopted. So I guess we're at
a point where we need ideas.

Simon

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Mar 2014 13:23:50 +0000

True. But in trying to wrap up this thread, can we agree that TURN TCP
candidates are a SHOULD NOT?

On Thu, Mar 6, 2014 at 1:14 PM, Simon Perreault <[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Mar 2014 13:34:24 +0000

Le 2014-03-06 13:23, Justin Uberti a écrit :
> can we agree that TURN TCP candidates are a SHOULD NOT?

Not a SHOULD, sure. SHOULD NOT, no.

Simon

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 14:17:22 +0000

> I would expect that corp or ISP servers would also be located very close to

Not in my experience.  At least not always.  At a previous job, I was
forced to use an HTTP proxy that was on the other side of the planet.
We were unable to get official clearance for a local breakout.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 16:33:46 +0100

> Not a SHOULD, sure. SHOULD NOT, no.

I would guess that the simplest is to remove discussion of TURN TCP
altogether from Transports. That would not recommend it nor make it
disallowed. If we want to be explicit, then simply motivate why we don't
believe it necessary.

Justin, what is the reason you wanted SHOULD NOT?

cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Mar 2014 07:41:21 -0700

Magnus said:

"I would guess that the simplest is to remove discussion of TURN TCP
altogether from Transports. That would not recommend it nor make it
disallowed. If we want to be explicit, then simply motivate why we don't
believe it necessary."

[BA] Removing a recommendation from the Transport document is OK with  me.
However, since we've had quite a bit of discussion on this topic, it would
be good to state why we don't believe it to be necessary (so as to avoid
rehashing this down the line).

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Mar 2014 21:00:46 +0100

On 03/11/2014 03:41 PM, Bernard Aboba wrote:
> [BA] Removing a recommendation from the Transport document is OK with  
> me.  However, since we've had quite a bit of discussion on this topic, 
> it would be good to state why we don't believe it to be necessary (so 
> as to avoid rehashing this down the line).

In RFC 2119 theory, MAY and not mentioning it at all have exactly the 
same weight.
MAY gives you a place to hang the discussion of why it's not anything 
stronger on.

>
>
> On Mon, Mar 10, 2014 at 8:33 AM, Magnus Westerlund 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>
>     SE-164 80 Stockholm, Sweden | mailto:
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 11 Mar 2014 21:26:36 +0100

>In RFC 2119 theory, MAY and not mentioning it at all have exactly the 

(That depends on whether the default is "allowed" or "prohibited" and
there are plenty of specifications where explicit MAY overrides a de-
fault of "prohibited".)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Mar 2014 21:54:42 +0100

> there are plenty of specifications where explicit MAY overrides a de-
Probably true. But I can't think of any at the moment - do you have
something specific in mind?

Anyway, in this case, I don't think we have any default.

My expectation of "normal" is that any implementation is free to add any
extension (past, present or future), as long as it's possible to
practice it; it is very rare that we do something explicit like the
RTCWEB SDES "MUST NOT".

-- 
Surveillance is pervasive. Go Dark.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 11 Mar 2014 22:23:08 +0100

>something specific in mind?

(A typical example is when RFC 2119 keywords are used to describe how a
protocol element is constructed, say, "<foo> elements MAY carry bar=''
attributes"; you wouldn't assume you can use <foo bar=''> without that.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Mar 2014 22:39:15 +0100

> attributes"; you wouldn't assume you can use <foo bar=''> without that.)
Any specific examples?

Without context, this seems a strange way to specify protocol elements;
more common is to use ABNF, and not 2119 keywords.

And ABNF even allows "free" extensibility by having other specs use the
/= operator....

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 11 Mar 2014 22:44:35 +0100

>> attributes"; you wouldn't assume you can use <foo bar=''> without that.)

I think this is really very common, https://tools.ietf.org/html/rfc4287
is an instance of my example above.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Mar 2014 17:58:47 -0700

The reason I suggested SHOULD NOT is because I think this technique is
unnecessary for WebRTC, and typically net harmful for the reasons that
Matthew mentions.

That said, I would be fine with saying MAY and including some explanatory
text; my main concerns was to avoid the ambiguity that would arise from
leaving this out altogether.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Mar 2014 08:52:22 +0100

On 2014-03-12 01:58, Justin Uberti wrote:
> That said, I would be fine with saying MAY and including some
> explanatory text; my main concerns was to avoid the ambiguity that would
> arise from leaving this out altogether.

Okay, as we have considerations, I would leave the RFC 2119 terms out. I
think a statement along the lines of the below might be most suitable.

Using TURN to provide TCP relay candidates [REF] was considered but not
seen as providing any significant benefit. First, use of TURN TCP would
only be relevant in cases which both peers requires to use TCP to
establish a PeerConnection. Secondly, that use case is anyway supported
by both side establishing UDP relay candidates using TURN over TCP
[REF]. Thirdly, using TCP only between the endpoint and its relay may
result in less issues with TCP in regards to real-time constraints, e.g.
due to head of line blocking.

Please provide feedback or word smith.

Cheers

Magnus
(As individual)

> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 12 Mar 2014 13:49:32 +0000

And your example is poor. "If XXX sends foo, then XXX MAY include a bar element" and if necessary a corresponding receiving requirement would be more correct.

Given that the ABNF probably already specifies how the the element is included, in other standards bodies I would write "can" here as in possibility, rather than option. Many such requirements are dynamic, not static, as an option should really be.

How do you test what you have written.

Keith

> From: rtcweb [mailto:[email-masked]] On Behalf Of 
> Bjoern Hoehrmann
> Sent: 11 March 2014 21:23
> To: Harald Alvestrand
> Cc: [email-masked]
> >>> In RFC 2119 theory, MAY and not mentioning it at all have exactly 
> >>> the same weight.
> (A typical example is when RFC 2119 keywords are used to 
> describe how a protocol element is constructed, say, "<foo> 
> elements MAY carry bar=''
> Björn Höhrmann · mailto:[email-masked] · 
> http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: 
> +49(0)160/4415681 · http://www.bjoernsworld.de

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 12 Mar 2014 16:10:56 +0000

Personally I think leaving in the "MAY" statement is a good idea unless there is a really reason why we don’t want an implementation to do this.  Including such a candidate does not appear to do anybody any harm so I think we should say it "MAY" be supported.

So I suggest modifying the first line the text Magnus suggested as follows:

Using TURN to provide TCP relay candidates [REF] MAY be supported however such candidates are not

Andy

> From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: 12 March 2014 07:52
> To: Justin Uberti
> Cc: [email-masked]