IETF Logo Mail Archive

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

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Mon, 07 April 2014 19:28 UTC

Return-Path: <matthew.kaufman@skype.net>
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 D73B41A0237 for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 12:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ynJ2pHMl7HHW for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 12:28:13 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE4D1A079D for <rtcweb@ietf.org>; Mon, 7 Apr 2014 12:27:58 -0700 (PDT)
Received: from BY2PR03CA034.namprd03.prod.outlook.com (10.242.234.155) by BY2PR03MB363.namprd03.prod.outlook.com (10.242.237.16) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 19:27:51 +0000
Received: from BN1AFFO11FD017.protection.gbl (2a01:111:f400:7c10::192) by BY2PR03CA034.outlook.office365.com (2a01:111:e400:2c2c::27) with Microsoft SMTP Server (TLS) id 15.0.908.10 via Frontend Transport; Mon, 7 Apr 2014 19:27:51 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD017.mail.protection.outlook.com (10.58.52.77) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Mon, 7 Apr 2014 19:27:48 +0000
Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.124]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0181.007; Mon, 7 Apr 2014 19:27:12 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation)
Thread-Index: AQHPUjfRb53lyS9CtEOLJeBSW/E7VJsGYYMAgAAFe4CAAADocIAAINQAgAABNqA=
Date: Mon, 07 Apr 2014 19:27:11 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484504B505E@TK5EX14MBXC298.redmond.corp.microsoft.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>
In-Reply-To: <5342FABC.4080200@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(479174003)(51704005)(13464003)(377454003)(24454002)(189002)(199002)(46102001)(85306002)(53806001)(79102001)(54356001)(93516002)(33656001)(84676001)(59766001)(77982001)(54316002)(99396002)(56776001)(97336001)(94946001)(92566001)(95666003)(44976005)(2656002)(97186001)(98676001)(66066001)(4396001)(2009001)(76482001)(94316002)(31966008)(49866001)(47976001)(92726001)(95416001)(46406003)(80976001)(86362001)(81542001)(47736001)(81342001)(97756001)(65816001)(87266001)(80022001)(97736001)(76786001)(74706001)(81816001)(23726002)(6806004)(69226001)(74366001)(2171001)(20776003)(56816005)(19580405001)(77096001)(74662001)(74876001)(50986001)(74502001)(81686001)(87936001)(47446002)(93136001)(90146001)(76796001)(83072002)(63696002)(50466002)(83322001)(55846006)(19580395003)(47776003)(85852003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB363; H:mail.microsoft.com; FPR:FC97F016.A7FAC789.3CD0314B.C4E4D271.2029B; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0174BD4BDA
Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
X-OriginatorOrg: skype.net
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JlqQZ549bNsaEtYN_eGMAgGJLKI
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 19:28:18 -0000

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

Matthew Kaufman

v2.23.0 | Report a Bug | By Email