Re: [P2PSIP] Choice of STUN peer or TURN peer

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com] 
> Sent: Saturday, February 02, 2008 00:32
> To: Audet, Francois (SC100:3055); 'Cullen Jennings'; 'Bruce Lowekamp'
> Cc: 'P2PSIP Mailing List'
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> Reports indicate that roughly 25% of NATs would block such 
> incoming packets. 
> 
> This means that a TURN client, trying to use a random TURN 
> server's transport address that is published into the p2p 
> overlay, would get a 75% success rate.
> If the TURN client tried two TURN servers it would get a 
> success rate of 87.5%, and so on, up to trying 11 TURN 
> servers to get a success rate of 99.9%.
> 
> 
> Those success rates include no calculations about TURN 
> servers that have crashed, had their p2p-TURN application 
> terminated, had their NATs crash or otherwise lose state, etc.

And?

That doesn't seem so bad to me. When a peers goes live (attempts to connect), it
would then try to find a working STUN/TURN server. After a few attempts, it is
likely to find a working one. A success of 87.5% after 2 tries seems very good to me.

Also, the alternative is that the servers themselves do a lot of self-assestment which
takes some time.

I'm also thinking that if somehow we could make the process of being a STUN/TURN server
and discovering others/joining the overlap mandatory, then we wouldn't have the problem
that everybody would opt out of being used as a STUN or TURN server.

(By mandatory, I don't mean "the spec says it's mandatory: I mean the procedures would be
intertwined enough that it would not be possible, or at least very difficult, to
disable the STUN and TURN server).

Just thinking out loud...
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
http://www.ietf.org/mailman/listinfo/p2psip