Re: [pntaw] Real-time media over TCP

Justin Uberti <juberti@google.com> Thu, 14 November 2013 23:00 UTC

Return-Path: <juberti@google.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 36ABA21E8064 for <pntaw@ietfa.amsl.com>; Thu, 14 Nov 2013 15:00:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.786
X-Spam-Level:
X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 6IAue8mCI7-n for <pntaw@ietfa.amsl.com>; Thu, 14 Nov 2013 15:00:47 -0800 (PST)
Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id B079711E8112 for <pntaw@ietf.org>; Thu, 14 Nov 2013 15:00:46 -0800 (PST)
Received: by mail-vb0-f49.google.com with SMTP id o19so2198953vbm.22 for <pntaw@ietf.org>; Thu, 14 Nov 2013 15:00:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BEr9tRd6LCl/7gND7CVywUVl263fMG7s7nD9sPoXTNM=; b=RNRxbv49XgPu7TykpTxDzRxD/RZZO4Kq81ZeFdj9m8XgJ781AQEzgFWnZ57UoV1j1u C/4tAPtBZdBlCnx9EqqSc7ecl5kS2N7V11FZBYgn/YmJcqFTVnfw34xa4iZmyA8dVk0S ZHupTIT3+SSeCldgf+HlinodJD4a7qokd+1J8Oais4ynW6Ptb27Rip7wR7aO90mb71p4 s3HLfdoD5FhwDbQyoG04ptCW1UKoFgzb7VzyVDhCo34F0hpnrzBNiVZEJ8TM2IJW3C74 6GkB1lx7SIEnkpNYnb29Wh6P4mvjdczvrnSvnTcdixX6jmRBqJC1oHGeB9cBCsl5Y6TV 5rYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BEr9tRd6LCl/7gND7CVywUVl263fMG7s7nD9sPoXTNM=; b=eHXkSyDwuJAZWJP2IP6fe0m1jYw3PINMdxJO2tSItafk7K+g8oM/pkpYWTzmdkxvTF vLakQSsTUVMmC5aAo10Jj6BzOv1RAC+WRLAdurQO7NqINizl0JyE3B+Xcc0mT8aEH4gM t6v8mbp1Q2jS3YWp51xmPGkIHhvDpbm+O595ruBJmqH67MoAIGmwAZSXI1Yv2s40mvKC r/8LoCeHuLyQE31xq9OQdo/UXfQBOSjYipyfXFgrbB3MzY7WnU1e75o7gAFCUacLJy+1 dK1nRL5t+OMFOdNDxdcWnR0Q8HOMeT7YsCNFP9dT5yf51Wn77K/2dOPTS38fPPZ+jeZE FoNA==
X-Gm-Message-State: ALoCoQkVR4YcCl7dnW2RPeIudX7eWuX1pxNtnA/o5M9U2wl9XuanzCKomFBp0cvsyEJAm2q4mknR9J7X5YBM6oPfZCR5HE2FMbASEBEWHAYi8QQ5JS9deq+TzSRNZ3EDBVHwa1hxUPf2SHK1HmcotOKX7UM0tmsfJP5qHr1hMMu6nNexy6PFGOCB9vEjZwb33SyCr5qvF2NT
X-Received: by 10.58.11.201 with SMTP id s9mr10406veb.91.1384470042942; Thu, 14 Nov 2013 15:00:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Thu, 14 Nov 2013 15:00:22 -0800 (PST)
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A117700@008-AM1MPN1-043.mgdnok.nokia.com>
References: <CAGTXFp92jSzQz05uHngzscz88n=fT_JPbEvQRxgeUUqPVRQUyQ@mail.gmail.com> <00ca01cec387$f881cae0$e98560a0$@co.in> <BLU406-EAS274696C3D9DFE505F96B8E393130@phx.gbl> <004201cec44f$381a47f0$a84ed7d0$@co.in> <52544E0E.5080405@viagenie.ca> <003b01cec511$27e1abe0$77a503a0$@co.in> <E44893DD4E290745BB608EB23FDDB7620A0D672F@008-AM1MPN1-042.mgdnok.nokia.com> <9E34D50A21D1D1489134B4D770CE039768081AC9@SZXEMA504-MBX.china.huawei.com> <004e01cec5df$cf8daaf0$6ea900d0$@co.in> <E44893DD4E290745BB608EB23FDDB7620A0E2DC6@008-AM1MPN1-043.mgdnok.nokia.com> <9F33F40F6F2CD847824537F3C4E37DDF17BEFB3E@MCHP04MSX.global-ad.net> <BLU402-EAS357ECBFC621A567B9D3A7B4931A0@phx.gbl> <525C148F.8070502@gmail.com> <00d401cec90e$d688d5a0$839a80e0$@co.in> <A51F486D-3BC0-4090-80CD-B4A15AC3EE69@cisco.com> <913383AAA69FF945B8F946018B75898A2000EB57@xmb-rcd-x10.cisco.com> <8F31D947-AB62-431A-875D-FCBAA2D38290@cisco.com> <525E806B.5060401@alvestrand.no> <000801cecdae$f6713160$e3539420$@co.in> <CAOJ7v-3W7Kj_Bn7pTPs+=-wPZRSvC1DzAHB9=2cnK8JiAoK3ug@mail.gmail.com> <E44893DD4E290745BB608EB23FDDB7620A10CA55@008-AM1MPN1-041.mgdnok.nokia.com> <CAOJ7v-3E8a9ayfbvk1tN6pqBn-U1tjQ=id1MtYaESB1BnH+sGQ@mail.gmail.com> <E44893DD4E290745BB608EB23FDDB7620A117700@008-AM1MPN1-043.mgdnok.nokia.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 14 Nov 2013 15:00:22 -0800
Message-ID: <CAOJ7v-1CZyMAQ2W_kdQp5+r3JBjLSn7XAzy32i9ff9KPyWcm_A@mail.gmail.com>
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>
Content-Type: multipart/alternative; boundary=047d7b41813d1cbdb304eb2b0d4d
Cc: Harald Tveit Alvestrand <harald@alvestrand.no>, 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: Thu, 14 Nov 2013 23:00:48 -0000

On Thu, Nov 14, 2013 at 3:39 AM, <Markus.Isomaki@nokia.com>; wrote:

>  Justin,
>
>
>
> One more clarification:
>
> [Markus] I wonder if you already have a plan in Chrome if and how to deal
> with HTTP (and TLS) restricted firewalls. Are you OK with the idea of
> connecting to a TURN server with HTTP CONNECT, or do you see some issues
> with that?
>
> [Justin] We already use HTTP CONNECT with ICE-TCP, TURN-TCP, and TURN-TLS.
> It works.
>
>
>
> [Markus] So you use HTTP CONNECT to open the TCP connections for ICE-TCP
> too? And in this way you will basically never need to use TURN for the
> conference server or gateway type of case where the other peer is reachable
> by TCP? That would be cool. Now we would have to get this standardized
> somehow or just convince other browsers to do the same, as the standards
> path seems tricky and lengthy. Could you tell how you decide if HTTP
> CONNECT is needed or not? Do you do some connectivity tests in the
> background and cache the result, or do you do it for each
> RTCPeerConnection? Or do you just follow the HTTP proxy configuration rules
> and apply them to ICE-TCP and TURN?
>

Yes, HTTP CONNECT is used for ICE-TCP.

I forget the details, but I think right now we just obey the proxy
configuration for TCP, but also try direct UDP. There could be cases where
direct TCP could work as well, but given that that's not an optimal outcome
anyway, I don't think that is hooked up.

>
>
> Markus
>
>
>
>
>
> *From:* ext Justin Uberti [mailto:juberti@google.com]
> *Sent:* 09 November, 2013 03:57
> *To:* Isomaki Markus (Nokia-CIC/Espoo)
> *Cc:* Parthasarathi R; Harald Tveit Alvestrand; pntaw@ietf.org
>
> *Subject:* Re: [pntaw] Real-time media over TCP
>
>
>
>
>
>
>
> On Fri, Nov 8, 2013 at 3:58 PM, <Markus.Isomaki@nokia.com>; wrote:
>
> Hi Justin,
>
>
>
> It’s great to hear that at least one browser will be able to do ICE-TCP.
> It is an optimization, but definitely a useful one for certain central
> server and gateway situations. I have heard also from other service/gateway
> providers that they want to avoid the TURN-TCP “hop” for the same reasons
> you state. After listening to them, I’d say ICE-TCP ought to be rather a
> “SHOULD” instead of “MAY” in the RTCWeb NAT traversal framework.
>
>
>
> Sounds good.
>
>
>
> I suppose that when real-time media runs over TCP, it is in general best
> to avoid bundling, but to run the different medias over separate TCP
> connections. That way a single lost packet only affects the rate of one of
> the medias instead of the aggregate.
>
>
>
>  That is an interesting idea, but I think it is probably difficult to
> make work because the BUNDLE decision happens separately from ICE candidate
> pair selection.
>
>
>
> I think what we really want is some sort of multi-TCP transport, where we
> can open several simultaneous TCP connections and rotate between them. Or
> maybe a Minion TCP-based approach. These would have their own issues, but
> be conceptually simpler.
>
>
>
>  I wonder if you already have a plan in Chrome if and how to deal with
> HTTP (and TLS) restricted firewalls. Are you OK with the idea of connecting
> to a TURN server with HTTP CONNECT, or do you see some issues with that?
>
>
>
> We already use HTTP CONNECT with ICE-TCP, TURN-TCP, and TURN-TLS. It
> works.
>
>
>
> Markus
>
>
>
>
>
> *From:* pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] *On Behalf
> Of *ext Justin Uberti
> *Sent:* 09 November, 2013 01:33
> *To:* Parthasarathi R
> *Cc:* Harald Alvestrand; pntaw@ietf.org
>
>
> *Subject:* Re: [pntaw] Real-time media over TCP
>
>
>
> FWIW: we use ICE-TCP to connect to a conferencing server, instead of
> TURN-TCP, to avoid the extra TURN hop and the whole TURN credentials
> business. It's an optimization for sure, but a useful one.
>
>
>
> I don't think ICE-TCP will be all that useful for P2P connectivity in the
> near future. The scenarios that require ICE-TCP are the exact ones where
> simultaneous open will probably be impossible.
>
>
>
> On Sun, Oct 20, 2013 at 9:10 AM, Parthasarathi R <
> partha@parthasarathi.co.in>; wrote:
>
> Hi Harald & all,
>
> I agree that ICE-TCP qualifies for "MAY" requirement in case both browsers
> are behind firewall. ICE-TCP is good for usecase wherein only one of the
> browsers is behind firewall. Existing WebRTC usecase namely FedEx call is
> good example for only one browser behind firewall wherein IVR is not going
> to be behind UDP blocking firewall. In those usecases, ICE-TCP candidates
> has merits over TURN relay candidates. IMO, ICE-TCP MUST be considered.
>
> The current WebRTC FW usecase is (accidentially) inline with one of the
> browser behind firewall scenario as mentioned in sec 3.3.2.1 of
> draft-ietf-rtcweb-use-cases-and-requirements-12:
>
>
> "The difference is that one of the users is behind a NAT that blocks UDP
> traffic."
>
> Thanks
> Partha
>
>
> > -----Original Message-----
> > From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
>
> > Of Harald Alvestrand
> > Sent: Wednesday, October 16, 2013 5:33 PM
> > To: pntaw@ietf.org
> > Subject: Re: [pntaw] Real-time media over TCP
> >
> > On 10/15/2013 06:15 PM, Dan Wing wrote:
> > > On Oct 14, 2013, at 11:02 PM, Tirumaleswar Reddy (tireddy)
> > <tireddy@cisco.com>; wrote:
> > >
> > >>> -----Original Message-----
> > >>> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> > Behalf Of Dan
> > >>> Wing (dwing)
> > >>> Sent: Tuesday, October 15, 2013 5:31 AM
> > >>> To: Markus.Isomaki@nokia.com
> > >>> Cc: pntaw@ietf.org; partha@parthasarathi.co.in
> > >>> Subject: Re: [pntaw] Real-time media over TCP
> > >>>
> > >>>
> > >>> On Oct 14, 2013, at 12:06 PM, Markus.Isomaki@nokia.com wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> In practice I doubt you find many situations where UDP is
> > completely blocked
> > >>> but incoming TCP connections from anywhere are allowed.
> > >>>
> > >>> Agreed.
> > >>>
> > >>> But if both ends are trying to communicate with each other, their
> > >>> communications will appear as a TCP simultaneous-open.  That could
> > (in fact,
> > >>> "should") work across a firewall because the firewall will see an
> > outbound SYN
> > >>> to a host/port after which it will see an inbound SYN from that
> > same
> > >>> host/port.
> > >> But firewall TCP inspection causes the inbound SYN from the same
> > host/port to be dropped (Firewalls typically do not permit TCP
> > simultaneous-open). Even with NAT as per the survey results in ICE TCP
> > (http://tools.ietf.org/html/rfc6544#appendix-A) TCP simultaneous-open
> > worked only in roughly 45% of the cases.
> > > If avoiding TURN improves the user experience, and IT policy says TCP
> > is allowed, I expect firewall vendors would make sure TCP simultaneous
> > open works.
> > >
> > >
> > If something improves the user experience if it is possible to do it,
> > but the basic functionality works without it, and it's unclear whether
> > the special circumstances under which it's going to improve the user
> > experience in fact exist in the field, I think that's perfect for a MAY
> > implement.
> >
> > _______________________________________________
> > 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
>
>
>
>
>