Re: [pntaw] Real-time media over TCP

[Dan Wing <[e-mail]>]

On Oct 7, 2013, at 11:32 AM, Bernard Aboba <[e-mail]> wrote:

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

And, even if a full SCTP stack is run over a full TCP stack, that will work but I agree won't work well.  But working is better than not working in situations where UDP is blocked.

To work well, we might look at SCTP Minion (draft-iyengar-minion-concept, which disables TCP's congestion control in lieu of SCTP's congestion control) is one answer to those conflicting congestion controls.

-d




> 
>> On Oct 7, 2013, at 11:07 AM, "Parthasarathi R" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of Dan Wing
>>> Sent: Wednesday, September 04, 2013 1:47 AM
>>> To: Harald Alvestrand
>>> Cc: Bernard Aboba; [e-mail]
>>> Subject: Re: [pntaw] Real-time media over TCP
>>> 
>>> 
>>> On Sep 3, 2013, at 11:11 AM, Harald Alvestrand <[e-mail]>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pntaw
>> 
>> _______________________________________________
>> pntaw mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pntaw