Re: [pntaw] Real-time media over TCP
Dan Wing <dwing@cisco.com> Mon, 07 October 2013 20:34 UTC
Return-Path: <dwing@cisco.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C47811E8138 for <pntaw@ietfa.amsl.com>; Mon, 7 Oct 2013 13:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlM-16CbCc31 for <pntaw@ietfa.amsl.com>; Mon, 7 Oct 2013 13:34:29 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 870BF11E814C for <pntaw@ietf.org>; Mon, 7 Oct 2013 13:34:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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 mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Oct 2013 20:34:25 +0000
Received: from sjc-vpn5-197.cisco.com (sjc-vpn5-197.cisco.com [10.21.88.197]) by mtv-core-4.cisco.com (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 <dwing@cisco.com>
In-Reply-To: <28C05866-180F-41B2-8466-502F57FF1DF1@lurchi.franken.de>
Date: Mon, 07 Oct 2013 13:34:23 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <AFD4485E-B51C-4ADF-A89D-FDF50AB96894@cisco.com>
References: <CAGTXFp92jSzQz05uHngzscz88n=fT_JPbEvQRxgeUUqPVRQUyQ@mail.gmail.com> <52244DD7.1020900@alvestrand.no> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <522590EE.7070508@alvestrand.no> <C632A223-A55A-47F4-B083-9BDC447DA959@cisco.com> <52262657.3080208@alvestrand.no> <A2C315DB-1882-4BD1-A8C0-E8AF7DEA48F4@cisco.com> <00ca01cec387$f881cae0$e98560a0$@co.in> <BLU406-EAS274696C3D9DFE505F96B8E393130@phx.gbl> <2924C1EA-613D-4B05-BD24-4CFD1411386E@cisco.com> <28C05866-180F-41B2-8466-502F57FF1DF1@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.1510)
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, Harald Alvestrand <harald@alvestrand.no>, "pntaw@ietf.org" <pntaw@ietf.org>, Parthasarathi R <partha@parthasarathi.co.in>
Subject: Re: [pntaw] Real-time media over TCP
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2013 20:34:33 -0000
On Oct 7, 2013, at 1:14 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote: > On Oct 7, 2013, at 10:08 PM, Dan Wing <dwing@cisco.com> wrote: > >> >> On Oct 7, 2013, at 11:32 AM, Bernard Aboba <bernard_aboba@hotmail.com> 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). -d > > Best regards > Michael >> >> -d >> >> >> >> >>> >>>> 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 >> >
- [pntaw] Real-time media over TCP Victor Pascual Avila
- Re: [pntaw] Real-time media over TCP Harald Alvestrand
- Re: [pntaw] Real-time media over TCP Bernard Aboba
- Re: [pntaw] Real-time media over TCP Bernard Aboba
- Re: [pntaw] Real-time media over TCP Harald Alvestrand
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Harald Alvestrand
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Parthasarathi R
- Re: [pntaw] Real-time media over TCP Bernard Aboba
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Michael Tuexen
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Harald Alvestrand
- Re: [pntaw] Real-time media over TCP Harald Alvestrand
- Re: [pntaw] Real-time media over TCP Michael Tuexen
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Parthasarathi R
- Re: [pntaw] Real-time media over TCP Simon Perreault
- Re: [pntaw] Real-time media over TCP Paul Kyzivat
- Re: [pntaw] Real-time media over TCP Parthasarathi R
- Re: [pntaw] Real-time media over TCP Markus.Isomaki
- Re: [pntaw] Real-time media over TCP Markus.Isomaki
- Re: [pntaw] Real-time media over TCP Paul Kyzivat
- Re: [pntaw] Real-time media over TCP Chenxin (Xin)
- Re: [pntaw] Real-time media over TCP Parthasarathi R
- Re: [pntaw] Real-time media over TCP Chenxin (Xin)
- Re: [pntaw] Real-time media over TCP Markus.Isomaki
- Re: [pntaw] Real-time media over TCP Hutton, Andrew
- Re: [pntaw] Real-time media over TCP Bernard Aboba
- Re: [pntaw] Real-time media over TCP Sergio Garcia Murillo
- Re: [pntaw] Real-time media over TCP Parthasarathi R
- Re: [pntaw] Real-time media over TCP Parthasarathi R
- Re: [pntaw] Real-time media over TCP Markus.Isomaki
- Re: [pntaw] Real-time media over TCP Paul Kyzivat
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Ted Hardie
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Tirumaleswar Reddy (tireddy)
- Re: [pntaw] Real-time media over TCP Dan Wing
- Re: [pntaw] Real-time media over TCP Harald Alvestrand
- Re: [pntaw] Real-time media over TCP Parthasarathi R
- Re: [pntaw] Real-time media over TCP Justin Uberti
- Re: [pntaw] Real-time media over TCP Markus.Isomaki
- Re: [pntaw] Real-time media over TCP Justin Uberti
- Re: [pntaw] Real-time media over TCP Parthasarathi R
- Re: [pntaw] Real-time media over TCP Harald Alvestrand
- Re: [pntaw] Real-time media over TCP Ravindran, Parthasarathi (NSN - IN/Bangalore)
- Re: [pntaw] Real-time media over TCP Harald Alvestrand
- Re: [pntaw] Real-time media over TCP Ravindran, Parthasarathi (NSN - IN/Bangalore)
- Re: [pntaw] Real-time media over TCP Markus.Isomaki
- Re: [pntaw] Real-time media over TCP Justin Uberti