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

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 15 Jul 2007 18:07:40 -0700

Dan Wing wrote:
> 
> At the BEHAVE meeting in Prague there was strong consensus to remove 
> the milestone: "Submit informational that discusses current NAT 
> traversal techniques used by applications" from our charter, and to
not 
> adopt draft-ford-behave-app to meet that milestone.

I must strongly disagree with this proposal for several reasons, besides
the fact that majority consensus in a meeting has nothing to do with
getting it right.

The I-D
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-behave-p2p-
state-03.txt has the outstanding value compared to most other proposals,
such as the over abundant literature for ICE:

* A study based on real networks and the Internet,
* The authors have created a tool for testing NAT traversal,
* Many contributors have used the tool and reported results,
* The results are published, see
http://pdos.csail.mit.edu/papers/p2pnat.pdf 

This outstanding work is not only a model for the BEHAVE WG but also for
most other IETF WGs, where concept I-D predominate unfortunately over
proposals backed up by published research, running code and published
performance.

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.

At any rate, <draft-ietf-behave-p2p-state-03.txt> must be the top BEHAVE
WG item. Continuing this work should include identifying and measuring
NAT types used by ISPs and also the multi-homed ISP network scenario.
Updated test results such as in
http://pdos.csail.mit.edu/papers/p2pnat.pdf would also be welcome.

Thanks, Henry

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

---

From: "David Barrett" <[email-masked]>
Date: Mon, 16 Jul 2007 11:44:11 -0700

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Subject: RE: [BEHAVE] Re: removing application milestone
> 

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