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
On 19-Jul-07, at 11:30 , Henry Sinnreich wrote:
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 PROTECTED]
Sent: Wednesday, July 18, 2007 8:19 PM
To: Henry Sinnreich
Cc: Magnus Westerlund; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected];
Pyda Srisuresh; Frank W. Miller; [EMAIL PROTECTED]
Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data
before
LCfor RFC
On 18-Jul-07, at 15:31 , Henry Sinnreich wrote:
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.
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
_______________________________________________
P2PSIP mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/p2psip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
