Subject: Re: [pntaw] Real-time media over TCP

From: Harald Alvestrand <[email-masked]>
Date: Mon, 02 Sep 2013 10:35:35 +0200

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.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Sep 2013 11:06:20 -0700

Can you describe the usage scenario? Is this about media traversal of highly restrictive firewalls? (E.g. HTTP-only)? 

On Aug 30, 2013, at 3:12 AM, "Victor Pascual Avila" <[email-masked]> wrote:

> Thanks,
> -Victor
> _______________________________________________
> pntaw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pntaw

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Sep 2013 11:17:10 -0700

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.

On Sep 2, 2013, at 1:37 AM, "Harald Alvestrand" <[email-masked]> wrote:

> 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).
> 
> In either case, I don't think performance of RTP over reliable transport is a firewall-related issue.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Sep 2013 09:34:06 +0200

> 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 sce…

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". Multiple TCP connections seems like 
a suboptimal design, given the existence of other solutions like Minion 
or SCTP.

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.

---

From: Dan Wing <[email-masked]>
Date: Tue, 3 Sep 2013 10:25:15 -0700

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

> 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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Sep 2013 20:11:35 +0200

> 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…

Victor didn't provide a date, so I was thinking "recently" - SCTP is 10 
years old at this point.
Minion is newer than that, of course.
> 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-t…
Indeed; that article seemed to indicate that the brand of NAT you bought 
was a decisive factor - it would be interesting to see if the state of 
the art has become more or less symmetric-TCP hostile in the intervening 
8 years.

---

From: Dan Wing <[email-masked]>
Date: Tue, 3 Sep 2013 13:17:05 -0700

On Sep 3, 2013, at 11:11 AM, Harald Alvestrand <[email-masked]> wrote:

> Victor didn't provide a date, so I was thinking "recently" - SCTP is 10 years old at this point.

SCTP has been around a long time as a protocol but for a variety of reasons has seen no deployment on the Internet to date, including no availability in the mainstream OSs which is everyone's interest.  SCTP-over-UDP was only recently defined and its user-mode release was only 12 or 18 months ago or so.

> Indeed; that article seemed to indicate that the brand of NAT you bought was a decisive factor - it would be interesting to see if the state of the art has become more or less symmetric-TCP hostile in the intervening 8 years.

-d