Subject: Re: [BEHAVE] TURN draft queries

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Dec 2007 00:19:10 -0500

inline:

David Barrett wrote:

>> If only one endpoint is behind symmetric NAT, ICE will not use the TURN
>> server for that call.
> 
> Actually, if one side is symmetric and the other side is restricted cone,
> won't TURN still be needed?
> 
> In this scenario, both sides filter out packets that come from ports that
> aren't explicitly being sent to.  This isn't a problem when doing CONE->CONE
> because both sides know where to send.  But if one side is symmetric, then
> the cone side doesn't know where to send to: thus the symmetric side won't
> receive anything, and anything it sends will be filtered out by the
> restricted cone.

If the other side is address restricted, it will still go direct as long 
the as the guy behind the symmetric NAT has a NAT with just a single 
external IP. If the other side is address and port restricted, you are 
correct a TURN server would be used.

> 
> Incidentally, my stats show something like 45% restricted cone (ie, port and
> endpoint dependent filtering) and 15% symmetric (port and endpoint dependent
> mapping).  So right off the top it sounds like somewhere around 6% of calls
> will be symmetric/restricted combination, and another 2% will be
> symmetric/symmetric, suggesting at least 9% of all calls will need TURN
> relaying (and that assumes perfect penetration everywhere else, which is an
> incredibly optimistic assumption).  

This number is pretty consistent with reports I've gotten from ICE 
deployments, which indicate a little less than 10% of calls are 
requiring TURN servers.

> 
> Anyway, I don't think that's a dealbreaker, but it's probably good to keep
> in mind that 90% peer connectivity is likely the *upper* bound of ICE's
> capabilities.

Until the deployment of behave-compliant NAT everywhere, yes. So the 
hope is that over time, turn usage with ICE drops from around 10% of 
calls eventually to zero. Then we can retire them. I hope.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "David Barrett" <[email-masked]>
Date: Wed, 12 Dec 2007 21:23:16 -0800

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Subject: Re: [BEHAVE] TURN draft queries
> 

Ah, cool!  Can you share any of those numbers in more detail?

> calls eventually to zero. Then we can retire them. I hope.

Yes, that'll be a good day!

-david

---

From: Christian Huitema <[email-masked]>
Date: Tue, 18 Dec 2007 17:01:48 -0800

> ...

Actually, that is not necessary. Suppose that the host behind the symmetric NAT opens 256 sockets, with 256 different port numbers, and sends on each socket a "bubble" towards the IP+Port of the port-restricted NAT. Suppose then that the host behind the restricted NAT picks 256 random port numbers, and sends 256 bubbles to the IP address of the symmetric NAT, each with a different random port number. The birthday paradox tells that there is a 63% chance that at least one bubble will pass through. If you are willing to open more sockets, say 640, and send 640 bubbles, the chances increase to well over 99%.

-- Christian Huitema

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 19 Dec 2007 09:43:43 +0200

Le Wednesday 19 December 2007 03:01:48 ext Christian Huitema, vous avez 
écrit :
> > If the other side is address restricted, it will still go direct as
> > long the as the guy behind the symmetric NAT has a NAT with just a
> > single external IP. If the other side is address and port restricted,
> > you are correct a TURN server would be used.
>
> Actually, that is not necessary. Suppose that the host behind the symmetric
> NAT opens 256 sockets, with 256 different port numbers, and sends on each
> socket a "bubble" towards the IP+Port of the port-restricted NAT. Suppose
> then that the host behind the restricted NAT picks 256 random port numbers,
> and sends 256 bubbles to the IP address of the symmetric NAT, each with a
> different random port number. The birthday paradox tells that there is a
> 63% chance that at least one bubble will pass through. If you are willing
> to open more sockets, say 640, and send 640 bubbles, the chances increase
> to well over 99%.

Assuming that the NAT devices preserve the randomness of the internal port 
number (and I suspect many NATs allocate bindings in a linear fashion).

Further assuming that sending 256 packets over a short period of time won't 
yield nasty congestion problems.

That reminds me of the ICE-TCP port prediction controversy at the last 
meeting. Yeah sure, port prediction works better than ICE, but how many 
minutes must I wait before the connection gets eventually established? In 
many scenarios, the maximum is 5 to 10 seconds.

-- 
Rémi Denis-Courmont

---

From: Christian Huitema <[email-masked]>
Date: Wed, 19 Dec 2007 00:02:52 -0800

> number (and I suspect many NATs allocate bindings in a linear fashion).

Sure, but if the NAT does not behave in a random fashion, then it is predictable, and you can use various tricks to establish contact with much less than 256 packets.

-- Christian Huitema