RE: [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

> > I think there is still some value in the NAT-type tests 
> even with use
> > of ICE. Positive assertions about traversable NATs may be brittle, I
> > agree. Negative assertions about hard-to-traverse NATs are 
> quite safe
> > and can eliminiate unnecessary tries. Particularly, if you know you
> > are behind a symmetric NAT you can safely eliminate STUN 
> address from
> > your offer.
> 
> I disgaree.
> 
> Cullen's results show that we are seeing hybrid NATs whose 
> type depends 
> on whether the random port selected by the client is 
> allocated already 
> or not. In such a case, if the client picks an already-allocated port 
> during the detection phase, it may detect the nat as 
> symmetric, when it 
> fact it might be port restricted in other cases.
> 
> With ICE, if you happen to be unlucky during a stun allocation, turn 
> would get used. If you're lucky, and you get a port-restricted port, 
> then the relay would not be used.

Cullen's results are also telling us that there are more chances for clients
to come across a symmetric case than we can see with current STUN 
test.

Since ICE has ability to traverse p2p UDP connection through a 
symmetric NAT if the other end does not have or does has a full-cone 
NAT or restricted, the results seem to motivate us more to go towards 
ICE.

Although ICE does this job without a knowledge of NAT types, I feel
it is good to have a standardized protocol to discover the types of 
NAT. In fact, we would have not been able to come to this point 
without the knowledge of NAT types and actual discovery tests, but in 
this case, clarification for applicability limitation of the NAT type 
discovery process and their reasons should be added to the document
I suppose.


Yutaka