Re: [rtcweb] Transports: RFC 6062 support

Good point on isolating TCP to the short legs.

On Wed, Mar 5, 2014 at 3:55 PM, Matthew Kaufman (SKYPE) <
matthew.kaufman@skype.net> 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" <juberti@google.com> 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 <gilzino@gmail.com> 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).
>>
>>
>>
>>
>>  On Wed, Mar 5, 2014 at 10:02 AM, Justin Uberti <juberti@google.com>wrote:
>>
>>>  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.
>>>
>>>
>>>  _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
>   _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>