Re: [pntaw] Real-time media over TCP

[Dan Wing <[e-mail]>]

On Sep 3, 2013, at 12:34 AM, Harald Alvestrand <[e-mail]> wrote:

> On 09/02/2013 08:17 PM, Bernard Aboba wrote:
>> If the issue is firewall restrictions on UDP, then the data channel is not likely to be a workable option. The question for me is how far we need to go to solve this (e.g. RFC 6062? 6544?). The scenario where both sides are behind UDP blocking firewalls is not common, but it does occur.
> 
> I was thinking more about "what can you do to avoid TCP's bad behaviour for real-time traffic, and still be in a connection-oriented, congestion-controlled environment".

DCCP is connection-oriented, message-oriented and unreliable (thus like UDP) with congestion control.  It should be pretty ideal for the list of constraints in your email.  DCCP can be tunneled over UDP if the network path or OS don't handle DCCP, see RFC6773.

And of course there is RMCAT, which is attempting to solely add congestion control without the other stuff that was added by DCCP.

> Multiple TCP connections seems like a suboptimal design, given the existence of other solutions like Minion or SCTP.

Sure.  But those technologies weren't on the table when Victor did interactive audio/video over TCP, I'm sure.  Much like they weren't on the table when HTTP started doing multiple TCP connections back in the early days of Netscape.

> 
> If both sides have TURN over TCP (or TURN over HTTP) enabled, and their respective TURN servers can talk UDP to each other, communication will occur, I think. I don't think we need to add TCP candidates for the TURN case in order to bypass firewalls.
> 
> We might want to do so for the benefit of the pure peer-to-peer case, but I'm not sure it's a case that's important enough to make 6062 (TURN TCP allocations) or 6544 (ICE TCP allocations, no TURN server) into MUSTs for RTCWEB.

I agree.  Additionally, before anyone ventures too far down that path it would be useful to understand how well the expected RTCWeb endpoints could do peer-to-peer TCP connections.  Reliable peer-to-peer TCP needs TCP simultaneous open needs to work well on both hosts, per the research by Saikat Guha and Paul Francis http://conferences.sigcomm.org/imc/2005/papers/imc05efiles/guha/guha.pdf.  In that research, they found Windows XP SP1 doesn't do simultaneous open well, but Windows XP with SP2 and SP3 and Linux worked okay.  I have not seen similar research for Android, OS X, or Windows 7 or Windows 8.

-d



> 
>> 
>> On Sep 2, 2013, at 1:37 AM, "Harald Alvestrand" <[e-mail]> wrote:
>> 
>>> On 08/30/2013 12:12 PM, Victor Pascual Avila wrote:
>>>> Hi,
>>>> 
>>>> Real-time media over TCP has some inherent challenges -- is this
>>>> something we're planning to discuss here? We did RTP over TCP (+ HTTP
>>>> CONNECT) in the past and ended up using multiple connections along
>>>> with application-layer redundancy. I'm wondering whether we'll be able
>>>> to do the same when moving to WebRTC
>>> If you really want to go there, I suggest you take a good hard look at either SCTP or TCP Minion (draft-iyengar-minion-concept-01.txt).
>>> 
>>> The RTCWeb stack already uses SCTP over DTLS over UDP.
>>> 
>>> In either case, I don't think performance of RTP over reliable transport is a firewall-related issue.
>>> 
>>> _______________________________________________
>>> pntaw mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pntaw
> 
> _______________________________________________
> pntaw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pntaw