Re: [pntaw] Real-time media over TCP

Dan Wing <> Mon, 07 October 2013 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C47811E8138 for <>; Mon, 7 Oct 2013 13:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IlM-16CbCc31 for <>; Mon, 7 Oct 2013 13:34:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 870BF11E814C for <>; Mon, 7 Oct 2013 13:34:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6735; q=dns/txt; s=iport; t=1381178066; x=1382387666; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YcPU0yR/HtkNWcFJ/9YTsOIK6193Hfe+9g5h405gKLk=; b=Kzrd2MLt03/SEiNBXHlMnyvCWYHw3R5k5PwaiNR6SL/1McVRnqPml8PF Y+XkoSpuoJwscCifyoXG8qFGmpZcjjh4y35/2Tq1TYIx6ndbRgK/w2EXE +41Sbvrnv3pbU7Z1kvibTQ4ZV4buQewqtjFYF8YnUm3KzT1M1Q6NUckDP Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFANcZU1KrRDoJ/2dsb2JhbABZgwc4rxySV4EiFnSCJQEBAQMBAQEBNy4EAggDBQcECxEEAQEBJwcnHwMBBQgGExuHWQMJBQ27I4xmgjgzBwaDGYEEA4k5imuBdYFogS+LG4U2g0Qc
X-IronPort-AV: E=Sophos;i="4.90,1051,1371081600"; d="scan'208";a="91575410"
Received: from ([]) by with ESMTP; 07 Oct 2013 20:34:25 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r97KYOrV006260; Mon, 7 Oct 2013 20:34:24 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <>
In-Reply-To: <>
Date: Mon, 7 Oct 2013 13:34:23 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <> <> <> <> <00ca01cec387$f881cae0$e98560a0$> <BLU406-EAS274696C3D9DFE505F96B8E393130@phx.gbl> <> <>
To: Michael Tuexen <>
X-Mailer: Apple Mail (2.1510)
Cc: Bernard Aboba <>, Harald Alvestrand <>, "" <>, Parthasarathi R <>
Subject: Re: [pntaw] Real-time media over TCP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Oct 2013 20:34:33 -0000

On Oct 7, 2013, at 1:14 PM, Michael Tuexen <> wrote:

> On Oct 7, 2013, at 10:08 PM, Dan Wing <> wrote:
>> On Oct 7, 2013, at 11:32 AM, Bernard Aboba <> 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?

Yes, start with something that works but is not optimal (SCTP over TCP) and expect/hope that one of the future paths are better:  OS vendors provide native SCTP support and networks support native SCTP, UDP is permitted by networks (allowing SCTP-over-UDP to work without competing CC), or OS vendors support SCTP Minion (which also avoids competing CC).


> Best regards
> Michael
>> -d
>>>> On Oct 7, 2013, at 11:07 AM, "Parthasarathi R" <> 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: [] On Behalf
>>>>> Of Dan Wing
>>>>> Sent: Wednesday, September 04, 2013 1:47 AM
>>>>> To: Harald Alvestrand
>>>>> Cc: Bernard Aboba;
>>>>> Subject: Re: [pntaw] Real-time media over TCP
>>>>> On Sep 3, 2013, at 11:11 AM, Harald Alvestrand <>
>>>>> 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
>>>>> 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 mailing list
>> _______________________________________________
>> pntaw mailing list