Re: [pntaw] Real-time media over TCP

Dan Wing <> Tue, 03 September 2013 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D19F11E8138 for <>; Tue, 3 Sep 2013 13:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.534
X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EtU2mKArkX8t for <>; Tue, 3 Sep 2013 13:17:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D41E711E813A for <>; Tue, 3 Sep 2013 13:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2376; q=dns/txt; s=iport; t=1378239427; x=1379449027; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NckazOw8angBOdtgMA4BYSW0/+pbWpwprzoMSVJW8X8=; b=Hew1X26wZpVcauhIGtYX5QcRWpoaLpct3iFjDaF7ON3irRih84m8YJUd 98YPMl+zWIhic+gu7nK362m2fdBJxqNPcfZ6E73EZfaQ2dE6lowJ7dilo B3WtrL2ZFyALy0mTMaYRCCGJmKo7t0qYZcHuyWEl/zi0L5Mzu+BzYMvoT Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,1016,1367971200"; d="scan'208";a="88386117"
Received: from ([]) by with ESMTP; 03 Sep 2013 20:17:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r83KH66r001639; Tue, 3 Sep 2013 20:17:06 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <>
In-Reply-To: <>
Date: Tue, 3 Sep 2013 13:17:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <> <> <>
To: Harald Alvestrand <>
X-Mailer: Apple Mail (2.1508)
Cc: Bernard Aboba <>, "" <>
Subject: Re: [pntaw] Real-time media over TCP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Sep 2013 20:17:13 -0000

On Sep 3, 2013, at 11:11 AM, Harald Alvestrand <> wrote:

> On 09/03/2013 07:25 PM, Dan Wing wrote:
>>> Multiple TCP connections seems like a suboptimal design, given the existence of other solutions like Minion or SCTP.
>> Sure.  But those technologies weren't on the table when Victor did interactive audio/video over TCP, I'm sure.  Much like they weren't on the table when HTTP started doing multiple TCP connections back in the early days of Netscape.
> Victor didn't provide a date, so I was thinking "recently" - SCTP is 10 years old at this point.

SCTP has been around a long time as a protocol but for a variety of reasons has seen no deployment on the Internet to date, including no availability in the mainstream OSs which is everyone's interest.  SCTP-over-UDP was only recently defined and its user-mode release was only 12 or 18 months ago or so.

> Minion is newer than that, of course.
>>> If both sides have TURN over TCP (or TURN over HTTP) enabled, and their respective TURN servers can talk UDP to each other, communication will occur, I think. I don't think we need to add TCP candidates for the TURN case in order to bypass firewalls.
>>> We might want to do so for the benefit of the pure peer-to-peer case, but I'm not sure it's a case that's important enough to make 6062 (TURN TCP allocations) or 6544 (ICE TCP allocations, no TURN server) into MUSTs for RTCWEB.
>> I agree.  Additionally, before anyone ventures too far down that path it would be useful to understand how well the expected RTCWeb endpoints could do peer-to-peer TCP connections.  Reliable peer-to-peer TCP needs TCP simultaneous open needs to work well on both hosts, per the research by Saikat Guha and Paul Francis  In that research, they found Windows XP SP1 doesn't do simultaneous open well, but Windows XP with SP2 and SP3 and Linux worked okay.  I have not seen similar research for Android, OS X, or Windows 7 or Windows 8.
> Indeed; that article seemed to indicate that the brand of NAT you bought was a decisive factor - it would be interesting to see if the state of the art has become more or less symmetric-TCP hostile in the intervening 8 years.