[BEHAVE] RE: ICE performance

> I ask because ICE does a 4-way handshake (of sorts), which
> is its NAT penetration.

This is a welcome discussion and points to the fact that we have no
published facts on ICE. Faith is a poor replacement for measurements.

ICE differs from say SIP in that it is far more than a protocol
agreement. ICE is a technology that has to deal with countless NAT
implementations and scenarios, with physical reality on the net vs.
getting an agreement on some protocol header or data format.

Excellent role models in BEHAVE where an I-D is based on facing and
measuring reality on the net are:

1. "NAT Classification Test Results"
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-jennings-behave-
test-results-04.txt  

and 

2. "Application Design Guidelines for Traversal through Network Address
Translators" 
<
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ford-behave-app-
05.txt> which is based on test tools and real testing on the net, as
reported in 

"Peer-to-Peer Communication Across Network Address Translators" 
http://www.brynosaurus.com/pub/net/p2pnat/ 

This is BTW the reason why I have argued <draft-ford-behave-app-05.txt>
to be a WG item.

Dan: Is there a way to squeeze it in?

To conclude; this discussion would not have taken place if we would have
had deployment results for ICE.

Thanks, Henry

-----Original Message-----
From: Dan Wing [mailto:dwing@cisco.com] 
Sent: Tuesday, July 17, 2007 7:33 AM
To: 'David Barrett'; Henry Sinnreich; behave@ietf.org
Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com
Subject: ICE performance 

(Changing subject line) 

> -----Original Message-----
> From: David Barrett [mailto:dbarrett@quinthar.com] 
> Sent: Tuesday, July 17, 2007 1:04 AM
> To: 'Dan Wing'; 'Henry Sinnreich'; behave@ietf.org
> Cc: henrys@adobe.com; baford@mit.edu; dank@kegel.com
> Subject: RE: [BEHAVE] Re: removing application milestone
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@cisco.com]
> > 
> > What's the latency if there are no NATs involved whatsoever?  Your
> > numbers indicate hundreds of milliseconds for every NAT scenario,
> > even for the kinds of NATs that allow connections from any IP
> > address.  NATs do not, on their own accord, add hundreds of
> > milliseconds of delay.  If they did, DNS queries would take too
> > long and people would complain that "the Internet" is slow (web
> > pages with lots of embedded objects on different servers).
> 
> I'm not sure I follow.  The times I gave were the elapsed ms 
> it took to establish the connection from start to finish.  So 
> it'd be roughly:
> 
> (The RTT time between A and the RZ server) +
> (The processing time inside the RZ) +
> (The RTT time between A and B) +
> (The three-way handshake and NAT penetration time)

Without any NATs, that last event (NAT penetration time) doesn't occur.
I'm
curious what times you have without any NATs.  This would allow learning
the
NAT penetration time for the non-ICE NAT traversal technique you're
using.

> Thus in general, it takes a second or less to establish the 
> connection. 

By 'the connection', I believe you're referring to that last step (3 way
handshake and NAT penetration time)?

Is the 3-way handshake TCP, or is that your NAT penetration code doing a
3-way handshake?  I ask because ICE does a 4-way handshake (of sorts),
which
is its NAT penetration.

> However, once that connection has been established, 
> there is no additional latency introduced by the system: packets 
> flow between A and B directly at whatever latency is introduced 
> by the intermediate networks.

Right.

> Does this answer your question?  How long does it typically 
> take ICE to establish a connection, including the "triggered 
> check" optimization? 

I don't know.  I don't have direct experience with ICE on 
the Internet.  I haven't seen any published information with
those numbers.  You may have noticed Henry asking for such
information on MMUSIC and on SIP, 
http://www1.ietf.org/mail-archive/web/mmusic/current/msg05997.html

> Is it also subsecond on average between any two points on the globe?

Most of the time, yes.

ICE always establishes a direct, peer-to-peer connection when it can.  
In some cases [such as two endpoints behind 'symmetric' NATs (RFC3489
terminology) or non-Endpoint-Independent Mapping NATs (RFC4787 
terminology)] there is no reliable technique to get a direct peer-to-
peer connection.  The unreliable technique to establish a direct 
peer-to-peer connection in that situation is to guess the port number 
assigned by the remote NAT.

-d

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave