[rtcweb] Usefulness of ICE-TCP (Was: Comments on draft-ietf-rtcweb-transports-01)

[<[e-mail]>]

Hi,

See below. 

Harald Alvestrand wrote:
> 
> On 11/13/2013 07:57 PM, Simon Perreault wrote:
> > 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.
> 
> Because we agreed to include server-based systems in section 3.4 of the use
> cases and requirements" document?
> 
> I think we have WG consensus that client-to-server based use cases, while
> less important than browser-to-browser use cases, are still important.
> 

Right. Some amount of WebRTC endpoints will definitely be gateways or central entities such as conference servers. I have no idea what portion of sessions would be like that, but I don't it will an insignificant amount since there is a lot of interest to gateway WebRTC to various "legacy" VoIP and video conferencing systems.  So I think those are important use cases. 

Typically gateways and conf server endpoints would be reachable by TCP. The question is thus how often a  "normal" (browser or mobile app) endpoint would be in a network where UDP is blocked but direct outgoing TCP connections are allowed. In that case ICE-TCP would be optimal way for that endpoint to connect with a gateway/server endpoint. TURN over TCP would solve the same case but is less optimal.

So unless people have data that shows that "UDP blocked but direct TCP allowed" is in itself a very rare setup (this is a question, I don't know that either), I think ICE-TCP is definitely worthwhile for a WebRTC endpoint to support. 

TURN (over TCP) will still be needed in many cases involving two "normal" endpoints, and there I agree ICE-TCP has little success. 

Regards,
	Markus