Re: [pntaw] Real-time media over TCP

[Michael Tuexen <[e-mail]>]

On Oct 7, 2013, at 10:08 PM, Dan Wing <[e-mail]> wrote:

> 
> 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.
This would either require changing the TCP stack in the kernel or using a
userland TCP stack without CC, which would require using a raw socket for
sending, for receiving some other strategy, both would require root privileges...
Or am I missing something?

Best regards
Michael
> 
> -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
> 
> _______________________________________________
> pntaw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pntaw
>