Re: [pntaw] Real-time media over TCP

Hi all,

RTP over TCP is unavoidable in case of RTCWeb media traffic has to traverse
through UDP blocking firewalls. TCP candidates with ICE (RFC 6544) may fail
due to the current OS implementation wherein TCP simultaneous Open will not
work. 

I have concern w.r.t TURN server as it introduces one extra network element
for RTCWeb session establishment. The current argument favoring for TURN
server is that RTP over TCP is required only till TURN server whereas the
media traffic between TURN server and the destination is UDP. In couple of
WebRTC deployment in Service provider network and Enterprise network, TURN
server will exist near to the destination and the WebRTC media traffic in
the internet is "RTP over TCP". I guess that Victor scenario falls under the
same category. In these deployment, RTP over TCP has advantage over TURN
over TCP as the extra element shall be avoided. 

Also, SCTP over DTLS over UDP will not work in case of RTCWeb media traffic
has to traverse through UDP blocking firewalls. So, there is a need of SCTP
over DTLS over TCP or multipath TCP kind of transport to meet this
requirement which needs separate discussion. 

Thanks
Partha

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> Of Dan Wing
> Sent: Wednesday, September 04, 2013 1:47 AM
> To: Harald Alvestrand
> Cc: Bernard Aboba; pntaw@ietf.org
> Subject: Re: [pntaw] Real-time media over TCP
> 
> 
> On Sep 3, 2013, at 11:11 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> 
> > 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.
> 
> 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.
> 
> > 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.pd
> f.  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.
> 
> -d
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw