Re: [rtcweb] Transports: RFC 6062 support

Justin Uberti <juberti@google.com> Wed, 05 March 2014 16:28 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B751A06E5 for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 08:28:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH-yMEXyCsVq for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 08:28:19 -0800 (PST)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id EAFF01A01BF for <rtcweb@ietf.org>; Wed, 5 Mar 2014 08:28:18 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id oy12so1270641veb.26 for <rtcweb@ietf.org>; Wed, 05 Mar 2014 08:28:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rvuQEFM7j9tHVvoQ73iFYVi33+o8TDM03bARMTjhYIk=; b=YmVTwMlMKVLIa7U3CebyvfzyPdojmXjHou2lUQefFn3PMTJvcnJm5z5HUVqdJYaYSh 9vqt6v+wb8s6H4wXek7/ehmF5ZIW5omWjb/QDiBuoWw5lHariqRK3rx+xbMxaIoj7RJw vhVnFJRJkZftZYrNkOPgKUTV++aSZ/80wzdzUFa1OR5yhNVPvMJ9vQ0hOfGQ6cMj15rN mlbVvZxhfLOjHMr3eZTQo3W13RdA8DwqwHKl8zLUkmiT82nv12mlgtMljIgy1KzXDZoA 8oZFDYJikZHZ8OrcqjpB+/HztVck2o7vr7w74n4KbGiQdF019HkiQWyV6WREeeawU33u dZ/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rvuQEFM7j9tHVvoQ73iFYVi33+o8TDM03bARMTjhYIk=; b=IkQwgEBL0+lNsZIO/Jq5aAA3vJOG3o5903g71k8eMSf5omOM5umcKY1pKSFSSIwa5D 5ceaPCxDPgFMV4mAC/D2QBBYHf1oCqaRVr1RqshJev1UbC/vkxrNa+DRBWRlW/ecK8FK ps03BVCWmxADTsaNg9vbtBUjm0v3/jxqYS4JlMNqikssytovgSg8d3xD4rg1+znl1ik2 SQ92iAsQLKoDARN7jFrdUx2lbEslENTPVYumytDJmBRKkcXh1/f4QeAHVF/Yi+xaEWvd WJ257HAnygJEoiBx/66VR1XXmG2rDN88H1YDCXeIFFZ8lb1NqaeJNUxYaqjV+gm/Oesz z/2w==
X-Gm-Message-State: ALoCoQk8suaZVp65W2IW+iFFYD4axivSy6qRdcgnHUhTsdmflsyKv8l60mINlahUSlKbEQjNHLt8R2wELccmVVfSHqZVch+8+Xp7Epl8v492o4wVC7pTsZbvkyM8aTi9CFiyUP6vvHlEhz8pFA5aMRsj0ACI0rvFcV1hnU9haxYCCcoyGxyw75Idbd8xB3pZppFVi3MEbs14
X-Received: by 10.52.189.33 with SMTP id gf1mr4323590vdc.26.1394036895188; Wed, 05 Mar 2014 08:28:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Wed, 5 Mar 2014 08:27:55 -0800 (PST)
In-Reply-To: <4A409D06-511D-424D-8285-E38B3E08292D@skype.net>
References: <CAOJ7v-0-U8ycUYcOwRGxgZVDQmdPMXC4Qt7F+uAn29AGOepX7w@mail.gmail.com> <CABAmMA00xA1TbXsQRYYnuukYyurZzdG8nKr95aT4gxHxQtNiMw@mail.gmail.com> <CAOJ7v-0xiG-omwmpXm9koakab+EDFo7W=gW+WY4fGS6QVKfALQ@mail.gmail.com> <4A409D06-511D-424D-8285-E38B3E08292D@skype.net>
From: Justin Uberti <juberti@google.com>
Date: Wed, 5 Mar 2014 16:27:55 +0000
Message-ID: <CAOJ7v-2Dcxp83FieD6i7-CQbJodENm=u3gE6iVqo8tBnPz1Vhg@mail.gmail.com>
To: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
Content-Type: multipart/alternative; boundary=001a1136b262f1281604f3de8165
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Yg2sl43HWnJIVlXp1hnGgYfGrRY
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Transports: RFC 6062 support
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 16:28:21 -0000

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;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
>
>