Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01

[Simon Perreault <[e-mail]>]

Le 2013-11-13 13:44, Harald Alvestrand a écrit :
>> All this relies on the possibility that a TCP peer-to-peer connection
>> could be successfully established where a UDP one couldn't. IMHO this
>> is very unlikely to happen in practice. So unlikely in fact that any
>> possible gain over just falling back on a TURN relay wouldn't be worth
>> the additional implementation cost.
>
> Simon, do you have any numbers on that - how many calls will be going to
> servers on the Internet versus how many calls will be going peer-to-peer?

Not sure what you mean.

> The argument being given only applies to the client-to-gateway usecase

My point only applied to peer-to-peer connections, not peer-to-server. 
If we're discussing peer-to-server, then I wonder why we're discussing 
that at all.

> (or to naked destination clients that are not behind a NAT, which
> hopefully will become common once IPv6 gets deployed, but aren't common
> now).

If we eliminate NAT, then we're left with firewalls. To benefit from 
ICE-TCP (i.e. ICE-TCP successfully establishing a peer-to-peer TCP 
connection instead of ICE-UDP falling back on TURN-over-TCP), you would 
need both peers to be behind firewalls that block inbound UDP (through 
hole punching or otherwise) but allow inbound TCP (through simultaneous 
open or otherwise). My personal experience is that this kind of firewall 
configuration would be very rare. Now, take that probability and square 
it since it needs to apply to both peers. You get something very very rare.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca