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

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

On 2nd thought, since ICE and the "hole punching for p2p" are of
interest for P2PSIP, I though I would share this with the WG. Sorry for
any duplicate messages you may have seen from the other lists.

________________________________

From: Henry Sinnreich 
Sent: Wednesday, July 18, 2007 7:20 AM
To: 'Magnus Westerlund'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: 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]

----------------------------------------------------------------------

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 19 Jul 2007 14:14:21 -0700

My apology for the duplicate postings. 
Having initiated this ample discussion about how to proceed with ICE-17,
it seems the following have emerged:

ICE-17 is an excellent document (bravo authors and contributors) and can
hardly get better at present.

The technical points discussed cannot change this fact either way.

Ironically, the defense of ICE-17 on procedural grounds makes even less
sense, since the culprit is not ICE-17, but the fact that present IETF
procedures do not make a clear enough distinction that everyone can
understand between I-D categories, such as:

* Concept memos; see the torrent in the P2PSIP WG
* Protocol standard agreements, such as for SIP
* Technology solutions such as ICE-17 or hole punching for NAT traversal
* I-Ds to support a business model (excuse me; I will not go there...)

Sorry to repeat: Process and consensus in meetings have nothing to do
with how good a technology may be. Only measurements and proof will do.

How does the IETF support the proof for a technology? (Yes, I have seen
all those quotes). Please remember that proving a technology also costs
money.
This is the reason why I trust more technologies coming out of funded
R&D, especially from University research. Vendors of technology may be
less likely to share such information.

Question: Is a standards organization the best place to develop and
promote new technology such as for NAT traversal? (all those p2p
companies and Skype did not think so...) Also, be prepared, SBC
traversal may come next.

In conclusion, there is nothing wrong with the ICE-17 paper IMHO, but
rather the IETF processes are either not satisfactory or not well
understood by folks like me who avoid reading process documents longer
than one web page :-) 

I have taken therefore the liberty to copy <[email-masked]> as Adam Roach
has suggested.

Thanks, 
Henry Sinnreich