Re: [pntaw] Real-time media over TCP

[Harald Alvestrand <[e-mail]>]

On 09/03/2013 07:25 PM, Dan Wing wrote:
>> 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.

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