Re: [pntaw] New version of TURN over websockets draft

Marc Petit-Huguenin <marc@petit-huguenin.org> Fri, 20 September 2013 18:59 UTC

Return-Path: <marc@petit-huguenin.org>
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 A07D521F99ED for <pntaw@ietfa.amsl.com>; Fri, 20 Sep 2013 11:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 wkbL15lotyic for <pntaw@ietfa.amsl.com>; Fri, 20 Sep 2013 11:59:20 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8FE21F9991 for <pntaw@ietf.org>; Fri, 20 Sep 2013 11:59:20 -0700 (PDT)
Received: from [IPv6:2601:9:4bc0:1c:fceb:fc0:562e:eeb0] (unknown [IPv6:2601:9:4bc0:1c:fceb:fc0:562e:eeb0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 35DCF20EB1; Fri, 20 Sep 2013 20:59:18 +0200 (CEST)
Message-ID: <523C9B03.2030002@petit-huguenin.org>
Date: Fri, 20 Sep 2013 11:59:15 -0700
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8
MIME-Version: 1.0
To: Oleg Moskalenko <mom040267@gmail.com>
References: <5232C18C.1030102@gmail.com> <523C8BDC.6050705@petit-huguenin.org> <CALDtMrKwygUqNWKcB81F+M7Y8wBmwZtTACeYChpJVvWKbXLTEw@mail.gmail.com>
In-Reply-To: <CALDtMrKwygUqNWKcB81F+M7Y8wBmwZtTACeYChpJVvWKbXLTEw@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "pntaw@ietf.org" <pntaw@ietf.org>, Lorenzo Miniero <lorenzo@meetecho.com>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "Chenxin \(Xin\)" <hangzhou.chenxin@huawei.com>, Victor Pascual Avila <victor.pascual.avila@gmail.com>
Subject: Re: [pntaw] New version of TURN over websockets draft
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: Fri, 20 Sep 2013 18:59:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/20/2013 11:19 AM, Oleg Moskalenko wrote:
> Thank you Marc for your comments and suggestions.
> 
> RFC 6062 is a relatively seldom used specs, this new draft is directed
> mostly toward extension of RFC 5766 for WebRTC users. They will be using
> TURN in RFC 5766 manner, with a single Websocket connection per Allocation.
> RFC 6062 is a rather exotic use case and it is not used in WebRTC. So I'd
> not complicate this draft with a new subprotocol.

Yes, after sending my email, I realized that it was not necessary.

> 
> In practice, even in the case of a few RFC 6062 users, in most cases a
> TURN allocation is created with a single or a few connections, so there
> will be no significant flood of TCP connections if we will keep a new
> Websocket connection for each new peer.
> 
> I'd suggest to keep it as simple as possible and as close to RFC 5766 and
> RFC 6062 as possible for most practical purposes. This draft originated
> mostly out of WebRTC requirements and as I said before the WebRTC
> allocations will be using a single Websocket connection.
> 
> If there will be a significant demand for RFC 6062-style communications
> with Websockets, then we can consider an extension.
> 
> So, I'd suggest to keep a new Websocket connection for every new peer, for
> RFC 6062 - style communications.

OK so I suggest to say in the draft that a new Websocket connection will be
created for each TCP peer, because that have an impact on implementation design.

> 
> Regards, Oleg
> 
> 
> 
> 
> 
> On Fri, Sep 20, 2013 at 10:54 AM, Marc Petit-Huguenin
> <marc@petit-huguenin.org <mailto:marc@petit-huguenin.org>> wrote:
> 
> I read the draft and I have some questions:
> 
> After TCP allocation over TURN Websocket, what is the Websocket equivalent
> of initiating a new TCP connection (RFC 6062) after sending a
> ConnectionBind or receiving a ConnectionAttempt?  Is a new Websocket
> connection opened and if it is the case, shouldn't it require a different
> subprotocol?  Perhaps a better alternative would be to use multiplexing 
> (draft-ietf-hybi-websocket-multiplexing) to not have to create multiple 
> Websocket connections to one TURN server?
> 
> See these links for a alternate way of multiplexing data exchanged with 
> multiple TCP peers over one connection:
> 
> http://www.ietf.org/proceedings/74/slides/behave-17.pdf 
> http://tools.ietf.org/html/draft-petithuguenin-turn-tcp-variant-01
> 
> On 09/13/2013 12:41 AM, Sergio Garcia Murillo wrote:
>> Hi all
> 
>> We have been working on a new version of the TURN over Websocket draft 
>> originally proposed by Xin, which is now available at:
> 
>> http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-01.txt
> 
>> We believe that it is very well aligned with the spirit of 
>> draft-hutton-rtcweb-nat-firewall-considerations and should be considered
>> to be endorsed by WebRTC.
> 
>> Also, in order to address the concerns about the impact on TURN servers
>> we will be working in providing a working prototype over the following
>> weeks by adding a preliminary support of TURN over websockets into the 
>> rfc5766-turn-server.
> 
>> Any kind of feedback would be very welcome.
> 
> 
> 

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJSPJsBAAoJECnERZXWan7Ea18P/0ZPrHem1l6IEO2HZ2xAo1sY
d4/S7RXLJBoqnPILtkKHZZHCUDZ6rjz4tqWY0+jXx1oNpBSoL5Pt9D3r1ZRBlBnQ
FdO8XVm54ICnBEYFsm1izeXv2bvmnEdWgKgEzcsIWibhJkhad7kppccNrCtoOayE
+/mlVVEwaw62Jn5uHu1lIeZRUkrTQ1CeMKnNO6YVKrU0iVAKqp4w5zA4l+CIbTg4
CjfZzwxRlE9plrRI1R5y+Fqzg+u0L1+A8XtLLA30ic+je1BsHsw58cCqFopQXT05
0icMundpmSsxoONIyHMECHirwrG56PG62tjhj75XRXbR4kV5z3hL7mHDUUSgFnDg
f5CCkRhp7KshdME75jAGqFev21hpblYLK/6sAXL59F50c908Nz+u96o00ODtR7g9
3++xqY/GRjQmVO638v5bUTsm0Iw6qajKGbNTiu/dEFGUloNpGUgMInEJMifQW6vs
+wMp3jrJAZFXiCy3K/6kMdl8lirSn3aUu0K023A0KYHr4c78z06rurj3K/JHaBNP
/vFsQZ7LGgraiOs+lj/t4zB2+coRue9J6KhujRrsBbH5G6YLCtBZIC6VuED7PqEo
9mtJmWuB812MZ7HOwVNaJulnV/+srPSvpJOc/ayQ2TB/klsiKzRZDcp1oyXjwtO2
MnOsj48NoHab/MqZjZob
=Jz+U
-----END PGP SIGNATURE-----