Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

Harald Alvestrand <harald@alvestrand.no> Wed, 13 November 2013 18:45 UTC

Return-Path: <harald@alvestrand.no>
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 8256111E8126 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 10:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.499
X-Spam-Level:
X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 MQkGq4DuR0Xk for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 10:44:57 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0745721F9C8E for <rtcweb@ietf.org>; Wed, 13 Nov 2013 10:44:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5861439E1B7; Wed, 13 Nov 2013 19:44:56 +0100 (CET)
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 16ORQkcuriWD; Wed, 13 Nov 2013 19:44:55 +0100 (CET)
Received: from [172.30.42.84] (unknown [62.109.39.85]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F39E939E176; Wed, 13 Nov 2013 19:44:54 +0100 (CET)
Message-ID: <5283C8A5.8030601@alvestrand.no>
Date: Wed, 13 Nov 2013 19:44:53 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>, "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <parthasarathi.ravindran@nsn.com>, ext Magnus Westerlund <magnus.westerlund@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <5282391D.3050002@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C63196@SGSIMBX006.nsn-intra.net> <5283291E.7090108@ericsson.com> <40AFDF4AF1909E4CB42B6D91CE6C419D19C71D01@SGSIMBX006.nsn-intra.net> <5283B92B.4080304@viagenie.ca>
In-Reply-To: <5283B92B.4080304@viagenie.ca>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] 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 18:45:03 -0000

On 11/13/2013 06:38 PM, Simon Perreault wrote:
> Le 2013-11-13 11:33, Ravindran, Parthasarathi (NSN - IN/Bangalore) a
> écrit :
>> In case of Browser - GW/Server use cases (Sec 3.4 of
>> draft-ietf-rtcweb-use-cases-and-requirements-12), the end-to-end TCP
>> connection is between browser & Gateway directly. Here, GW/server
>> acts as RTP endpoint/mixer in the middle of the network and acts as
>> "RTP relay" [Note 1] to the actual remote endpoint. TURN server (TCP
>> to UDP relay) is becoming "second middle box" in case GW/server
>> provider has to deploy TURN server as well. ICE-TCP solves the issue
>> as it creates the host candidates from GW/Server.
>
> 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?
The argument being given only applies to the client-to-gateway usecase
(or to naked destination clients that are not behind a NAT, which
hopefully will become common once IPv6 gets deployed, but aren't common
now).

>
> Simon


-- 
Surveillance is pervasive. Go Dark.