Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation)

Michael Thornburgh <mthornbu@adobe.com> Mon, 07 April 2014 20:57 UTC

Return-Path: <mthornbu@adobe.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F081A080D for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 13:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0daunx2HwqkP for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 13:57:03 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9F11A081F for <rtcweb@ietf.org>; Mon, 7 Apr 2014 13:57:03 -0700 (PDT)
Received: from BY2PR02MB364.namprd02.prod.outlook.com (10.141.140.152) by BY2PR02MB364.namprd02.prod.outlook.com (10.141.140.152) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 20:56:55 +0000
Received: from BY2PR02MB364.namprd02.prod.outlook.com ([10.141.140.152]) by BY2PR02MB364.namprd02.prod.outlook.com ([10.141.140.152]) with mapi id 15.00.0913.002; Mon, 7 Apr 2014 20:56:55 +0000
From: Michael Thornburgh <mthornbu@adobe.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
Thread-Topic: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation)
Thread-Index: AQHPUjfoFsMB+NfjFkSckgH26QDjTZsGYYIAgAAFfICAAAHNAIAAH+8AgAABlICAAAFiAIAAD+cQ
Date: Mon, 7 Apr 2014 20:56:55 +0000
Message-ID: <bdd3d523fd4844b0824f588e12d4ec44@BY2PR02MB364.namprd02.prod.outlook.com>
References: <CABkgnnWWuU63Vd=gw+wrh2ADgVYtQzhoRzRE1sv5azJE=MhWDg@mail.gmail.com> <533F191D.8050109@alum.mit.edu> <CABkgnnVht5EmJ7a2LDh50ivjUdoTpJ8GannQKReBSJbVGQGmgA@mail.gmail.com> <53425BAF.4070105@alvestrand.no> <CABkgnnXKe65-30qkuhkCLmaUYVfe8vrWv9BCJzOvC7KaRwUH=g@mail.gmail.com> <5342DE6F.6040306@alvestrand.no> <AE1A6B5FD507DC4FB3C5166F3A05A484504B4D9C@TK5EX14MBXC298.redmond.corp.microsoft.com> <5342FABC.4080200@alum.mit.edu> <AE1A6B5FD507DC4FB3C5166F3A05A484504B505E@TK5EX14MBXC298.redmond.corp.microsoft.com> <CAHBDyN4N4T+xj_fMUQeYAL0Z=+iQ2z0uMbuDDg+ASV3mgceq3A@mail.gmail.com>
In-Reply-To: <CAHBDyN4N4T+xj_fMUQeYAL0Z=+iQ2z0uMbuDDg+ASV3mgceq3A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.150.19.4]
x-forefront-prvs: 0174BD4BDA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(479174003)(199002)(24454002)(189002)(13464003)(377454003)(51704005)(87936001)(19580395003)(47976001)(76786001)(50986001)(76796001)(92566001)(15975445006)(47446002)(2656002)(74502001)(63696002)(77982001)(83072002)(74316001)(49866001)(81686001)(47736001)(93136001)(76576001)(4396001)(85852003)(90146001)(19580405001)(59766001)(99396002)(56816005)(83322001)(74876001)(87266001)(74706001)(20776003)(69226001)(46102001)(56776001)(54316002)(81816001)(53806001)(66066001)(86362001)(80022001)(79102001)(81342001)(65816001)(94316002)(76482001)(80976001)(54356001)(74662001)(98676001)(74366001)(85306002)(93516002)(97336001)(33646001)(95666003)(81542001)(94946001)(31966008)(95416001)(97186001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR02MB364; H:BY2PR02MB364.namprd02.prod.outlook.com; FPR:FC97F096.A7F24789.3CD3B14B.C6E6D251.20372; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: adobe.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-IAePZGM7eJCKkeI4Rcywblz6cY
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Apr 2014 20:57:08 -0000

> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mary Barnes
> Sent: Monday, April 07, 2014 12:32 PM
> 
> On Mon, Apr 7, 2014 at 2:27 PM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:
> 
> 	-----Original Message-----
> 	> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat
> 	> Sent: Monday, April 7, 2014 12:22 PM
> 	> To: rtcweb@ietf.org
> 	> Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with
> 	> media isolation)
> 	>
> 	> On 4/7/14 1:27 PM, Matthew Kaufman (SKYPE) wrote:
> 	> >
> 	> > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald
> 	> >> Alvestrand
> 	> >> ...
> 	> >> (and to Matthew: At least we wouldn't have *yet* another congestion
> 	> >> context to manage, which would be the case with a separate TCP
> 	> connection.
> 	> >> There are always tradeoffs.)
> 	> >
> 	> > If it was me (and at one time, it was) I would use a protocol that allows for
> 	> multiplexing and prioritization of media and data channels over the same
> 	> secure session with shared congestion state. Over such a protocol, opening
> 	> another data stream for this purpose could be done immediately without
> 	> even a round trip.
> 	> >
> 	> > RFC 7016 documents such an approach.
> 	>
> 	> I see that the title starts with "Adobe's". Sigh.
> 
> 	Yes, but there's little stopping many of these ideas from becoming the basis for an IETF-
> developed transport protocol that actually meets the needs we have here.
> 
> [MB] Except, maybe, IPR:
>  https://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-thornburgh-adobe-rtmfp
> [/MB]

we would love for RTMFP to become the basis for an IETF-developed standard transport protocol.  and as far as using RTMFP as-is, note section VI of the (most recent) above-referenced IPR disclosure: "Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers."  we think it's pretty good already and published it (among other reasons) in the hopes that others would find new uses for it.

> 	> If you want to entertain something other than existing solutions for media,
> 	> why not simply run the RTP media streams over SCTP along with the data
> 	> channels?
> 
> 	Except for some critical shortcomings of SCTP (which are being fixed), this isn't actually a
> terrible idea.

except for the critical shortcomings of SCTP (for real-time communications) that aren't being fixed.

> 	Matthew Kaufman

-michael thornburgh