Re: [pntaw] Real-time media over TCP

Justin Uberti <juberti@google.com> Sat, 09 November 2013 01:56 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 223E111E8103 for <pntaw@ietfa.amsl.com>; Fri, 8 Nov 2013 17:56:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.792
X-Spam-Level:
X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=0.185, 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 bI96CZA1i4u4 for <pntaw@ietfa.amsl.com>; Fri, 8 Nov 2013 17:56:57 -0800 (PST)
Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 086B311E80FB for <pntaw@ietf.org>; Fri, 8 Nov 2013 17:56:56 -0800 (PST)
Received: by mail-ve0-f180.google.com with SMTP id oy12so2030882veb.11 for <pntaw@ietf.org>; Fri, 08 Nov 2013 17:56:54 -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=SImG/HAco+NZNCCrfSVf8OxE/TVls5vXUR2R5JJeYy8=; b=NBPpvqEIGJVQRIOqbPWKqkYlY0U8g+GHHOYrpknKnBQvijuVQbMAvgiCbI+zjZT8jq XPXQPTO37MWDbkI3LOtAFqvuq+9wFt/c1Q7eFdihzj7eSRAaIDyUW4q5oe//qN6acEyW 7iXYbXXwwe/78ZRkV+pOhYjLz+BNrKcRlSSzRw80ODaCB/hoAlYNJ0xgAFYKB0nGwDcV j0IgYFRm8aOeOVyKAiNWORbxbARoMfnsoEGbF1bySverkI8poZAblaHZyv0cisUjKmJl Uv0OdYdRSA26RmCOI61EHfhBAgCSr5VS19B3E+7OYipCnK1CIy/wrEYx44uMoeH1VL1Z +WOA==
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=SImG/HAco+NZNCCrfSVf8OxE/TVls5vXUR2R5JJeYy8=; b=daRW+nI7kuMm0TVW5VDS5ptn8Tjr/+/NAeHRc2FzozpiA8aXV1nTmqCJKoyxjtSOVb aEo3L6FKrCkbIAk9giAVr7S6UGcIqlQg6yriGmXkxnGpiqR6MsNop+vTI2vpm1E67TOY 77f48PgvvDNy2ODw6BFEH+roKKgIotuY1azpGfyOB+QFRZp1K2TLJo+gWkCh6aYpiI36 v5mJLZjC5xh/cUzW/vpujXwRvcuWkNLBSl6hAbGjU6+PF3/XxgxZlU7iBCt7k4dysa0c VWVKo79tT0Qakg37BxUdcr0HjQv/SAwfeUHQHulwxPTc3bqpNf+hpza9B4BcjK4+3qGk Wpsw==
X-Gm-Message-State: ALoCoQk9NdHPuHCuoJA6a9n59iO+gNuP3UDieEXLPGn0Ql3IveH9rYzLYwhkRfETFtexOY75KMDoTMI+njHlcQw1vh2GfNA/wWUpsRwWbY7ExD950GQO5A5T3mJAsnARv3fUwBQRY8dsVuhCWqkf7Zmt+ADjl8oZ80YEIUsbWg5VDcMFpd1Q/HAbvzq+WM6qGlzQd541Ui5e
X-Received: by 10.220.164.202 with SMTP id f10mr14707854vcy.25.1383962214215; Fri, 08 Nov 2013 17:56:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Fri, 8 Nov 2013 17:56:34 -0800 (PST)
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A10CA55@008-AM1MPN1-041.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>
From: Justin Uberti <juberti@google.com>
Date: Fri, 8 Nov 2013 17:56:34 -0800
Message-ID: <CAOJ7v-3E8a9ayfbvk1tN6pqBn-U1tjQ=id1MtYaESB1BnH+sGQ@mail.gmail.com>
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>
Content-Type: multipart/alternative; boundary=001a11c1e980294e8604eab4d098
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: Sat, 09 Nov 2013 01:57:00 -0000

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