Subject: [BEHAVE] Re: ICE deployment data before LC for RFC

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 17 Jul 2007 11:50:07 -0700

Following some discussions and soul searching, the best approach for
ICE-17 for LC would be to _go ahead and make it an experimental RFC_.

This would support the development of interoperable implementations, the
collection of deployment data and also hopefully open source code.

Though I have full faith in ICE, following the practices that made the
IETF successful take precedent here, I believe.

This is a change from the attached that I wrote on 7/16/2007.

Note: We can only hope the proliferation of SBC in VoIP service provider
networks will not make these concerns and ICE for SIP a moot issue, but
this is another topic.

=========================================================

>The work on ICE is truly impressive and so are the numerous I-Ds
associated with ICE.

>However, before sending the <ice-17> I-D for LC to the IESG, it would
be prudent and responsible to the industry 
>(that spends considerable resources on ICE in good faith) implementing
ICE, to either (1) make it an informational RFC or 
>(2) publish some deployment data showing such items as:

>* NAT scenarios that have been tested,
>* The % of success,
>* Performance, such as call setup delay using SIP.

>I have not seen any such public data on ICE deployment, for example
with SIP. 
>A private report has raised my concern about the performance of ICE.

>In the best IETF tradition, it would also help to have open source code
>available for ICE, before declaring it a standard.

>ICE is too important for the IETF (good work Jonathan and other
authors!) >not to publish 
>(1) deployment results and (2) publish open source code as well.
>The various nits discussed on the lists are only of secondary
importance to >the LC 
>compared to the above and would get resolved with such a process
anyway.

>These are my personal two cents.

Henry Sinnreich

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Jul 2007 10:10:43 +0200

> networks will not make these concerns and ICE for SIP a moot issue, but

Henry,

I don't quite understand why you are requesting a status change of ICE? 
To me it appears that ICE is almost finished spec. It has been 
implemented, used and feedback has been influencing the protocol. It is 
definitly one of the better examples of current IETF work that actually 
has running code. Sure, the implementations may not be fully updated yet 
to the latest draft version. But I think it is safe to say that ICE 
works in the intended core cases. If there are some corner cases where 
it fails, that may be. But that is not information we will have until 
really large scale deployement or someone makes very extensive tests.

I think the IETF and the Internet has much more benefit from a standards 
track solution than any of the risks existing with ICE of today.

And to be clear, proposed standard is allowed to be published without a 
single implementation exists. It might not be good practice, but it is 
allowed by our process. And as I said before ICE has had enough 
implementation that I am very confortable in balloting YES for it when 
it appears on the IESGs table.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 18 Jul 2007 07:20:23 -0700

Magnus,

I sincerely appreciate your interest and this note!

> I don't quite understand why you are requesting a status change of ICE

However the arguments stated by the WG co-chairs and by you here are
procedural in nature, whereas the facts are some cause for serious
concern, and I will just mention a few facts:

RFC 3489 (STUN) was also presented as a NAT traversal solution back in
2003, but <draft-ietf-behave-rfc3489bis-07> now clearly admits that
"STUN is not a NAT traversal solution by itself. Rather, it is a tool to
be used in the context of a NAT traversal solution. This is an important
change from the previous version of this specification (RFC 3489), which
presented STUN as a complete solution."

http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt

My guess is, in plain English, RFC 3489 turned out just NOT to be an
acceptable solution as it was hoped to be. 

The excellent I-D <draft-ietf-sipping-nat-scenarios-07> shows the ICE
call flow with two endpoints behind two NAT (Fig. 22 on page 38) require
66 messages just for the SIP INVITE!

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.
txt 

What happens if the two endpoints are in different ISPs that have NAT of
their own in addition to the ones in Fig. 22?

What happens if one would try ICE along a P2PSIP route with say 5-8
hops? Would there be hundreds of messages? What is the likelihood for
failure?

By contrast with such approaches based on hope and faith, the BEHAVE WG
has produced work based on real measurements and tools to do the
measurements, such as

"NAT Classification Test Results"

"Application Design Guidelines for Traversal through Network Address
Translators" 

The measurements for hole punching are reported in

"Peer-to-Peer Communication Across Network Address Translators" 

http://www.brynosaurus.com/pub/net/p2pnat/

I am also a believer in ICE and have actually urged Jonathan Rosenberg
to do this work and he has given his best. Now that we have ICE-17
version, it is in the best interest of the industry and the IETF to make
it an experimental RFC, but not yet a standard so that:

 1. Independent, compliant implementations will be developed,

 2. Testing in events such as SIPit,

 3. Reporting the results, such as reported for the "hole punching"
above.

What happens if indeed hole punching proves to be the far more effective
approach?

The industry can ill afford a new series of RFC[ICE]-bis and all the
years it takes to move from believing to measuring and proving. I am
sure IETF procedures were meant in this spirit (though I am not good in
producing the right quotes).

Thanks again for your attention to this concern about ICE. 

Also my apology to all the anguish to the numerous contributors to the
ICE related I-Ds, but writing test tools and reporting measurements is
the right way to go.

Henry

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 1:11 AM
To: Henry Sinnreich
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC

Henry,

Cheers

Magnus Westerlund

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 18 Jul 2007 08:53:30 -0600

Greetings,

What I think Henry is advocating is a systematic approach to making sure
that the content of the ICE spec is right for its intended purpose, i.e. a
complete, general NAT traversal solution.  NAT traversal has been in my
opinion one of the most difficult aspects of SIP implementation and its very
important that its eventual standardized solution be right.  I know I spent
a lot of time implementing all the "tests" in the first 3489, only to
discover that they were not that useful.  There are two valid technical
concerns that are put forth in this email:

1)     Viability of correct operation in practical implementations.  ICE can
result in very complicated message transfers.

2)     Performance.  As pointed out in this email and in other places, the
additional latency associated with ICE operations can be significant.

Henry also points out that there are competing approaches (e.g. Hole
Punching) that can perform well in many situations and have better
performance.  IMHO, another approach by the IETF in general would be to
standardize on Hole Punching and leverage the IETF's considerable influence
to force NAT vendors to migrate towards implementations that are friendly to
Hole Punching.

The bottom line is that I agree with Henry in that labeling ICE as an
experimental draft is the right thing to do.  It will allow those
implementing ICE (including myself in all likelihood) to proceed but signals
to the users the correct status of the standard's contents.

I also want to applaud loudly the underlying tone of Henry's thread here.
That is, in solving specific technical problems within the IETF forum,
focusing on empirical observation of working implementations should be the
MO that we all strive for when developing and proposing what may become
protocol standards.

Thanks,

FM

  _____  

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 8:20 AM
To: Magnus Westerlund
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC

Magnus,

However the arguments stated by the WG co-chairs and by you here are
procedural in nature, whereas the facts are some cause for serious concern,
and I will just mention a few facts:

RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003,
but <draft-ietf-behave-rfc3489bis-07> now clearly admits that "STUN is not a
NAT traversal solution by itself. Rather, it is a tool to be used in the
context of a NAT traversal solution. This is an important change from the
previous version of this specification (RFC 3489), which presented STUN as a
complete solution."

The excellent I-D <draft-ietf-sipping-nat-scenarios-07> shows the ICE call
flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66
messages just for the SIP INVITE!

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.txt 

What happens if one would try ICE along a P2PSIP route with say 5-8 hops?
Would there be hundreds of messages? What is the likelihood for failure?

By contrast with such approaches based on hope and faith, the BEHAVE WG has
produced work based on real measurements and tools to do the measurements,
such as

I am also a believer in ICE and have actually urged Jonathan Rosenberg to do
this work and he has given his best. Now that we have ICE-17 version, it is
in the best interest of the industry and the IETF to make it an experimental
RFC, but not yet a standard so that:

 3. Reporting the results, such as reported for the "hole punching" above.

The industry can ill afford a new series of RFC[ICE]-bis and all the years
it takes to move from believing to measuring and proving. I am sure IETF
procedures were meant in this spirit (though I am not good in producing the
right quotes).

Also my apology to all the anguish to the numerous contributors to the ICE
related I-Ds, but writing test tools and reporting measurements is the right
way to go.

Henry

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 1:11 AM
To: Henry Sinnreich
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC

Henry,

Cheers

Magnus Westerlund

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 18 Jul 2007 08:37:12 -0700 (PDT)

Thanks to Henry and Frank for so eloquently articulating this. 

As both Henry and Frank mentioned, I fully support standardizing on HOLE
PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence to force
NAT vendors to migrate towards implementations that are friendly to Hole
Punching and the Application developers to design applications using the hole
punching techniques. That should be the FIRST order of priority. 

Yet, what is happening in BEHAVE WG is the other way around. Some people have
put their weight so heavily in favor of ICE that they asked to drop the work on
hole punching technique as WG item. THIS IS WRONG. I no longer see "NAT
Traveral application design guidelines" as BEHAVE WG milestone.

Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING TECHNIQUES
to move forward as a WG item?
 
regards,
suresh

---

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Jul 2007 12:26:55 -0400

Frank, Henry, Suresh:

I agree that ICE is a complex spec. I also agree that it would be  
very interesting to see
more data on which situations result in a direct path between  
endpoints, as opposed to
a path via a TURN server.

However, I don't understand the comment that "Hole Punching  
Techniques" are an alternative.
In my view, ICE _is_ a "Hole Punching Technique".

Perhaps you are referring to the use of STUN alone???
The problem with using STUN alone is that there are cases where using  
the reflexive address
doesn't work, and there is no way with STUN alone to determine when  
an endpoint should or
should not use a reflexive address.

But perhaps you are referring to something else?
- Philip

---

From: "David Barrett" <[email-masked]>
Date: Wed, 18 Jul 2007 11:13:43 -0700

I agree with Henry, Frank, Suresh, and the lurkers on this list who have
concern that ICE hasn't demonstrated its claims in the real world, while
others have achieved similar ends with great success using much simpler
approaches.  (Some examples: Skype, Hamachi, Red Swoosh/Akamai, etc.)

For example, regarding the "hole punching" approach (by which I assume you
mean "opening a hole and trying to keep it open" versus ICE's "open a hole
'on demand' for each connection"), it's been demonstrated to work at large
scale with at least 90% direct peer connectivity across the internet, today,
with a much simpler message flow and implementation.  I find it concerning
that ICE has taken a more costly, difficult route without confirming it's
truly worth the additional incremental effort (or even a step backwards).

I share the concern that ICE standardization has gotten far out ahead of the
horse in inventing a new protocol from scratch rather than modeling off of
the proven protocols that came before it, which historically has been the
IETF strength.  Given this choice to go a new route, I think it warrants a
higher burden of evidence -- contrasted against known success rates of
competing solutions -- before being formally endorsed by the IETF.

I'm completely open to ICE being superior to all others.  I have no doubt
more effort has been put into it, and I'm eager to enjoy the fruits of
everyone's labor.  But I'd like to see the data that proves it, and I see no
reason to charge ahead with standardization until data is firmly in hand.

-david

> From: Philip Matthews [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2007 9:27 AM
> To: Pyda Srisuresh
> Cc: [email-masked]; [email-masked]; [email-masked]; 'Henry Sinnreich'
> Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC
> 
> Frank, Henry, Suresh:
> 
> > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence
> > to force

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Jul 2007 11:18:59 -0700

> The excellent I-D <draft-ietf-sipping-nat-scenarios-07> shows 
> the ICE call flow with two endpoints behind two NAT (Fig. 22 
> on page 38) require 66 messages just for the SIP INVITE!
> 

That figure does not show 66 messages.

That figure is clearly showing how the STUN messages are NATted,
which leads to an incorrect conclusion around the number of 
messages.  Specifically, for example, it shows this message
exchange which might be counted as "four messages"; yet, there
are only two messages (the allocate request and the allocate
response), which are NATted:

   L               NAT             STUN              
                                   Server
   |                |                |               
   |(1) Alloc Req   |                |               
   |Src=L-PRIV-1    |                |               
   |Dest=STUN-PUB-1 |                |               
   |--------------->|                |               
   |                |                |               
   |                |(2) Alloc Req   |               
   |                |Src=L-NAT-PUB-1 |               
   |                |Des=STUN-PUB-1  |               
   |                |--------------->|               
   |                |                |               
   |                |(3) Alloc Resp  |               
   |                |<---------------|               
   |                |Src=STUN-PUB-1  |               
   |                |Dest=L-NAT-PUB-1|               
   |                |Map=L-NAT-PUB-1 |               
   |                |Rel=STUN-PUB-2  |               
   |                |                |               
   |(4) Alloc Resp  |                |               
   |<---------------|                |               
   |Src=STUN-PUB-1  |                |               
   |Dest=L-PRIV-1   |                |               
   |Map=L-NAT-PUB-1 |                |               
   |Rel=STUN-PUB-2  |                |               
   |                |                |               

If we added another NAT on that path, the number of messages
on the network does not double.  The number of messages on 
the network stays the same -- the messages merely have their
IP and UDP headers rewritten by the NATs.  That NAT function
does not increase the number of messages on the network.

Similarly, another message shown in that same figure is also
one message; however, it's shown as two messages:

L               NAT             STUN              NAT               R
                                Server
|(9) SIP INVITE  |                |                |                |
|------------------------------------------------->|                |
|                |                |                |(10) SIP INVITE |
|                |                |                |--------------->|

As you know, there aren't two messages -- it's one message that is
NATted.

If message 9 and 10 were shown as clearly as messages 1-4, messages
9-10 would be shown as four messages (one from L to its NAT, another 
from NAT to NAT, and the forth (shown) from NAT to R).  But this is
just one SIP message, which is NATted.  It is inaccurate  to count
it as two separate messages or as four separate messages, because
it is only one packet that is NATted.  Counting a STUN packet,
or a DNS packet, as a separate message each time it traverses a 
NAT is similarly inaccurate.

By my count, figure 22 exchanges 24 STUN/ICE messages and 6 
SIP messages.

> What happens if the two endpoints are in different ISPs that 
> have NAT of their own in addition to the ones in Fig. 22?

The same 24 STUN/ICE messages would be exchanged, and the same
6 SIP messages would be exchanged.

> What happens if one would try ICE along a P2PSIP route with 

The SIP signaling messages would traverse those 5-8 additional 
hops between the P2PSIP nodes participating in the SIP proxy
overlay.  The STUN/ICE messages are sent peer-to-peer, and 
would remain the same 24 messages if you're doing the same 
Figure 22 flow.  

> Would there be hundreds of messages?

No.

-d

---

From: Melinda Shore <[email-masked]>
Date: Wed, 18 Jul 2007 14:43:54 -0400

On 7/18/07 2:13 PM, "David Barrett" <[email-masked]> wrote:
> with a much simpler message flow and implementation.

ICE makes me want to pound red-hot nails into my eye sockets.  That said,
90% really isn't nearly good enough for residential deployments.  For
cheap-o residential equipment, the margins are so thin that a support call
or two is sufficient to wipe out the profit on that sale.  Part of the
reason that ICE is the mess it is is that the group has been iteratively
fixing the various failures by adding more tests and probes and messages
and whatnot.  There are certainly a lot of other ways to achieve reliability
but regardless of which one you choose, reliability really does have to be
a priority.  Ancillary to that is that when you fail you should fail in
a way that can be diagnosed with reasonable ease and transparency
(auditability is good!), and I think we all know what happens when
traditional NAT hole-punching fails - stuff just doesn't work.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 18 Jul 2007 11:38:24 -0700 (PDT)

> should not use a reflexive address.

[suresh] Right, ICE does use the HOLE PUNCHING technique and the BCP guidelines
described in draft-ford-behave-app draft, even though ICE draft does NOT
acknowledge or reference the above draft or prior work that introduced HOLE
PUNCHING TECHNIQUE. ICE is also using HOLE PUNCHING in a limited way within the
constraints of STUN and SIP. Hence, the croner case scenarios you site. ICE is
NOT HOLE PUNCHING in its native form.

In the BEHAVE WG meeting(last IETF), several people talked of ICE as the new
application traversal approach blessed by IETF, and proposed dropping the
original draft ford-behave-app draft that proposes HOLE PUNCHING TECHNIQUE. As
a result, the application milestone is dropped from the WG charter and
ford-behave-app is not adapted as work group item. This, to me, is pitting ICE
against the basic HOLE PUNCHING TECHNIQUE. This is what I believe to be WRONG.

regards,
suresh

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 18 Jul 2007 12:20:22 -0700

Dan,

What you say makes sense but there is a lingering suspicion that after
admitting that RFC 3489 (STUN), RFC 4091, 4092 (ANAT), etc. just don't
work is that such paper evaluations are in no way a replacement for
proof and measurements. We still need an explanation why the right
approach cannot be taken:

* Publish open source code at Sourceforge.net or similar,
* Publish a test tool as well,
* Gather and publish the results, possibly involving SIPit or another,
* Perfect the OS code and the protocol until it works OK.

This has been done for "Hole Punching for P2P" in 
http://www.brynosaurus.com/pub/net/p2pnat/ 

What if ICE proves to be no better than its predecessors? 

So how can one compare something that has tools, measured and published
results with something like ICE that we have to take on pure faith?

My assumption is that hole punching is much more effective for P2PSIP
and I have copied the P2PSIP WG on this. The ratio of messages is
probably 5:1 or higher for ICE vs. hole punching and this is critical
when routing a P2PSIP message over an overlay in 5-10 hops. Of course I
cannot prove it since as yet ICE cannot be measured.

Let's do ICE the right way, there is too much at stake here.

Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 1:19 PM
To: Henry Sinnreich; 'Magnus Westerlund'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC

   L               NAT             STUN              
                                   Server
   |                |                |               
   |(1) Alloc Req   |                |               
   |Src=L-PRIV-1    |                |               
   |Dest=STUN-PUB-1 |                |               
   |--------------->|                |               
   |                |                |               
   |                |(2) Alloc Req   |               
   |                |Src=L-NAT-PUB-1 |               
   |                |Des=STUN-PUB-1  |               
   |                |--------------->|               
   |                |                |               
   |                |(3) Alloc Resp  |               
   |                |<---------------|               
   |                |Src=STUN-PUB-1  |               
   |                |Dest=L-NAT-PUB-1|               
   |                |Map=L-NAT-PUB-1 |               
   |                |Rel=STUN-PUB-2  |               
   |                |                |               
   |(4) Alloc Resp  |                |               
   |<---------------|                |               
   |Src=STUN-PUB-1  |                |               
   |Dest=L-PRIV-1   |                |               
   |Map=L-NAT-PUB-1 |                |               
   |Rel=STUN-PUB-2  |                |               
   |                |                |               

L               NAT             STUN              NAT               R
                                Server
|(9) SIP INVITE  |                |                |                |

No.

-d

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 18 Jul 2007 12:31:18 -0700

Phil,

> In my view, ICE _is_ a "Hole Punching Technique".

Yes, you absolutely right, though the devil is in the details.

We cannot go here into a shoot-out between hole punching or other
mentioned on the list vs. ICE, but there seems to be a huge difference
in effectiveness and performance. 

Of course I cannot prove it since there are no measurements published
for ICE, only faith. 

Just think of traversing all the NAT while going over 5-10 overlay
network hops. Also many ISP are NATed and some are multiple NATed. We
are supposed to provide a solution that works across the Internet. A
provable (testing tools) and proven solution (measurements).

I like ICE and hope to be proven wrong, but the risk is just too big for
now.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 9:27 AM
To: Pyda Srisuresh
Cc: Frank W. Miller; Henry Sinnreich; 'Magnus Westerlund'; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for
RFC

Frank, Henry, Suresh:

On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote:

>> ---------------------------------------------------------------------

>> -
>> ---------------------------------------------------------------------

>> -
>> ---------------------------------------------------------------------

>> -

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Jul 2007 14:38:09 -0500

> http://www.brynosaurus.com/pub/net/p2pnat/ 

Heuh, no. This is just "exploratory concept" stuff, certainly
not an interoperable protocol specification.

And if the proponents of this alternative hole punching didn't 
propose a draft at IETF when we starting working on this back
in 2001, it seems to me that it's too late.

> My assumption is that hole punching is much more effective 
> for P2PSIP and I have copied the P2PSIP WG on this. The ratio 
> of messages is probably 5:1 or higher for ICE vs. hole 
> punching and this is critical when routing a P2PSIP message 
> over an overlay in 5-10 hops. Of course I cannot prove it 
> since as yet ICE cannot be measured.

Well, your assumption may be wrong, especially in the absence of
a specification for this alternative hole punching technique.

The other thing I find funny in here is that the alternative 
hole punching techique as described on the web site uses a
centralize server common to BOTH ends to relay the address, while
ICE does not (i.e., each end can use their own STUN server).

In other words, the major difference between ICE and the
alternative-hole-
punching technique seems to be that alternative-hole-punching
assumes both ends use the same STUN server, which makes the 
rest of the exchange simpler (the "magic box" architectural
concept is always handy).

Ironically, this seems to me to be LESS usable in a global network
where you wont't use centralize servers, especially for p2psip.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 18 Jul 2007 12:42:57 -0700

Francois,

> Heuh, no. This is just "exploratory concept" stuff, certainly not an 
> interoperable protocol specification.

I am happy to report we are in total agreement.

Henry

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 2:38 PM
To: Henry Sinnreich; Dan Wing; Magnus Westerlund
Cc: [email-masked]; [email-masked]; [email-masked]; Philip Matthews;
[email-masked]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 18 Jul 2007 15:05:13 -0600

> where you wont't use centralize servers, especially for p2psip.

This may be sufficient, but I don't think its necessary.  Each UA
punches the hole (and keeps it open, as David described) to whatever
STUN server they like, all that's required is that each server have the
same view of each client.  That is somewhat less restrictive.  In the
common case of the open Internet, as long as the STUN servers used by
each respective UA are in the "open", they don't have to be the same.
After that, the "public" or "visible" IP address/port is put in the
Contact headers.

Regarding the 90% coverage, this is what I'm referring to when I say
that it may be preferable to influence the NAT vendors to not do the
things that put them in the 10% cases.  I sort of thought that was what
the NAT guidelines draft was for.

In addition, if we are standardizing a protocol based on the 10% cases
and imposing potentially huge costs on the 90% to do so, then our
approach is incorrect.  We should be designing for the 90% case and
handling the 10% as exceptional behavior, i.e. a solution where you pay
the big cost only in the case where you are actually in the 10%.

FM

---

From: "David Barrett" <[email-masked]>
Date: Wed, 18 Jul 2007 15:38:52 -0700

> From: Melinda Shore [mailto:[email-masked]]
> 
> 90% really isn't nearly good enough for residential deployments.

Incidentally, 90% is where my stats come out today -- this doesn't include
restricted-cone/symmetric and symmetric/symmetric penetration, which has
been prototyped but not added to the production system yet.  The hope is
this will get us much close to the 99% range, but it remains to be seen by
how much.

Furthermore, I'd wager that for most applications (such as VoIP), even
routing 1 in 10 calls through a central relay isn't going to break the bank.
(Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) to
act as "free" relays for their peers.)

Thus while NAT penetration using what I guess we're calling the "hole
punching technique" has been demonstrated to work at 90%+ on a very large
scale (hundreds of thousands of clients tested) we should expect that it's
possible to get even better still.  If ICE can show how it'd do better,
that'd be great.  But we can't tolerate ICE being any worse than that, and
thus before rushing ahead with standardizing an unproven ICE, we should just
take the time to prove it.

-david

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Jul 2007 11:12:27 -0500

On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote:

> I don't quite understand why you are requesting a status change of  
> ICE? To me it appears that ICE is almost finished spec. It has been  
> implemented, used and feedback has been influencing the protocol.  
> It is definitly one of the better examples of current IETF work  
> that actually has running code. Sure, the implementations may not  
> be fully updated yet to the latest draft version. But I think it is  
> safe to say that ICE works in the intended core cases. If there are  
> some corner cases where it fails, that may be. But that is not  
> information we will have until really large scale deployement or  
> someone makes very extensive tests.

Henry has, I believe, been very consistent in urging the IETF to have  
more "running code" experience on every specification (not just ICE)  
than our process requires. He has, IIRC, also advocated changing the  
process to require running code before publishing an RFC. He's even  
suggested at times that one should have running code before  
submitting a protocol draft.

Another point to consider -- I've known Henry to bark at a tree with  
no squirrel in it occasionally, but most of the time he's pretty  
reliable, more so than most technology predictors. If he's worried  
about ICE, it's probably because he's been talking to people who are  
trying to implement it and they're telling him it is difficult or  
that they're having performance or reliability issues. I imagine that  
there are plenty of internal development teams in various companies  
that are working on this and not necessarily bringing their results  
back to the IETF. After all, if everybody sees the emperor as fully  
clothed, they'd be embarrassed to proclaim otherwise. Of course, I  
wish all of these developers were tied into the IETF, but then I'm  
sure I don't want to see every ice-implementor's question on the SIP  
list. That is why we have a sip-implementors mailing list, right?

Personally, I think ICE is the best solution we have. We KNOW of  
cases where hole-punching doesn't work, and I think ICE will produce  
usable results in most of those cases. But that's just my personal  
opinion from reading the specs. I haven't implemented ICE, and I  
haven't used anybody else's implementation. Sure, it's complex, but  
that's because the underlying problem is complex -- there are just  
too many different behaviors out there in "NAT and firewall land". Of  
course, I could be wrong, too. It's happened before, once or  
twice ;-). Just how sure are we that we're right about this?

Are we designing a "spruce goose" or a practical system? Only  
experience will tell us. But some good flight reports from the  
prototypes could go a long way towards reassuring us of the design's  
utility.

So far we've had a couple of people report hearsay evidence -- that  
somebody else has an ICE implementation and it works. Any of you  
folks have personal experience you can share? Have there been  
prototypes exercised at the interop events?

--
Dean

---

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Jul 2007 21:19:21 -0400

> in effectiveness and performance.

What precise algorithm are you talking about when you say this?
As far as I am concerned, ICE is simply a well-documented hole  
punching algorithm.
It differs from others that I have seen written up in the following  
ways:
- ICE has the concept of peer reflexive addresses, which other hole- 
punching techniques that I have seen do not;
- ICE has the concept of controlling/controlled endpoint, which gives  
the controller additional flexibility in choosing a path;
- ICE does NOT have the concept of port prediction, which some other  
techniques do (e.g., Saikat's TCP work).

Philip

---

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Jul 2007 21:57:34 -0400

On 18-Jul-07, at 21:19 , Philip Matthews wrote:

> - ICE has the concept of controlling/controlled endpoint, which  
> gives the controller additional flexibility in choosing a path;
> - ICE does NOT have the concept of port prediction, which some  
> other techniques do (e.g., Saikat's TCP work).

I should add that ICE also handles:
- the case of multi-homed peers,
- peers that want to exchange multiple media streams,
- media streams which are composed of multiple components (e.g. RTP  
and RTCP).
These are cases that a solution for SIP needs to handle, but I have  
not seen discussed in other proposals.

- Philip

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 18 Jul 2007 20:56:09 -0600

> What precise algorithm are you talking about when you say this?

Well, here's the algorithm I use with my UA (the most recent versions I
might add):

                            STUN
UA         Registrar       Server
 |  REGISTER   |             |
 |-5060------->|             |
 |  w/rport    |             |
 |             |             |
 |   200 OK    |             |
 |<5060--------|             |
 |             |             |
 |             |             |
 |  STUN BReq  |             |
 |-5060--------------------->|
 |  STUN BReq  |             |
 |-5004--------------------->|
 |  STUN BResp |             |
 |<5060----------------------|
 |  STUN BResp |             |
 |<5004----------------------|
 |             |             |
 |      .      |             |
 |      .      |             |
 |    10sec    |             |
 |      .      |             |
 |      .      |             |
 |             |             |
 |  STUN BReq  |             |
 |-5060--------------------->|
 |  STUN BResp |             |
 |<5060----------------------|
 |  STUN BReq  |             |
 |-5004--------------------->|
 |  STUN BResp |             |
 |<5004----------------------|
 |             |             |
 |             |             |

I pick up the rport addressing during the REGISTER transaction because
of the way my multithreading is done and because its nice to see the
same value coming from two different sources out on the Internet.  The
port numbers on the UA are local port numbers.  STUN BReq is a STUN
binding request and STUN BResp is a STUN binding response.  Port 5004 is
for a single RTP session but the same algorithm is usable for any and
all UDP ports you need, e.g. additional session ports and RTCP.  The
difference in order in the first and second sequence is intentional, the
implementation doesn't care when the responses show up.

This algorithm lets the UA know what its "visible" IP address and port
is all the time (assuming that rport and STUN are working) and keeps it
the same assuming that the NAT doesn't change it unilaterally (which I
have yet to see BTW).  When signaling occurs, the "visible" IP address
and port are used in the Contact headers for SIP and in the SDP for
offers/answers for RTP.

Its just about as simple as it gets and I know you're going to say that
it doesn't work 100% of the time.  I haven't measured how well its done
in deployments I've done as yet.  I guess I need to do something along
those lines.  The good news is, I haven't had anyone complain about it
so I guess I've been lucky.  So let me have it...  ;)

Thanks,
FM

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Jul 2007 19:55:30 -0700

First I apologize for the cross post - this is a mmusic draft, I  
would appreciate replies on the mmusic list only.

Few things I am looking for here  ....

1) specific reasons why this work is less appropriate for standards  
track than other work that IETF puts on the standards track. Keep in  
mind the first step of standards track is Proposed Standards which  
requires basically no interoperability, then it could move to Draft  
Standard where interoperability is shown and finally Full Standard if  
it turns out to be a good idea.  If you are going to post a reply to  
this point, make sure you have read RFC 2026.

2) I am interested in the specifics of problems that ICE fails to  
solve that the WG has not previous considered. There are lots of  
people that have implemented versions of it and think it is a good  
idea - if people are having some problems with it, I'd love to hear  
about details of things that are wrong. That it has a lot of messages  
in some use cases has been known for a long time. It used to have far  
more messages  - engineering was done to consider what was a  
reasonable amount for call set up times and a new design was done to  
bring the message to a level most people invovled with the design  
felt was reasonable. If there are specific other than these that are  
wrong and not considered in the design, now would be a good time to  
get them on the table.

3) If people think that Skype for example has a simpler solution that  
works better than ICE. Feel free to describe exactly what it is.  
Several people invovled with the ICE design have looked in extreme  
detail at Skype and others and so far none of them have come back  
with what we should do different than ICE.

4) ICE can be used in a mode where it only provided the reflexive  
candidate. People were pretty clear that this was far inferior to the  
modes where there are other candidates. If someone would like to  
provide exactly how hole punching works better than this very limited  
ICE technique, I'd be glad to hear the details. This has certainly  
been an topic that any could have brought up over the last several  
years. If someone has specifics, I suggest they get out a full  
proposal really soon. I am very doubtful that hole punching solution  
is fundamentally different than the type of hole punching ICE does.

5) Some people have suggested that if all NATs were behave complaint,  
then we would not need ICE. I strongly disagree. I think the only  
part of ICE we would not need is the TURN relays which are more or  
less an optional part. Again, specifics on what can be removed are  
welcome.

ICE is far more complicated that anyone wants - the problem is, no  
one has come up with a proposal that looks like it comes anywhere  
close to meeting the requirements and if simpler. The design space  
has been extensively explored by many people. The raw data to  
understand what will work on what NATs have been painfully tested and  
documented in publications such as:

http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf

http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt

https://www.guha.cc/saikat/stunt-results.php?

(Ford used to have a page too but it seems to be gone)

I have a very open mind to considering better ways to do ICE - but I  
need specific suggestions or it is impossible for me to really think  
about if the suggestions represent a better path or not.

I would love to see more open source ICE code (there is lots already)  
- I feel that this is an area where ICE is likely just table stakes  
and owning an proprietary ICE stack will not turn out to be a  
competitive advantage. Having open source implementations where the  
development cost was shared and everyone could get working products  
to market faster would be an advantage to companies. Clearly I expect  
the bulk of ICE implementations to not be open source but I still  
would be keen on doing what I can to contribute to an open source  
version as personally I feel that is in the interest of end users, my  
employer, and the IETF as a SDO.

Cullen <with my individual hat on>

On Jul 18, 2007, at 9:12 AM, Dean Willis wrote:

>> ICE? To me it appears that ICE is almost finished spec. It has  
>> been implemented, used and feedback has been influencing the  
>> protocol. It is definitly one of the better examples of current  
>> IETF work that actually has running code. Sure, the  
>> implementations may not be fully updated yet to the latest draft  
>> version. But I think it is safe to say that ICE works in the  
>> intended core cases. If there are some corner cases where it  
>> fails, that may be. But that is not information we will have until  
> Henry has, I believe, been very consistent in urging the IETF to  
> have more "running code" experience on every specification (not  
> just ICE) than our process requires. He has, IIRC, also advocated  
> changing the process to require running code before publishing an  
> RFC. He's even suggested at times that one should have running code  
> before submitting a protocol draft.
>
> Another point to consider -- I've known Henry to bark at a tree  
> with no squirrel in it occasionally, but most of the time he's  
> pretty reliable, more so than most technology predictors. If he's  
> worried about ICE, it's probably because he's been talking to  
> people who are trying to implement it and they're telling him it is  
> difficult or that they're having performance or reliability issues.  
> I imagine that there are plenty of internal development teams in  
> various companies that are working on this and not necessarily  
> bringing their results back to the IETF. After all, if everybody  
> sees the emperor as fully clothed, they'd be embarrassed to  
> proclaim otherwise. Of course, I wish all of these developers were  
> tied into the IETF, but then I'm sure I don't want to see every ice- 
> implementor's question on the SIP list. That is why we have a sip- 
> implementors mailing list, right?
>
> cases where hole-punching doesn't work, and I think ICE will  
> produce usable results in most of those cases. But that's just my  
> personal opinion from reading the specs. I haven't implemented ICE,  
> and I haven't used anybody else's implementation. Sure, it's  
> complex, but that's because the underlying problem is complex --  
> there are just too many different behaviors out there in "NAT and  
> firewall land". Of course, I could be wrong, too. It's happened  
> before, once or twice ;-). Just how sure are we that we're right  
> about this?
>
> prototypes could go a long way towards reassuring us of the  
> design's utility.
>

---

From: "David Barrett" <[email-masked]>
Date: Thu, 19 Jul 2007 03:15:28 -0700

Hi Cullen, I think you bring up lot of really great and detailed questions.

However, speaking for myself at least, answering those questions doesn't
really address my concern.  All I want to know is:

	Does ICE work, and how well?

What "works" means is entirely open to debate.  I've tossed out "high peer
connectivity" and "low connection setup time" as the most important
criteria, and I've put hard data behind those numbers as a stake in the
ground for comparison, but I'm open to other metrics as well.

But regardless of the metrics, I want somebody who uses it and loves it and
bases their business upon its success to stand up and explain why it's
great.  And I want this person to provide real-world data, sampled on a wide
scale, proving that ICE "works" -- by any definition.

Basically, I want ICE firmly grounded in wide-scale testing and real-world
data, and answering the questions below doesn't bring us any closer to that.
Whether it's level 10 or level 12 doesn't produce new data.  How its
algorithms differ from competing ones doesn't show that they're any better
or worse.  Detailed proposals for change don't shed any light on whether
those changes improve or worsen it, because its current state is completely
unmeasured.

The most powerful thing the IETF can do to standardize the world upon ICE is
prove that it works better than any alternative.  Because until that's
proven, we just need to take it as a matter of faith.

-david

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2007 7:56 PM
> To: SIP; Behave WG; [email-masked]
> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC
> 
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 19 Jul 2007 07:57:36 -0400

On 18-Jul-07, at 22:56 , Frank W. Miller wrote:

<Algorithm details deleted>
> so I guess I've been lucky.  So let me have it...  ;)

This is the original STUN algorithm.
One situation where it fails is the following:

                STUN
               server
                 |
                NAT
                 |
         ------------------
         |                |
        UA1              UA2

If the NAT does not support hairpinning, then your algorithm will not
work.

[http://tools.ietf.org/html/draft-jennings-behave-test-results-04
shows that most NATs today do not support UDP hairpinning, and
http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf reports that most do not
support TCP hairpinning.]

This situation can occur when the two UAs belong to the same company,
or both are in the same hotel, or both use the same service provider
and the service provider has a NAT in front of its entire network, etc.

ICE does to things to solve this problem. First of all, UA1 and UA2  
exchange
their local addresses and ports as well as their STUN-learned addresses.
They then test to see which path works. Second, they also exchange
TURN addresses, which serve as a backup in case everything else fails.

David Barrett's algorithm, if I understand it correctly, would work in
this situation. (As far as I can tell, David's is a simplified version
of ICE).

- Philip

---

From: Evgeniy Khramtsov <[email-masked]>
Date: Thu, 19 Jul 2007 22:34:30 +1000

> I would love to see more open source ICE code (there is lots already)  

Could you point me to the _lots_ of open source ICE code? Is there any 
open source implementation which supports TURN?

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 19 Jul 2007 15:57:19 +0300

> open source implementation which supports TURN?

I doubt this be much relevant, since hole punching does not support TURN or 
anything equivalent either.

-- 
Rémi Denis-Courmont

---

From: Evgeniy Khramtsov <[email-masked]>
Date: Thu, 19 Jul 2007 23:16:42 +1000

>anything equivalent either.

What do you mean? I am not talking about "hole punching". I'm talking 
about ICE. ICE makes use of TURN, so ICE implementations should support 
TURN :) Am I wrong? :)

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 19 Jul 2007 16:52:15 +0300

On Thursday 19 July 2007 16:16:42 ext Evgeniy Khramtsov wrote:
> >I doubt this be much relevant, since hole punching does not support TURN
> > or anything equivalent either.
>

TURN is an *optional* add-on to ICE to support symmetric NATs and other 
worst-cases scenario that hole punching (whether ICE or otherwise) cannot 
solve.

As such, support for TURN only improves the reliability of ICE way beyond what 
pure hole punching does. You can still use ICE without TURN, and get better 
results than what pure RFC3489-based hole punching would.

-- 
Rémi Denis-Courmont

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 19 Jul 2007 08:30:18 -0700

Phil,

You are right again, but as mentioned, concept papers (a true torrent
over many years lately) and discussion lists cannot replace published
measurement tools, measured results and tweaking the approach based on
measurements; measuring the improvements, etc. 

This is the reason why I am not going into debating points about the
merits of ICE, but rather the best approach to make it successful and be
able to prove it.

ICE is not a protocol agreement like SIP, but a technology that faces
the great physical complexity on the net, so the protocol discussion
approach is no replacement for testing and tweaking. This probably
explains why we are in this discussion about ICE in the first place.

By the same token I-D process arguments and consensus are no replacement
either for proof on the net. 

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 8:19 PM
To: Henry Sinnreich
Cc: Magnus Westerlund; [email-masked]; [email-masked]; [email-masked];
Pyda Srisuresh; Frank W. Miller; [email-masked]
Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before
LCfor RFC

Philip

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

---

From: "David Barrett" <[email-masked]>
Date: Thu, 19 Jul 2007 10:44:53 -0700

> this situation. (As far as I can tell, David's is a simplified version

That's correct.  The major differences (so far as I know) between what I'm
doing and what ICE does include:

- Peer's needn't exchange SDP before attempting connection establishment
(rather, the rendezvous server just tells both sides the others' LAN/NAT
addresses and they try to connect immediately). 

- Paths are evaluated in parallel rather than sequentially (ie, I attempt to
contact you direct via the LAN and indirectly via your NAT at the same time,
and then pick the faster of the two)

- There's no support for TURN servers as my application doesn't require them
(though it would be extremely straightforward to add).

- Clients attempt NAT classification as a *purely advisory* function to
support debugging and feed into certain non-critical pairwise optimizations.
(Said another way, even if the classification is totally wrong, it'll still
work.)

- Clients use adaptive keepalives to a STUN server to keep their NAT/FW
"hole" open.  By "adaptive" I mean I use probing to determine highest safe
keepalive frequency of the NAT/FW.  (Incidentally, there's no requirement
that any two clients use the same STUN server, and indeed I intend to move
to enable a "distributed STUN service" using the peers themselves.)

Basically, I do the minimum necessary for my requirements, which I respect
are much easier than SIP's.  However, know that despite my system being much
easier, it has been *extremely difficult and time consuming* to get working,
despite dozens of iterations drawing upon a network of hundreds of thousands
of machines on which to test.  Thus I would suggest that if my solution took
as long as it did, and went through as many variations as it did, the
SIP/ICE implementers should be very wary of hardening anything too early
before it hits the real world.  Because the real world is really, really
strange and unpredictable, I can guarantee you that.

Phillip's asked me to put together a bit more precise overview of the system
I use and I'll try to get to that soon.

-david

---

From: Philip Matthews <[email-masked]>
Date: Thu, 19 Jul 2007 13:51:47 -0400

I agree that it would be very nice to see more published data on
when ICE succeeds (and specifically when it succeeds in finding a  
direct path).
It would also be nice to see more open source implementations.

It used to be that the Routing area would hold a draft in the "almost  
done" state
until they had some implementation experience, and then publish as an  
RFC only
once they had that data. Is this what you are looking for?

- Philip

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 20 Jul 2007 07:48:38 -0700 (PDT)

> punching techniques that I have seen do not;

[suresh] I dont know what you are talking about. AFAIK, Peer reflexive address
is same as the public endpoint assigned to a node behind NAT. How can that be
not part of HOLE-PUNCHING technique? 

> the controller additional flexibility in choosing a path;

[suresh] HOLE-PUNCHING technique is based on communication along a control path
with external rendezvous server(s), which act as the key controller. The 
peering endpoints either make requests to punch holes or receiving requests to
help in hole-punching by a peer.  

> techniques do (e.g., Saikat's TCP work).

[suresh] Hole punchign technique is not complete by itself to setup
connections. It needs a fallback scheme. Port prediction and relays can be
effective fallback to hole punching.

regards,
suresh