Re: [pntaw] Real-time media over TCP

<Markus.Isomaki@nokia.com> Sat, 09 November 2013 00:00 UTC

Return-Path: <Markus.Isomaki@nokia.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 8009621F9C37 for <pntaw@ietfa.amsl.com>; Fri, 8 Nov 2013 16:00:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.544
X-Spam-Level:
X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 EFxyx4B+nCNV for <pntaw@ietfa.amsl.com>; Fri, 8 Nov 2013 16:00:01 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5814D21F9C33 for <pntaw@ietf.org>; Fri, 8 Nov 2013 16:00:00 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.56]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA8NwP1M008602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sat, 9 Nov 2013 01:58:25 +0200
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.204]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.03.0136.001; Fri, 8 Nov 2013 23:58:24 +0000
From: <Markus.Isomaki@nokia.com>
To: <juberti@google.com>, <partha@parthasarathi.co.in>
Thread-Topic: [pntaw] Real-time media over TCP
Thread-Index: AQHOpWlrwk9eq/rvIEmYBkw2NSNGdZmyI/aAgACifgCAAN6pAIAApSuAgAAM8oCAACMQgIA1SsoAgAAHUgCAAYcrAIAACRcAgAF6zgCAAAPgcIAAkKAAgAEIx4CAAS4k0IAE5epggAAK6QCAAA3RgIAAMVCAgAAA0lCAAFToAIAAZOYAgACrYYCAAUudgIAGjqCAgB5XvICAAAImwA==
Date: Fri, 8 Nov 2013 23:58:24 +0000
Message-ID: <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>
In-Reply-To: <CAOJ7v-3W7Kj_Bn7pTPs+=-wPZRSvC1DzAHB9=2cnK8JiAoK3ug@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IhueGIqUfGX1Vo3TN0QuXNLYJ0nYlxFdLFJ5gcB/PGe53F84VK518ganGlutIy+o0MU6sTNCUH7/ZKSzG1tsY08YZ1WSe3114qbZYLHJo/sijV3LmoKgzfDvxeg6LXMqY0XjGFDVD13ObRalSFs0aBBTUObDVKdYN/pUpib2TAy6Ie0vW48/ap31ZEtJhVVVpx2PW4Gb8laD1xJakbzopy9luigbwLJJQAWEdev5+7Kn
x-originating-ip: [10.163.32.108]
Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A10CA55008AM1MPN1041mg_"
MIME-Version: 1.0
X-Nokia-AV: Clean
Cc: harald@alvestrand.no, pntaw@ietf.org
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 00:00:06 -0000

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.

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.

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?

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<mailto: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> [mailto: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<mailto: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<mailto:tireddy@cisco.com>> wrote:
> >
> >>> -----Original Message-----
> >>> From: pntaw-bounces@ietf.org<mailto:pntaw-bounces@ietf.org> [mailto: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<mailto:Markus.Isomaki@nokia.com>
> >>> Cc: pntaw@ietf.org<mailto:pntaw@ietf.org>; partha@parthasarathi.co.in<mailto:partha@parthasarathi.co.in>
> >>> Subject: Re: [pntaw] Real-time media over TCP
> >>>
> >>>
> >>> On Oct 14, 2013, at 12:06 PM, Markus.Isomaki@nokia.com<mailto: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<mailto:pntaw@ietf.org>
> https://www.ietf.org/mailman/listinfo/pntaw

_______________________________________________
pntaw mailing list
pntaw@ietf.org<mailto:pntaw@ietf.org>
https://www.ietf.org/mailman/listinfo/pntaw