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

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:

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

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

> 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
>
> --- "Frank W. Miller" <[email-masked]> wrote:
>
>>
>>
>> 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,
>>
>>
>>
>> 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 Sinnreich skrev:
>>
>>> 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.
>>
>>
>>
>> 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]
>>
>> ---------------------------------------------------------------------

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

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

---

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: 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: "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

---

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

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

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