Re: [pntaw] Real-time media over TCP

Harald Alvestrand <harald@alvestrand.no> Tue, 03 September 2013 18:11 UTC

Return-Path: <harald@alvestrand.no>
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 B2EB021F9CA1 for <pntaw@ietfa.amsl.com>; Tue, 3 Sep 2013 11:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.536
X-Spam-Level:
X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Q3xLGw17SlQJ for <pntaw@ietfa.amsl.com>; Tue, 3 Sep 2013 11:11:40 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CE29421F9BB4 for <pntaw@ietf.org>; Tue, 3 Sep 2013 11:11:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F85F39E469; Tue, 3 Sep 2013 20:11:37 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz06qKfitSYG; Tue, 3 Sep 2013 20:11:36 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 60ADA39E03B; Tue, 3 Sep 2013 20:11:36 +0200 (CEST)
Message-ID: <52262657.3080208@alvestrand.no>
Date: Tue, 03 Sep 2013 20:11:35 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dan Wing <dwing@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>
In-Reply-To: <C632A223-A55A-47F4-B083-9BDC447DA959@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 18:11:44 -0000

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