Re: [rtcweb] Transports: RFC 6062 support
Bernard Aboba <bernard.aboba@gmail.com> Wed, 05 March 2014 16:30 UTC
Return-Path: <bernard.aboba@gmail.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 29B381A0424 for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 08:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 KUpXK5nLB7kG for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 08:30:55 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id BF8911A01BF for <rtcweb@ietf.org>; Wed, 5 Mar 2014 08:30:54 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id a1so1545985wgh.22 for <rtcweb@ietf.org>; Wed, 05 Mar 2014 08:30:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ggtw52GOVnCV2/lnPisBZjYOPmcMMY35GqS5F2NKAds=; b=MeshrUP3zVxfJoZKVgZ3yOapgxAHqvDFdULXld8SZZ2bb5ORTuhwuc8Sdj0wsQATRn vvFzxmttZ8mVzFcT1ttfvO69MZ5dRUnDO9E9vfM6AwrenbNZbmX1jhPyMfoG4xSt/pGH TfGqO9IcvgTWDb6aS4PP4wAVOq+m+JsswCQhLH+pMH3R594esYtaEUso8r+HbcLVEJNN Y1hKgbVKEFmAqcoq18CfncnO9RejDn6b5Un8iwOV8j5zWEL04hgkF7if/xySTNHsIyUF zkb+HzeF+Wx2si+Z9UZB8HkvkRevXdh+Mt0C0HtP4lJ0upcHLBaPgzo9wS28dLcE6JM9 cSKg==
X-Received: by 10.194.85.168 with SMTP id i8mr2192585wjz.81.1394037039901; Wed, 05 Mar 2014 08:30:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.217.161.66 with HTTP; Wed, 5 Mar 2014 08:30:19 -0800 (PST)
In-Reply-To: <CAOJ7v-0xiG-omwmpXm9koakab+EDFo7W=gW+WY4fGS6QVKfALQ@mail.gmail.com>
References: <CAOJ7v-0-U8ycUYcOwRGxgZVDQmdPMXC4Qt7F+uAn29AGOepX7w@mail.gmail.com> <CABAmMA00xA1TbXsQRYYnuukYyurZzdG8nKr95aT4gxHxQtNiMw@mail.gmail.com> <CAOJ7v-0xiG-omwmpXm9koakab+EDFo7W=gW+WY4fGS6QVKfALQ@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 05 Mar 2014 16:30:19 +0000
Message-ID: <CAOW+2dsFz6LEeBV2D=tx61XGHspiH7bKDiLvjyTKkz94MoqB3A@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="089e010d7efc91310904f3de8afa"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y_qMuL4B8sRNLEKquxXkIJoNhIg
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:30:57 -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. On Wed, Mar 5, 2014 at 3:31 PM, 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 > >
- [rtcweb] Transports: RFC 6062 support Justin Uberti
- Re: [rtcweb] Transports: RFC 6062 support Gil Zino
- Re: [rtcweb] Transports: RFC 6062 support Justin Uberti
- Re: [rtcweb] Transports: RFC 6062 support Matthew Kaufman (SKYPE)
- Re: [rtcweb] Transports: RFC 6062 support Justin Uberti
- Re: [rtcweb] Transports: RFC 6062 support Bernard Aboba
- Re: [rtcweb] Transports: RFC 6062 support Martin Thomson
- Re: [rtcweb] Transports: RFC 6062 support Simon Perreault
- Re: [rtcweb] Transports: RFC 6062 support Matthew Kaufman (SKYPE)
- Re: [rtcweb] Transports: RFC 6062 support Simon Perreault
- Re: [rtcweb] Transports: RFC 6062 support Justin Uberti
- Re: [rtcweb] Transports: RFC 6062 support Simon Perreault
- Re: [rtcweb] Transports: RFC 6062 support Justin Uberti
- Re: [rtcweb] Transports: RFC 6062 support Simon Perreault
- Re: [rtcweb] Transports: RFC 6062 support Martin Thomson
- Re: [rtcweb] Transports: RFC 6062 support Magnus Westerlund
- Re: [rtcweb] Transports: RFC 6062 support Bernard Aboba
- Re: [rtcweb] Transports: RFC 6062 support Harald Alvestrand
- Re: [rtcweb] Transports: RFC 6062 support Bjoern Hoehrmann
- Re: [rtcweb] Transports: RFC 6062 support Harald Alvestrand
- Re: [rtcweb] Transports: RFC 6062 support Bjoern Hoehrmann
- Re: [rtcweb] Transports: RFC 6062 support Harald Alvestrand
- Re: [rtcweb] Transports: RFC 6062 support Bjoern Hoehrmann
- Re: [rtcweb] Transports: RFC 6062 support Justin Uberti
- Re: [rtcweb] Transports: RFC 6062 support Magnus Westerlund
- Re: [rtcweb] Transports: RFC 6062 support DRAGE, Keith (Keith)
- Re: [rtcweb] Transports: RFC 6062 support Hutton, Andrew