Re: [P2PSIP] Choice of STUN peer or TURN peer

"Francois Audet" <audet@nortel.com> Mon, 04 February 2008 17:54 UTC

Return-Path: <p2psip-bounces@ietf.org>
X-Original-To: ietfarch-p2psip-archive@core3.amsl.com
Delivered-To: ietfarch-p2psip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BEAF3A70B9; Mon, 4 Feb 2008 09:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.374
X-Spam-Level:
X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU482ROeKi6q; Mon, 4 Feb 2008 09:54:51 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C293A7065; Mon, 4 Feb 2008 09:54:47 -0800 (PST)
X-Original-To: p2psip@core3.amsl.com
Delivered-To: p2psip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904BE3A7065 for <p2psip@core3.amsl.com>; Mon, 4 Feb 2008 09:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7+g-UNjdM9B for <p2psip@core3.amsl.com>; Mon, 4 Feb 2008 09:54:45 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3CDFA3A707B for <p2psip@ietf.org>; Mon, 4 Feb 2008 09:54:41 -0800 (PST)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m14HuAv10045; Mon, 4 Feb 2008 17:56:10 GMT
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 4 Feb 2008 11:56:06 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF14A0DE18@zrc2hxm0.corp.nortel.com>
In-Reply-To: <2e0701c86576$16be5da0$c4f0200a@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [P2PSIP] Choice of STUN peer or TURN peer
Thread-Index: AchkjSnVj/XzQBCHRDyw9Ba1icG9uwAn2nGgABIuK/AAeCawIA==
References: <174701c85f78$24a386b0$44a36b80@cisco.com><001501c86156$04a31ee0$2d09a40a@china.huawei.com><20d2bdfb0801280801s5058a661td76c82985b54918@mail.gmail.com><0B983815-ED15-419D-9F59-47EFC094995E@cisco.com> <1ECE0EB50388174790F9694F77522CCF14996504@zrc2hxm0.corp.nortel.com> <2e0701c86576$16be5da0$c4f0200a@cisco.com>
From: "Francois Audet" <audet@nortel.com>
To: "Dan Wing" <dwing@cisco.com>, "Cullen Jennings" <fluffy@cisco.com>, "Bruce Lowekamp" <lowekamp@sipeerior.com>
Cc: P2PSIP Mailing List <p2psip@ietf.org>
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2psip-bounces@ietf.org
Errors-To: p2psip-bounces@ietf.org


> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com] 
> Sent: Saturday, February 02, 2008 00:32
> To: Audet, Francois (SC100:3055); 'Cullen Jennings'; 'Bruce Lowekamp'
> Cc: 'P2PSIP Mailing List'
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> Reports indicate that roughly 25% of NATs would block such 
> incoming packets. 
> 
> This means that a TURN client, trying to use a random TURN 
> server's transport address that is published into the p2p 
> overlay, would get a 75% success rate.
> If the TURN client tried two TURN servers it would get a 
> success rate of 87.5%, and so on, up to trying 11 TURN 
> servers to get a success rate of 99.9%.
> 
> 
> Those success rates include no calculations about TURN 
> servers that have crashed, had their p2p-TURN application 
> terminated, had their NATs crash or otherwise lose state, etc.

And?

That doesn't seem so bad to me. When a peers goes live (attempts to connect), it
would then try to find a working STUN/TURN server. After a few attempts, it is
likely to find a working one. A success of 87.5% after 2 tries seems very good to me.

Also, the alternative is that the servers themselves do a lot of self-assestment which
takes some time.

I'm also thinking that if somehow we could make the process of being a STUN/TURN server
and discovering others/joining the overlap mandatory, then we wouldn't have the problem
that everybody would opt out of being used as a STUN or TURN server.

(By mandatory, I don't mean "the spec says it's mandatory: I mean the procedures would be
intertwined enough that it would not be possible, or at least very difficult, to
disable the STUN and TURN server).

Just thinking out loud...
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
http://www.ietf.org/mailman/listinfo/p2psip