Re: [pntaw] Real-time media over TCP

Dan Wing <dwing@cisco.com> Tue, 03 September 2013 20:17 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D19F11E8138 for <pntaw@ietfa.amsl.com>; Tue, 3 Sep 2013 13:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.534
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtU2mKArkX8t for <pntaw@ietfa.amsl.com>; Tue, 3 Sep 2013 13:17:08 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D41E711E813A for <pntaw@ietf.org>; Tue, 3 Sep 2013 13:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: AhEFABFDJlKrRDoH/2dsb2JhbABbgwc1wXCBLhZ0giQBAQECAQFoEQULCxguSQENBhMbh2EFDblPj0MzB4MdgQADiTWKZoNagS+QN4NAHA
X-IronPort-AV: E=Sophos;i="4.89,1016,1367971200"; d="scan'208";a="88386117"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 03 Sep 2013 20:17:07 +0000
Received: from sjc-vpn5-462.cisco.com (sjc-vpn5-462.cisco.com [10.21.89.206]) by mtv-core-2.cisco.com (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 <dwing@cisco.com>
In-Reply-To: <52262657.3080208@alvestrand.no>
Date: Tue, 3 Sep 2013 13:17:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2C315DB-1882-4BD1-A8C0-E8AF7DEA48F4@cisco.com>
References: <CAGTXFp92jSzQz05uHngzscz88n=fT_JPbEvQRxgeUUqPVRQUyQ@mail.gmail.com> <52244DD7.1020900@alvestrand.no> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <522590EE.7070508@alvestrand.no> <C632A223-A55A-47F4-B083-9BDC447DA959@cisco.com> <52262657.3080208@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1508)
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] Real-time media over TCP
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2013 20:17:13 -0000

On Sep 3, 2013, at 11:11 AM, Harald Alvestrand <harald@alvestrand.no>; 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 http://conferences.sigcomm.org/imc/2005/papers/imc05efiles/guha/guha.pdf.  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.

-d