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

"Dan Wing" <dwing@cisco.com> Sat, 02 February 2008 08:30 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 27D9D28C467; Sat, 2 Feb 2008 00:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.902
X-Spam-Level:
X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, 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 Edi3BPwAC1vU; Sat, 2 Feb 2008 00:30:33 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DE128C385; Sat, 2 Feb 2008 00:30:33 -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 2EFC03A6A0A for <p2psip@core3.amsl.com>; Sat, 2 Feb 2008 00:30:32 -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 ox8fyVeU3Ih2 for <p2psip@core3.amsl.com>; Sat, 2 Feb 2008 00:30:31 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4E6D23A6884 for <p2psip@ietf.org>; Sat, 2 Feb 2008 00:30:31 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.25,294,1199692800"; d="scan'208";a="11154891"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2008 00:32:04 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m128W4hc025814; Sat, 2 Feb 2008 00:32:04 -0800
Received: from dwingwxp01 ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m128W3qX010903; Sat, 2 Feb 2008 08:32:03 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Francois Audet'" <audet@nortel.com>, "'Cullen Jennings'" <fluffy@cisco.com>, "'Bruce Lowekamp'" <lowekamp@sipeerior.com>
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>
Date: Sat, 2 Feb 2008 00:32:03 -0800
Message-ID: <2e0701c86576$16be5da0$c4f0200a@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AchkjSnVj/XzQBCHRDyw9Ba1icG9uwAn2nGgABIuK/A=
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF14996504@zrc2hxm0.corp.nortel.com>
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
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: p2psip-bounces@ietf.org 
> [mailto:p2psip-bounces@ietf.org] On Behalf Of Francois Audet
> Sent: Friday, February 01, 2008 4:14 PM
> To: Cullen Jennings; Bruce Lowekamp
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
> 
> I'm sure this is an incredibly dumb question: but why does a 
> peer need to
> think of being a TURN server (by presumably "testing" if it 
> is behind a NAT)?
> 
> Wouldn't it work if all peer always try to be TURN/STUN servers?
> A peer would advertize a TURN server for the any public IP addresses
> it has. That includes both local public IP addresses as well as
> self-discovered IP addresses (gathered through STUN using 
> other peers).
> 
> If it happens that the peer is behind a NAT that does not have an 
> endpoint independent mapping, then it just won't receive any 
> TURN/STUN packets.
> 
> The algorithm could work something like this, upon connecting 
> to the network:
> 
> - If local IP address is public then advertize it (both STUN and TURN)
> - Then, when another peer STUN server is discovered, discover 
> if you have another public IP address
>   binding (that would occur for example if you have NATing of 
> public IP addresses)
> - Then advertize new IP address (both for STUN and TURN 
> server) on discovered IP address and port
> - And so on
> 
> You just won't get any incoming STUN/TURN destined to your 
> local IP:port if you are NATed (public to
> public). Similarly, you won't get any incoming STUN/TURN 
> destined to your discovered IP:port if the
> NAT is not endpoint-independent.

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.

-d

> > -----Original Message-----
> > From: p2psip-bounces@ietf.org 
> > [mailto:p2psip-bounces@ietf.org] On Behalf Of Cullen Jennings
> > Sent: Thursday, January 31, 2008 20:44
> > To: Bruce Lowekamp
> > Cc: P2PSIP Mailing List
> > Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer
> > 
> > 
> > On Jan 28, 2008, at 8:01 AM, Bruce Lowekamp wrote:
> > 
> > > But otherwise, the TURN
> > > protocol seems to work as is.  For the purposes of a TURN 
> server, a 
> > > NAT having endpoint independent mapping seems to be the only real 
> > > requirement on the NAT
> > 
> > Agree on that but ...
> > I think the hard part we have not fully solved yet is how a 
> > peer that is thinking of being a TURN server is going to 
> > detect if this is the case or not.
> > _______________________________________________
> > P2PSIP mailing list
> > P2PSIP@ietf.org
> > http://www.ietf.org/mailman/listinfo/p2psip
> > 
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> http://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
http://www.ietf.org/mailman/listinfo/p2psip