[rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)

<Markus.Isomaki@nokia.com> Wed, 13 November 2013 19:49 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50BE11E8136 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 11:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.526
X-Spam-Level:
X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 5RU2m+2nR16o for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 11:49:24 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A318311E817E for <rtcweb@ietf.org>; Wed, 13 Nov 2013 11:49:21 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.21]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rADJhVwA029040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 13 Nov 2013 21:43:32 +0200
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.74]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.03.0136.001; Wed, 13 Nov 2013 19:43:30 +0000
From: <Markus.Isomaki@nokia.com>
To: <harald@alvestrand.no>, <simon.perreault@viagenie.ca>, <parthasarathi.ravindran@nsn.com>, <magnus.westerlund@ericsson.com>, <rtcweb@ietf.org>
Thread-Topic: Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
Thread-Index: Ac7gpqENKxnuBO9vSm6c7jmb7Ls8IQ==
Date: Wed, 13 Nov 2013 19:43:30 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A115B66@008-AM1MPN1-043.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: bRtCJmKTkquuTioqIWF0acanolSKdHlEDp6iJ5RAVS6z6QSTlNFlSJz4ki/TmxLqE7EXPyCMrfpRcU9oSaRw+/VYMN+LYcY1FhzjV2/bAjsizBADfHQ+bpwBp3oLG9cp0QA8QqBMlW8Ya/IHQPZtWoFo6NgMcqrnGUgO35mnGQTCgi+aPVHswFH97c/zsYSG/8NSEOhJrAe6KaHBPBe/jSNovrNDfiP4+H1ltQSyYczLJ51cXhEvCPZK6e0Ti5TTA1BB4QlDK50gncSnLkL83unLpXRPU0Vtdi2G9xMcE4w=
x-originating-ip: [10.163.173.36]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: [rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Nov 2013 19:49:30 -0000

Hi,

See below. 

Harald Alvestrand wrote:
> 
> On 11/13/2013 07:57 PM, Simon Perreault wrote:
> > Le 2013-11-13 13:44, Harald Alvestrand a écrit :
> >>> All this relies on the possibility that a TCP peer-to-peer
> >>> connection could be successfully established where a UDP one
> >>> couldn't. IMHO this is very unlikely to happen in practice. So
> >>> unlikely in fact that any possible gain over just falling back on a
> >>> TURN relay wouldn't be worth the additional implementation cost.
> >>
> >> Simon, do you have any numbers on that - how many calls will be going
> >> to servers on the Internet versus how many calls will be going
> >> peer-to-peer?
> >
> > Not sure what you mean.
> >
> >> The argument being given only applies to the client-to-gateway
> >> usecase
> >
> > My point only applied to peer-to-peer connections, not peer-to-server.
> > If we're discussing peer-to-server, then I wonder why we're discussing
> > that at all.
> 
> Because we agreed to include server-based systems in section 3.4 of the use
> cases and requirements" document?
> 
> I think we have WG consensus that client-to-server based use cases, while
> less important than browser-to-browser use cases, are still important.
> 

Right. Some amount of WebRTC endpoints will definitely be gateways or central entities such as conference servers. I have no idea what portion of sessions would be like that, but I don't it will an insignificant amount since there is a lot of interest to gateway WebRTC to various "legacy" VoIP and video conferencing systems.  So I think those are important use cases. 

Typically gateways and conf server endpoints would be reachable by TCP. The question is thus how often a  "normal" (browser or mobile app) endpoint would be in a network where UDP is blocked but direct outgoing TCP connections are allowed. In that case ICE-TCP would be optimal way for that endpoint to connect with a gateway/server endpoint. TURN over TCP would solve the same case but is less optimal.

So unless people have data that shows that "UDP blocked but direct TCP allowed" is in itself a very rare setup (this is a question, I don't know that either), I think ICE-TCP is definitely worthwhile for a WebRTC endpoint to support. 

TURN (over TCP) will still be needed in many cases involving two "normal" endpoints, and there I agree ICE-TCP has little success. 

Regards,
	Markus