Re: [rtcweb] Transports: RFC 6062 support

"Matthew Kaufman (SKYPE)" <> Wed, 05 March 2014 15:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ED6081A0750 for <>; Wed, 5 Mar 2014 07:56:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0mMEBLGbfgO3 for <>; Wed, 5 Mar 2014 07:56:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9F9FE1A0236 for <>; Wed, 5 Mar 2014 07:56:04 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.883.10; Wed, 5 Mar 2014 15:55:59 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.888.9; Wed, 5 Mar 2014 15:55:57 +0000
Received: from (2a01:111:f400:7c10::114) by (2a01:111:e400:879::28) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 5 Mar 2014 15:55:57 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Wed, 5 Mar 2014 15:55:57 +0000
Received: from ([]) by ([]) with mapi id 14.03.0174.002; Wed, 5 Mar 2014 15:55:23 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] Transports: RFC 6062 support
Thread-Index: AQHPOIP9MQysxUHuaES93/Eve9xs+5rSnXuAgAABcwCAAAaraQ==
Date: Wed, 05 Mar 2014 15:55:22 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_4A409D06511D424D8285E38B3E08292Dskypenet_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(438001)(199002)(189002)(24454002)(377454003)(93516002)(4396001)(83072002)(74366001)(56816005)(90146001)(33656001)(85852003)(31966008)(81542001)(74502001)(47446002)(92566001)(77096001)(36756003)(79102001)(20776003)(63696002)(15202345003)(65816001)(30436002)(80022001)(512954002)(94316002)(94946001)(92726001)(47736001)(93136001)(50986001)(47976001)(86362001)(19580405001)(83322001)(49866001)(76786001)(19580395003)(6806004)(81816001)(15975445006)(95416001)(81686001)(82746002)(95666003)(87266001)(76482001)(51856001)(87936001)(53806001)(83716003)(59766001)(77982001)(74706001)(80976001)(81342001)(69226001)(76796001)(44976005)(16236675002)(85306002)(46102001)(54316002)(2656002)(54356001)(74876001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB437;; CLIP:; FPR:BCB2C137.AA3E6FC3.23EB7373.84E1D2FA.2037F; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 01415BB535
Received-SPF: Pass (: domain of designates as permitted sender) receiver=; client-ip=;;
Cc: "" <>
Subject: Re: [rtcweb] Transports: RFC 6062 support
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Mar 2014 15:56:12 -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" <<>> 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 <<>> 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 <<>> wrote:
>From the transports draft, Section 3.4:

   TURN TCP candidates [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 mailing list<>