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

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

_______________________________________________
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: Pyda Srisuresh <[email-masked]>
Date: Thu, 19 Jul 2007 10:38:41 -0700 (PDT)

David,

90% success in connection rate is very impressive. Are you refering to UDP, TCP
or both? As you say, fallback such as relay is essential for 100% connectivity.
One cannot use hole punching without a good fallback scheme.
 
regards,
suresh

--- David Barrett <[email-masked]> wrote:

> > -----Original Message-----
> > From: Melinda Shore [mailto:[email-masked]]
> > 
> > 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.
> 
> 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
> 
>