From nobody Fri Nov 3 10:08:26 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5621513FEFD for ; Fri, 3 Nov 2017 10:08:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.64.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150972890535.16418.946092318155802796.idtracker@ietfa.amsl.com> Date: Fri, 03 Nov 2017 10:08:25 -0700 From: IETF Secretariat Archived-At: Subject: [AVTCORE] Milestones changed for avtcore WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 17:08:25 -0000 Changed milestone "Submit Feedback Mechanism for RTP Congestion Control for Proposed Standard", added draft-ietf-avtcore-cc-feedback-message to milestone. URL: https://datatracker.ietf.org/wg/avtcore/about/ From nobody Fri Nov 3 10:27:10 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A508013FF03 for ; Fri, 3 Nov 2017 10:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com 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 hzGqDjifxG6I for ; Fri, 3 Nov 2017 10:27:07 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0CF13FF02 for ; Fri, 3 Nov 2017 10:27:07 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id m189so4097010qke.4 for ; Fri, 03 Nov 2017 10:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=Q7E5Y73MVnBGN3Khr/+ifgItP0i+Fow9jxj1OpGXC6A=; b=1V6Mq/MWu7Ui33z5XdTPgPceYbhY8xepyB4eTQ+f6lncxRQqIbyKgIueTyVpN+O03y HGzTq6Y4T+g6Ewuuja9c7vTyFTv85hJwwcG/EjCFrxQ0OepEgjpZkYU0RP6RTncTAxZM kenre2GNQ6WGshIN7mUfbPlFBSlHeuJphae27wPYTnqeR+eoPcTLx4UdhSHKzYi//1+R +GL7nBYiROfPDmiiGn95mg7RStaCT/t7Lf9fxvRS6Q8BReLp/PKZN17Ux+h7fhQHURKp RiUn2HZticH/blsRmqnGNxhWRQa72iPoQUYBZ6skovG9Feq1Xod3eC7Z61/jsh5r1f5X uhbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=Q7E5Y73MVnBGN3Khr/+ifgItP0i+Fow9jxj1OpGXC6A=; b=UAgZ9jiX7OjFbbiwuBOG5K/oaPfwxflyAwEjWlPag/ILbyHkc1BOY726FU64YcBHVb QB+xjnkZt6YejNqvHevS+L+RLomJNNFhc16IrXoBBG3gfRTAqCyYdmxf4eH1xttAxJ66 H2otEe0OyIEL0or6DyXztqzW8pRKxucHCR4rnoP7XwLntwU/i3RlZTs5M1acRdfp+Nz/ Hj3j5En3kkCMqcXKoSIWGVctutpeu4K/sshI5tUmQpuwSuDcH2yCFwSHdq3T8UyEVLwq 5WFrHYoiMfS3EtGOwGSEwoTBHnAmgUK7mNPEfm+yXsE+PrkQIpcHQ3dl6Eunh9as0erL 780Q== X-Gm-Message-State: AMCzsaXHW1KBNoii/e2I4XJe3mhAsBVux6iof3I2lGfYxiVj1fTWdOuG w/T/nkV86nNVIBxHaUgWs9Ka/kX1uh8= X-Google-Smtp-Source: ABhQp+RXwOyqdK25+91L7wytfvma4GHxh82irE4Oe6/+McK8XXYetkd8fdF7YEgjTgrEouHu6puMBQ== X-Received: by 10.55.18.223 with SMTP id 92mr10442070qks.303.1509730026124; Fri, 03 Nov 2017 10:27:06 -0700 (PDT) Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id b194sm4047508qkc.31.2017.11.03.10.27.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Nov 2017 10:27:05 -0700 (PDT) From: Jonathan Lennox Content-Type: multipart/alternative; boundary="Apple-Mail=_43133DD0-2B21-410B-86DA-96FC6D374E64" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <30A6BB67-D972-4812-9812-CAC07CC58560@vidyo.com> Date: Fri, 3 Nov 2017 13:27:04 -0400 To: IETF AVTCore WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [AVTCORE] Draft agenda for AVTCore meeting in Singapore X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 17:27:08 -0000 --Apple-Mail=_43133DD0-2B21-410B-86DA-96FC6D374E64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The AVTCore working group will meet in Singapore at 9:30 AM on Thursday, = November 16, in the Orchard room of the Raffles City Convention Center. On the IETF agenda the group scheduled for a one-hour session, but the = room is free until at least 11:00 (when DMarc is scheduled to start) and = probably until 12:00 (since DMarc is likely to cancel). The group=E2=80=99= s current agenda is scheduled to run through 11:00. We will also have one draft presented that is proposed new work for the = XRBlock working group. The draft agenda is at = https://datatracker.ietf.org/doc/agenda-100-avtcore/ = . Please send = the chairs any suggested additions, changes, or corrections. See you in Singapore!= --Apple-Mail=_43133DD0-2B21-410B-86DA-96FC6D374E64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The AVTCore working group will meet in = Singapore at 9:30 AM on Thursday, November 16, in the Orchard room of = the Raffles City Convention Center.

On the IETF agenda the group scheduled = for a one-hour session, but the room is free until at least 11:00 (when = DMarc is scheduled to start) and probably until 12:00 (since DMarc is = likely to cancel).  The group=E2=80=99s current agenda is scheduled = to run through 11:00.

We will also have one draft presented that is proposed new = work for the XRBlock working group.

The draft agenda is at https://datatracker.ietf.org/doc/agenda-100-avtcore/ .=  Please send the chairs any suggested additions, changes, or = corrections.

See= you in Singapore!
= --Apple-Mail=_43133DD0-2B21-410B-86DA-96FC6D374E64-- From nobody Sat Nov 4 23:44:01 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78BF13FB48 for ; Sat, 4 Nov 2017 23:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SJRP95tMGtuF for ; Sat, 4 Nov 2017 23:43:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787B413FB42 for ; Sat, 4 Nov 2017 23:43:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRZ86416; Sun, 05 Nov 2017 06:43:55 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 5 Nov 2017 06:43:54 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Sun, 5 Nov 2017 14:43:42 +0800 From: Roni Even To: Jonathan Lennox , "Huangyihong (Rachel)" CC: IETF AVTCore WG Thread-Topic: [AVTCORE] Draft agenda for AVTCore meeting in Singapore Thread-Index: AQHTVMkLPdS0rQKFuEaIvfaJ1TOx5qMFWH2Q Date: Sun, 5 Nov 2017 06:43:42 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD831225@DGGEMM506-MBX.china.huawei.com> References: <30A6BB67-D972-4812-9812-CAC07CC58560@vidyo.com> In-Reply-To: <30A6BB67-D972-4812-9812-CAC07CC58560@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD831225DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59FEB32C.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 50da39a2b7fd485918961fb4499537ae Archived-At: Subject: Re: [AVTCORE] Draft agenda for AVTCore meeting in Singapore X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 06:44:00 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD831225DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uYXRoYW4sDQoNCkkgdGhpbmsgTWFydmluIHdvdWxkIG5lZWQgc29tZSB0aW1lIHRvIHBy ZXNlbnQgdGhlIG5ldyBtdWx0aXBsZXhpbmcgYXJjaGl0ZWN0dXJlIGRyYWZ0LiBJIGFsc28gbm90 aWNlIHRoYXQgZXZlbiB0aG91Z2ggSSBhc2tlZCBmb3IgNSBtaW51dGVzIHRvIHByZXNlbnQgZHJh ZnQtZXZlbi1hdnRjb3JlLXByaW9yaXR5LW1hcmtpbmdzDQpJIGRvIG5vdCBzZWUgaXQgb24gdGhl IGFnZW5kYQ0KUm9uaQ0KDQpGcm9tOiBhdnQgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpvbmF0aGFuIExlbm5veA0KU2VudDog15nXldedINeVIDAzINeg15XXkdee 15HXqCAyMDE3IDE5OjI3DQpUbzogSUVURiBBVlRDb3JlIFdHDQpTdWJqZWN0OiBbQVZUQ09SRV0g RHJhZnQgYWdlbmRhIGZvciBBVlRDb3JlIG1lZXRpbmcgaW4gU2luZ2Fwb3JlDQoNClRoZSBBVlRD b3JlIHdvcmtpbmcgZ3JvdXAgd2lsbCBtZWV0IGluIFNpbmdhcG9yZSBhdCA5OjMwIEFNIG9uIFRo dXJzZGF5LCBOb3ZlbWJlciAxNiwgaW4gdGhlIE9yY2hhcmQgcm9vbSBvZiB0aGUgUmFmZmxlcyBD aXR5IENvbnZlbnRpb24gQ2VudGVyLg0KDQpPbiB0aGUgSUVURiBhZ2VuZGEgdGhlIGdyb3VwIHNj aGVkdWxlZCBmb3IgYSBvbmUtaG91ciBzZXNzaW9uLCBidXQgdGhlIHJvb20gaXMgZnJlZSB1bnRp bCBhdCBsZWFzdCAxMTowMCAod2hlbiBETWFyYyBpcyBzY2hlZHVsZWQgdG8gc3RhcnQpIGFuZCBw cm9iYWJseSB1bnRpbCAxMjowMCAoc2luY2UgRE1hcmMgaXMgbGlrZWx5IHRvIGNhbmNlbCkuICBU aGUgZ3JvdXDigJlzIGN1cnJlbnQgYWdlbmRhIGlzIHNjaGVkdWxlZCB0byBydW4gdGhyb3VnaCAx MTowMC4NCg0KV2Ugd2lsbCBhbHNvIGhhdmUgb25lIGRyYWZ0IHByZXNlbnRlZCB0aGF0IGlzIHBy b3Bvc2VkIG5ldyB3b3JrIGZvciB0aGUgWFJCbG9jayB3b3JraW5nIGdyb3VwLg0KDQpUaGUgZHJh ZnQgYWdlbmRhIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2FnZW5kYS0x MDAtYXZ0Y29yZS8gLiAgUGxlYXNlIHNlbmQgdGhlIGNoYWlycyBhbnkgc3VnZ2VzdGVkIGFkZGl0 aW9ucywgY2hhbmdlcywgb3IgY29ycmVjdGlvbnMuDQoNClNlZSB5b3UgaW4gU2luZ2Fwb3JlIQ0K --_000_6E58094ECC8D8344914996DAD28F1CCD831225DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIEpvbmF0aGFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgTWFydmlu IHdvdWxkIG5lZWQgc29tZSB0aW1lIHRvIHByZXNlbnQgdGhlIG5ldyBtdWx0aXBsZXhpbmcgYXJj aGl0ZWN0dXJlIGRyYWZ0LiBJIGFsc28gbm90aWNlIHRoYXQgZXZlbiB0aG91Z2ggSSBhc2tlZCBm b3IgNSBtaW51dGVzIHRvIHByZXNlbnQgPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ ZHJhZnQtZXZlbi1hdnRjb3JlLXByaW9yaXR5LW1hcmtpbmdzPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSBkbyBub3Qgc2VlIGl0IG9uIHRoZSBhZ2VuZGE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Um9uaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBhdnQgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Sm9uYXRoYW4gTGVubm94PGJyPg0KPGI+U2VudDo8L2I+IDxzcGFuIGxhbmc9IkhFIiBk aXI9IlJUTCI+15nXldedJm5ic3A715UgMDMg16DXldeR157XkdeoIDIwMTcgMTk6Mjc8L3NwYW4+ PGJyPg0KPGI+VG86PC9iPiBJRVRGIEFWVENvcmUgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0FW VENPUkVdIERyYWZ0IGFnZW5kYSBmb3IgQVZUQ29yZSBtZWV0aW5nIGluIFNpbmdhcG9yZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgQVZU Q29yZSB3b3JraW5nIGdyb3VwIHdpbGwgbWVldCBpbiBTaW5nYXBvcmUgYXQgOTozMCBBTSBvbiBU aHVyc2RheSwgTm92ZW1iZXIgMTYsIGluIHRoZSBPcmNoYXJkIHJvb20gb2YgdGhlIFJhZmZsZXMg Q2l0eSBDb252ZW50aW9uIENlbnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gdGhlIElFVEYgYWdlbmRhIHRoZSBncm91cCBzY2hlZHVs ZWQgZm9yIGEgb25lLWhvdXIgc2Vzc2lvbiwgYnV0IHRoZSByb29tIGlzIGZyZWUgdW50aWwgYXQg bGVhc3QgMTE6MDAgKHdoZW4gRE1hcmMgaXMgc2NoZWR1bGVkIHRvIHN0YXJ0KSBhbmQgcHJvYmFi bHkgdW50aWwgMTI6MDAgKHNpbmNlIERNYXJjIGlzIGxpa2VseSB0byBjYW5jZWwpLiAmbmJzcDtU aGUgZ3JvdXDigJlzIGN1cnJlbnQgYWdlbmRhIGlzIHNjaGVkdWxlZA0KIHRvIHJ1biB0aHJvdWdo IDExOjAwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XZSB3aWxsIGFsc28gaGF2ZSBvbmUgZHJhZnQgcHJlc2VudGVkIHRoYXQgaXMgcHJvcG9z ZWQgbmV3IHdvcmsgZm9yIHRoZSBYUkJsb2NrIHdvcmtpbmcgZ3JvdXAuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBhZ2VuZGEg aXMgYXQgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvYWdlbmRhLTEw MC1hdnRjb3JlLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9hZ2VuZGEtMTAw LWF2dGNvcmUvPC9hPiZuYnNwOy4gJm5ic3A7UGxlYXNlIHNlbmQgdGhlIGNoYWlycyBhbnkgc3Vn Z2VzdGVkIGFkZGl0aW9ucywgY2hhbmdlcywgb3IgY29ycmVjdGlvbnMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZSB5b3UgaW4gU2luZ2Fw b3JlITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_6E58094ECC8D8344914996DAD28F1CCD831225DGGEMM506MBXchina_-- From nobody Sat Nov 4 23:53:10 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4966213FB51 for ; Sat, 4 Nov 2017 23:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gURBWAaQYd5G for ; Sat, 4 Nov 2017 23:53:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9285913FB4D for ; Sat, 4 Nov 2017 23:53:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRZ87141; Sun, 05 Nov 2017 06:53:03 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 5 Nov 2017 06:53:03 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Sun, 5 Nov 2017 14:52:50 +0800 From: Roni Even To: Jonathan Lennox , "Huangyihong (Rachel)" CC: IETF AVTCore WG Thread-Topic: [AVTCORE] Draft agenda for AVTCore meeting in Singapore Thread-Index: AQHTVMkLPdS0rQKFuEaIvfaJ1TOx5qMFWhjw Date: Sun, 5 Nov 2017 06:52:49 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD832245@DGGEMM506-MBX.china.huawei.com> References: <30A6BB67-D972-4812-9812-CAC07CC58560@vidyo.com> In-Reply-To: <30A6BB67-D972-4812-9812-CAC07CC58560@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD832245DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59FEB550.002A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 50da39a2b7fd485918961fb4499537ae Archived-At: Subject: Re: [AVTCORE] Draft agenda for AVTCore meeting in Singapore X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 06:53:08 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD832245DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uYXRoYW4sDQpTb21lIGFnZW5kYSBjb21tZW50cw0KDQpJIHNhdyBvbiB0aGUgYWdlbmRh DQpkcmFmdC1pZXRmLWF2dGNvcmUtcmZjNTI4NS1iaXMgICAgICAgICAgW0lFU0cgQXBwcm92ZWQs IG9uZSBvcGVuIGlzc3VlXQ0KVGhpcyBkb2N1bWVudCBpcyBwdWJsaXNoZWQgYXMgUkZDODI4NSBz byBJIGFtIG5vdCBzdXJlIHdoYXQgb3BlbiBpc3N1ZXMuDQoNCg0KZHJhZnQtaWV0Zi1hdnRjb3Jl LWFyaWEtc3J0cCAgICAgICAgICAgIFtJRVNHIEV2YWx1YXRpb25dDQoNCldhcyBwdWJsaXNoZWQg YXMgUkZDODI2OQ0KDQoNCmRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0w OQ0KICAgICAgICAgICAgW1JGQyBFZGl0b3IgUXVldWU6IE1JU1NSRUY6IDUyODViaXNdDQpXYXMg cHVibGlzaGVkIGFzIFJGQzgyODYNCg0KUm9uaQ0KDQpGcm9tOiBhdnQgW21haWx0bzphdnQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbmF0aGFuIExlbm5veA0KU2VudDog15nXlded INeVIDAzINeg15XXkdee15HXqCAyMDE3IDE5OjI3DQpUbzogSUVURiBBVlRDb3JlIFdHDQpTdWJq ZWN0OiBbQVZUQ09SRV0gRHJhZnQgYWdlbmRhIGZvciBBVlRDb3JlIG1lZXRpbmcgaW4gU2luZ2Fw b3JlDQoNClRoZSBBVlRDb3JlIHdvcmtpbmcgZ3JvdXAgd2lsbCBtZWV0IGluIFNpbmdhcG9yZSBh dCA5OjMwIEFNIG9uIFRodXJzZGF5LCBOb3ZlbWJlciAxNiwgaW4gdGhlIE9yY2hhcmQgcm9vbSBv ZiB0aGUgUmFmZmxlcyBDaXR5IENvbnZlbnRpb24gQ2VudGVyLg0KDQpPbiB0aGUgSUVURiBhZ2Vu ZGEgdGhlIGdyb3VwIHNjaGVkdWxlZCBmb3IgYSBvbmUtaG91ciBzZXNzaW9uLCBidXQgdGhlIHJv b20gaXMgZnJlZSB1bnRpbCBhdCBsZWFzdCAxMTowMCAod2hlbiBETWFyYyBpcyBzY2hlZHVsZWQg dG8gc3RhcnQpIGFuZCBwcm9iYWJseSB1bnRpbCAxMjowMCAoc2luY2UgRE1hcmMgaXMgbGlrZWx5 IHRvIGNhbmNlbCkuICBUaGUgZ3JvdXDigJlzIGN1cnJlbnQgYWdlbmRhIGlzIHNjaGVkdWxlZCB0 byBydW4gdGhyb3VnaCAxMTowMC4NCg0KV2Ugd2lsbCBhbHNvIGhhdmUgb25lIGRyYWZ0IHByZXNl bnRlZCB0aGF0IGlzIHByb3Bvc2VkIG5ldyB3b3JrIGZvciB0aGUgWFJCbG9jayB3b3JraW5nIGdy b3VwLg0KDQpUaGUgZHJhZnQgYWdlbmRhIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2FnZW5kYS0xMDAtYXZ0Y29yZS8gLiAgUGxlYXNlIHNlbmQgdGhlIGNoYWlycyBhbnkg c3VnZ2VzdGVkIGFkZGl0aW9ucywgY2hhbmdlcywgb3IgY29ycmVjdGlvbnMuDQoNClNlZSB5b3Ug aW4gU2luZ2Fwb3JlIQ0K --_000_6E58094ECC8D8344914996DAD28F1CCD832245DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIEpvbmF0aGFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Tb21lIGFnZW5kYSBjb21tZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzYXcgb24gdGhlIGFnZW5kYTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRp djtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDgu MHB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7 Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmRyYWZ0LWll dGYtYXZ0Y29yZS1yZmM1Mjg1LWJpcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg W0lFU0cgQXBwcm92ZWQsIG9uZSBvcGVuIGlzc3VlXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoaXMgZG9jdW1lbnQgaXMgcHVibGlzaGVkIGFzIFJGQzgyODUgc28gSSBh bSBub3Qgc3VyZSB3aGF0IG9wZW4gaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpw YXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4 LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9y ZGVyOm5vbmU7cGFkZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OmJsYWNrIj5kcmFmdC1pZXRmLWF2dGNvcmUtYXJpYS1zcnRwJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgW0lFU0cgRXZhbHVhdGlvbl08bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5XYXMgcHVibGlzaGVkIGFzIFJGQzgyNjk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFy YS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4w cHQgOC4wcHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1i b3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRl cjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+ZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTA5PGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtSRkMgRWRpdG9yIFF1ZXVlOiBN SVNTUkVGOiA1Mjg1YmlzXTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2FzIHB1Ymxpc2hlZCBhcyBSRkM4Mjg2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb25pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGF2dCBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb25hdGhhbiBMZW5ub3g8YnI+DQo8Yj5TZW50Ojwv Yj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV150mbmJzcDvXlSAwMyDXoNeV15HXnteR 16ggMjAxNyAxOToyNzwvc3Bhbj48YnI+DQo8Yj5Ubzo8L2I+IElFVEYgQVZUQ29yZSBXRzxicj4N CjxiPlN1YmplY3Q6PC9iPiBbQVZUQ09SRV0gRHJhZnQgYWdlbmRhIGZvciBBVlRDb3JlIG1lZXRp bmcgaW4gU2luZ2Fwb3JlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBBVlRDb3JlIHdvcmtpbmcgZ3JvdXAgd2lsbCBtZWV0IGluIFNpbmdh cG9yZSBhdCA5OjMwIEFNIG9uIFRodXJzZGF5LCBOb3ZlbWJlciAxNiwgaW4gdGhlIE9yY2hhcmQg cm9vbSBvZiB0aGUgUmFmZmxlcyBDaXR5IENvbnZlbnRpb24gQ2VudGVyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB0aGUgSUVURiBhZ2Vu ZGEgdGhlIGdyb3VwIHNjaGVkdWxlZCBmb3IgYSBvbmUtaG91ciBzZXNzaW9uLCBidXQgdGhlIHJv b20gaXMgZnJlZSB1bnRpbCBhdCBsZWFzdCAxMTowMCAod2hlbiBETWFyYyBpcyBzY2hlZHVsZWQg dG8gc3RhcnQpIGFuZCBwcm9iYWJseSB1bnRpbCAxMjowMCAoc2luY2UgRE1hcmMgaXMgbGlrZWx5 IHRvIGNhbmNlbCkuICZuYnNwO1RoZSBncm91cOKAmXMgY3VycmVudCBhZ2VuZGEgaXMgc2NoZWR1 bGVkDQogdG8gcnVuIHRocm91Z2ggMTE6MDAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdpbGwgYWxzbyBoYXZlIG9uZSBkcmFmdCBwcmVz ZW50ZWQgdGhhdCBpcyBwcm9wb3NlZCBuZXcgd29yayBmb3IgdGhlIFhSQmxvY2sgd29ya2luZyBn cm91cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIGRyYWZ0IGFnZW5kYSBpcyBhdCA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9hZ2VuZGEtMTAwLWF2dGNvcmUvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2FnZW5kYS0xMDAtYXZ0Y29yZS88L2E+Jm5ic3A7LiAmbmJzcDtQbGVhc2Ugc2Vu ZCB0aGUgY2hhaXJzIGFueSBzdWdnZXN0ZWQgYWRkaXRpb25zLCBjaGFuZ2VzLCBvciBjb3JyZWN0 aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2VlIHlvdSBpbiBTaW5nYXBvcmUhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD832245DGGEMM506MBXchina_-- From nobody Sun Nov 5 05:54:48 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027EC13F920 for ; Sun, 5 Nov 2017 05:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com 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 b3Argi_vpJ9P for ; Sun, 5 Nov 2017 05:54:45 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDBA13AF75 for ; Sun, 5 Nov 2017 05:54:44 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id f8so8116461qta.5 for ; Sun, 05 Nov 2017 05:54:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=10IiGrD9HEjEf14Fudcrn9OL2tGNYhIYJ/tdQQW51oU=; b=oJd2MMowMDY83ZUTi71n26lrCW6GHwv/o81tJ3lmlYb8C6ijRr/rU+xzDzYt6cV5xq VeC1w8dKzz3+hCljsjdnyzV1GbgHJ4jL+F73hgG/5AUUhhQUdgF6ay28fKN+UtG3Z9Ue 1N2J7a3gzxUqk4aVSwD+i4vJRF/aNk/EqBvImUS9Vd+is8spr1gY92X9B9G0a4cq02qD 8J/H9zsyNVYwmZCupr3vHX2idP1qtAL4VX6QOxucp4DcGph8/+0ySGWzo633ToZ4xLOE 3FWarbMe3fX9joT9Myu8lMYTxVi4ly5Ym7pAu8qgF/xomuvu6RAK2o0lH1qeIPm1g0M6 /BtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=10IiGrD9HEjEf14Fudcrn9OL2tGNYhIYJ/tdQQW51oU=; b=mtNixq7e3k+jXYWJA9qxPETm0sqizi8bwanurclVBt+hB6+IixYE8w1W1NMEcRgwxy IU6gQzpSM3X7Dflt22z0v7S0nX3Vnj2euXY7/PxnNIdmlZxLbXiR8Zl8GA/5oc4R/Oq4 VxfGxM9YiZe+cYj8qXL/ad/BeQR4T671Rq+W0SAcPwqMW0IPkS+4UP71QepbS5pj9xGF qnoLsyCGd6tkunrOEnS8YCT8xLd1wlI43DzH9L2IzzB8cnOuXAjSjWIQk8JxdxZTwh9+ XhiqeMv3VRWO7d1oJisW55LNd+oDiM+14+j0/t8RarkOxrv3wJSvzSgPJChh35sBui32 aApA== X-Gm-Message-State: AJaThX4olqxn/TdZcb1DxK02LdBR9E4i23xTXHZPKAInVKu31VJ2fTDw iiNVBfdIubU9RS7hjftLai4KHA== X-Google-Smtp-Source: ABhQp+QpNv7lpH70I5l5ipoQxNyF972gQPWMsRZgfD87Fr7zy88lANS0Hm2yFY4DP0t612ME+UMPLA== X-Received: by 10.200.38.194 with SMTP id 2mr17857740qtp.196.1509890083886; Sun, 05 Nov 2017 05:54:43 -0800 (PST) Received: from [192.168.2.120] (pool-100-35-229-243.nwrknj.fios.verizon.net. [100.35.229.243]) by smtp.gmail.com with ESMTPSA id m63sm6627451qke.9.2017.11.05.05.54.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 05:54:43 -0800 (PST) From: Jonathan Lennox Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_413C4BBB-7224-4FA5-8EE3-DE0A880113EF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 5 Nov 2017 08:54:48 -0500 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD832245@DGGEMM506-MBX.china.huawei.com> Cc: "Huangyihong (Rachel)" , IETF AVTCore WG To: Roni Even References: <30A6BB67-D972-4812-9812-CAC07CC58560@vidyo.com> <6E58094ECC8D8344914996DAD28F1CCD832245@DGGEMM506-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] Draft agenda for AVTCore meeting in Singapore X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 13:54:47 -0000 --Apple-Mail=_413C4BBB-7224-4FA5-8EE3-DE0A880113EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oh dear, my deepest apologies, I accidentally uploaded the agenda from = IETF 99! I=E2=80=99ve now fixed this. Please, everyone, check out the *correct* = agenda for IETF 100=E2=80=99s AVTCore session at = https://datatracker.ietf.org/doc/agenda-100-avtcore/ = . > On Nov 5, 2017, at 1:52 AM, Roni Even wrote: >=20 > Hi Jonathan, > Some agenda comments > =20 > I saw on the agenda > draft-ietf-avtcore-rfc5285-bis [IESG Approved, one open = issue] >=20 > This document is published as RFC8285 so I am not sure what open = issues. > =20 > draft-ietf-avtcore-aria-srtp [IESG Evaluation] > =20 > Was published as RFC8269 > =20 > draft-ietf-avtext-splicing-notification-09 > [RFC Editor Queue: MISSREF: 5285bis] > Was published as RFC8286 > =20 > Roni > =20 > From: avt [mailto:avt-bounces@ietf.org ] = On Behalf Of Jonathan Lennox > Sent: =D7=99=D7=95=D7=9D =D7=95 03 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 = 2017 19:27 > To: IETF AVTCore WG > Subject: [AVTCORE] Draft agenda for AVTCore meeting in Singapore > =20 > The AVTCore working group will meet in Singapore at 9:30 AM on = Thursday, November 16, in the Orchard room of the Raffles City = Convention Center. > =20 > On the IETF agenda the group scheduled for a one-hour session, but the = room is free until at least 11:00 (when DMarc is scheduled to start) and = probably until 12:00 (since DMarc is likely to cancel). The group=E2=80=99= s current agenda is scheduled to run through 11:00. > =20 > We will also have one draft presented that is proposed new work for = the XRBlock working group. > =20 > The draft agenda is at = https://datatracker.ietf.org/doc/agenda-100-avtcore/ = . Please send = the chairs any suggested additions, changes, or corrections. > =20 > See you in Singapore! --Apple-Mail=_413C4BBB-7224-4FA5-8EE3-DE0A880113EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Oh dear, my deepest apologies, I accidentally = uploaded the agenda from IETF 99!

I=E2=80=99ve now fixed this. =  Please, everyone, check out the *correct* agenda for IETF 100=E2=80=99= s AVTCore session at https://datatracker.ietf.org/doc/agenda-100-avtcore/ .=

On Nov 5, 2017, at 1:52 AM, Roni Even <roni.even@huawei.com> wrote:

Hi Jonathan,
Some agenda comments
 
I saw on the agenda

draft-ietf-avtcore-rfc5285-bis        =   [IESG Approved, one open issue]

This document is = published as RFC8285 so I am not sure what open issues.
 
draft-ietf-avtcore-aria-srtp =
           [IESG Evaluation]
 
Was published as = RFC8269
 
draft-ietf-avtext-splicing-notification-09
 =
           [RFC Editor Queue: MISSREF: =
5285bis]
Was published as = RFC8286
 
Roni
 
From: avt [mailto:avt-bounces@ietf.org] On Behalf = Of Jonathan = Lennox
Sent: =D7=99=D7=95=D7=9D =D7=95 03 =D7=A0=D7=95=D7=91=D7=9E=D7=91= =D7=A8 2017 19:27
To: IETF AVTCore WG
Subject: [AVTCORE] Draft agenda for = AVTCore meeting in Singapore
 
The AVTCore working group will meet in = Singapore at 9:30 AM on Thursday, November 16, in the Orchard room of = the Raffles City Convention Center.
 
On the IETF agenda the group scheduled for a one-hour = session, but the room is free until at least 11:00 (when DMarc is = scheduled to start) and probably until 12:00 (since DMarc is likely to = cancel).  The group=E2=80=99s current agenda is scheduled to run = through 11:00.
 
We will also have one draft presented that is = proposed new work for the XRBlock working group.
 
The draft agenda is at https://datatracker.ietf.org/doc/agenda-100-avtcore/ .=  Please send the chairs any suggested additions, changes, or = corrections.
 
See you in = Singapore!

= --Apple-Mail=_413C4BBB-7224-4FA5-8EE3-DE0A880113EF-- From nobody Tue Nov 7 23:07:28 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A971D131675 for ; Tue, 7 Nov 2017 23:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2om0VHnk-Ya8 for ; Tue, 7 Nov 2017 23:07:25 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B171317AE for ; Tue, 7 Nov 2017 23:04:56 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id f66so1281866oib.2 for ; Tue, 07 Nov 2017 23:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=y1EzM/cD9XrcvQKWaWobrYclBQzI5bTs2RHMlaYOiT8=; b=na23Q4qcAqNRE5RfoJCZIrlbJ9V2FgVaFzrKzojvbjg7bBN5SY70tjgW6oopqfw24z +FbOLKl9c0eK0BB3ckj14SKyZIvLIYeo49Visfvv/sL7u65dF/HxsCfAEZv6xQZutul6 Zg9fUiXGy5KIx7TzWiYU/9GJ28cEf06rZNLJW65gcFW+nnz37DSiQ/DslSdn4Dg72W7B ercV/tXEDmNCXYF68HsF7y2yWkIDWY8vC8VWhE7mlZY20DowoXeSBDRqAiiGc7NXt3Su okCsA3yh8ctbJb6CW4X5iWhlIZx88px9eeF6CQzsHI/Os5l1n2IXVNsPd8/k1fVy5R3H WDxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=y1EzM/cD9XrcvQKWaWobrYclBQzI5bTs2RHMlaYOiT8=; b=IY5PCJkz9fR3ULkjptRxACinWSBemSlmmH0pAbunBZOsyiKJ9Kynx3yvGx86dI6Olj 07eRFw2IZ5Ou51gwbHb1WzABEViX+zuBu7gzcnckx+8c28OJPv0B/4UKGtYVB1AuBa6p 7SUzsE5NqEXFhiHo7JIo3vmIEmE8NtIr0EUx+2U42sjmoFbkpVSvQZTH1zomF3nSC5FW zJc5r5yZPb6LC90DNIx0EK6n81LgjfliA273p6s/DnD2wcU0vqUmgvgMsGjlZS4sdnPn d9C+EAIrFgbrgXc5SZpR2/8uucbeZUROsRDCkYLNhQXDkByVKQB99vHVhPiCLbGxcXUs fXIg== X-Gm-Message-State: AJaThX6nTolvAtTX7JebJCyqJnjP411GUOgc+hRshY4CCxS725W216yV 0ir/c614pKs6rRLHYp1GMi1+C5NO+OTjb0WT4w9boQ== X-Google-Smtp-Source: ABhQp+S+fD/TZEn0lg6XZRo34fcPqoLVMIqXunhYZJk3JXR3wL6lRrwFZzcl6HQOjsm7AnFh8Hr2qS+4UUBYrAOnxpw= X-Received: by 10.202.225.130 with SMTP id y124mr745368oig.88.1510124695750; Tue, 07 Nov 2017 23:04:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.155 with HTTP; Tue, 7 Nov 2017 23:04:55 -0800 (PST) From: Martin Thomson Date: Wed, 8 Nov 2017 18:04:55 +1100 Message-ID: To: "avt@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 07:07:26 -0000 This is a timely contribution. We'll be discussing this in the first QUIC session at IETF 100 (Tuesday 1330). I encourage people who care about this topic to attend. I won't be present for the Thursday morning avtcore session, so I thought that I'd provide my input on the list. I think that there are several considerations the draft doesn't give due consideration. First is the set of things that need to be multiplexed. The draft mostly seems to assume that everything needs to be multiplexed with everything else. This is not necessary, as far as I can see. - I still don't understand why RFC 7983 gives TURN channels top billing. If I'm talking to a TURN server, that link only ever sees STUN and TURN channels. I would not expect to see SRTP. I might see DTLS if I was using STUN over DTLS, but I wouldn't expect to see QUIC. - I don't know if we care about ZRTP. - I don't see any case for needing to demux DTLS and QUIC. The draft talks about DTLS-SRTP for keying SRTP, but the observation I'd make here is that QUIC has a TLS handshake. That handshake can happily carry the use_srtp extension. In other words, if you are serious, QUIC-SRTP isn't that much of a stretch. - If RTP is being sent *inside* QUIC, you don't care about demux between QUIC and SRTP any more. I guess you could send RTP in two places between the same two peers, but that seems like something that could be ruled out. Second is that this doesn't really give due credit to the role of signaling in protecting properties you care about. For instance, one of the gnarlier bits of the multiplexing puzzle is the QUIC Version Negotiation packet, which doesn't include any integrity check (as of this moment, that is). Signaling could be used to ensure that Version Negotiation never has to happen. It also opens up other more ... disruptive ... options as well. Third is the strategies that the draft proposes. I agree that these are three options (I've a few corrections on my suggested strategy to add below). But this list is not exhaustive. Option 0: crypto An important observation to make is that (almost) all the packets that need to be demultiplexed use a cryptographic integrity check in some form (MESSAGE-INTEGRITY, HMAC, AEAD, etc...) That means that if all else fails, an implementation could feed every packet to every stack and the right thing would happen. Keep that in mind when it comes to this discussion, because it highlights the fact that this is all about optimization. Option 4: a new QUIC version As I observed, if version negotiation is possible, then negotiating a new QUIC version is possible. That new version could be defined with maximum compatibility for multiplexing. For instance, it might define new packet types that cause critical messages to land in gaps in the RFC 7983 table. It is possible that this is the ONLY change that it makes - QUIC versions numbers are inexpensive. On the heuristics option, there are a few things: - I would never consider DTLS-SRTP in addition to QUIC if you have QUIC-SRTP. - the document should talk about reordering a little. Application data in QUIC can arrive before the final handshake packets. This isn't something I originally mentioned, but it does have an effect on the multiplexing scheme. The potential for overlap is transitory though. - just bundle the initial ICE checks with the consent checks when talking about this. You could find a way to disable ICE-level consent and replace it with QUIC PING/PONG, but I don't see the point. A few (minor) errors: - clause 2.a is a non-requirement, because QUIC Initial, Handshake, Retry, and 0-RTT packets have to use the long header; similarly, clause 3.a is a non-requirement, because 1-RTT protected packets have to use the short header (though this is a recent change); that invalidates the alternative in clause 3.c.i. - clause 3.d.i talks about collisions (on the first octet) between QUIC handshake packets and STUN, but handshake packets always have the high bit of the octet set. STUN actually conflicts with all QUIC packets. Finally, I would say that the multiplexing scheme that realtime protocols use doesn't have any sort of architectural or moral right to continue to exist. The draft implies that multiplexing in the way enshrined in RFC 7983 is some goal that needs to be protected, even as new protocols are added into the mix. I don't think that claim is necessarily true. RFC 7983 describes a protocol. That protocol is the composit of up to 5 protocols. Those protocols were simply glued together and by some combination of luck and planning they avoided collisions. Any new protocol either fits into this scheme or not. If we want that new protocol to fit, and can make it happen, great, but that doesn't mean that every new protocol has to fit. Insisting that all protocols that use UDP fit into this system is not sustainable. There's little enough free space left already. For this reason, the option where modifications are made to QUIC is a bad option. Not because QUIC can't afford the bits, but more for the precedent it establishes. (I recall similar objections from the TLS people, and rightly so.) From nobody Wed Nov 8 02:04:06 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52440131945 for ; Wed, 8 Nov 2017 02:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 z_Jq-7ZMqLxM for ; Wed, 8 Nov 2017 02:04:03 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1A813192E for ; Wed, 8 Nov 2017 02:04:02 -0800 (PST) X-AuditID: c1b4fb3a-1c7889c000006897-37-5a02d690f939 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.37.26775.096D20A5; Wed, 8 Nov 2017 11:04:00 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Wed, 8 Nov 2017 11:03:59 +0100 From: Christer Holmberg To: Martin Thomson , "avt@ietf.org" Thread-Topic: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing Thread-Index: AQHTWGA+fW04DO4ezkOmM+BTR83iW6MKQAAQ Date: Wed, 8 Nov 2017 10:03:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C6959C2@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7pe6Ea0xRBjc+WFm87FnJbnHtzD9G ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjwJkutoLZhhUXmreyNzBOU+9i5OSQEDCR +Lz/PROILSRwmFFi5g7+LkYuIHsRo8SW2cuZuxg5ONgELCS6/2mD1IgI+EhM+P6eESQsLOAh cWqdIkTYU2L5lk1sELaRxIJX+8FsFgEViWN337OC2LwCvhKnzm5jg1gVINH0u58RxOYUCJQ4 svoVM4jNKCAm8f3UGrBzmAXEJW49mc8EcaaAxJI955khbFGJl4//sULYShKNS56wQtTrSCzY /YkNwtaWWLbwNTPEXkGJkzOfsExgFJmFZOwsJC2zkLTMQtKygJFlFaNocWpxcW66kZFealFm cnFxfp5eXmrJJkZgLBzc8ttqB+PB546HGAU4GJV4eNu3MkUJsSaWFVfmHmKU4GBWEuE9dxYo xJuSWFmVWpQfX1Sak1p8iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwTB6dUA2MDp8BGLxsF i2kLJKYs/v+5NcHlZVbZuooIoZLEfuktBazNDpZTI9lMGLtn6c3tf2twpyFo7nQ+M03eG4Ir /m1g5ClxZvvweysfa+DDT4aPVxlMt/58zWjOBzMH4aCLxXMlW/eYmG0w5l47Kb3rgr2TusEW y5SXrbNYg5RVBEsvuU/56x13T4mlOCPRUIu5qDgRAKWvwXqBAgAA Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 10:04:05 -0000 Hi, A few initial questions: Q1: ----- The Abstract says: "This document describes potential approaches to multiplexing of QUIC along with RTP, RTCP, DTLS, STUN, TURN and ZRTP in WebRTC peer-to- peer data exchange." Is there a reason why this is limited to WebRTC? And, if it is, I think it should be indicated in the draft title. "QUIC Mul= tiplexing for WebRTC", or something like that. Q2: ----- Is the intention to include SDP O/A procedures in the draft? Regards, Christer -----Original Message----- From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Martin Thomson Sent: 08 November 2017 09:05 To: avt@ietf.org Subject: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing This is a timely contribution. We'll be discussing this in the first QUIC = session at IETF 100 (Tuesday 1330). I encourage people who care about this= topic to attend. I won't be present for the Thursday morning avtcore sess= ion, so I thought that I'd provide my input on the list. I think that there are several considerations the draft doesn't give due co= nsideration. First is the set of things that need to be multiplexed. The draft mostly s= eems to assume that everything needs to be multiplexed with everything else= . This is not necessary, as far as I can see. - I still don't understand why RFC 7983 gives TURN channels top billing. I= f I'm talking to a TURN server, that link only ever sees STUN and TURN chan= nels. I would not expect to see SRTP. I might see DTLS if I was using STU= N over DTLS, but I wouldn't expect to see QUIC. - I don't know if we care about ZRTP. - I don't see any case for needing to demux DTLS and QUIC. The draft talks= about DTLS-SRTP for keying SRTP, but the observation I'd make here is that= QUIC has a TLS handshake. That handshake can happily carry the use_srtp e= xtension. In other words, if you are serious, QUIC-SRTP isn't that much of= a stretch. - If RTP is being sent *inside* QUIC, you don't care about demux between QU= IC and SRTP any more. I guess you could send RTP in two places between the= same two peers, but that seems like something that could be ruled out. Second is that this doesn't really give due credit to the role of signaling= in protecting properties you care about. For instance, one of the gnarlie= r bits of the multiplexing puzzle is the QUIC Version Negotiation packet, w= hich doesn't include any integrity check (as of this moment, that is). Sig= naling could be used to ensure that Version Negotiation never has to happen= . It also opens up other more ... disruptive ... options as well. Third is the strategies that the draft proposes. I agree that these are th= ree options (I've a few corrections on my suggested strategy to add below).= But this list is not exhaustive. Option 0: crypto An important observation to make is that (almost) all the packets that need= to be demultiplexed use a cryptographic integrity check in some form (MESS= AGE-INTEGRITY, HMAC, AEAD, etc...) That means that if all else fails, an i= mplementation could feed every packet to every stack and the right thing wo= uld happen. Keep that in mind when it comes to this discussion, because it= highlights the fact that this is all about optimization. Option 4: a new QUIC version As I observed, if version negotiation is possible, then negotiating a new Q= UIC version is possible. That new version could be defined with maximum co= mpatibility for multiplexing. For instance, it might define new packet typ= es that cause critical messages to land in gaps in the RFC 7983 table. It = is possible that this is the ONLY change that it makes - QUIC versions numb= ers are inexpensive. On the heuristics option, there are a few things: - I would never consider DTLS-SRTP in addition to QUIC if you have QUIC-SRT= P. - the document should talk about reordering a little. Application data in = QUIC can arrive before the final handshake packets. This isn't something I= originally mentioned, but it does have an effect on the multiplexing schem= e. The potential for overlap is transitory though. - just bundle the initial ICE checks with the consent checks when talking a= bout this. You could find a way to disable ICE-level consent and replace it= with QUIC PING/PONG, but I don't see the point. A few (minor) errors: - clause 2.a is a non-requirement, because QUIC Initial, Handshake, Retry, = and 0-RTT packets have to use the long header; similarly, clause 3.a is a n= on-requirement, because 1-RTT protected packets have to use the short heade= r (though this is a recent change); that invalidates the alternative in cla= use 3.c.i. - clause 3.d.i talks about collisions (on the first octet) between QUIC han= dshake packets and STUN, but handshake packets always have the high bit of = the octet set. STUN actually conflicts with all QUIC packets. Finally, I would say that the multiplexing scheme that realtime protocols u= se doesn't have any sort of architectural or moral right to continue to exi= st. The draft implies that multiplexing in the way enshrined in RFC 7983 i= s some goal that needs to be protected, even as new protocols are added int= o the mix. I don't think that claim is necessarily true. RFC 7983 describes a protocol. That protocol is the composit of up to 5 protocols. Those protocols were simply glued together and by some combin= ation of luck and planning they avoided collisions. Any new protocol eithe= r fits into this scheme or not. If we want that new protocol to fit, and can make it happen, great, but tha= t doesn't mean that every new protocol has to fit. Insisting that all prot= ocols that use UDP fit into this system is not sustainable. There's little= enough free space left already. For this reason, the option where modifications are made to QUIC is a bad o= ption. Not because QUIC can't afford the bits, but more for the precedent = it establishes. (I recall similar objections from the TLS people, and righ= tly so.) _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From nobody Wed Nov 8 08:46:15 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D6A128AFE for ; Wed, 8 Nov 2017 08:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZHSjHBklS1Gn for ; Wed, 8 Nov 2017 08:46:13 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 631D7128A32 for ; Wed, 8 Nov 2017 08:46:13 -0800 (PST) X-AuditID: 1207440d-853ff70000000f42-1d-5a0334d231c7 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 9C.4E.03906.3D4330A5; Wed, 8 Nov 2017 11:46:11 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vA8Gk93h027038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 8 Nov 2017 11:46:10 -0500 To: avt@ietf.org References: From: Paul Kyzivat Message-ID: <98e9fdcc-6408-edc7-1cd8-d724d9e0d3c0@alum.mit.edu> Date: Wed, 8 Nov 2017 11:46:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixO6iqHvFhDnK4F4To8XLnpXsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOP5qD0vBHo6Kqw2f2BsYL7F1MXJySAiYSEx8/Ie1i5GLQ0hg B5PE3HPPoZzPTBKPvn1lB6kSFvCQOHt0JpgtIiAgsWL7XxYQW0ggQKLpdz8jiM0moCUx59B/ sDivgL3El4tvmUBsFgEVid+fX4P1igqkSdyZ8ZAJokZQ4uTMJ2D1nAKBEkdWv2IGsZkFzCTm bX4IZYtL3HoynwnClpfY/nYO8wRG/llI2mchaZmFpGUWkpYFjCyrGOUSc0pzdXMTM3OKU5N1 i5MT8/JSi3SN9HIzS/RSU0o3MULCkncH4/91MocYBTgYlXh4NRSZooRYE8uKK3MPMUpyMCmJ 8j54BRTiS8pPqcxILM6ILyrNSS0+xCjBwawkwturzxwlxJuSWFmVWpQPk5LmYFES51Vbou4n JJCeWJKanZpakFoEk5Xh4FCS4OUAxp+QYFFqempFWmZOCUKaiYMTZDgP0PCNxiDDiwsSc4sz 0yHypxiNOXp6bvxh4ng283UDsxBLXn5eqpQ4bytIqQBIaUZpHtw0WGp5xSgO9JwwryXIUh5g WoKb9wpoFRPQqv0hDCCrShIRUlINjNHzpt4XfLIxPFfHTuPe68dBYZ/Pusw+l2YZNMljxeXm stSbF/5/ENNZfPanQatE+rrY8xGVFlHf1mefyn3weU5jgGDou6DVciUm/oIW/4Pa0tauP2RQ Kc6mfmWF6Ob5s5bMu+qyY2bxnCLrw1b+zy7biSxJMz0Y9eyjU4nPLWmp46siizw0K5VYijMS DbWYi4oTAfl3zJ0IAwAA Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 16:46:15 -0000 On 11/8/17 2:04 AM, Martin Thomson wrote: > Finally, I would say that the multiplexing scheme that realtime > protocols use doesn't have any sort of architectural or moral right to > continue to exist. The draft implies that multiplexing in the way > enshrined in RFC 7983 is some goal that needs to be protected, even as > new protocols are added into the mix. I don't think that claim is > necessarily true. > > RFC 7983 describes a protocol. That protocol is the composit of up to > 5 protocols. Those protocols were simply glued together and by some > combination of luck and planning they avoided collisions. Any new > protocol either fits into this scheme or not. > > If we want that new protocol to fit, and can make it happen, great, > but that doesn't mean that every new protocol has to fit. Insisting > that all protocols that use UDP fit into this system is not > sustainable. There's little enough free space left already. +1 The technique of 9783 is a hack to avoid formalizing another layer in the protocol stack. Thanks, Paul From nobody Wed Nov 8 10:50:04 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534A6129B15 for ; Wed, 8 Nov 2017 10:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oGdVv6S8z8Sf for ; Wed, 8 Nov 2017 10:50:00 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579CE129AFC for ; Wed, 8 Nov 2017 10:50:00 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id 65so2637995uaq.8 for ; Wed, 08 Nov 2017 10:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2fPxT1L8XXSepyQ1OKdBObVr2DJCq5fV/OkJFJqDKUo=; b=jBn25TKN75TpF85q1AbYrwCMpWoKRAfmH1GmdQYJsTnGkr2lFXbNave/Q0rZs+Yoqf roS9Si7fch1fr8MMvZtOvXeTtBkc2LJhy3ymxxVqYyvaNXBbDgvabaWsQb5aR5Y6s5tM 3j37W39Y1BvHopiP+s9TUwhdbJ/rKRRJEbxjnz0PXwoJJ4NrCqV9l0OT2bfwg9js9Rsx L7GnSmoEaoUP196gKysDH+FAp//ccMFAmec/RTAcQBhuh6VZSfv2FS3L3U+VGZOvK5E4 rVKPXAMnruvDcisGeZltoA1bM9dgEawW33oumcFbOuG9VPe+0OOTpjn+dLDmnUXmsaoO dWOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2fPxT1L8XXSepyQ1OKdBObVr2DJCq5fV/OkJFJqDKUo=; b=Vx6KIx0Hu8rxUrNqCu8n4FsXfJPn8goLYCRFje2Sj0yjJP1LtMl77tMIkOIMrO1qLU Lfkttt2Cl29LealoSltGo23DTiCuch/jongPPUO9XOeh7Pn5pV5Na1wFsnqREUs+MaFF RXS1OEekTlrXje0RATjN3sWv06JD4Pg6zryglNt00UgyjVvXvX5WtKodDfmOpB17hVw8 puqKPUtL67RQalJGkLtZvvY7fg5z3fv/ZciodlRNfTtafEMtpWaycCqHGv34HxvwYXAR 983ziX+88gqge1EHZooRAYmhUmwNwp9mdNuugvv+/NacgL1EuFSPZ68WJjOBopJKv7TL 6Vkg== X-Gm-Message-State: AJaThX4UYpL++zh2bpZhiU2zctZDOP9v9AzE4ztH+AYi4c654RV/iyZ1 LhM3GhahayUWoZXok7hpqS+oO8hj0Yu3pfSSnGQ= X-Google-Smtp-Source: ABhQp+RA8zXfxeQFS/nFQesBLgYv5/o9GiwWss+PCfADAGWAFY9cpgGY5iC/vaAEOr1zbBD6xS2VQ9c+hY0BrxHd2Dg= X-Received: by 10.176.64.131 with SMTP id i3mr1279341uad.195.1510166999157; Wed, 08 Nov 2017 10:49:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Wed, 8 Nov 2017 10:49:38 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 8 Nov 2017 10:49:38 -0800 Message-ID: To: Martin Thomson Cc: "avt@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c12370e8952e1055d7d275b" Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 18:50:03 -0000 --94eb2c12370e8952e1055d7d275b Content-Type: text/plain; charset="UTF-8" Martin said: "- I don't see any case for needing to demux DTLS and QUIC." [BA] Demuplexing of QUIC and DTLS is a requirement for initial deployments of peer-to-peer QUIC data exchange, since in those initial deployments DTLS-SRTP, SRTP/SRTCP and even the SCTP/DTLS/UDP data channel will continue to be used. Supporting multiplexing of DTLS and QUIC allows QUIC usage scenarios to be progressively rolled out as standards and implementation work is completed, rather than requiring that everything be done before anything can happen. While QUIC may eventually be widely used for SRTP keying (QUIC-SRTP), trasnport of RTP, and all data exchange scenarios (obsoleting the existing SCTP/DTLS/UDP data channel), it seems unwise to mandate that all of those QUIC uses be standardized and successfully deployed before enabling the first step toward peer-to-peer use of QUIC by enabling QUIC data exchange. At the moment, it is not even clear that peer-to-peer QUIC data exchange based on the QUIC transport document can completely substitute for all of the potential uses of the SCTP data channel (such as unreliable, low-latency data exchange in games), so that applications could conceivably wish to use both the SCTP data channel and QUIC data exchange in their applications. Martin also said: "If we want that new protocol to fit, and can make it happen, great, but that doesn't mean that every new protocol has to fit. " [BA] I would agree that attempting to support "every new protocol" would be difficult and unnecessary. On the other hand, QUIC may not be the last protocol that needs to multiplex with other protocols covered by RFC 7983, so that figuring out how this works is important. On Tue, Nov 7, 2017 at 11:04 PM, Martin Thomson wrote: > This is a timely contribution. We'll be discussing this in the first > QUIC session at IETF 100 (Tuesday 1330). I encourage people who care > about this topic to attend. I won't be present for the Thursday > morning avtcore session, so I thought that I'd provide my input on the > list. > > I think that there are several considerations the draft doesn't give > due consideration. > > First is the set of things that need to be multiplexed. The draft > mostly seems to assume that everything needs to be multiplexed with > everything else. This is not necessary, as far as I can see. > > - I still don't understand why RFC 7983 gives TURN channels top > billing. If I'm talking to a TURN server, that link only ever sees > STUN and TURN channels. I would not expect to see SRTP. I might see > DTLS if I was using STUN over DTLS, but I wouldn't expect to see QUIC. > > - I don't know if we care about ZRTP. > > - I don't see any case for needing to demux DTLS and QUIC. The draft > talks about DTLS-SRTP for keying SRTP, but the observation I'd make > here is that QUIC has a TLS handshake. That handshake can happily > carry the use_srtp extension. In other words, if you are serious, > QUIC-SRTP isn't that much of a stretch. > > - If RTP is being sent *inside* QUIC, you don't care about demux > between QUIC and SRTP any more. I guess you could send RTP in two > places between the same two peers, but that seems like something that > could be ruled out. > > Second is that this doesn't really give due credit to the role of > signaling in protecting properties you care about. For instance, one > of the gnarlier bits of the multiplexing puzzle is the QUIC Version > Negotiation packet, which doesn't include any integrity check (as of > this moment, that is). Signaling could be used to ensure that Version > Negotiation never has to happen. It also opens up other more ... > disruptive ... options as well. > > Third is the strategies that the draft proposes. I agree that these > are three options (I've a few corrections on my suggested strategy to > add below). But this list is not exhaustive. > > Option 0: crypto > > An important observation to make is that (almost) all the packets that > need to be demultiplexed use a cryptographic integrity check in some > form (MESSAGE-INTEGRITY, HMAC, AEAD, etc...) That means that if all > else fails, an implementation could feed every packet to every stack > and the right thing would happen. Keep that in mind when it comes to > this discussion, because it highlights the fact that this is all about > optimization. > > Option 4: a new QUIC version > > As I observed, if version negotiation is possible, then negotiating a > new QUIC version is possible. That new version could be defined with > maximum compatibility for multiplexing. For instance, it might define > new packet types that cause critical messages to land in gaps in the > RFC 7983 table. It is possible that this is the ONLY change that it > makes - QUIC versions numbers are inexpensive. > > On the heuristics option, there are a few things: > > - I would never consider DTLS-SRTP in addition to QUIC if you have > QUIC-SRTP. > > - the document should talk about reordering a little. Application > data in QUIC can arrive before the final handshake packets. This > isn't something I originally mentioned, but it does have an effect on > the multiplexing scheme. The potential for overlap is transitory > though. > > - just bundle the initial ICE checks with the consent checks when > talking about this. You could find a way to disable ICE-level consent > and replace it with QUIC PING/PONG, but I don't see the point. > > A few (minor) errors: > > - clause 2.a is a non-requirement, because QUIC Initial, Handshake, > Retry, and 0-RTT packets have to use the long header; similarly, > clause 3.a is a non-requirement, because 1-RTT protected packets have > to use the short header (though this is a recent change); that > invalidates the alternative in clause 3.c.i. > - clause 3.d.i talks about collisions (on the first octet) between > QUIC handshake packets and STUN, but handshake packets always have the > high bit of the octet set. STUN actually conflicts with all QUIC > packets. > > Finally, I would say that the multiplexing scheme that realtime > protocols use doesn't have any sort of architectural or moral right to > continue to exist. The draft implies that multiplexing in the way > enshrined in RFC 7983 is some goal that needs to be protected, even as > new protocols are added into the mix. I don't think that claim is > necessarily true. > > RFC 7983 describes a protocol. That protocol is the composit of up to > 5 protocols. Those protocols were simply glued together and by some > combination of luck and planning they avoided collisions. Any new > protocol either fits into this scheme or not. > > If we want that new protocol to fit, and can make it happen, great, > but that doesn't mean that every new protocol has to fit. Insisting > that all protocols that use UDP fit into this system is not > sustainable. There's little enough free space left already. > > For this reason, the option where modifications are made to QUIC is a > bad option. Not because QUIC can't afford the bits, but more for the > precedent it establishes. (I recall similar objections from the TLS > people, and rightly so.) > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --94eb2c12370e8952e1055d7d275b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin said:=C2=A0

"- I don't see any case for needing to demux DTLS and= QUIC."

<= /div>
[BA] Demuplexing of QUIC and DTL= S is a requirement for initial deployments of
peer-to-peer QUIC data exchange, since in those initi= al deployments DTLS-SRTP,
SRTP/SRTCP and even the SCTP/DTLS/UDP data channel will continue to be use= d.

= Supporting multiplexing of DTLS and QUIC a= llows QUIC usage scenarios to be
progressively rolled out as standards and implementation work is co= mpleted, rather
than requ= iring that everything be done before anything can happen.=C2=A0

While QUIC may eventually be widely used for SRTP keying= (QUIC-SRTP),=C2=A0
trasn= port of RTP, and all data exchange scenarios (obsoleting the existing
SCTP/DTLS/UDP data channel), i= t seems unwise to mandate that all of those
QUIC uses be standardized and successfully deployed befo= re enabling
the first ste= p toward=C2=A0=C2=A0peer-to-peer us= e of QUIC by enabling QUIC data
exchange.=C2=A0=C2=A0

At the moment,= it is not even clear that peer-to-peer QUIC data exchange=C2=A0
= based on the QUIC transport document can completely substitute for all of= =C2=A0
the potential uses of the SCTP data channel (such as unrel= iable, low-latency
data exchange in games), so that applications = could conceivably wish to use
both the SCTP data channel and QUIC= data exchange in their applications.=C2=A0

Martin= also said:=C2=A0

"If we want that new protocol to fit, and can make it happen, great,<= /span>
but that doesn't mean= that every new protocol has to fit.=C2=A0"

[BA] I would agree that attempting to support "every new protoco= l" would be=C2=A0
difficult and unnecessary.=C2=A0 On the ot= her hand, QUIC may not be the last
protocol that needs to multipl= ex with other protocols covered by RFC 7983, so
that figuring out= how this works is important.=C2=A0



On Tue, Nov 7, = 2017 at 11:04 PM, Martin Thomson <martin.thomson@gmail.com><= /span> wrote:
This is a timely contributi= on.=C2=A0 We'll be discussing this in the first
QUIC session at IETF 100 (Tuesday 1330).=C2=A0 I encourage people who care<= br> about this topic to attend.=C2=A0 I won't be present for the Thursday morning avtcore session, so I thought that I'd provide my input on the<= br> list.

I think that there are several considerations the draft doesn't give due consideration.

First is the set of things that need to be multiplexed.=C2=A0 The draft
mostly seems to assume that everything needs to be multiplexed with
everything else.=C2=A0 This is not necessary, as far as I can see.

- I still don't understand why RFC 7983 gives TURN channels top
billing.=C2=A0 If I'm talking to a TURN server, that link only ever see= s
STUN and TURN channels.=C2=A0 I would not expect to see SRTP.=C2=A0 I might= see
DTLS if I was using STUN over DTLS, but I wouldn't expect to see QUIC.<= br>
- I don't know if we care about ZRTP.

- I don't see any case for needing to demux DTLS and QUIC.=C2=A0 The dr= aft
talks about DTLS-SRTP for keying SRTP, but the observation I'd make
here is that QUIC has a TLS handshake.=C2=A0 That handshake can happily
carry the use_srtp extension.=C2=A0 In other words, if you are serious,
QUIC-SRTP isn't that much of a stretch.

- If RTP is being sent *inside* QUIC, you don't care about demux
between QUIC and SRTP any more.=C2=A0 I guess you could send RTP in two
places between the same two peers, but that seems like something that
could be ruled out.

Second is that this doesn't really give due credit to the role of
signaling in protecting properties you care about.=C2=A0 For instance, one<= br> of the gnarlier bits of the multiplexing puzzle is the QUIC Version
Negotiation packet, which doesn't include any integrity check (as of this moment, that is).=C2=A0 Signaling could be used to ensure that Version=
Negotiation never has to happen.=C2=A0 It also opens up other more ...
disruptive ... options as well.

Third is the strategies that the draft proposes.=C2=A0 I agree that these are three options (I've a few corrections on my suggested strategy to add below).=C2=A0 But this list is not exhaustive.

Option 0: crypto

An important observation to make is that (almost) all the packets that
need to be demultiplexed use a cryptographic integrity check in some
form (MESSAGE-INTEGRITY, HMAC, AEAD, etc...)=C2=A0 That means that if all else fails, an implementation could feed every packet to every stack
and the right thing would happen.=C2=A0 Keep that in mind when it comes to<= br> this discussion, because it highlights the fact that this is all about
optimization.

Option 4: a new QUIC version

As I observed, if version negotiation is possible, then negotiating a
new QUIC version is possible.=C2=A0 That new version could be defined with<= br> maximum compatibility for multiplexing.=C2=A0 For instance, it might define=
new packet types that cause critical messages to land in gaps in the
RFC 7983 table.=C2=A0 It is possible that this is the ONLY change that it makes - QUIC versions numbers are inexpensive.

On the heuristics option, there are a few things:

- I would never consider DTLS-SRTP in addition to QUIC if you have QUIC-SRT= P.

- the document should talk about reordering a little.=C2=A0 Application
data in QUIC can arrive before the final handshake packets.=C2=A0 This
isn't something I originally mentioned, but it does have an effect on the multiplexing scheme.=C2=A0 The potential for overlap is transitory
though.

- just bundle the initial ICE checks with the consent checks when
talking about this. You could find a way to disable ICE-level consent
and replace it with QUIC PING/PONG, but I don't see the point.

A few (minor) errors:

- clause 2.a is a non-requirement, because QUIC Initial, Handshake,
Retry, and 0-RTT packets have to use the long header; similarly,
clause 3.a is a non-requirement, because 1-RTT protected packets have
to use the short header (though this is a recent change); that
invalidates the alternative in clause 3.c.i.
- clause 3.d.i talks about collisions (on the first octet) between
QUIC handshake packets and STUN, but handshake packets always have the
high bit of the octet set.=C2=A0 STUN actually conflicts with all QUIC
packets.

Finally, I would say that the multiplexing scheme that realtime
protocols use doesn't have any sort of architectural or moral right to<= br> continue to exist.=C2=A0 The draft implies that multiplexing in the way
enshrined in RFC 7983 is some goal that needs to be protected, even as
new protocols are added into the mix.=C2=A0 I don't think that claim is=
necessarily true.

RFC 7983 describes a protocol.=C2=A0 That protocol is the composit of up to=
5 protocols.=C2=A0 Those protocols were simply glued together and by some combination of luck and planning they avoided collisions.=C2=A0 Any new
protocol either fits into this scheme or not.

If we want that new protocol to fit, and can make it happen, great,
but that doesn't mean that every new protocol has to fit.=C2=A0 Insisti= ng
that all protocols that use UDP fit into this system is not
sustainable.=C2=A0 There's little enough free space left already.

For this reason, the option where modifications are made to QUIC is a
bad option.=C2=A0 Not because QUIC can't afford the bits, but more for = the
precedent it establishes.=C2=A0 (I recall similar objections from the TLS people, and rightly so.)

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

--94eb2c12370e8952e1055d7d275b-- From nobody Wed Nov 8 11:13:24 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BBA128990 for ; Wed, 8 Nov 2017 11:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 TzILM1wgkVMN for ; Wed, 8 Nov 2017 11:13:21 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C50F129B4C for ; Wed, 8 Nov 2017 11:13:21 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA8JDIe1024849 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 8 Nov 2017 13:13:19 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Bernard Aboba , Martin Thomson Cc: "avt@ietf.org" References: From: Adam Roach Message-ID: <37be0b2e-822b-4db3-68f2-518339e8a562@nostrum.com> Date: Wed, 8 Nov 2017 13:13:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:13:23 -0000 [as individual] On 11/8/17 12:49 PM, Bernard Aboba wrote: > [BA] I would agree that attempting to support "every new protocol" > would be > difficult and unnecessary.  On the other hand, QUIC may not be the last > protocol that needs to multiplex with other protocols covered by RFC > 7983, so > that figuring out how this works is important. > It worked by pure luck. I agree with Martin: that's not a sustainable model. I'm kind of ambivalent about the QUIC work under discussion (mostly because I haven't looked at the use cases in detail), but if you're envisioning some kind of UDP-wide /etc/magic approach, I urge you to stop. /a From nobody Wed Nov 8 12:44:36 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F400012957F for ; Wed, 8 Nov 2017 12:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JFcJf8hCTOYv for ; Wed, 8 Nov 2017 12:44:32 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F7C126579 for ; Wed, 8 Nov 2017 12:44:32 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id 207so32141pgc.12 for ; Wed, 08 Nov 2017 12:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CrBoNTHHmuaiqzN1l7m8hOfP0cB7NnQb3fn6qn9YlRA=; b=K4rQyGXbC4MBAi1C/zizLU3u0m3AqvwYx4oiIStPx1QyPkw4MUo1EE4xsHE3vU3FDB C8uEzSTm1n/Ipc8S2TIacPn5p2bAN65As/BaPjqG+EQuOWLAQbqJMoXeiRQlLDEf59/i 8oRNskr6XAo5+6yK9jINy+QXy4KecJdMzrO8cBDefOQq64jM0qySPAl6P5YG1kqQBPVo K/qw8ZvRjKkYQj1d1aKA2LSRtHEEEj9tOGp8i343nbgqmMCtI5V2ME2gb5XAjySkXi3a C3AM2vDHGfF9grdbAyT6TXpSsO/YNE0Ih8ON7w8P1NElK0iBqVeXkmx4Cf3w+Lo/zDjb Ul5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CrBoNTHHmuaiqzN1l7m8hOfP0cB7NnQb3fn6qn9YlRA=; b=smuwVJJovm6uDo0d7FRSNLVIw6W9iNR+NjN8AOcLKLWw2JocjEN6UpMoQW0YLnhZNC xLfMnCtsOBPr3gA6G1WmVaw9TMj8qXUPrAxbQJf0iZNcpemG3QHJ1gFjwmqA/CAMWM0C IX0eKlA8UMVaEbh8AvuYUduZIXNy+Z8iLvk9QufrZs9xCWVKVV0FbJf/iZc/RSlqsiet fYv5H7aOLjJ78ecb8K2WrdwWHmqh8289e1Lpl84YCCjTrbX2ZPJPIP8gc4HNmGiVi+kA FtjlWi0XHshoCArjCn3Mo5ESevUIrYt7k42upmJ9ZKr71oUN07y+hG4RWnn6kEpaP1Z1 3Wfw== X-Gm-Message-State: AJaThX4se6rSh0vKefQjY2UANi1cMWamzX33qLzBI7l6zyA9W0scwyvW M92d3su7wWJJCgCd8mv9jXg9UGJL X-Google-Smtp-Source: ABhQp+TMe40Yyice6VICsWc3Oe8RkLaJYhujzGGos0sRBuYoPTNCtrRWviUrIod8U3nkohG7aBb4bA== X-Received: by 10.84.212.136 with SMTP id e8mr1529326pli.205.1510173871791; Wed, 08 Nov 2017 12:44:31 -0800 (PST) Received: from [192.168.1.116] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id a81sm9276800pfe.32.2017.11.08.12.44.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 12:44:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (15B93) In-Reply-To: <37be0b2e-822b-4db3-68f2-518339e8a562@nostrum.com> Date: Wed, 8 Nov 2017 12:44:30 -0800 Cc: Martin Thomson , "avt@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <53E86745-C398-44FD-8E6A-B9E9792FAB2A@gmail.com> References: <37be0b2e-822b-4db3-68f2-518339e8a562@nostrum.com> To: Adam Roach Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 20:44:34 -0000 > On Nov 8, 2017, at 11:13, Adam Roach wrote: >=20 > It worked by pure luck. I agree with Martin: that's not a sustainable mode= l. I'm kind of ambivalent about the QUIC work under discussion (mostly becau= se I haven't looked at the use cases in detail), but if you're envisioning s= ome kind of UDP-wide /etc/magic approach, I urge you to stop. [BA] We=E2=80=99re not trying to boil the ocean - just enable peer-to-peer Q= UIC data exchange based on the QUIC transport document. Other uses of QUIC m= ay also come along, but we don=E2=80=99t want to be gated on those other use= s and standards which may (or may not) ever come to fruition.=20 And yes, RFC 7983 seems more like documentation of fortuitous circumstances t= han an extensible architecture - particularly with respect to the IANA allo= cations section. From nobody Wed Nov 8 12:50:00 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623CA129BE6 for ; Wed, 8 Nov 2017 12:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 u3YdZETIwYJ3 for ; Wed, 8 Nov 2017 12:49:57 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA612126579 for ; Wed, 8 Nov 2017 12:49:57 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id o9so3488424ota.3 for ; Wed, 08 Nov 2017 12:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ii4hg7CjCTwZYiatPbCPzHB77dLz/J+2riDKh26nEJA=; b=b0RsLc5GEw0NbwZN1TO/StWj/i07ruQ1CN2SFCL0A6bK8hqIqoiKOatME1Ey1EYwwj SxlgQe5ITwi9V1fM42bkV9NNF5kQvaggU5kDoHxt74ycnpsnRBYi7cedBSUoDf3aY1Mz M9xiUhyeFtvuz1RLRFppXf2uYbQjymqI5iV6CZYAULHkMgpqCDT499NNeD+H/9cccGfA Teq+H+hXLnSUbIgSrHWDWgq9+e2JldGubb2Wa8/m6uxCEUQKXf4sZEP6OlNn1+/HtCRM EM/Gehpk8IlsRmAQ9UglG6JRd3aEpPMUH8201C8zzQiTpLfnYjSAg2BIAyuZMX56lHho II7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ii4hg7CjCTwZYiatPbCPzHB77dLz/J+2riDKh26nEJA=; b=rLTeH5hHzuT0PxHXSvbqrZDdo7ztlH4JUi9sm/xKLmI0lzu1P6uD4inkwv3fics7ce VoKDJ9jMtCvgMmqMnKqg0ElCa53IjmTnOuAGUDbfR2XIapBilGYg4wg5UO5eRqM6m34b Fcez5itK1KNby0AmxIFbfrgSLFYfPRnHIKqs+nwEkoxpyKn2Z5AVCxefCjZdY/oOJShA 6MkTHmV+HgDJuCo2KPruAdGM0pRrUJOqIEnQdA+87pT1U8d08FOnuS79NjBffClwVRT+ 5kgkRdCtmMT9+k81nA+PLMK5c9E8K8gGq7oqMDHBC9sz2ZgHWdkBTIPlnx3xgBgMts0e V0dg== X-Gm-Message-State: AJaThX6++XHHdoDscxm/350ZdYZEXMi2BopUDSmNcT4k7tqfAuZrtUoU 0tl3LN54tJxBNsGAFZcAlKg29s/7d13D2mRhmTI= X-Google-Smtp-Source: AGs4zMYTPiiAYZzaC1PrNm1NCcIjh0yshkcf21Cu/dunhqTvSgEtL4rB8pmyH8jSRGJ/dgYU8UJH9AJ+Mp4AiF9sCjk= X-Received: by 10.157.41.7 with SMTP id d7mr1166028otb.44.1510174197102; Wed, 08 Nov 2017 12:49:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.23 with HTTP; Wed, 8 Nov 2017 12:49:56 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Nov 2017 07:49:56 +1100 Message-ID: To: Bernard Aboba Cc: "avt@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 20:49:59 -0000 On Thu, Nov 9, 2017 at 5:49 AM, Bernard Aboba wrote: > Martin said: > > "- I don't see any case for needing to demux DTLS and QUIC." > > [BA] Demuplexing of QUIC and DTLS is a requirement for initial deployments > of > peer-to-peer QUIC data exchange, since in those initial deployments > DTLS-SRTP, > SRTP/SRTCP and even the SCTP/DTLS/UDP data channel will continue to be used. You need to be really crisp about your assumed deployment model here. Let's say that you want to do data channels over QUIC. That seems the most plausible model, mainly to drive down the number of round trips between session signaling and session use. I can imagine a very simple mapping of the data channel protocol would work nicely. In that case, as I suggested, keying SRTP using QUIC is feasible, even trivial. No DTLS. Or, as you explore in the rtpfolks draft, you want to do RTP over QUIC. That seems far less of a short term goal, but I'll humor you. In that case, you have no SRTP in the mix. Then I'll concede that you might have an issue... But only if you can't finish the data channel work first. That seems like an unlikely scenario given the complexities involved. If that does happen, then yes, things get unpleasant. But I'd be inclined to argue for modifications to QUIC (in the sense of a new QUIC version more than a change in the fundamental protocol invariants) or a shim in that case. > At the moment, it is not even clear that peer-to-peer QUIC data exchange > based on the QUIC transport document can completely substitute for all of > the potential uses of the SCTP data channel (such as unreliable, low-latency > data exchange in games), so that applications could conceivably wish to use > both the SCTP data channel and QUIC data exchange in their applications. There's a draft about that: https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams/. It turns out to be possible, even if we might quibble about some of the details in that draft. A mapping should be straightforward. I'd prefer to work on QUIC-SRTP and datachannels-over-quic than worry about these contingencies. That way you have a much smaller pool of protocols to mash together. From nobody Wed Nov 8 12:52:47 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00439129BEF for ; Wed, 8 Nov 2017 12:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 e8x2mICjlAV4 for ; Wed, 8 Nov 2017 12:52:45 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5F6129BE8 for ; Wed, 8 Nov 2017 12:52:44 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id m18so2826884pgd.13 for ; Wed, 08 Nov 2017 12:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Rn2h9Y6tXPd/OgF7Wg4nZtP6pSITbMOX/LtZv4SCso=; b=M22bEmREm/kQMlSyBr4SxqbmgcffyUVIbBeRZo0ir4SoSmis4it29S0N3yIyd6qptJ 0cFoAteruGlu4a7X+obBd3LBoPPXHhCzId5e+4SHhb9mAvaGNfLb9yG64MGMRudB2Ht4 lCZgHgr8neROlaMuTZJLsxeIFwqG6s5woRZgQa7Vt4vl+8d7mkmC1TpexW5vrHE2dN2G D8GcgO+vqblqNCiDIltTReWVfA5RBM8Yd+PtNQfpyz6ywI8Vth13zc75dI2vXfbHnLoe JNA+PvDqmYdonjY+P/STfhwNlGku5RV38d08xixFEVspl6sgHF0OF5f5EhwueJj8x2fH 51gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Rn2h9Y6tXPd/OgF7Wg4nZtP6pSITbMOX/LtZv4SCso=; b=NOIVd1exlmVOyutnolnPq9QBKEa7SG520g8l2Lftq8A13IvIkZlXo1bdZcyyRnGqVb Er7cfG2MmSy6pa6uiShp3Wd29UxOwNYhqlSgN6h9pnv3+E9sWutxhw64nzInxm9Mc48N SZ+1evB9MLxzmHkgX86iLAd8Dfsp7hlBNnbIeTLqGzOwSwv8DuKw5e4RWxGrz2QV9Muo EbOpUVU3VTv54FbPbaTaP1L8HHvotSH+1kmexv+IrTWmY788nOtFF6AJjU7PR1DQroOh ey5Tjo/nMuru1F8K4xx1WfXE0TxepKsZDaH0Xl7lprqprWzyxvDsyayFn/APTmJXpOoI CJvA== X-Gm-Message-State: AJaThX6Q+XtuobO4aMP3EAZ4FDLgamnBaFTXx0XUgKsP6QVX5vUcQNey Xa9sDGRQxcwj5KOaS+y2NPWgC1mC X-Google-Smtp-Source: ABhQp+R5jLjxOpLAs/5dB+BwV5pH+SEqAUW0w3+f+LKCvTHfNhLQ/i8holCa7UrpsDuu1qH941HAkA== X-Received: by 10.99.115.78 with SMTP id d14mr1611668pgn.391.1510174364042; Wed, 08 Nov 2017 12:52:44 -0800 (PST) Received: from [192.168.1.116] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id o19sm8270728pgn.0.2017.11.08.12.52.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 12:52:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (15B93) In-Reply-To: <37be0b2e-822b-4db3-68f2-518339e8a562@nostrum.com> Date: Wed, 8 Nov 2017 12:52:42 -0800 Cc: Martin Thomson , "avt@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <37be0b2e-822b-4db3-68f2-518339e8a562@nostrum.com> To: christer.holmberg@ericsson.com Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 20:52:46 -0000 Christer said:=20 =E2=80=9CIs this just for WebRTC?=E2=80=9D [BA] It=E2=80=99s for use by applications that could need to multiplex QUIC w= ith the other applications covered by RFC 7983. So that need could be share= d more widely than WebRTC.=20 =E2=80=9CWhat about SDP?=E2=80=9D [BA] The draft is focused on multiplexing. How QUIC integrates with SDP and= things like BUNDLE is a distinct problem and will require other documents. I= n general, it seems like a better idea to handle those questions separately t= han to attempt to wedge a new feature into BUNDLE, for example.=20= From nobody Wed Nov 8 13:12:39 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D08126579 for ; Wed, 8 Nov 2017 13:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bcEA5-wVT1ZQ for ; Wed, 8 Nov 2017 13:12:35 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEB6124B0A for ; Wed, 8 Nov 2017 13:12:35 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id s75so2901868pgs.0 for ; Wed, 08 Nov 2017 13:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UlBFDuMRatO0f2eFG8KyfmkIhaLNRcFTr4uHclQrK0I=; b=UNAMFiP/gXZj/UOqZZTZzZ+K+uaGFzstEbjNxDlmGoXIXDbrxhQl0/XiD7NpVUVDO7 TsrBjqsqheqztZlTqdjrlxrt6tK5qZq+tXiWvIzILWOyjPQoeS0dwtAzy/EruqLwzK/5 i2g+qrOHM6ExdVVW5kI0g9CjYZCI58qUKrjhYZSsHBSURPaEd8AVXp29B3TTIl8f7LDr y8yllOwdeVSDEDfB3i+TYaDGUwbIuxXafanqQovbKI9AUj9Th4gR3Rd/lTNd0+ObhEW0 5fIYxENA/SpCU2kWpUmhwzaZyeGxE2n4Y8aP4qQ/FlLMybRrxOSHmozfMIzWh93kkmNQ DLqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UlBFDuMRatO0f2eFG8KyfmkIhaLNRcFTr4uHclQrK0I=; b=ukaTv+CD/DEpm+S1rrwU5qCKAJX2pmR5sw80gfhkG6a+IC2CXpnVeuXcMn0ZZALiAb a/onfhsWrklWnF+Y7Oh9pXDKtcIR203uoC8dXj4Hrnx6ADEcSDiPjZ0fFhaGiYb667Yz 33U7vhib2VNyUQR9173b1yo1BL3eAB1KYRGwVYOF4uJkNuLAlqECHWAFiMI/uUMw12rv 2Rkv2Fjxuw4L149b4/B3mgEB+RsEdMNfh8lh1E+ssD25puuqnUomR3lqi8cVB0Z+r0Dv ZxMiwQiYNu9VSfakebbNtm5fgVqjHYXqJdY1Qm7sMlFxoU4p9QIvVq43btTu9VSbJyGb tjyg== X-Gm-Message-State: AJaThX6sT5E1tmZBfddnBC7uoOrN3kUuEXUvw04jwYF0/ILRy1gafYEw +9lrq31drJtXohDn3X7VuaLhjdt8 X-Google-Smtp-Source: ABhQp+RllZrWozaklQ9J3YZkqbEJ3VGrv9g1OybnbIr3uBnI+FZCaTtHt4vpQtK8QfsXQY1qFx6hrQ== X-Received: by 10.98.245.21 with SMTP id n21mr1826990pfh.68.1510175554844; Wed, 08 Nov 2017 13:12:34 -0800 (PST) Received: from [192.168.1.116] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id w9sm9726099pfk.16.2017.11.08.13.12.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 13:12:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (15B93) In-Reply-To: Date: Wed, 8 Nov 2017 13:12:33 -0800 Cc: "avt@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> References: To: Martin Thomson Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 21:12:37 -0000 On Nov 8, 2017, at 12:49, Martin Thomson wrote: >=20 > You need to be really crisp about your assumed deployment model here. >=20 > Let's say that you want to do data channels over QUIC. =20 [BA] That might come later, but would require additional standards work to d= efine the protocol for support of data channels run over QUIC. So for now, the goal is to support the use of peer-to-peer QUIC streams, as d= escribed in the QUIC transport document.=20 > That seems the > most plausible model, mainly to drive down the number of round trips > between session signaling and session use. I can imagine a very > simple mapping of the data channel protocol would work nicely. [BA] Since there are applications that can make use of QUIC streams, the imm= ediate goal is to provide JS access to that. Support for RTCDataChannels ca= n be built on top of this in a JavaScript library once RTCDataChannel over Q= UIC protocol is worked out.=20 > In that case, as I suggested, keying SRTP using QUIC is feasible, even > trivial. No DTLS. [BA] Indeed, this might be a good idea, particularly in scenarios where only= QUIC is used and not the SCTP/DTLS/UDP data channel. However, we=E2=80=99r= e not there yet - I=E2=80=99m not clear that QUIC as defined in the QUIC tra= nsport document can substitute for the SCTP/DTLS/UDP data channel in every c= onceivable scenario. Also, existing implementations use DTLS/SRTP. So we d= on=E2=80=99t want to rule out multiplexing of QUIC and DTLS, even if that mi= ght not be necessary long-term.=20 > Or, as you explore in the rtpfolks draft, you want to do RTP over > QUIC. That seems far less of a short term goal, but I'll humor you. [BA] Definitely not a short term goal because that kind of a change would ap= pear to require significant discussion and standards development, as well as= a much bigger change to implementations than merely using QUIC for peer-to-= peer data exchange. >=20 > There's a draft about that: > https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams/. > It turns out to be possible, even if we might quibble about some of > the details in that draft. A mapping should be straightforward. [BA] It doesn=E2=80=99t look complicated, but I=E2=80=99m not aware of any i= mplementations and it has been ruled out of scope for the QUIC WG, so we don= =E2=80=99t want support for peer-to-peer QUIC data exchange to depend on it.= =20 > I'd prefer to work on QUIC-SRTP and datachannels-over-quic than worry > about these contingencies. That way you have a much smaller pool of > protocols to mash together. [BA] You are most welcome to work on those things. But as noted above, the p= otential need to utilize QUIC and SCTP data channels simultaneously means th= at you still need to multiplex QUIC and DTLS, at least in the short term. A= lso, since RTCDataChannel can be built on top of the QUIC stream API, work o= n that protocol isn=E2=80=99t a gating factor either.= From nobody Wed Nov 8 14:50:19 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6C2126C2F for ; Wed, 8 Nov 2017 14:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Pfwlt7A8O7Qm for ; Wed, 8 Nov 2017 14:50:07 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D7C126C19 for ; Wed, 8 Nov 2017 14:50:07 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id w197so3136033oif.6 for ; Wed, 08 Nov 2017 14:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hg9K0ZE27rFQ9wb8kdWmyXSS12Ow75UY2z3jfhUkbcs=; b=nZ8RlqKLB7H0PEH/t17SlT9LBdMYgk/5tRJSTiJCT75zlHpPqzFf6HSxVNcy3weO4q LGQTrDJx18yJAj7eyBVZv2OKMF2QewgGz3CLMNKqvlY208ngQa4uULGMjO1eG1aB7elk 4gtgZaUzVjlmmvkNZvjSpCeIXVrvp65fnBCAST4wqpsBEAbD1H0Xgv0DsJkGsocRTMEf lHDSSzPNhhfMC3ZLc1cHjQ+szXLEZ1MLRYGNXLE4+RllkGVq2rCfflF4pOeq8CIq6IU5 Km8yznCntG5K4CPwxO2MtwKmpmm113Bj3zbOflJgONR3HdKhNnWZ36J5EWm7xGpjTlhy Lufw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hg9K0ZE27rFQ9wb8kdWmyXSS12Ow75UY2z3jfhUkbcs=; b=DtHgUnZKVoB3ZhBqzpvq+bl7Spq3udV/298L0HVBRD0NOU8uFGgH3KrPHkczN2M8OT q1SW+X44UtLw1hFhUGQG2/J5ENYSpTQbpBfeN40LEPWlkovMFI1RvemvRb7TRXVO+wk1 3JJwoGSwltwh8qSNRsPIBParIR8QnFAxrisb+cJuRNXkTH7PmjVDzEZDHs0qMEl37K/1 y8uJrQOecmvMXL8mExEEpRquA2t9IMx6wEjinTU/YKPXF64b3edd5Dq4VRX2iJ6Lbmgi c07lOghS9uPiG/fTJGKKOmk5n3HFKT54WIYznIA/LWQbhTeZz3hvyKaO0EDwB/OAAW8v Grsw== X-Gm-Message-State: AJaThX4x8cJDHck1jvbjAM33tafqVmmQF+67Y4gXxe5iUuvqMGpeKvxu fVOA7NVMMBpzZJ60z//bf7uK5CBWoKrhnPd4N3w= X-Google-Smtp-Source: ABhQp+Q4+Lxr6bctxO65M0lN/4SHncIFIXZFLJ1Y3GuGdI9J/U6fxVNIfllm5PQEadP+AYiKUBM1BS9kAiHbNJ8irIg= X-Received: by 10.202.67.135 with SMTP id q129mr1137944oia.390.1510181406353; Wed, 08 Nov 2017 14:50:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.23 with HTTP; Wed, 8 Nov 2017 14:50:05 -0800 (PST) In-Reply-To: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> From: Martin Thomson Date: Thu, 9 Nov 2017 09:50:05 +1100 Message-ID: To: Bernard Aboba Cc: "avt@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:50:17 -0000 On Thu, Nov 9, 2017 at 8:12 AM, Bernard Aboba wrote: > So for now, the goal is to support the use of peer-to-peer QUIC streams, as described in the QUIC transport document. Can you unpack that a little more? QUIC is a generic protocol. Presumably you have an application (protocol) in mind. From nobody Wed Nov 8 15:21:45 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DCE126D46 for ; Wed, 8 Nov 2017 15:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AdKptZ6BN_zv for ; Wed, 8 Nov 2017 15:21:42 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079B9126C22 for ; Wed, 8 Nov 2017 15:21:42 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id j28so536578pfk.8 for ; Wed, 08 Nov 2017 15:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=47zqQz7czGVG/LQM/GZakrwMEOw4zExcjf4k5yIUlR0=; b=t2osrlsBxLb3TYHTGHOi48DQpzN/LeVl34wfrTy2rxV/7ogYcM8NHizumDUY2i3Ygv lmMIq5qS2kdyjgPUVMW0MBH0cMgSJAKAVdlegpkbxOi64VresvUBve3D3mW1cVyV6r30 wGdqQEHmBTeprmZeBIvxGPln3ZrCvIocHmGF9zhxzv0o9NriWiywKPKCEGNALWUdEav+ u98w5h4X4HCJ83fHekesjxJvmrolrhXSAXEENH6l+LhuJKxTeebDOvZhv11XAL6LTBui jGZk1Hbcz4x7rVKPsivcaEovc+8iBd3quOBUXufXL/5NXgrlUSOYBDESY/Q1XM1WYA9e sQFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=47zqQz7czGVG/LQM/GZakrwMEOw4zExcjf4k5yIUlR0=; b=rGP1Jlc8UpO2AS5k7j5RPhedYoqaoyvORqs+BVtc+7JgI/CAZD7nZUA92pUpGVxSqw PbNAoLJ3hApHLvJBEJMvqSx06KTJcHV8jV+LuAhKhC1iamJ0JW1qHiNmdtrNwed/z807 mfpPb2OghgtL0cYKnLtkQmgDAPcLQTuQh0QJUXViU3JH5uvmTesHt4KQ7LtPVWD0uw4U Rguhn2rNx4/NLnwOXxIEE9z5mj1qiOwynVcY4volzeDdpXCp5BZ/inS+Q0gTDg2wsrvY ql5ZnltCBQ5PXjyUlGklm+l7011bK1fLrux7CYiNFhRWGq8bUWV+u9ZmBXaM9m8nBGcp /p7w== X-Gm-Message-State: AJaThX4Zr/kUA9jMfXyHsIxlPlAW6NjFLBxhm5Zpprj27YRXFQ3EtwWR IXQ7vzxNK/LfdwRsNrcdS8lPoFK7 X-Google-Smtp-Source: ABhQp+T6KepJyBhslh0I2wT4Q8dutmXB0ECoUwRmv+1eFwA3yNBmFXevWho1/6LQnWznfDsxrEkpdw== X-Received: by 10.101.73.205 with SMTP id t13mr1932555pgs.289.1510183301112; Wed, 08 Nov 2017 15:21:41 -0800 (PST) Received: from [192.168.1.116] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id s9sm7907088pgc.18.2017.11.08.15.21.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 15:21:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (15B93) In-Reply-To: Date: Wed, 8 Nov 2017 15:21:39 -0800 Cc: "avt@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> To: Martin Thomson Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 23:21:43 -0000 On Nov 8, 2017, at 14:50, Martin Thomson wrote: >=20 > Can you unpack that a little more? QUIC is a generic protocol. > Presumably you have an application (protocol) in mind. [BA] Some immediate use cases:=20 1. Embedded systems. These devices often want to utilize as little code as p= ossible. If they are already incorporating client-server QUIC (for use with H= TTP/2), then using QUIC for a reliable data channel as well will be natural,= particularly if the devices do not need to inter-operate with browsers that= only support the SCTP data channel.=20 2. File transfer along with audio and video. QUIC supports pluggable congest= ion control, which SCTP implementations typically do not. This means that QU= IC congestion control can be made to be friendly with the congestion control= mechanisms utilized for audio and video (such as the algorithms discussed i= n RMCAT). In contrast, the aggressive loss-based congestion control of SCTP= builds queues that can result in additional delay, degrading audio and vide= o.=20= From nobody Wed Nov 8 15:57:56 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C10A129413 for ; Wed, 8 Nov 2017 15:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 u0iXGc4Mu5We for ; Wed, 8 Nov 2017 15:57:54 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE589127010 for ; Wed, 8 Nov 2017 15:57:54 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id r128so3241707oig.9 for ; Wed, 08 Nov 2017 15:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dGGn1pZWSBIBFcrVGwSk3gyIZwSPr5PpzH/+2/Hn9Tg=; b=gHoQfi91tR+s7ONu11Z7FpS6qEVO1QwUecLNOPvzyp6Kg2fQeRbErqqcUPaEYcgVT0 sAb12aEWV6fvI3iVvWnGZdo1NplMMAZSlVwRQnNR5xDEZLMFrWTxEIcXZpUp6OZeP9o5 3N4W78qRgLl5rhQbYOpYhCjYtmRwAVNdw9IpS2DJpPEDUMjFeOwBGBnSX8ULSlDr2a6S kULQuIYcSagX2ZVitCzAmMEO7H/RYYx3GzXu4YApPh4nlXh26xKy/J56Om1Xqp6PqqJ1 0UffYTkHf2BUdWxHZyzq6VWkpp88jMZKa1ZF8+KAfNYaSAaU0EHSyurQ4p4dNGDDu9Jd 1YVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dGGn1pZWSBIBFcrVGwSk3gyIZwSPr5PpzH/+2/Hn9Tg=; b=HOavgdq4GSecoaEIi1csp7y7IPVFzJTKNa8B4gHiXTCkqj93NXvd8JPitkd0n8CriT gZIA0iCvr5W0hhs706Ria0a8Qv9WPaiZuCG5Xs3VR8RH19EN35goDF/618RGdpPVabXv N/0GxqpvjwwaZHhOMppMDDakrfQh/QrDQPcdYr/LzLOzjbsuzlnFDtktWF0/QUEUOk4Q xKhbNEcWXrdmwurO/UvKLEl+mZZ/W/pZzE/J1p7+R2Zhq1uRQOVU4qIQBaZM2RhXYTOC M4qN7lWMRF6f2WTE+MA1rN9GYucTU5PU3SSnBcSZ+iXO6tZgS878+OIi5CsTrgoCE9ta 0A8A== X-Gm-Message-State: AJaThX7jKk1lHOpPcyD7hqK4c+mEi2V6R99V+M985dounAOGRxTVVzhR RWFwq2tDNppm4iALQisHIcEnhS/6gCFGqEofKeN3EQ== X-Google-Smtp-Source: ABhQp+Tw3oRoDbd2c1hVcBX+Y0VtMIINUQDkmIgAbqusUNmVvvWvTnqheN6EGZiQhDUFegtjPxMrNJxcL7Dbyh6zLIw= X-Received: by 10.202.166.141 with SMTP id t13mr1326950oij.392.1510185473985; Wed, 08 Nov 2017 15:57:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.23 with HTTP; Wed, 8 Nov 2017 15:57:53 -0800 (PST) In-Reply-To: <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> From: Martin Thomson Date: Thu, 9 Nov 2017 10:57:53 +1100 Message-ID: To: Bernard Aboba Cc: "avt@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 23:57:56 -0000 On Thu, Nov 9, 2017 at 10:21 AM, Bernard Aboba wr= ote: > On Nov 8, 2017, at 14:50, Martin Thomson wrote= : >> >> Can you unpack that a little more? QUIC is a generic protocol. >> Presumably you have an application (protocol) in mind. > > [BA] Some immediate use cases: What protocol would these use? You don't just "use" QUIC and more than you "use" TCP. I can believe that you want something simpler than the datachannel protocol, but it seems like you aren't far from that when you talk about these use cases. > 1. Embedded systems. These devices often want to utilize as little code = as possible. If they are already incorporating client-server QUIC (for use = with HTTP/2), then using QUIC for a reliable data channel as well will be n= atural, particularly if the devices do not need to inter-operate with brows= ers that only support the SCTP data channel. > > 2. File transfer along with audio and video. QUIC supports pluggable cong= estion control, which SCTP implementations typically do not. This means tha= t QUIC congestion control can be made to be friendly with the congestion co= ntrol mechanisms utilized for audio and video (such as the algorithms discu= ssed in RMCAT). In contrast, the aggressive loss-based congestion control = of SCTP builds queues that can result in additional delay, degrading audio = and video. From nobody Wed Nov 8 17:56:21 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37B512751F for ; Wed, 8 Nov 2017 17:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QxlpiMLSx3PL for ; Wed, 8 Nov 2017 17:56:18 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7858612711A for ; Wed, 8 Nov 2017 17:56:18 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id z80so3083188pff.4 for ; Wed, 08 Nov 2017 17:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1njOtsTuZu4Vnvs1TH8UaJkvBlq3N2E/ia+qTt1+VO8=; b=LjsQVmuQzsNmhN7pp0pxy7k37P6fwXcMB1Qj2HsmZF6+HIYfy/OzCeR3Z6tbX12ZUo czJTzt4yxk3mb3KaV+hvJvBGB8zGw8KAvWL8Uzf0D1Jb+IDctRzHcfdtInzrkFLxUjJa bIDPffHPGP7W86W54EZnxqQ7vGBtB+dEIbjodGdtM9oihLAlxp713w/2CAN3r9F3+WxC 0nYlD3QZpgn9Npo+oBAOGAxOJuOZtzTYxLj/vabYQjQSj8+fpTL/En8pmbDLzeQ9QT/N Gb5c4VdCO5M7VDdHQJrdaw8WKhEdOsz3yNz73WZ1SLFrcba/B7lIYSTQ7i6PacPUNFHg 3FSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1njOtsTuZu4Vnvs1TH8UaJkvBlq3N2E/ia+qTt1+VO8=; b=MIoPTTxrieGxveKxRt0uRMc8dkhspdKXWiGslhn0zd0H/uGixkIJL/+5LP1UaIOV6A ZMoS9+aHh6mpL5nuYpGhGA6OH4E0tejVDfnEFD3F2gqAzqlJvBwROhODzU/E3KU33eOz pDb0TyVAG15NJwrpW0DYff3zIgbHYopQHVGgECsLtLED3IKJZZT25CUsoIbWEaq1RL/w Mlfm3/dYDxZ9Kndbd/xFraq9cp5fVD3qGUEXtYT5pI8DiwPuTT2azJsCA3t9o0era9qG l2JvAs3HCEhCbh9yLkVKAy5QkVtohvqOmfYsK1fOHP7HzP6bBq6KS7RT307Vyy9mn0JN ng2w== X-Gm-Message-State: AJaThX7xb5RWO3s+8Xy20KRJkWcHHU8UQauVEoUvjngL8sGv9UGp8tsF UiQlS6kzfQNxtvM9IqUrcEPCr57B X-Google-Smtp-Source: ABhQp+T28a+bu0VyAGNLUCOrdG39ToGZV46aQ33cqxbuxvlE1QqePQKHzGKyTU66nL9bdM8KvA6X9g== X-Received: by 10.99.62.207 with SMTP id l198mr2269645pga.376.1510192577475; Wed, 08 Nov 2017 17:56:17 -0800 (PST) Received: from [10.151.49.151] (mobile-166-176-187-157.mycingular.net. [166.176.187.157]) by smtp.gmail.com with ESMTPSA id t84sm11157614pfa.91.2017.11.08.17.56.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 17:56:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15B93) In-Reply-To: Date: Wed, 8 Nov 2017 17:56:15 -0800 Cc: "avt@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> To: Martin Thomson Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 01:56:20 -0000 Use cases based on reliable QuicStreams are most ready for implementation ba= sed on the QuicTransport/QuicStream Javascript API Peter described at W3C TP= AC. The data channel API isn=E2=80=99t needed where bare QuicStreams can do the j= ob and data chsnnel does not support back pressure so it can be an awkward f= it in situations where the receiver might not be able to keep up (such as em= bedded). > On Nov 8, 2017, at 3:57 PM, Martin Thomson wrot= e: >=20 >> On Thu, Nov 9, 2017 at 10:21 AM, Bernard Aboba w= rote: >>> On Nov 8, 2017, at 14:50, Martin Thomson wrot= e: >>>=20 >>> Can you unpack that a little more? QUIC is a generic protocol. >>> Presumably you have an application (protocol) in mind. >>=20 >> [BA] Some immediate use cases: >=20 > What protocol would these use? You don't just "use" QUIC and more > than you "use" TCP. >=20 > I can believe that you want something simpler than the datachannel > protocol, but it seems like you aren't far from that when you talk > about these use cases. >=20 >> 1. Embedded systems. These devices often want to utilize as little code a= s possible. If they are already incorporating client-server QUIC (for use wi= th HTTP/2), then using QUIC for a reliable data channel as well will be natu= ral, particularly if the devices do not need to inter-operate with browsers t= hat only support the SCTP data channel. >>=20 >> 2. File transfer along with audio and video. QUIC supports pluggable cong= estion control, which SCTP implementations typically do not. This means that= QUIC congestion control can be made to be friendly with the congestion cont= rol mechanisms utilized for audio and video (such as the algorithms discusse= d in RMCAT). In contrast, the aggressive loss-based congestion control of S= CTP builds queues that can result in additional delay, degrading audio and v= ideo. From nobody Wed Nov 8 18:04:05 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C124124B18 for ; Wed, 8 Nov 2017 18:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 d73Z2-5jYT5d for ; Wed, 8 Nov 2017 18:04:02 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED4E129536 for ; Wed, 8 Nov 2017 18:03:56 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id c47so4058998otj.6 for ; Wed, 08 Nov 2017 18:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sgrfXl1uAyO24BwxEDZ7tJl016I5IR/VpGYAhhsztIA=; b=DMuilqUf4uWWhh81f8IZy7gXI5Rkf3Axe3Xi/QJJac8LM2iBXg2B3N0dcJ8MxQPPiV GaY+AzsHL5HOk9QCQYrJsh75D5aEChVCLZrQcagfgxKzyLjCjvoui6OeptbxNY7IGs4J e1/Yg+Y4W4ftQk/KrF7P/LPW55PJQe+Tf8z5n0X5C8w7PHO3K6fEGeBCLm0enMQhgHek CzWraGcyyH1gzLKtatbAMsgSIRsy3499KmWlINWn5QGeg81NIAo60YK7g8zzVV6sTop7 cs8oDxFA7X6gzPCWwUx0GhQibs4LE7R2gxOi/p0JUTC9hHsIziUkRbV/IJcOfN2sE+GE Mzlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sgrfXl1uAyO24BwxEDZ7tJl016I5IR/VpGYAhhsztIA=; b=sKrZJtm1pXfpXHwu4kLJlY0r8aN37NCpZRsHKFrWy0VbTiKejTO7pTu0AhjumN0tJm vWX9nJdkaHfqxXJc2NVRHRYqJsNbBm/So9KN93SvpAEcFnV+Xaqz4l3f5BXXKuYowBnl cXYmiytzw2z77EccgLo7Sk0mpXqin+4Slezhqc9WYez/NzShNuGs6FylZvIwNoMdjrmP hqsKWsTl+2acyRo6juX2AnMfCpbY4MI1j2TJs0MeY18d+/5TmSHn+oGJwlizINW2W5HB mWsI2+YXcNk1Ztlk3RjtF2ZO7isqG6vjOiW/8+KUWHtYk0A+0qDdi4J4blPJ+LsGSgFH petw== X-Gm-Message-State: AJaThX7Sr+wTPmkcO+bX9YAZHsSofxg+K1OsqdM7wXq74hmSLiT0juoM qpgtUKKjPbv6a2+QuZJd8qLSFYr5IrUSFE2Y1u0= X-Google-Smtp-Source: AGs4zMYP9kSYULFoVumBiWC3wD047q0bFSfcGQlIRbd1lN0wqDa2VUKgE9/ZMoF4uCfJD5IeW07RkY3yPWZW5Pfkpbs= X-Received: by 10.157.11.24 with SMTP id a24mr1627594ota.401.1510193036251; Wed, 08 Nov 2017 18:03:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.23 with HTTP; Wed, 8 Nov 2017 18:03:55 -0800 (PST) In-Reply-To: References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> From: Martin Thomson Date: Thu, 9 Nov 2017 13:03:55 +1100 Message-ID: To: Bernard Aboba Cc: "avt@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 02:04:04 -0000 The back pressure thing is - I think - just a matter of lack of attention. I think that all the pieces are in place. Gluing JS streams to the websockets API might be all that is needed. I'll have to look at Peter's proposed API now. This is the first I've heard of it. On Thu, Nov 9, 2017 at 12:56 PM, Bernard Aboba wr= ote: > Use cases based on reliable QuicStreams are most ready for implementation= based on the QuicTransport/QuicStream Javascript API Peter described at W3= C TPAC. > > The data channel API isn=E2=80=99t needed where bare QuicStreams can do t= he job and data chsnnel does not support back pressure so it can be an awkw= ard fit in situations where the receiver might not be able to keep up (such= as embedded). > >> On Nov 8, 2017, at 3:57 PM, Martin Thomson wr= ote: >> >>> On Thu, Nov 9, 2017 at 10:21 AM, Bernard Aboba wrote: >>>> On Nov 8, 2017, at 14:50, Martin Thomson wr= ote: >>>> >>>> Can you unpack that a little more? QUIC is a generic protocol. >>>> Presumably you have an application (protocol) in mind. >>> >>> [BA] Some immediate use cases: >> >> What protocol would these use? You don't just "use" QUIC and more >> than you "use" TCP. >> >> I can believe that you want something simpler than the datachannel >> protocol, but it seems like you aren't far from that when you talk >> about these use cases. >> >>> 1. Embedded systems. These devices often want to utilize as little cod= e as possible. If they are already incorporating client-server QUIC (for us= e with HTTP/2), then using QUIC for a reliable data channel as well will be= natural, particularly if the devices do not need to inter-operate with bro= wsers that only support the SCTP data channel. >>> >>> 2. File transfer along with audio and video. QUIC supports pluggable co= ngestion control, which SCTP implementations typically do not. This means t= hat QUIC congestion control can be made to be friendly with the congestion = control mechanisms utilized for audio and video (such as the algorithms dis= cussed in RMCAT). In contrast, the aggressive loss-based congestion contro= l of SCTP builds queues that can result in additional delay, degrading audi= o and video. From nobody Wed Nov 8 18:11:51 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0FE124B18 for ; Wed, 8 Nov 2017 18:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GztvkFojx3o9 for ; Wed, 8 Nov 2017 18:11:48 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DA012957C for ; Wed, 8 Nov 2017 18:11:48 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id b79so3168494pfk.5 for ; Wed, 08 Nov 2017 18:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W7mhD5QGYCujwBHmw93WYFYIqRZpMupyeq5DSVZJChE=; b=JoF1eX0QdM1/zhJtnkjGDM54mOwR1Dfrs4EjjCs21GWYKkESUGFDXLMf8etpte3KIE 6PdGS4ilgub9LoXO3+c8sPy6ofdeD2Nyu76ddjRIzcdjs1H9zf5CvcYBrDsd3d0NeJhL HK8xRbkJf3j8Pinfeoj4FhdvrdOIHH+7OZJsWUL9CWIPItChet44i+xgN8aBOILGnZ/V ab8/xYZMg0LvwrlmTyqncVLY3NFHl6oBoD4HZl8E7rlUbVHJzttJb1WJJ5Cbk2ZWObDM le10ZpCZkH7mqUIpDLVImLfMVDcfjYwmowhNa7ZFkFPuOHvhvNHeNRM6Ts2eoC1RKO7m dRYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W7mhD5QGYCujwBHmw93WYFYIqRZpMupyeq5DSVZJChE=; b=RHF6GA0YYuQlfI0fyDePkSxu7v1+5Y/VXe22tgQN6d0JmC2RmnTkvrcVwxRvqEEdVY IiSe7t5V+R0HRtGCLa4kYnI0yqcAfZma4wpNpFlZRkRNiV2nKLeDQ00Fw7dtzAjhR3zJ pQgViDvC5N+bzdpwcblm35KIGz8m3oyNnMvma7P96vmU5zTPe4MjFkF4/q5CpVZqCZLQ WQvQbUnj9pFglvpwbYpANrH9E1i3X0+SZNm/03QId461nG/CPmTZ0UijcsR4OlZl6kNQ /9ody5jSAJPr6pP/z47U5ga0ihDEn4FHKYArMM2MAiG2mXyZi5BL+VgdHSB2HGsGraRA uYcQ== X-Gm-Message-State: AJaThX5DI0rO8DN71wh4Skihm/IaRR3YHHi0uNLIkjkLxjwpSetIt5Cv g8PVwZlAyjEMNRoWpu/PnCv8M1nD X-Google-Smtp-Source: ABhQp+Rz2kTRWrpfU6KcRJuvIISooH4Ea/Ac7hQgcfWUACd4wIfMQ9pZ3+IsaMJkKqXMY1ufMSmsdw== X-Received: by 10.98.214.65 with SMTP id r62mr1309853pfg.39.1510193506995; Wed, 08 Nov 2017 18:11:46 -0800 (PST) Received: from [10.151.49.151] (mobile-166-176-187-157.mycingular.net. [166.176.187.157]) by smtp.gmail.com with ESMTPSA id q12sm8797519pgn.56.2017.11.08.18.11.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 18:11:46 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-152E7F4C-19E6-463A-B271-5A241417BB69 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15B93) In-Reply-To: Date: Wed, 8 Nov 2017 18:11:45 -0800 Cc: "avt@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <951702FF-D42C-492D-B5BF-D43E33A504B2@gmail.com> References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> To: Martin Thomson Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 02:11:50 -0000 --Apple-Mail-152E7F4C-19E6-463A-B271-5A241417BB69 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Proposal starts at slide 86 here: https://docs.google.com/presentation/d/1Sg_1TVCcKJvZ8Egz5oa0CP01TC2rNdv9HVu7= W38Y4zA/edit > On Nov 8, 2017, at 6:03 PM, Martin Thomson wrot= e: >=20 > The back pressure thing is - I think - just a matter of lack of > attention. I think that all the pieces are in place. Gluing JS > streams to the websockets API might be all that is needed. >=20 > I'll have to look at Peter's proposed API now. This is the first I've > heard of it. >=20 >=20 >> On Thu, Nov 9, 2017 at 12:56 PM, Bernard Aboba w= rote: >> Use cases based on reliable QuicStreams are most ready for implementation= based on the QuicTransport/QuicStream Javascript API Peter described at W3C= TPAC. >>=20 >> The data channel API isn=E2=80=99t needed where bare QuicStreams can do t= he job and data chsnnel does not support back pressure so it can be an awkwa= rd fit in situations where the receiver might not be able to keep up (such a= s embedded). >>=20 >>>> On Nov 8, 2017, at 3:57 PM, Martin Thomson w= rote: >>>>=20 >>>>> On Thu, Nov 9, 2017 at 10:21 AM, Bernard Aboba wrote: >>>>> On Nov 8, 2017, at 14:50, Martin Thomson wr= ote: >>>>>=20 >>>>> Can you unpack that a little more? QUIC is a generic protocol. >>>>> Presumably you have an application (protocol) in mind. >>>>=20 >>>> [BA] Some immediate use cases: >>>=20 >>> What protocol would these use? You don't just "use" QUIC and more >>> than you "use" TCP. >>>=20 >>> I can believe that you want something simpler than the datachannel >>> protocol, but it seems like you aren't far from that when you talk >>> about these use cases. >>>=20 >>>> 1. Embedded systems. These devices often want to utilize as little cod= e as possible. If they are already incorporating client-server QUIC (for use= with HTTP/2), then using QUIC for a reliable data channel as well will be n= atural, particularly if the devices do not need to inter-operate with browse= rs that only support the SCTP data channel. >>>>=20 >>>> 2. File transfer along with audio and video. QUIC supports pluggable co= ngestion control, which SCTP implementations typically do not. This means th= at QUIC congestion control can be made to be friendly with the congestion co= ntrol mechanisms utilized for audio and video (such as the algorithms discus= sed in RMCAT). In contrast, the aggressive loss-based congestion control of= SCTP builds queues that can result in additional delay, degrading audio and= video. --Apple-Mail-152E7F4C-19E6-463A-B271-5A241417BB69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Proposal starts at slide 86= here:

On N= ov 8, 2017, at 6:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

The back pressure thing is - I think - just a matter= of lack of
attention.  I think that all the pieces are= in place.  Gluing JS
streams to the websockets API mig= ht be all that is needed.

I'll have to look= at Peter's proposed API now.  This is the first I've
h= eard of it.


On Thu, Nov 9,= 2017 at 12:56 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Use cases based on reliable QuicStreams are most ready for implemen= tation based on the QuicTransport/QuicStream Javascript API Peter described a= t W3C TPAC.
The data channel API isn=E2=80= =99t needed where bare QuicStreams can do the job and data chsnnel does not s= upport back pressure so it can be an awkward fit in situations where the rec= eiver might not be able to keep up (such as embedded).

On Nov 8, 2017, at 3:57 PM, Martin Th= omson <martin.thomson@gmail.c= om> wrote:

<= span>On Thu, Nov 9, 2017 at 10:21 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
On Nov 8= , 2017, at 14:50, Martin Thomson <martin.thomson@gmail.com> wrote:

=
Can you unpack that a little more?  QUIC is a generic protoco= l.
Presumably you have an application (protocol) in mind= .

[BA] Some immediate use= cases:

=
What protocol woul= d these use?  You don't just "use" QUIC and more
than= you "use" TCP.

I can believe that you w= ant something simpler than the datachannel
protocol, but i= t seems like you aren't far from that when you talk
<= /blockquote>
about t= hese use cases.

1. Embedded systems.  These devices often want to utilize as little c= ode as possible. If they are already incorporating client-server QUIC (for u= se with HTTP/2), then using QUIC for a reliable data channel as well will be= natural, particularly if the devices do not need to inter-operate with brow= sers that only support the SCTP data channel.

2. File transfer along with audio and video. QUIC supports pluggabl= e congestion control, which SCTP implementations typically do not. This mean= s that QUIC congestion control can be made to be friendly with the congestio= n control mechanisms utilized for audio and video (such as the algorithms di= scussed in RMCAT).  In contrast, the aggressive loss-based congestion c= ontrol of SCTP builds queues that can result in additional delay, degrading a= udio and video.
= --Apple-Mail-152E7F4C-19E6-463A-B271-5A241417BB69-- From nobody Wed Nov 8 19:12:06 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A49F120713 for ; Wed, 8 Nov 2017 19:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Lwp9qDcINhQu for ; Wed, 8 Nov 2017 19:12:04 -0800 (PST) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 52A9A126C23 for ; Wed, 8 Nov 2017 19:12:03 -0800 (PST) X-AuditID: 1207440e-bf9ff70000007085-d2-5a03c7803e69 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 6F.CF.28805.187C30A5; Wed, 8 Nov 2017 22:12:01 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vA93Bxev027905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 8 Nov 2017 22:12:00 -0500 To: avt@ietf.org References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> From: Paul Kyzivat Message-ID: <8b46385a-46a2-7978-610e-7bddf9f800a7@alum.mit.edu> Date: Wed, 8 Nov 2017 22:11:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixO6iqNt0nDnKYNFmNouXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWLBHJaCu5wVx9cvYmlg/MrexcjJISFgItGwbgdrFyMXh5DA DiaJL42n2SGcz0wSm9/cZAOpEhbwkDh7dCZYh4iAgMSK7X9ZQGwhgW5miU2dkiA2m4CWxJxD /8HivAL2Ei+u/ACzWQRUJF7dm8AEYosKpEncmfGQCaJGUOLkzCdgNZwCthInFxwAs5kFzCTm bX7IDGGLS9x6Mp8JwpaX2P52DvMERv5ZSNpnIWmZhaRlFpKWBYwsqxjlEnNKc3VzEzNzilOT dYuTE/PyUot0jfVyM0v0UlNKNzFCwpJvB2P7eplDjAIcjEo8vC9WMUcJsSaWFVfmHmKU5GBS EuV98IopSogvKT+lMiOxOCO+qDQntfgQowQHs5II751DQOW8KYmVValF+TApaQ4WJXFetSXq fkIC6YklqdmpqQWpRTBZGQ4OJQnejmNAjYJFqempFWmZOSUIaSYOTpDhPEDDg4+CDC8uSMwt zkyHyJ9itOTo6bnxh4nj0Y27QPLZzNcNzEIsefl5qVLivDdBGgRAGjJK8+BmwtLMK0ZxoBeF eStAVvMAUxTc1FdAC5mAFu4PYQBZWJKIkJJqYMx4YnH/7fdT3Vwf1yvfWb3/ykHxntq7x8rO VuyK5Cpfe0C53W3fyixpzgP7/T2n2B16e/eFbVz/Eq3Tl6sesXpUvimZlHBw1fMvjRI524+o TL2rZyf+urOz62Z0iOAxSzt+rx4L2Te8e3Xlcn6d5pe87p93f4lBcldX8pEFMy5PnW5xNfTW zlQlluKMREMt5qLiRADgUt8xDgMAAA== Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 03:12:05 -0000 On 11/8/17 6:21 PM, Bernard Aboba wrote: > On Nov 8, 2017, at 14:50, Martin Thomson wrote: >> >> Can you unpack that a little more? QUIC is a generic protocol. >> Presumably you have an application (protocol) in mind. > > [BA] Some immediate use cases: > > 1. Embedded systems. These devices often want to utilize as little code as possible. If they are already incorporating client-server QUIC (for use with HTTP/2), then using QUIC for a reliable data channel as well will be natural, particularly if the devices do not need to inter-operate with browsers that only support the SCTP data channel. > > 2. File transfer along with audio and video. QUIC supports pluggable congestion control, which SCTP implementations typically do not. This means that QUIC congestion control can be made to be friendly with the congestion control mechanisms utilized for audio and video (such as the algorithms discussed in RMCAT). In contrast, the aggressive loss-based congestion control of SCTP builds queues that can result in additional delay, degrading audio and video. What this sounds like to me is: we don't like RTCWeb and want to try again based on QUIC. Or did I misunderstand? Thanks, Paul From nobody Wed Nov 8 19:20:21 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75691129467 for ; Wed, 8 Nov 2017 19:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eQ7wF-4q3DF0 for ; Wed, 8 Nov 2017 19:20:17 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E87126C23 for ; Wed, 8 Nov 2017 19:20:17 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id a8so3299081pfc.0 for ; Wed, 08 Nov 2017 19:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dUKkvdxdteAEef+XqYes5rQrYZoojj7ObWCLiHeADrw=; b=gLkaHWQbk8MokesmIhBDzrpgtLm1nH0GAsB/NuZGJZxs8SmToZs2grOi/3CxClVSRD lquNwQrpsEEfLOUwT6R/uZHdC+5OY3KBbWCsRh4lbJ4izIWP/FKTGpTirMM0dO/etbkR 2vAHdO7fkGfcoBrpHwGTT52H3rG+TQwPWFPj3FoWit2rWGCIz8mxC8wEXgq8VG6sEY8e Mdne4HGXdtl+iSoBcw2m/aQjomAffw+9dLcrtnQN1mtvzw0LBL36jyVmBWJHjng1UQD8 jcPYPGVrhRcBCOoJ8HhFrhxzGvWfH4TNvuJ6KIp+n61WGWgHC+CQQAKrRQstwCoNrjw7 7HLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dUKkvdxdteAEef+XqYes5rQrYZoojj7ObWCLiHeADrw=; b=XPQucQaFM91udRkyo6AOxqYARvrAXXlsgB7TaqnB6gIMzSJbyuLbsP1Ct6wm8i5ngw tMcV/iM7sVybm60wMkeVeL4MUC5Frp/YVA6qoEfyQuUpvefms6JQbpK/6p9CZjsDpivA i9exoYNwbZX57YsORPkhvxg9EoC8sdphkIHbH7Flr6w+7HvH/a1r54JJptJS1E+i75Pq Bmlbg1BMfByE6oO0FRePSIvqGbrpFAPzdLMjtdIb0KNS0bSd3DFxSU68Eh6i25DlLzkA eHXO8oj50NInqKQ15BWSMRm3leAOlVe+sh9VzAnvAi7GgKUSbdql+ojNgRgw1eGXViLD bUzw== X-Gm-Message-State: AJaThX4hyuR8HFbZ9G4Hb4s6P3napPf8w0SI3yMQEM23IweqcKNU2jio GPVIyjkCLqwI6RCwLQ1Plr8d+72E X-Google-Smtp-Source: ABhQp+RtTTxEx5iXv7wVBcybw2uPbKhUQ5SN0Bk9NqA5MaYkrJU4gXOqhx/f2u0HJ2DG71rbyW+R6g== X-Received: by 10.98.163.200 with SMTP id q69mr2312448pfl.52.1510197617068; Wed, 08 Nov 2017 19:20:17 -0800 (PST) Received: from [192.168.1.116] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id o19sm8929043pgn.0.2017.11.08.19.20.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 19:20:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (15B93) In-Reply-To: <8b46385a-46a2-7978-610e-7bddf9f800a7@alum.mit.edu> Date: Wed, 8 Nov 2017 19:20:15 -0800 Cc: avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> <8b46385a-46a2-7978-610e-7bddf9f800a7@alum.mit.edu> To: Paul Kyzivat Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 03:20:19 -0000 >> What this sounds like to me is: > we don't like RTCWeb and want to try again based on QUIC. >=20 > Or did I misunderstand? [BA] The draft is only about enabling multiplexing of peer-to-peer QUIC data= exchange. In particular, it takes the position that adding multiplexing su= pport for QUIC data exchange shouldn=E2=80=99t require massive changes to th= e rest of the RTCWEB protocol stack (such as requiring that RTP run over QUI= C, that QUIC-SRTP be used, or that the SCTP data channel be abandoned.=20 Those other uses of QUIC might or might not be good things, but they are ort= hogonal to use of QUIC purely for peer-to-peer data exchange.=20= From nobody Wed Nov 8 19:33:49 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760C0129AE9 for ; Wed, 8 Nov 2017 19:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 j4a54B80CxUa for ; Wed, 8 Nov 2017 19:33:45 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5201B129467 for ; Wed, 8 Nov 2017 19:33:45 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id j24so3661069otb.1 for ; Wed, 08 Nov 2017 19:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JJTJk1bMY5tpJ/hCXbBjz6yBsiFX+zH9Tidk2O+bZpI=; b=QbxU01ttYlx1FESgzjvHH5NaT+DKCdAQEnwHZi0CU3oS3qVre7SLpw7w8cwrEUMU39 L9l92EREnWA/UQkJGPmKsiZLkL9Ttfr+FsBkU6E8w3daHa/zcyiSmU2gX/MTCnb1OGi6 Xg4Xsc8b3WFKWKZHZJkuIGx6YlGdf+IqRxR22Pe+pQxtBiRlKGffG7XocmKyXuaE2VjB 61T1PW6eOM/NSLi+VQzHVWXBsBvhQf9/l/k0mZKUCok9pI2Toj3Omw4kc19FN79rLyWH YeOg3QTPJFWC19Q3xkR6iS3uAaGR+guJZVVhb/G/kucKqVpWO5F0+qSawHr3EWYj8laN 5ycg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JJTJk1bMY5tpJ/hCXbBjz6yBsiFX+zH9Tidk2O+bZpI=; b=PKKipe5lL4F3uj7aaV09yhNNc/pG2x6F17WjcZD1dDNIb5T0+FC3TMCZGPOgoZw3tl mhaU80Oyc8ixMEWvd4JBNxD3v+A++QPoxOAyXqOPVvrNrvpV+TtTjLHSX+hwv1zi1K9R PjKPImQPjrWUUQ7r8XYWv/KFIyVpw8vGBn4f2/gh2qYNZYvKBJiTY1TB8JzbJQkcQZ8p kZp7lP7pE0m8px7BxiPySyZJqD4+Gp/Hy9zI6EL9Z5+0VFDluOEK9VsYWO/x/uLjePtk 011FI5iyn+s2GrlyeeGljeygp4clenCKWCjh52JrZQartONIdgaVdUESKqXHCM1DjZRx nNdg== X-Gm-Message-State: AJaThX6qdQ7nBHOPqniP9fT8szKVDusgSwsjI/uiRcx5TgxGLEAbPpoA FP1ZPUf4Y+Q22PRZ7BsTEtim4SbUx9QeCvk0T8K5Hp2N X-Google-Smtp-Source: AGs4zMakKU3T27SCkv/9PrYLjdDEmi82vQruKGgasHo0zdka0lUayi97/4Wr5PBFD+c4epxC0n/sIxu+usk4iCVdSGI= X-Received: by 10.157.53.8 with SMTP id o8mr1363443otc.35.1510198424476; Wed, 08 Nov 2017 19:33:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.23 with HTTP; Wed, 8 Nov 2017 19:33:43 -0800 (PST) In-Reply-To: <951702FF-D42C-492D-B5BF-D43E33A504B2@gmail.com> References: <1B579316-3280-4256-84EE-F948EFAD4B91@gmail.com> <9F70AB19-FA4D-4897-8AEE-287CD0EE9447@gmail.com> <951702FF-D42C-492D-B5BF-D43E33A504B2@gmail.com> From: Martin Thomson Date: Thu, 9 Nov 2017 14:33:43 +1100 Message-ID: To: Bernard Aboba Cc: "avt@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 03:33:47 -0000 Thanks for the pointer. This probably needs a more strategic approach. I agree with the notion that there is value in letting websites choose their mechanisms, but this would have a third thing added to the platform that looks like a websocket. Maybe it's time to talk about layers: one for the type of communications medium, one for the application contract (ordered, unordered, reliable, not, etc...). It is basically just datachannels over QUIC. Which necessarily means a new protocol (Peter outlines some of the ways in which that protocol might be designed to use QUIC, and those seem like reasonable things). On Thu, Nov 9, 2017 at 1:11 PM, Bernard Aboba wro= te: > Proposal starts at slide 86 here: > https://docs.google.com/presentation/d/1Sg_1TVCcKJvZ8Egz5oa0CP01TC2rNdv9H= Vu7W38Y4zA/edit > > On Nov 8, 2017, at 6:03 PM, Martin Thomson wro= te: > > The back pressure thing is - I think - just a matter of lack of > attention. I think that all the pieces are in place. Gluing JS > streams to the websockets API might be all that is needed. > > I'll have to look at Peter's proposed API now. This is the first I've > heard of it. > > > On Thu, Nov 9, 2017 at 12:56 PM, Bernard Aboba > wrote: > > Use cases based on reliable QuicStreams are most ready for implementation > based on the QuicTransport/QuicStream Javascript API Peter described at W= 3C > TPAC. > > > The data channel API isn=E2=80=99t needed where bare QuicStreams can do t= he job and > data chsnnel does not support back pressure so it can be an awkward fit i= n > situations where the receiver might not be able to keep up (such as > embedded). > > > On Nov 8, 2017, at 3:57 PM, Martin Thomson wro= te: > > > On Thu, Nov 9, 2017 at 10:21 AM, Bernard Aboba > wrote: > > On Nov 8, 2017, at 14:50, Martin Thomson wrote= : > > > Can you unpack that a little more? QUIC is a generic protocol. > > Presumably you have an application (protocol) in mind. > > > [BA] Some immediate use cases: > > > What protocol would these use? You don't just "use" QUIC and more > > than you "use" TCP. > > > I can believe that you want something simpler than the datachannel > > protocol, but it seems like you aren't far from that when you talk > > about these use cases. > > > 1. Embedded systems. These devices often want to utilize as little code = as > possible. If they are already incorporating client-server QUIC (for use w= ith > HTTP/2), then using QUIC for a reliable data channel as well will be > natural, particularly if the devices do not need to inter-operate with > browsers that only support the SCTP data channel. > > > 2. File transfer along with audio and video. QUIC supports pluggable > congestion control, which SCTP implementations typically do not. This mea= ns > that QUIC congestion control can be made to be friendly with the congesti= on > control mechanisms utilized for audio and video (such as the algorithms > discussed in RMCAT). In contrast, the aggressive loss-based congestion > control of SCTP builds queues that can result in additional delay, degrad= ing > audio and video. From nobody Sun Nov 12 22:51:40 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DDE1292C5 for ; Sun, 12 Nov 2017 22:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-com.20150623.gappssmtp.com 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 x8BXLtEuQDGI for ; Sun, 12 Nov 2017 22:51:30 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD65128C82 for ; Sun, 12 Nov 2017 22:51:30 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id x7so11223117pfa.1 for ; Sun, 12 Nov 2017 22:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mGrmor/YopIy6TwKxmHszqB9AEMpyvZFQ59p/ifPpgA=; b=1ckVBg69xmJQUBKMd4DTbRsowamgZyoMLSoNVoxMzH182L0S2CeZyRQ0uOAJU4XeR6 Mqkf/uYlD9r3PFKyUBGoSioEpbl1rzqORj6Q9Kb2IsktPTYfSx+utK9wm8i0OVio/c5X 5pN8KCH77bvtdu6jaxMwKMIxOLxo7c5rV67p6+3xa/dDVdoOcpAfVdt8xVGv9fJRuZ/Q uV/qyVIa5tk094pxO5VCXST//ZpaawippBWdiWMXopDpYT9CMzDP5I9d7SqtBYyqfklC 7THsuiFatX38bg+7Mnl/D3So+VJ9O25oGJE67ZFsla+WmQU4C9FRcxp/Uw9XpObzXIrh hmJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mGrmor/YopIy6TwKxmHszqB9AEMpyvZFQ59p/ifPpgA=; b=AxLyfRSM/PWvOjdWvDf8Pd+KKIyR2FTzMZr+7osB75KryS8zEp0P9ha+Xt+OHavaRQ xK1aJJhmGKkoTsNapMhJlW2//Jlp4/OjoWhg7Um6UTQJWslwazRZ9kro5Ha+VWcjk7Nd K+i6YJf18FXhaJKnBIS5StqGRgqqDLz0OObw+bq1HPQoKv+S5gDtyXFh/JV/+pQ/htgi mJ7mD30fyKCPOBB6lylF0L/t+WYJoMzfBR+XaeRldeZAKwZ41uh4iQx1VOw68GwqqtxK 4v7xgCQkv9EzprkQfIpA0Dg8xKS2ZWaUiihK0FH0cOyVK35qO0FvKX/3a91IflFxeY+E eNWw== X-Gm-Message-State: AJaThX4lCsrvPbYbkPQ23/UYm+n88lzCwbD3uayKhcPxKQKXhkVd6eK8 o7i+ppUp4drnQoSd3wGBmC6+sQ== X-Google-Smtp-Source: AGs4zMZcMFaC+rvQeknYvmKmIzPfGhe3VC7OjLVhekFSBUfFCd0hrwwunxQT57OqwCvrpvd5Sia8JA== X-Received: by 10.99.127.91 with SMTP id p27mr6896082pgn.1.1510555890234; Sun, 12 Nov 2017 22:51:30 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:ed0d:3546:761f:c4d5? ([2001:67c:1232:144:ed0d:3546:761f:c4d5]) by smtp.gmail.com with ESMTPSA id 84sm30444166pfy.179.2017.11.12.22.51.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 22:51:29 -0800 (PST) From: Jonathan Lennox Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_344783BB-C939-4402-9C4B-F71B651CC567" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 14:51:26 +0800 In-Reply-To: Cc: Ingemar Johansson S , "rmcat@ietf.org" , Zaheduzzaman Sarker , "Michael Ramalho (mramalho)" , "varun.singh@iki.fi" , IETF AVTCore WG To: Colin Perkins References: <150913051158.22299.4504001911028448869@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [AVTCORE] [rmcat] I-D Action: draft-dt-rmcat-feedback-message-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 06:51:33 -0000 --Apple-Mail=_344783BB-C939-4402-9C4B-F71B651CC567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since this draft is now draft-ietf-avtcore-cc-feedback-message, it=E2=80=99= d be better to move this discussion to avt@ietf.org = . Thanks! Jonathan (AVTCore chair)=20 > On Nov 13, 2017, at 12:33 PM, Colin Perkins wrote: >=20 >=20 >> On 30 Oct 2017, at 15:35, Ingemar Johansson S = wrote: >>=20 >> Hi >>=20 >> Read through the draft and I believe that I understand how it should = be implemented and when time permits I will replace the home-brewn RTCP = feedback that is currently used with SCReAM with the version that is = specified in the dt draft. >>=20 >> There are a few questions though. >> 1) Arrival time offset (ATO) and Report timestamp (RTS): The time = granularity of the ATO is 1ms while the time granularity of the RTS = seems to be 0.1ms or can even be configurable?. Is there any reason to = have a differing time granularity for ATO and RTS? >=20 > We need to define these more carefully, but I agree that ideally they = have the same units. The obvious unit for Report Timestamp would be the = middle 32 bits out of 64 in the NTP timestamp, as used in the LSR field = of SR packets. That doesn=E2=80=99t map so nicely to the 13 bit ATO = field though, unless we make it count 1/1024 of a second ticks rather = than 1/1000. >=20 >> 2) Byte order for ATO and RTS is not specified. I guess it should be = network byte order for both RTS and ATO, right ?.=20 >=20 > Right. >=20 > Colin >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ --Apple-Mail=_344783BB-C939-4402-9C4B-F71B651CC567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Since this draft is now = draft-ietf-avtcore-cc-feedback-message, it=E2=80=99d be better to move = this discussion to avt@ietf.org.  Thanks!

Jonathan (AVTCore chair) 

On = Nov 13, 2017, at 12:33 PM, Colin Perkins <csp@csperkins.org> = wrote:


On 30 Oct = 2017, at 15:35, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi

Read through = the draft and I believe that I understand how it should be implemented = and when time permits I will replace the home-brewn RTCP feedback that = is currently used with SCReAM with the version that is specified in the = dt draft.

There are a few questions = though.
1)  Arrival time offset (ATO) and Report = timestamp (RTS): The time granularity of the ATO is 1ms while the time = granularity of the RTS seems to be 0.1ms or can even be configurable?. = Is there any reason to have a differing time granularity for ATO and = RTS?

We need to define these = more carefully, but I agree that ideally they have the same units. The = obvious unit for Report Timestamp would be the middle 32 bits out of 64 = in the NTP timestamp, as used in the LSR field of SR packets. That = doesn=E2=80=99t map so nicely to the 13 bit ATO field though, unless we = make it count 1/1024 of a second ticks rather than 1/1000.

2) Byte = order for ATO and RTS is not specified. I guess it should be network = byte order for both RTS and ATO, right ?.

Right.

Colin



--
Colin = Perkins
https://csperkins.org/

= --Apple-Mail=_344783BB-C939-4402-9C4B-F71B651CC567-- From nobody Mon Nov 13 18:18:42 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29367129B02 for ; Mon, 13 Nov 2017 18:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 WNqMztW9u3bN for ; Mon, 13 Nov 2017 18:18:39 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C169C12954B for ; Mon, 13 Nov 2017 18:18:39 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 70378D715769C for ; Tue, 14 Nov 2017 02:18:37 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 14 Nov 2017 02:18:38 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.198]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 10:18:31 +0800 From: "Huangyihong (Rachel)" To: "avt@ietf.org" CC: "jonathan@vidyo.com" Thread-Topic: Slides please Thread-Index: AdNc7s9VYYku9ch6QK6cPr6FuNu2SA== Date: Tue, 14 Nov 2017 02:18:31 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C602578@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.42.219] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C602578nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [AVTCORE] Slides please X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:18:41 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C602578nkgeml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Those who are going to make a presentation in AVTCORE Thursday morning, ple= ase don't forget to send your slides to our co-chairs in advance. Thanks. BR, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C602578nkgeml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Those who are going to make a p= resentation in AVTCORE Thursday morning, please don’t forget to send = your slides to our co-chairs in advance. Thanks.

 

BR,

Rachel

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C602578nkgeml513mbschi_-- From nobody Sun Nov 19 19:07:29 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA36B1201F2 for ; Sun, 19 Nov 2017 19:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4-Gzu76ITbqW for ; Sun, 19 Nov 2017 19:07:26 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 53894126B7F for ; Sun, 19 Nov 2017 19:07:26 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0B04BA50BCBFE for ; Mon, 20 Nov 2017 03:07:23 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 20 Nov 2017 03:07:24 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.219]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 11:07:20 +0800 From: "Huangyihong (Rachel)" To: IETF AVTCore WG Thread-Topic: minutes for AVTcore in IETF 100 Thread-Index: AdNhrKvOaKjEOwPQSmmC1+IG86XzhA== Date: Mon, 20 Nov 2017 03:07:19 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C614A32@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.153.152] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C614A32nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [AVTCORE] minutes for AVTcore in IETF 100 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 03:07:27 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C614A32nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The minutes have been uploaded: https://datatracker.ietf.org/meeting/100/materials/minutes-100-avtcore/ Thanks to Magnus Westerlund for taking it in Etherpad. If you have any corrections, please let us know. BR, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C614A32nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The minutes have been uploaded:=

 

https://datatracker.ie= tf.org/meeting/100/materials/minutes-100-avtcore/

 

Thanks to Magnus Westerlund for= taking it in Etherpad.

 

If you have any corrections, pl= ease let us know.

 

BR,

Rachel

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C614A32nkgeml513mbxchi_-- From nobody Thu Nov 23 08:47:53 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B9812EBA9 for ; Thu, 23 Nov 2017 08:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SkfgRdXp5jul for ; Thu, 23 Nov 2017 08:47:50 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3A012EBAC for ; Thu, 23 Nov 2017 08:47:50 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id o70so12144303vkc.9 for ; Thu, 23 Nov 2017 08:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WUtkxf8SCgzSCtVbcnukg/ScU5UpSm+yLmYhAxc9Lsc=; b=bgWnzFBnImgfYThgb+XJYNMamw0YNf1A6PgD6XojLKmcjBJkCYRH0i5EK/CiWaL5YO 3qv58GDR+J9A8peMBM4PnSSRDT3YTnhg4DOhH53Q8cMUHFWjXCvGSCo7GEMPBM7LttRp tvVCOZ33yUtLaQNiqlq0mVnm0BPoNQudlk0TtZlM6KB515jz2R1IeGsbK4m7TSH96PB6 JGvg8gz8IGmHBCTYAoNdeI6ITRUglEtOicBLzaVpV0zYU265fUZ61kcrb3J09/YuPDXw oE724ZLhhey1MYfNIkc9d6W606W2a4mgJMQegMxUERKZN3y3ooZtJ2wKPphM4i39G3oC 1BXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WUtkxf8SCgzSCtVbcnukg/ScU5UpSm+yLmYhAxc9Lsc=; b=Ext06qRQJZFTRlylIGCI+peWJppjNoizUJVYY0t2yoj3Ifc/bLm0EnlgRsyhEcGzwt ARGgxzVNO0kE+t6rfsCzwQNPMB1WhPOPkKLgKzvMkjAoHbizXus4slGcXcYSZ/5xfRKb TwbG8F1GIacO1ogKd74zn6O6dTWbwz2o31Jb6hBTxqhhGoZ7fq2F4ndYhogNx1/FiU36 +5frepANp5BJKjlbJeg7v4PNFK58wSTRHP8yiWBN+XKe2TkGRGbVYOiCWAMbQfDoN0Rj XcoSmmkEWr8w0NEcQApV/4eVJ0iPivoolamJ/plL80K5IkiSkPf2VrY+GgZvRWveNnwq TrIw== X-Gm-Message-State: AJaThX5SYsf67kaGEtQK2Q/IeHlZ8xEUb2KU9v45oTkkgc4KR1RDcvCK 4mZTqUvdKHtfiK62zlkcMyJ9U6f5cjh+dyacXKiVgUj/ X-Google-Smtp-Source: AGs4zMbemB1PYdOk2MtstlAvvYSHRIbfbuMjICKRbE0471824Gx3sZ99Iezhq0gl+a19eAZBXmYSPQ0VdE6PzVYYTvs= X-Received: by 10.31.5.66 with SMTP id 63mr19303485vkf.15.1511455668804; Thu, 23 Nov 2017 08:47:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.230 with HTTP; Thu, 23 Nov 2017 08:47:28 -0800 (PST) From: Bernard Aboba Date: Thu, 23 Nov 2017 08:47:28 -0800 Message-ID: To: IETF AVTCore WG Content-Type: multipart/alternative; boundary="001a1143dd5a3ba3b0055ea9327e" Archived-At: Subject: [AVTCORE] RFC 7983 and multiplex principles X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 16:47:52 -0000 --001a1143dd5a3ba3b0055ea9327e Content-Type: text/plain; charset="UTF-8" At IETF 100, we had a discussion about the extensibility of RFC 7983 in the context of QUIC multiplexing. Martin has put together some thoughts on multiplexing principles: https://martinthomson.github.io/mux-principles/draft- thomson-mux-principles.html One of the points made in this document is the potential impact of multiplexing on protocol evolution. For example, with respect to DTLS: "For instance, DTLS 1.3 [DTLS13] defines a record layout that uses the first octet in a very different fashion to earlier versions; this design is constrained by the need to remain compatible with the scheme in RFC 7983" Maintaining compatibility of DTLS with RFC 7983 does seem to be important, since non-backward compatible changes could leave existing RFC 7983 implementations unable to upgrade. But is this binding, or merely a "nice to have"? To the extent that there is one, the "contract" entered into by protocols mentioned in RFC 7983 is contained in Section 9 (IANA considerations), which covers: Section 9.1: STUN Methods Section 9.2: TLS ContentType (see: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5 ) Section 9.3: TURN Channel Numbers It is interesting to note that RTP/RTCP and ZRTP are not included in the IANA considerations section, so that there is no "requires coordination" applying to RTP version allocation, as there is to TLS ContentType. --001a1143dd5a3ba3b0055ea9327e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At IETF 100, we had a discussion about the extensibility o= f RFC 7983 in the context of QUIC multiplexing.=C2=A0

Ma= rtin has put together some thoughts on multiplexing principles:=C2=A0
=
One of the points made in this document is the potential impac= t of multiplexing on protocol evolution.=C2=A0 For example, with respect to= DTLS:=C2=A0

"For instance, DTLS 1.3=C2=A0[DTLS13]=C2=A0defines a= record layout that uses the first octet in a very different fashion to ear= lier versions; this design is constrained by the need to remain compatible = with the scheme in RFC 7983"

Maintaini= ng compatibility of DTLS with RFC 7983 does seem to be important, since non= -backward compatible changes could leave existing RFC 7983 implementations = unable to upgrade. But is this binding, or merely a "nice to have"= ;?=C2=A0

To the extent that there is one, the &quo= t;contract" entered into by protocols mentioned in RFC 7983 is contain= ed in Section 9 (IANA considerations), which covers:=C2=A0

=C2=A0 =C2=A0 Section 9.1:=C2=A0 STUN Methods
=C2=A0 =C2=A0 Section 9.3: TURN Channel Numbers

It is interesting to note that RTP/RTCP and ZRTP are not in= cluded in the IANA considerations section, so that there is no "requir= es coordination" applying to RTP version allocation, as there is to TL= S ContentType.=C2=A0


--001a1143dd5a3ba3b0055ea9327e-- From nobody Thu Nov 23 22:01:52 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41416129AB2 for ; Thu, 23 Nov 2017 22:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TvRevjGo5RRC for ; Thu, 23 Nov 2017 22:01:44 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE1C129AB0 for ; Thu, 23 Nov 2017 22:01:44 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id o23so17942350otd.1 for ; Thu, 23 Nov 2017 22:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4ZE9ea6OLdxvcPFaWlXsCiKergXqvudiyKUMWRL8Cgc=; b=EfOOOLjnOTNU1x9GKNIcJwayE9j6jEpo5pXCFxmLOqRDO1xpkvNdnuYchBcxPWSRYh vkQYWLKJtJ6brK30ysPlDMNdcN58Re3/+7joebw+tnXF1ATjJM43osvoOaiuWkb+fZof /s9j6GAohqn5QSeLEXcoNZvu96bc2XBK8dmMcmDyhKHtV3UTErZBkVyyEa2AeMGaMtTX aVB3T0b6rJPXZmm+F1Ad16Dbptb8vo2RVmjdMlbtD+0+uSE2fKMnImQOPjogkAI+GN78 rg8zJZ9osI+biA1s9UseDp292GSXMYG+XWUQ4hOEqKdqCLAKnMerpEbP5jPqcBj9XfSV AQ1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4ZE9ea6OLdxvcPFaWlXsCiKergXqvudiyKUMWRL8Cgc=; b=IVkg85TYQSifJ9XKgbsuVO9q3eVDOze8H8rpyepVOGI6oJJJb9/GMLOY7XotGK6IW2 i/FIfV3Phw3zJsT+Slepv7shPvzoyIfDnJu+S+ysn8Y9Yhrh2Ad5l+MFzfjbwWNkiPgT /j4SO65hqRdhY+E/bsFRLDh7yuOQpbE0LBkAzzbYPJ9uK/QXelT/6GIk7pX0W6tvUNz4 ZZ6xfI7I2KZy7M589H59UCpzNM0XxHQ6e8YGutq8F5i5wt0WoHI/x+f+vLJIWF5YdgJg iPfK4O9AgTBWZro73z3BwD69rDYFib1rMZF+14YfwPyzqsMY8caH1LzFkfY6qiT1whRg MjiA== X-Gm-Message-State: AJaThX7SVO3mmXJ3pKTV7hyJ9A5KmckFeAeLzluYK0junXZU1mP+d4jx nsLVNEdgozEjM8aKeLreMs73Fe5RIYJjVLbanTU= X-Google-Smtp-Source: AGs4zMbp8HbeRAAApbJ0USUWlY3m+FY3rXEDIgWeuswsNS1wpmyx2FqiI12n0+woojL2/LSUxAWAQDQncaNecUU0FZI= X-Received: by 10.157.69.65 with SMTP id p1mr19125227oti.93.1511503304047; Thu, 23 Nov 2017 22:01:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Thu, 23 Nov 2017 22:01:43 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 24 Nov 2017 17:01:43 +1100 Message-ID: To: Bernard Aboba Cc: IETF AVTCore WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [AVTCORE] RFC 7983 and multiplex principles X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 06:01:51 -0000 The principle I propose in the draft of a draft says that a general purpose protocol should not consider the multiplexing use to be binding. DTLS is often used with 7983, but not exclusively. I would say that it's not a guarantee that new versions of DTLS stay in the 20-63 range. Obviously, we will try - and we have done so with the latest changes to the DTLS record layer - but that is not an ironclad guarantee. You could say that 7983 imposed that contract on DTLS, but that wasn't entirely consensual. If DTLS identifies a need to break this contract that is stronger than its desire to remain compatible with 7983, then I think that is a decision that will be made on the strength of the need. On Fri, Nov 24, 2017 at 3:47 AM, Bernard Aboba wrote: > At IETF 100, we had a discussion about the extensibility of RFC 7983 in the > context of QUIC multiplexing. > > Martin has put together some thoughts on multiplexing principles: > https://martinthomson.github.io/mux-principles/draft-thomson-mux-principles.html > > One of the points made in this document is the potential impact of > multiplexing on protocol evolution. For example, with respect to DTLS: > > "For instance, DTLS 1.3 [DTLS13] defines a record layout that uses the first > octet in a very different fashion to earlier versions; this design is > constrained by the need to remain compatible with the scheme in RFC 7983" > > Maintaining compatibility of DTLS with RFC 7983 does seem to be important, > since non-backward compatible changes could leave existing RFC 7983 > implementations unable to upgrade. But is this binding, or merely a "nice to > have"? > > To the extent that there is one, the "contract" entered into by protocols > mentioned in RFC 7983 is contained in Section 9 (IANA considerations), which > covers: > > Section 9.1: STUN Methods > Section 9.2: TLS ContentType (see: > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5) > Section 9.3: TURN Channel Numbers > > It is interesting to note that RTP/RTCP and ZRTP are not included in the > IANA considerations section, so that there is no "requires coordination" > applying to RTP version allocation, as there is to TLS ContentType. > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From nobody Tue Nov 28 15:37:08 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E3F128E00 for ; Tue, 28 Nov 2017 15:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 D6MMilLTie0e for ; Tue, 28 Nov 2017 15:37:05 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804951205F0 for ; Tue, 28 Nov 2017 15:37:05 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id q13so2053715uaq.8 for ; Tue, 28 Nov 2017 15:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k3MFVUv9OIHmw67Nxlg4hZF0Ya4XwU1kP6ipbmRaxOo=; b=ppcr1SRKJKFDUjIO9tqF0+fDxGzjJfD447jyrp2c+2Y1pk2aRNbCajxght+KiKazzt t7LJygodtBcW1d8yshOKayeVF4ygysakbJer4e2sA17kOikEDXSKTS3twD24nQ5LYodk Db4BZ9+2H/dDBfHabr1hjd2gf4/wKg/lQ1MS1wPZIV6YOnfl9K3AOuSjhih4Ehsh5flr ecvLK3H0NSUJtPl/NyDmVZT4HWI4x1tG+hShBItd9xFxV22/WXoj+DTkzYYRFoQMPApp WIYMmQhyYtInsP0rI9qW9I6Qrt4xzzZjS+Ma4l8qPZrf+y77nNdg/wZt7T1GIPhyggez MHmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k3MFVUv9OIHmw67Nxlg4hZF0Ya4XwU1kP6ipbmRaxOo=; b=jbZIOe4e719oat0aWef8BgG6pJfXF55Xqjz2NBDY9ZDpVeYT3gUq2lOYXV6sPrnp+S fYbICxJVlnlpte1lui0By9JtHyJeM3Z+oHhe1EmtQfKRmxtXvqEAfEXlfSat285WCK4d tFbmAc3V2Nz/PMMNd/0BPpn0V/8w0XK26wLlwjgD4rgaM+xWMdDKVeNHEcn9ve2qzWaz 27+6Oaw6LJvrAQ+4hm1W/zF/s+INfdvLt26GiXaX0mvyuUtU3ujlS3QKMYIERgMIJGG3 NB0AN/kPeWRsWebgG7tAWFQvgrVPAtN5IaDzXPuXfvqeJ6xTs2bfAoFVCcWF4Jn4XJvu 4yJQ== X-Gm-Message-State: AJaThX592rz1ZQ/D/CNsz1MH8S4fhdpgToexCxXdABV0v88vF92gILNA 1OxCKqtlf6TcZtY5uJrZaUuWl3jJTGhLsHzeViS8LeY5 X-Google-Smtp-Source: AGs4zMZ1C15Jkt1f7JaFSuLSmNg6mTVDjRT9a4p2/TerEL+DazIKPXKjMNE7+YjjjwOoqM17CaE9r4IN7XbI7TaDJMQ= X-Received: by 10.176.71.226 with SMTP id w34mr833923uac.33.1511912224229; Tue, 28 Nov 2017 15:37:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.230 with HTTP; Tue, 28 Nov 2017 15:36:43 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Tue, 28 Nov 2017 15:36:43 -0800 Message-ID: To: Martin Thomson Cc: IETF AVTCore WG Content-Type: multipart/alternative; boundary="f403043791980e90bc055f137fdc" Archived-At: Subject: Re: [AVTCORE] RFC 7983 and multiplex principles X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 23:37:07 -0000 --f403043791980e90bc055f137fdc Content-Type: text/plain; charset="UTF-8" Martin said: "The principle I propose in the draft of a draft says that a general purpose protocol should not consider the multiplexing use to be binding. DTLS is often used with 7983, but not exclusively." [BA] No RFC is "binding" in perpetuity, since with appropriate consensus, another RFC can always be produced to update or obsolete it. Also, RFC 7983 is conservative in its IANA Considerations section, which only mentions allocation policies for STUN Methods (Section 9.1), TLS ContentType (Section 9.2) and TURN Channel Numbers (Section 9.3). Since Section 9 doesn't mention anything about RTP/RTCP allocation policies, it can't even be said to "bind" RTP/RTCP, let alone other general purpose protocols. "I would say that it's not a guarantee that new versions of DTLS stay in the 20-63 range. Obviously, we will try - and we have done so with the latest changes to the DTLS record layer - but that is not an ironclad guarantee." [BA] That is entirely consistent with the IANA allocation policy for TLS ContentType, which is "Coordination Required". "You could say that 7983 imposed that contract on DTLS, but that wasn't entirely consensual. If DTLS identifies a need to break this contract that is stronger than its desire to remain compatible with 7983, then I think that is a decision that will be made on the strength of the need." [BA] I think that is implied by the "Coordination Required" policy, is it not? The more complicated question relates to the practicalities of opting out of RFC 7983. That seems somewhat akin to Brexit in that we may not know how hard it will be until we look into the details... For example, we talked about how a future version of QUIC might make at least portions of RFC 7983 unnecessary by potentially transporting media over QUIC (making it unnecessary to multiplex RTP/RTCP with QUIC) or by supporting QUIC-SRTP and replacing the SCTP data channel (making it unnecessary to multiplex DTLS with QUIC). On Thu, Nov 23, 2017 at 10:01 PM, Martin Thomson wrote: > The principle I propose in the draft of a draft says that a general > purpose protocol should not consider the multiplexing use to be > binding. DTLS is often used with 7983, but not exclusively. > > I would say that it's not a guarantee that new versions of DTLS stay > in the 20-63 range. Obviously, we will try - and we have done so with > the latest changes to the DTLS record layer - but that is not an > ironclad guarantee. > > You could say that 7983 imposed that contract on DTLS, but that wasn't > entirely consensual. If DTLS identifies a need to break this contract > that is stronger than its desire to remain compatible with 7983, then > I think that is a decision that will be made on the strength of the > need. > > > On Fri, Nov 24, 2017 at 3:47 AM, Bernard Aboba > wrote: > > At IETF 100, we had a discussion about the extensibility of RFC 7983 in > the > > context of QUIC multiplexing. > > > > Martin has put together some thoughts on multiplexing principles: > > https://martinthomson.github.io/mux-principles/draft- > thomson-mux-principles.html > > > > One of the points made in this document is the potential impact of > > multiplexing on protocol evolution. For example, with respect to DTLS: > > > > "For instance, DTLS 1.3 [DTLS13] defines a record layout that uses the > first > > octet in a very different fashion to earlier versions; this design is > > constrained by the need to remain compatible with the scheme in RFC 7983" > > > > Maintaining compatibility of DTLS with RFC 7983 does seem to be > important, > > since non-backward compatible changes could leave existing RFC 7983 > > implementations unable to upgrade. But is this binding, or merely a > "nice to > > have"? > > > > To the extent that there is one, the "contract" entered into by protocols > > mentioned in RFC 7983 is contained in Section 9 (IANA considerations), > which > > covers: > > > > Section 9.1: STUN Methods > > Section 9.2: TLS ContentType (see: > > https://www.iana.org/assignments/tls-parameters/ > tls-parameters.xhtml#tls-parameters-5) > > Section 9.3: TURN Channel Numbers > > > > It is interesting to note that RTP/RTCP and ZRTP are not included in the > > IANA considerations section, so that there is no "requires coordination" > > applying to RTP version allocation, as there is to TLS ContentType. > > > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > --f403043791980e90bc055f137fdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin said:=C2=A0

"The principle I propose in the draft of a draft says tha= t a general
purpose protocol s= hould not consider the multiplexing use to be
binding.=C2=A0 DTLS is often used = with 7983, but not exclusively."

[BA] No RFC= is "binding" in perpetuity, since with appropriate consensus, an= other RFC can always be produced to update or obsolete it.=C2=A0 Also, RFC = 7983 is conservative in its IANA Considerations section, which only mention= s allocation policies for STUN Methods (Section 9.1), TLS ContentType (Sect= ion 9.2) and TURN Channel Numbers (Section 9.3).=C2=A0 Since Section 9 does= n't mention anything about RTP/RTCP allocation policies, it can't e= ven be said to "bind" RTP/RTCP, let alone other general purpose p= rotocols.

"I would say that it's not a guarantee that new versions = of DTLS stay
in the 20-63 range.=C2=A0 Obviously, we will try - and we have done= so with
the latest changes to the DTLS record layer - but that is not an=
ironclad gu= arantee."

[BA] That is entirely consis= tent with the IANA allocation policy for TLS ContentType, which is "Co= ordination Required".=C2=A0

"You could say that 7983 imposed that contract on DTLS, but that = wasn't=C2=A0entirely consensual= .=C2=A0=C2=A0 If DTLS identifies a = need to break this contract
th= at is stronger than its desire to remain compatible with 7983, then=C2=A0I think that is a decision that will = be made on the strength of the
need."

[B= A] I think that is implied by the "Coordination Required" policy,= is it not?=C2=A0=C2=A0

The more complicate= d question relates to the practicalities of opting out of RFC 7983.=C2=A0 T= hat seems somewhat akin to Brexit in that we may not know how hard it will = be until we look into the details...

For example, = we talked about how a future version of QUIC might make at least portions o= f RFC 7983 unnecessary by potentially transporting media over QUIC (making = it unnecessary to multiplex RTP/RTCP with QUIC) or by supporting QUIC-SRTP = and replacing the SCTP data channel (making it unnecessary to multiplex DTL= S with QUIC).=C2=A0

<= /div>


=

On Thu, Nov= 23, 2017 at 10:01 PM, Martin Thomson <martin.thomson@gmail.com= > wrote:
The principle I propos= e in the draft of a draft says that a general
purpose protocol should not consider the multiplexing use to be
binding.=C2=A0 DTLS is often used with 7983, but not exclusively.

I would say that it's not a guarantee that new versions of DTLS stay in the 20-63 range.=C2=A0 Obviously, we will try - and we have done so with=
the latest changes to the DTLS record layer - but that is not an
ironclad guarantee.

You could say that 7983 imposed that contract on DTLS, but that wasn't<= br> entirely consensual.=C2=A0 If DTLS identifies a need to break this contract=
that is stronger than its desire to remain compatible with 7983, then
I think that is a decision that will be made on the strength of the
need.


On Fri, Nov 24, 2017 at 3:47 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> At IETF 100, we had a discussion about the extensibility of RFC 7983 i= n the
> context of QUIC multiplexing.
>
> Martin has put together some thoughts on multiplexing principles:
> https://martint= homson.github.io/mux-principles/draft-thomson-mux-principles.html=
>
> One of the points made in this document is the potential impact of
> multiplexing on protocol evolution.=C2=A0 For example, with respect to= DTLS:
>
> "For instance, DTLS 1.3 [DTLS13] defines a record layout that use= s the first
> octet in a very different fashion to earlier versions; this design is<= br> > constrained by the need to remain compatible with the scheme in RFC 79= 83"
>
> Maintaining compatibility of DTLS with RFC 7983 does seem to be import= ant,
> since non-backward compatible changes could leave existing RFC 7983 > implementations unable to upgrade. But is this binding, or merely a &q= uot;nice to
> have"?
>
> To the extent that there is one, the "contract" entered into= by protocols
> mentioned in RFC 7983 is contained in Section 9 (IANA considerations),= which
> covers:
>
>=C2=A0 =C2=A0 =C2=A0Section 9.1:=C2=A0 STUN Methods
>=C2=A0 =C2=A0 =C2=A0Section 9.2: TLS ContentType (see:
> https://ww= w.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5)
>=C2=A0 =C2=A0 =C2=A0Section 9.3: TURN Channel Numbers
>
> It is interesting to note that RTP/RTCP and ZRTP are not included in t= he
> IANA considerations section, so that there is no "requires coordi= nation"
> applying to RTP version allocation, as there is to TLS ContentType. >
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>

--f403043791980e90bc055f137fdc-- From nobody Tue Nov 28 17:43:46 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2871286D6 for ; Tue, 28 Nov 2017 17:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rUCyWkM8ZE5n for ; Tue, 28 Nov 2017 17:43:43 -0800 (PST) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3F878126E7A for ; Tue, 28 Nov 2017 17:43:43 -0800 (PST) X-AuditID: 12074414-0d3ff70000006ddf-6b-5a1e10cd82a8 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C2.7E.28127.DC01E1A5; Tue, 28 Nov 2017 20:43:41 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vAT1heYt028027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 28 Nov 2017 20:43:41 -0500 To: avt@ietf.org References: From: Paul Kyzivat Message-ID: <3b458e44-37a7-42f2-fe81-532e9c6c00b6@alum.mit.edu> Date: Tue, 28 Nov 2017 20:43:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYndR1D0rIBdl8K3byOJlz0p2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlXJ7XzFiwTrfi/e2zLA2MR5W6GDk5JARMJHp/d7J1MXJxCAns YJLovL+EBcL5wiQxYe81VpAqYQELiW0rb7KD2CICAhIrtv+FKrrHKPG3axoLSIJNQEtizqH/ QDYHB6+AvcT3q5IgYRYBVYlFm2+xgdiiAmkSey50gJXzCghKnJz5BMzmFAiUOPx6KyOIzSxg JjFv80NmCFtc4taT+UwQtrxE89bZzBMY+WchaZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwp Tk3WLU5OzMtLLdK10MvNLNFLTSndxAgJS5EdjEdOyh1iFOBgVOLh1VgtGyXEmlhWXJl7iFGS g0lJlPfTQqAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd7KSUA53pTEyqrUonyYlDQHi5I477fF 6n5CAumJJanZqakFqUUwWRkODiUJ3mR+uSghwaLU9NSKtMycEoQ0EwcnyHAeoOGMwDgW4i0u SMwtzkyHyJ9itOc4tunyHyaOnp4bQPLRjbtA8tnM1w3MQix5+XmpUuK8D/mA2gRA2jJK8+Am w1LOK0ZxoEeFeaNBDuABpiu42a+A1jIBrb25XxpkbUkiQkqqgZHFYJnV2b1Klw9oTa2ZGvLT Zrdxy9kVAu+3CJl6r/mTmv2n90GGjA8Dd/IS45k6EqcXbjpm+uBAQK723E8xcddKM4z7Th5n VhW371sjfCzpL7vQktr3e33Lbv4WElzo9emFapqW7Plfcw+pM7k7Mx+867JMVf7KziJZNdMZ r31YztdsZfoe/VOJpTgj0VCLuag4EQDn7TPrFAMAAA== Archived-At: Subject: Re: [AVTCORE] RFC 7983 and multiplex principles X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:43:45 -0000 Doing the multiplexing this way was always a devil's bargain. It is just a matter of when the bill comes due. On 11/28/17 6:36 PM, Bernard Aboba wrote: > Martin said: > > "The principle I propose in the draft of a draft says that a general > purpose protocol should not consider the multiplexing use to be > binding.  DTLS is often used with 7983, but not exclusively." > > [BA] No RFC is "binding" in perpetuity, since with appropriate > consensus, another RFC can always be produced to update or obsolete it. > Also, RFC 7983 is conservative in its IANA Considerations section, which > only mentions allocation policies for STUN Methods (Section 9.1), TLS > ContentType (Section 9.2) and TURN Channel Numbers (Section 9.3).  Since > Section 9 doesn't mention anything about RTP/RTCP allocation policies, > it can't even be said to "bind" RTP/RTCP, let alone other general > purpose protocols. > > "I would say that it's not a guarantee that new versions of DTLS stay > in the 20-63 range.  Obviously, we will try - and we have done so with > the latest changes to the DTLS record layer - but that is not an > ironclad guarantee." > > [BA] That is entirely consistent with the IANA allocation policy for TLS > ContentType, which is "Coordination Required". > > "You could say that 7983 imposed that contract on DTLS, but that wasn't > entirely consensual.   If DTLS identifies a need to break this contract > that is stronger than its desire to remain compatible with 7983, then I > think that is a decision that will be made on the strength of the > need." > > [BA] I think that is implied by the "Coordination Required" policy, is > it not? > > The more complicated question relates to the practicalities of opting > out of RFC 7983.  That seems somewhat akin to Brexit in that we may not > know how hard it will be until we look into the details... > > For example, we talked about how a future version of QUIC might make at > least portions of RFC 7983 unnecessary by potentially transporting media > over QUIC (making it unnecessary to multiplex RTP/RTCP with QUIC) or by > supporting QUIC-SRTP and replacing the SCTP data channel (making it > unnecessary to multiplex DTLS with QUIC). > > > > > On Thu, Nov 23, 2017 at 10:01 PM, Martin Thomson > > wrote: > > The principle I propose in the draft of a draft says that a general > purpose protocol should not consider the multiplexing use to be > binding.  DTLS is often used with 7983, but not exclusively. > > I would say that it's not a guarantee that new versions of DTLS stay > in the 20-63 range.  Obviously, we will try - and we have done so with > the latest changes to the DTLS record layer - but that is not an > ironclad guarantee. > > You could say that 7983 imposed that contract on DTLS, but that wasn't > entirely consensual.  If DTLS identifies a need to break this contract > that is stronger than its desire to remain compatible with 7983, then > I think that is a decision that will be made on the strength of the > need. > > > On Fri, Nov 24, 2017 at 3:47 AM, Bernard Aboba > > wrote: > > At IETF 100, we had a discussion about the extensibility of RFC > 7983 in the > > context of QUIC multiplexing. > > > > Martin has put together some thoughts on multiplexing principles: > > > https://martinthomson.github.io/mux-principles/draft-thomson-mux-principles.html > > > > > One of the points made in this document is the potential impact of > > multiplexing on protocol evolution.  For example, with respect to > DTLS: > > > > "For instance, DTLS 1.3 [DTLS13] defines a record layout that > uses the first > > octet in a very different fashion to earlier versions; this design is > > constrained by the need to remain compatible with the scheme in > RFC 7983" > > > > Maintaining compatibility of DTLS with RFC 7983 does seem to be > important, > > since non-backward compatible changes could leave existing RFC 7983 > > implementations unable to upgrade. But is this binding, or merely > a "nice to > > have"? > > > > To the extent that there is one, the "contract" entered into by > protocols > > mentioned in RFC 7983 is contained in Section 9 (IANA > considerations), which > > covers: > > > >     Section 9.1:  STUN Methods > >     Section 9.2: TLS ContentType (see: > > > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5 > ) > >     Section 9.3: TURN Channel Numbers > > > > It is interesting to note that RTP/RTCP and ZRTP are not included > in the > > IANA considerations section, so that there is no "requires > coordination" > > applying to RTP version allocation, as there is to TLS ContentType. > > > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From nobody Tue Nov 28 19:10:52 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD7A126E7A for ; Tue, 28 Nov 2017 19:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EW0KUq9x8lrB for ; Tue, 28 Nov 2017 19:10:50 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62CB1200C1 for ; Tue, 28 Nov 2017 19:10:49 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id e74so1850461ote.7 for ; Tue, 28 Nov 2017 19:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vXL3InJSbnJswt1mzfETiklEKxCyH5L38G6nfDOjL/4=; b=N7vioq4/JaGQKrfRLPwDWYJ5ODIeMKdrVao1qw1AIictt49qi+sQGx9Cskl71ar6uJ 1rmzxjBPq+wjv+7EMw3AhUhDIDwO/1jhpvlSwYG6oVzWU4nuFfqLxMV5Dh4n2tnkJgp5 IDS8q2p88En1nAu/8TkY5wL6N626cnhQ1sdLMNjJAt9Pmqov2PsBKLVWlTUDsoWRBmwu SCojcjUAVf+xUk8V7H84gkernxQzBTYROe8gy5epnc1vSrj60FYFGPEFB9AgblquhIbI Y4x/KiMpUiM8AaMM2FilewdGm9Bl7UM/dKB9hlQHK6iaAHx3CXyfM0bIw4HT0bHmPtLl 2i5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vXL3InJSbnJswt1mzfETiklEKxCyH5L38G6nfDOjL/4=; b=i9Bh4jpvRzxktSTynv9fK/VY2zr2J+WOnompnUGJ+gdC7gQpyFSjdbVkQEcLim6may tZd4QCfAlgC7euSkIJxgPyw5VwjsJfNBoBwCjY4zXUFBNE83DgKiVHv2keYJcnVgQkGb gaNs5jua7UYu4DGG2yf8qb96u4QyyCnOgTGHdQ/TdP6ZcaxiGnxt4JOSHPDxl83kwD3M Zzyfsfv7TuHKt8gMbPHKBI60GE92Qo38vLxIpUopZdkbP035cmb4pzsux8i+heGlSjbg dpkgaa4+YJePnVIn59c21vtQ4rFiLG2enNlgxwYL4W85/IFG3OMvUFcjhnfw9pMFxdYs Exkw== X-Gm-Message-State: AJaThX4jAID2I+I5Ucc3hcATD93WumEKKq63RwvJQ/z70Thq8SMZjZOb a2J2SIb+v/N3I/NX6l9yRIdSPU5U87JwT4xC39Vnag== X-Google-Smtp-Source: AGs4zMa7ZUpIQdbCE1mz6g7E4RqhnERiCWsvtQeAki9oZsJ8iREaHR6MFdf0OZCt0C9y6xgOoGw5BxEOtTx+bY2Q0bU= X-Received: by 10.157.32.19 with SMTP id n19mr1227750ota.133.1511925049133; Tue, 28 Nov 2017 19:10:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Tue, 28 Nov 2017 19:10:48 -0800 (PST) In-Reply-To: <3b458e44-37a7-42f2-fe81-532e9c6c00b6@alum.mit.edu> References: <3b458e44-37a7-42f2-fe81-532e9c6c00b6@alum.mit.edu> From: Martin Thomson Date: Wed, 29 Nov 2017 14:10:48 +1100 Message-ID: To: Paul Kyzivat Cc: "avt@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [AVTCORE] RFC 7983 and multiplex principles X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 03:10:52 -0000 I've gotta say, the Brexit analogy is somewhat appealing, if not entirely accurate. On Wed, Nov 29, 2017 at 12:43 PM, Paul Kyzivat wrote: > Doing the multiplexing this way was always a devil's bargain. > It is just a matter of when the bill comes due. > > On 11/28/17 6:36 PM, Bernard Aboba wrote: >> >> Martin said: >> >> "The principle I propose in the draft of a draft says that a general >> purpose protocol should not consider the multiplexing use to be >> binding. DTLS is often used with 7983, but not exclusively." >> >> [BA] No RFC is "binding" in perpetuity, since with appropriate consensus, >> another RFC can always be produced to update or obsolete it. Also, RFC 7983 >> is conservative in its IANA Considerations section, which only mentions >> allocation policies for STUN Methods (Section 9.1), TLS ContentType (Section >> 9.2) and TURN Channel Numbers (Section 9.3). Since Section 9 doesn't >> mention anything about RTP/RTCP allocation policies, it can't even be said >> to "bind" RTP/RTCP, let alone other general purpose protocols. >> >> "I would say that it's not a guarantee that new versions of DTLS stay >> in the 20-63 range. Obviously, we will try - and we have done so with >> the latest changes to the DTLS record layer - but that is not an >> ironclad guarantee." >> >> [BA] That is entirely consistent with the IANA allocation policy for TLS >> ContentType, which is "Coordination Required". >> >> "You could say that 7983 imposed that contract on DTLS, but that wasn't >> entirely consensual. If DTLS identifies a need to break this contract >> that is stronger than its desire to remain compatible with 7983, then I >> think that is a decision that will be made on the strength of the >> need." >> >> [BA] I think that is implied by the "Coordination Required" policy, is it >> not? >> >> The more complicated question relates to the practicalities of opting out >> of RFC 7983. That seems somewhat akin to Brexit in that we may not know how >> hard it will be until we look into the details... >> >> For example, we talked about how a future version of QUIC might make at >> least portions of RFC 7983 unnecessary by potentially transporting media >> over QUIC (making it unnecessary to multiplex RTP/RTCP with QUIC) or by >> supporting QUIC-SRTP and replacing the SCTP data channel (making it >> unnecessary to multiplex DTLS with QUIC). >> >> >> >> >> On Thu, Nov 23, 2017 at 10:01 PM, Martin Thomson > > wrote: >> >> The principle I propose in the draft of a draft says that a general >> purpose protocol should not consider the multiplexing use to be >> binding. DTLS is often used with 7983, but not exclusively. >> >> I would say that it's not a guarantee that new versions of DTLS stay >> in the 20-63 range. Obviously, we will try - and we have done so with >> the latest changes to the DTLS record layer - but that is not an >> ironclad guarantee. >> >> You could say that 7983 imposed that contract on DTLS, but that wasn't >> entirely consensual. If DTLS identifies a need to break this contract >> that is stronger than its desire to remain compatible with 7983, then >> I think that is a decision that will be made on the strength of the >> need. >> >> >> On Fri, Nov 24, 2017 at 3:47 AM, Bernard Aboba >> > wrote: >> > At IETF 100, we had a discussion about the extensibility of RFC >> 7983 in the >> > context of QUIC multiplexing. >> > >> > Martin has put together some thoughts on multiplexing principles: >> > >> >> https://martinthomson.github.io/mux-principles/draft-thomson-mux-principles.html >> >> >> > >> > One of the points made in this document is the potential impact of >> > multiplexing on protocol evolution. For example, with respect to >> DTLS: >> > >> > "For instance, DTLS 1.3 [DTLS13] defines a record layout that >> uses the first >> > octet in a very different fashion to earlier versions; this design >> is >> > constrained by the need to remain compatible with the scheme in >> RFC 7983" >> > >> > Maintaining compatibility of DTLS with RFC 7983 does seem to be >> important, >> > since non-backward compatible changes could leave existing RFC 7983 >> > implementations unable to upgrade. But is this binding, or merely >> a "nice to >> > have"? >> > >> > To the extent that there is one, the "contract" entered into by >> protocols >> > mentioned in RFC 7983 is contained in Section 9 (IANA >> considerations), which >> > covers: >> > >> > Section 9.1: STUN Methods >> > Section 9.2: TLS ContentType (see: >> > >> >> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5 >> >> ) >> > Section 9.3: TURN Channel Numbers >> > >> > It is interesting to note that RTP/RTCP and ZRTP are not included >> in the >> > IANA considerations section, so that there is no "requires >> coordination" >> > applying to RTP version allocation, as there is to TLS ContentType. >> > >> > >> > >> > _______________________________________________ >> > Audio/Video Transport Core Maintenance >> > avt@ietf.org >> > https://www.ietf.org/mailman/listinfo/avt >> >> > >> >> >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt