Subject: RE: [BEHAVE] Re: removing application milestone

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jul 2007 14:05:31 -0700

> To be clear, I'm not using SIP (or ICE, or standard STUN). 

Alright.  Several of ICE's features are designed to allow ICE
to complete quickly (most notably ICE's "triggered checks").
 
> So, I don't have the SDP exchange step -- can you remind 
> me why that is necessary?

For UDP hole-punching to work, both sides need to indicate their
IP address and UDP port to the other, via a rendezvous server of
some sort.

> The connection-establishment protocol in my architecture is:
> 
> 0) Clients centrally register their addresses on startup

Ok, so that's your rendezvous server.

> ...
> 1) Client A asks the server how to contact B
> 2) The server returns B's address to A
> 3) Simultaneously, the server instructs B to connect to A
> 4) A and B connect to each other at the same time over all routes
> 5) The connection is established once a single route is identified
> 6) If a faster route is identified, it switches to that
> 
> I don't have a detailed breakdown of the latencies of each 
> step (though that
> would be interesting).

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).

-d

> -david
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[email-masked]]
> > Sent: Monday, July 16, 2007 12:05 PM
> > To: 'David Barrett'; 'Henry Sinnreich'; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: [BEHAVE] Re: removing application milestone
> > 
> > For several of those NAT types, the SDP answer needs to be 
> received before
> > the UDP hole-punching is successful.  It's important to 
> also know the
> > (SIP?)
> > signaling delay through your rendezvous servers (SIP 
> prox(y|ies)), between
> > the two RTP peers?  For example, if it takes 250ms for the 
> SDP offer to
> > get
> > to the called party, and another 250ms for their answer to 
> get back there
> > is
> > built-in overhead of 500ms due to the signaling system -- 
> ignoring all the
> > STUN candidate gathering and ignoring all of the ICE 
> connectivity checks.
> > 
> > -d
> > 
> > > -----Original Message-----
> > > From: David Barrett [mailto:[email-masked]]
> > > Sent: Monday, July 16, 2007 11:44 AM
> > > To: 'Henry Sinnreich'; [email-masked]
> > > Cc: [email-masked]; [email-masked]; 'Dan Wing'; [email-masked]
> > > Subject: RE: [BEHAVE] Re: removing application milestone
> > >
> > > > -----Original Message-----
> > > > From: Henry Sinnreich [mailto:[email-masked]]
> > > > Subject: RE: [BEHAVE] Re: removing application milestone
> > > >
> > > > Given that ICE has now gained the status of a creed and 
> maybe I have
> > > > missed it: Are there any published results on the
> > > effectiveness of ICE,
> > > > such as % of success in various NAT scenarios and call
> > > setup delay when
> > > > used with SIP?
> > > > I have seen one private report and it does not look that great.
> > >
> > > Incidentally, I'm dealing with measuring peer connectivity of
> > > my own system
> > > (non-ICE), and here are some of the results for various NAT types:
> > >
> > > Type        Count       Connectivity Open Time
> > > Fullcone    150 (9%)    92%          1056ms
> > > Fullstatic  397 (25%)   94%          867ms
> > > Fw          68  (4%)    2%           374ms
> > > Rstrcone    598 (37%)   89%          706ms
> > > Rstrstatic  82 ( 5%)    91%          769ms
> > > symmetric	293 (18%)   94%          906ms
> > >
> > > This is read as "598 tested clients had a restricted cone NAT
> > > (making up 37%
> > > of all clients tested), with an average peer connectivity
> > > success rate of
> > > 89%".  ("FullStatic" and "Rstrstatic" means a non-NAT'd
> > > client with endpoint
> > > independent/dependent filtering, respectively; "Fw" means a
> > > client that
> > > failed our STUN operation and thus might just have UDP
> > > blocked altogether;
> > > "Open Time" is the time it took to establish the 
> connection and begin
> > > sending actual connection data.)
> > >
> > >            fullcone fullstatic fw      rstrcone 
> rstrstatic symmetric
> > > fullcone   98%      96%        0%      96%      94%        98%
> > > fullstatic 97%      97%        5%      97%      90%        98%
> > > fw         0%       5%         0%      0%       0%         0%
> > > rstrcone   96%      97%        0%      16%      66%        27%
> > > rstrstatic 94%      92%        0%      66%      100%
> > > symmetric  98%      98%        0%      12%      100%
> > >
> > > Here are the pairwise peer connectivities.  As you can see,
> > > this is a pretty
> > > small test (only maybe 1000 total clients), an thus not 
> all pairwise
> > > scenarios got tested (ie, no rstrstatic:symmetric or
> > > symmetric:symmetric
> > > tests were attempted).
> > >
> > > Thus I wouldn't put too much faith in those numbers
> > > (especially anything
> > > claiming 100%) until I have numbers on a broader scale.  For
> > > some reason I'm
> > > seeing peer connectivity problems at larger scales (average peer
> > > connectivity across the board is 90% in the above case, but
> > > drops to 40%
> > > when tested on 10x the clients), and I'm still ironing 
> them out (there
> > > appears to be a problem in my test infrastructure).
> > >
> > > Basically, I'd love to see some results on ICE in the 
> above format, as
> > > that'll let me do an apples-to-apples comparison of it 
> versus mine.
> > >
> > > -david

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

---

From: "David Barrett" <[email-masked]>
Date: Tue, 17 Jul 2007 01:03:32 -0700

> 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)

Thus in general, it takes a second or less to establish the connection.
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.

Does this answer your question?  How long does it typically take ICE to
establish a connection, including the "triggered check" optimization?  Is it
also subsecond on average between any two points on the globe?

-david