Subject: [MMUSIC] ICE-TCP status

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 18 Feb 2008 09:43:01 +0200

Hello,

From my (admittedly very limited) testing, TCP simultaneous open works poorly. 
It does work for some NATs combinations but so seldom... considering that 
ICE-TCP is a lot more complicated than ICE (which is already very 
complicated), I am not sure it makes so practical much sense to implement :(

Still, someone (Philip Matthews, IIRC?) pointed out some method could yield 
better results... is there any update on this? or does it needs so much setup 
time, that it is not usable for real-time medias?

-- 
Rémi Denis-Courmont
_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Feb 2008 23:13:29 -0500

So, here is where we are.

ICE-tcp basically implements the 'p2pnat' solution as described in 
Saikats paper:

http://saikat.guha.cc/pub/imc05-tcpnat.pdf

his study, which covers some 90 different NATs, shows only 44% 
effectiveness for this technique. That is consistent with your results. 
With ICE, in many cases, even this is no big deal; for those cases 
you'll just end up with TURN. Not ideal but it works. And as S-O works 
better that percentage goes up.

Now the problem that was raised in Vancouver, is that p2psip in 
particular cannot fall back to public TURN servers to fix this problem. 
And the p2p protocol itself, which is ideally tcp-based, needs to make 
use of ICE.

So, I think we are going to need to improve upon this.

My current thinking is to add pseudo-port prediction to ice-tcp. I say 
'pseudo' in that, you would not need to determine your nat mapping type. 
Instead, try several things. According to Saikats results, most NAT are 
either endpoint independent mapping or else +1 mapping. So offer 
candidates that are both, and one should work. Still thinking about 
whether this will do what we need.

I'm going to be working on ice-tcp this week and hopefully can figure 
this out and get something incorporated into the next draft revision 
(along with the fixes for ice-lite as we discussed last time).

-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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 19 Feb 2008 06:38:37 -0800

>effectiveness for this technique.

>you'll just end up with TURN. Not ideal but it works.

I beg to differ since this is an abysmal failure if one considers the cost of bandwidth, servers and hosting for large VoIP networks. Such loads are even more expensive when considering large traffic surges for some usage scenarios that are very different from the stable VoIP telephony provider usage. 
Furthermore we don't have numbers for the call setup delays. Actually, we don't have any numbers for ICE at all, neither success ratios, or for call setup delay or for some cost metrics.

A better approach IMO may be to first use NAT tools to discover the NAT scenario as described in several I-Ds here and then decide right away what NAT traversal procedure is optimal, maybe go straight to some tunneling approach, thus reducing cal setup delay, message exchanges and processing. Having cooperating STUN servers at every NAT level is however not practical in CS SIP but may be doable in P2PSIP since peer nodes at different NAT levels could advertise their existence and help with hairpinning. Some peers behind friendly NAT could also act as media relays and thus relieve the application/service provider of provisioning relay service for peak loads.

All this is however still work to be done and we have no numbers to prove where each approach is optimal. Also, let's not forget that simple SIP NAT helpers and SIP media relays are widely deployed and are another tool to consider, even though no I-Ds have been (regrettably) written about them. The economics are also compelling (some are free).

My guess is ICE will be recognized as another tool for NAT traversal, but not the complete solution as it is promoted today. The initial STUN RFC 3489 was also presented as the solution, only to be recognized today as another tool in the toolbox.

Lat but not least, NAT traversal has to be solved and optimized for other apps as well, besides SIP, for RTSP for example. Other solutions may surface.

My apology for jumping into this discussion: ICE performance is highly hypothetical, since we have no numbers to work with when deciding which approach to take and how to optimize NAT traversal for success ratio, call setup delay and cost of ownership. NAT traversal design is after all a business decision based on numbers.

Henry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
Sent: Monday, February 18, 2008 10:13 PM
To: Rémi Denis-Courmont
Cc: [email-masked]
Subject: Re: [MMUSIC] ICE-TCP status

-Jonathan R.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 19 Feb 2008 17:08:40 +0200

Le Tuesday 19 February 2008 16:38:37 ext Henry Sinnreich, vous avez écrit :
> I beg to differ since this is an abysmal failure if one considers the cost
> of bandwidth, servers and hosting for large VoIP networks.
> Such loads are even more expensive when considering large traffic
> surges for some usage scenarios that are very different from the
> stable VoIP telephony provider usage.

May well be true.

> Furthermore we don't have numbers for the call setup delays.

Don't we? Looking quickly here, ICE was reasonably fast, though I have not 
made precise figures or formulas.

In any case, I *STRONGLY* prefer slow call setup, to fast call setup with 
media clipping, as we get with RFC3489 without ICE.

> Actually, we don't have any numbers for ICE at all, neither success
> ratios, or for call setup delay or for some cost metrics.

And we never will have verifiable numbers. These would depends on the NAT 
population you are measuring.

In any case, given the mechanisms involved, ICE will be no worse than plain 
RFC3489 + hole punching. In fact, it logically should be slightly better.

> A better approach IMO may be to first use NAT tools to discover the
> NAT scenario as described in several I-Ds here

Described in several I-Ds and well known to NOT WORK PROPERLY.
There are also many descriptions as to why it does not work (second and third 
order NAT behaviors or whatever you want to call it).

Teredo has been using NAT type determination and been deployed for several 
years, and if there's one thing I learnt form it, it's that NAT type 
determination does NOT work. Full point.

It might (seem to) work over small time intervals, i.e. right before you send 
the media, but then it is slower than ICE. Which makes no sense.
Over long time intervals, it starts to become overly unreliable and just 
causes silent failures. I much prefer increased call setup delays and/or 
explicit errors than silent failures.

> and then decide right away what NAT traversal procedure is optimal,

The optimal NAT traversal procedure is a function of (at least):
- how many Watts you're willing to spend for NAT traversal,
- whether you assume the availability of STUN servers,
- whether you assume the availability of TURN relays,
- whether you accept silent failures and media clipping,
- how generic you (don't) want the procedure to be,
- whether you want "always on" or "on demand" connectivity,
- what middlebox you (don't) want to be nice with,
- what transport semantics you want to have on top,
- what NAT models are common in your targetted population.

Lest all NATs become BEHAVE-compliant, there is no way you're going to find an 
optimal solution that is optimal for every body.

> maybe go straight to some tunneling approach,
> thus reducing cal setup delay, message exchanges and processing.

Agreed. There are already IETF and non-IETF protocols to do that, by the way.

Note however, tunneling only reduces call setup when you have multiple flows 
inside the same tunnel. IMHO, the main advantage is not call setup. It's the 
ability to use any transport protocol unencumbered, especially TCP, inside.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 19 Feb 2008 12:33:19 -0800

>made precise figures or formulas.

It would be great if anyone on the list could share numbers/statistics from Internet deployment.

>ability to use any transport protocol unencumbered, especially TCP, inside.

I fully agree and am wondering why openVPN and HIP NAT traversal have not been discussed here as alternatives, since they work for all application protocols. 
One tunnel for everything... :-)

Henry

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Tuesday, February 19, 2008 9:09 AM
To: Henry Sinnreich
Cc: Jonathan Rosenberg; [email-masked]
Subject: Re: [MMUSIC] ICE-TCP status

May well be true.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 20 Feb 2008 09:45:55 +0200

Le Tuesday 19 February 2008 22:33:19 ext Henry Sinnreich, vous avez écrit :
> >Note however, tunneling only reduces call setup when you have multiple
> > flows inside the same tunnel. IMHO, the main advantage is not call setup.
> > It's the ability to use any transport protocol unencumbered, especially
> > TCP, inside.
>
> I fully agree and am wondering why openVPN and HIP NAT traversal have not
> been discussed here as alternatives, since they work for all application
> protocols. One tunnel for everything... :-)

As far as I know, OpenVPN is not standardized, and does not have much advanced 
NAT traversal mechanism (though I haven't looked at it for a looong time). I 
agree that using OpenVPN or ESP-in-UDP or any kind of UDP tunneling with a 
real p2p NAT traversal method would make sense - and I guess that's where the 
home access BoF was heading before it was denied.

In this context, HIP NAT traversal looks very much like a -cleaner- 
reinvention of RFC4380. Except that RFC4380 is deployed in MILLIONS of 
Windows boxes TODAY, while even baseline HIP is not -yet- in any mainstream 
OS.

I don't think people want to wait for HIP to be ready to start solving the 
problems that RFC4380 and draft-ietf-mmusic-ice(-tcp) (try to) solve.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 20 Feb 2008 06:54:21 -0800

> problems that RFC4380 and draft-ietf-mmusic-ice(-tcp) (try to) solve.

(try to) solve

This is an excellent conclusion on which we can fully agree.

Henry

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 20 Feb 2008 17:06:24 +0200

> This is an excellent conclusion on which we can fully agree.

And so...?

As far as I am concerned, draft-ietf-mmusic-ice is a middlebox-friendly 
solution for transmitting UDP packets. And RFC4380 solves the problem of 
tunneling any transport protocol over UDP, albeit obviously in 
non-middlebox-friendly manner.

I don't see what's missing from your point of view?

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 21 Feb 2008 10:21:43 +0100

Hi, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Denis-Courmont
> Sent: Wednesday, February 20, 2008 8:46 AM
> To: ext Henry Sinnreich
> Cc: [email-masked]
> > >Note however, tunneling only reduces call setup when you have 
> > >multiple  flows inside the same tunnel. IMHO, the main 
> advantage is not call setup.
> > > It's the ability to use any transport protocol unencumbered, 
> > >especially  TCP, inside.
> >
> > I fully agree and am wondering why openVPN and HIP NAT 
> traversal have 
> > not been discussed here as alternatives, since they work for all 
> > application protocols. One tunnel for everything... :-)
> 
> As far as I know, OpenVPN is not standardized, and does not 
> have much advanced NAT traversal mechanism (though I haven't 
> looked at it for a looong time). I agree that using OpenVPN 

OpenVPN is using TCP and does have the some advantages or disadvantges with respect to NAT traversal as, e.g., http. 

> or ESP-in-UDP or any kind of UDP tunneling with a real p2p 
> NAT traversal method would make sense - and I guess that's 
> where the home access BoF was heading before it was denied.
> 
> In this context, HIP NAT traversal looks very much like a 
> -cleaner- reinvention of RFC4380. Except that RFC4380 is 
> deployed in MILLIONS of Windows boxes TODAY, while even 
> baseline HIP is not -yet- in any mainstream OS.

Conceptionally HIP could be a cleaner solution, but nobody has yet seen the HIP NAT traversal solution. The design team is still working on that and the old attempt is not aiming at peer-to-peer. 

> 
> I don't think people want to wait for HIP to be ready to 
> start solving the problems that RFC4380 and 
> draft-ietf-mmusic-ice(-tcp) (try to) solve.

Agreed, as having HIP completely being able to deal with NAT boxes will take another year or two.

[email-masked]   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014  
_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic