Re: [pntaw] Real-time media over TCP

Hi Bernard/Harald,

I understand that two WebRTC endpoint are behind firewall scenario wherein
TURN server is unavoidable. Most of the SP & Enterprise deployment wherein
one of the endpoint is not surely going to be behind UDP blocking Firewall,
mandating TURN server as a mechanism is overkill. As ICE is mandated in
WebRTC, supporting ICE-TCP should not be such a complex activity.

Thanks
Partha

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> Of Bernard Aboba
> Sent: Tuesday, October 08, 2013 12:03 AM
> To: Parthasarathi R
> Cc: Harald Alvestrand; pntaw@ietf.org; Dan Wing
> Subject: Re: [pntaw] Real-time media over TCP
> 
> As you point out, in most cases ICE-TCP will not avoid use of TURN, so
> we are only talking about a modest efficiency gain for ICE-TCP and RTP
> over TCP, but a substantial increase in complexity.
> 
> Running SCTP over TCP is undesirable because the congestion control in
> SCTP and TCP will interact poorly with each other.
> 
> > On Oct 7, 2013, at 11:07 AM, "Parthasarathi R"
> <partha@parthasarathi.co.in> wrote:
> >
> > 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
> >
> > _______________________________________________
> > pntaw mailing list
> > pntaw@ietf.org
> > https://www.ietf.org/mailman/listinfo/pntaw
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw