From nobody Sat Nov 4 15:14:30 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941B813FBC5 for ; Sat, 4 Nov 2017 15:14:28 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 8UCtH8pz4BzV for ; Sat, 4 Nov 2017 15:14:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 DF11313FBC0 for ; Sat, 4 Nov 2017 15:14:24 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-fe-59fe3bbe6c1b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 10.DE.03220.EBB3EF95; Sat, 4 Nov 2017 23:14:23 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sat, 4 Nov 2017 23:14:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6TExxLLnOV2JTLVwytot3HXixuJWf11ayYVU8vKkVSU=; b=Y3jlSkuZfePWm0MSuJelXhq2XsSA8Ehh4GHRmH4J7oQSFqSXKyr4y+ksyIIta9+NVdFBj0TteIst60rwCTO52/4e76UWj13r12HeZ/QZT+mdEh0aY3+i+VwZApmKHdu8GJ1UhiDTiPbdM4HnXr9lRxHn+GGETLYHDu3UrB3WrkQ= Received: from HE1PR07MB3260.eurprd07.prod.outlook.com (10.170.246.27) by HE1PR07MB3260.eurprd07.prod.outlook.com (10.170.246.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Sat, 4 Nov 2017 22:14:21 +0000 Received: from HE1PR07MB3260.eurprd07.prod.outlook.com ([fe80::c91:47f7:1319:ce12]) by HE1PR07MB3260.eurprd07.prod.outlook.com ([fe80::c91:47f7:1319:ce12%13]) with mapi id 15.20.0218.005; Sat, 4 Nov 2017 22:14:21 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: IETF100 meeting agenda uploaded Thread-Index: AdNVuez3Jhzg+3IaQ2u+xfg/p42lVA== Date: Sat, 4 Nov 2017 22:14:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [109.225.125.147] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3260; 6:JiJYRR2tZdkuzsFsdnBi8GgU0hE4H+BN+DmtyhM7fQHYDlbPaFi1a9UiW8UCQvS8aCU3ybzEloqMr7x8eBykeW/Ml6GoGnd7rnpieSALmyCJ9I+SgaLF8KlGyCTEj15FbohoPKFsciPbEAGzOirD7fXrJqvsPrHHC64hO7VEiR4/3IVB98zjSnQKKhJjGACaX5PQJQnaW1u/nwR5fIulXGDuiaTQ3WuuZo5MwrcCl6y26BPlBqAmNwIGdimyVGjWGVg+oq+ccHpY3F0PiBdBd8j2JdVwlHZE0Pu4cOp8Qt6o/oY7QQxsih58kBsvRlZuSGyVaDPw9gikDt30pGvoT22uGhdJJOmFIywwdph6S6A=; 5:NLRvb9QxMjG5iN83JpQCzh3BkjHL3dsihZkxchGQMvkmTiNIjGOQRoCunKL3toWp/qPDYqeQ2YSFvYmUee12YmXPXUnRtZI7xU3Oha99L5ldpph+L7KsUataYHnmrkLRTEqxJeiFTM6o4HeJamt57Kw+esIkVKL6jsvUe2vxRg4=; 24:M5m34m9TXnFASOOMNEQYfEaFQh4F2zztEc7mac2EJcREr99hrpu1Qlb7q0HsTPcnOfwXYuLABeG1gvFHYXTIK4SdWHOgg2EREO0fba517ac=; 7:FCToZa18X/s3SzRJd6yHLvij0sQEQAmvwfpXjpq4CB9qg/j04MFOghWW4OfQepFtW7h4QtNEnAs7U+me21upQzou0lV7pBmF42Tb6o0klHcgLQ2doCSsFmt/MQpaYoekgqDKr0bG3U+zNW5q3VUb50XHV4Cc3EAlrPkj86ofZfz7zU1Jv1jYtSHGI2eVYvTjGb+FYCTiCAXNmo0hZ/etvnf6BGAJ1Qz1P6uhUvjCHDvH9p9oV89xh5lLrq7PX38T x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 41cbfef5-5823-4527-64cf-08d523d16630 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR07MB3260; x-ms-traffictypediagnostic: HE1PR07MB3260: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(202460600054446)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231021)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3260; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3260; x-forefront-prvs: 048111149A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(189998001)(86362001)(3660700001)(5660300001)(7736002)(2351001)(305945005)(25786009)(2906002)(3280700002)(14454004)(7696004)(74316002)(102836003)(6116002)(3846002)(966005)(99286004)(15974865002)(478600001)(2900100001)(97736004)(50986999)(105586002)(54356999)(68736007)(66066001)(53936002)(55016002)(6506006)(2501003)(6436002)(6916009)(33656002)(8936002)(81166006)(1730700003)(81156014)(8676002)(106356001)(6306002)(9686003)(5640700003)(316002)(101416001)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3260; H:HE1PR07MB3260.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3260CD10D0BE39FC9763A4409F520HE1PR07MB3260eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 41cbfef5-5823-4527-64cf-08d523d16630 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2017 22:14:21.1596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3260 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUyM2K7h+5+63+RBl9fMVnciXFg9Fiy5CdT AGMUl01Kak5mWWqRvl0CV8bndS+ZChrkKra++c/WwDhbuouRk0NCwESi/8M3li5GLg4hgcOM EkfuH2UDSQgJHGeU+Pc+CCTBItDLLNG/8gwbRNVUJom+/89YIZwHjBL9qycCZTg42ARsJB4v 9gPpFhFQlri8fyPYJGEBDYmXDWfZIeK6EleuTGKFsPUkrm/pAKthEVCRmHDyDQuIzSsQI7F+ wm6wGkYBMYnvp9YwgdjMAuISt57MZ4I4W0BiyZ7zzBC2qMTLx/+g6pMlpn5tZYOIK0tsOTIT ql5W4tL8bkaQmyUEDrFLnPi/FapZT2LrxLeMELavxPW1q5khimYySjR8aWKHSGhJHN+4hBXC zpFY8XovVEO2xO6+FqiaK6wSrx8IQNgyEis2wQzayipxbMp+RkigpkosX9vKCAkWKYm7VzoZ JzBqzULyHYSdL3F++kKWWeDQEJQ4OfMJC0RcT+LG1ClsELa2xLKFr5khbF2JGf8OsSCLL2Bk X8UoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRmGgObvmtuoPx8hvHQ4wCHIxKPLyOJv8ihVgT y4orcw8xSnAwK4nwzuIBCvGmJFZWpRblxxeV5qQWH2KU5mBREud13HchQkggPbEkNTs1tSC1 CCbLxMEp1cBYlHlVYud1r3lbl018sDbX25pLnP9V/e/+70fnpB00Zah/klWXurjroOQ08UXf LBtmNXc2m7wI5eM5cGBbR8ndLI0Z8ttjosXUIs9d/uXc/2emyI72O0vSZdqO2b97fP7w1s2d /GeDps2Y9vGN6r8wu7otKro3PjzndMpZYNEeE/1m2qXKNVEuSizFGYmGWsxFxYkAPGX0LzAD AAA= Archived-At: Subject: [Taps] IETF100 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 22:14:28 -0000 --_000_HE1PR07MB3260CD10D0BE39FC9763A4409F520HE1PR07MB3260eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello WG, The agenda for IETF100 has been uploaded https://datatracker.ietf.org/meeti= ng/100/materials/agenda-100-taps/ Any comments? BR Zahed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ANM ZAHEDUZZAMAN SARKER Ericsson Research Ericsson Laboratoriegr=E4nd 11 97128 Lule=E5, Sweden Phone +46 10 717 37 43 Mobile +46 76 115 37 43 Office +46 76 115 37 43 Fax +46 920 996 21 zaheduzzaman.sarker@ericsson.com www.ericsson.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --_000_HE1PR07MB3260CD10D0BE39FC9763A4409F520HE1PR07MB3260eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello WG,
 
 
Any comments?
 
BR
 
Zahed
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
ANM ZAHEDUZZAMAN SARKER
Erics= son Research

Ericsson=
Laboratoriegr=E4nd 11
97128 Lule=E5, Sweden
Phone +46 10 717 37 43
Mobile +46 76 115 37 43
Office +46 76 115 37 43
Fax +46 920 996 21
zaheduzzaman.sarker@ericsson.com
www.ericsson.com<= /u>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
 
 
 
 --_000_HE1PR07MB3260CD10D0BE39FC9763A4409F520HE1PR07MB3260eurp_-- From nobody Sun Nov 5 00:49:58 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E08713FB6D for ; Sun, 5 Nov 2017 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 KTApoLdRaIfe for ; Sun, 5 Nov 2017 00:49:53 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 A7C4913FB6C for ; Sun, 5 Nov 2017 00:49:53 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eBFgl-0001sw-Bz; Sun, 05 Nov 2017 08:49:51 +0100 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.6]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eBFgk-0008Gv-JQ; Sun, 05 Nov 2017 08:49:51 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E80FB0AD-3EA3-435E-87C1-2AD45E461E94" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 5 Nov 2017 08:49:52 +0100 In-Reply-To: Cc: "taps@ietf.org" To: Zaheduzzaman Sarker References: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.6]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.096, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 24B2572403F56218524AF14FFDC82C5923C8D157 Archived-At: Subject: Re: [Taps] IETF100 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 07:49:56 -0000 --Apple-Mail=_E80FB0AD-3EA3-435E-87C1-2AD45E461E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, It seems to me that this charter contains three items that relate to the = API: 1) draft-trammell-taps-post-sockets-03 2) draft-tiesel-taps-socketintents-01 3) draft-fairhurst-taps-neat-00 ...which are currently charter items 3, 4 and 6 (an unrelated - no less = important! because it describes the implementation! - item takes = position 5). Moreover, for the first one, it says "expected adoption = call targeting charter item 3=E2=80=9D. I think it would make more sense to first hear all three proposals and = then discuss the possible adoption of one of them? Cheers, Michael > On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker = wrote: >=20 > Hello WG, > =20 > The agenda for IETF100 has been uploaded = https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/ = > =20 > Any comments? > =20 > BR > =20 > Zahed > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > ANM ZAHEDUZZAMAN SARKER=20 > Ericsson Research >=20 > Ericsson > Laboratoriegr=C3=A4nd 11 > 97128 Lule=C3=A5, Sweden > Phone +46 10 717 37 43 > Mobile +46 76 115 37 43 > Office +46 76 115 37 43 > Fax +46 920 996 21 > zaheduzzaman.sarker@ericsson.com = > www.ericsson.com > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > =20 > =20 > =20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps = --Apple-Mail=_E80FB0AD-3EA3-435E-87C1-2AD45E461E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

It = seems to me that this charter contains three items that relate to the = API:
1) draft-trammell-taps-post-sockets-03
2) draft-tiesel-taps-socketintents-01
3) draft-fairhurst-taps-neat-00

...which are currently charter items 3, = 4 and 6 (an unrelated - no less important! because it describes the = implementation! - item takes position 5). Moreover, for the first one, = it says "expected = adoption call targeting charter item 3=E2=80=9D.

I think it would make more sense to first hear all = three proposals and then discuss the possible adoption of one of = them?

Cheers,
Michael


On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hello = WG,
 
The agenda for = IETF100 has been uploaded https://datatracker.ietf.org/meeting/100/materials/agenda-100-t= aps/
 
Any = comments?
 
BR
 
Zahed
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
ANM ZAHEDUZZAMAN = SARKER 
Ericsson = Research

Ericsson
Laboratoriegr=C3=A4nd 11
97128 Lule=C3=A5, = Sweden
Phone +46 10 717 37 43
Mobile +46 76 = 115 37 43
Office +46 76 115 37 43
Fax +46 = 920 996 21
zaheduzzaman.sarker@ericsson.com
www.ericsson.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
 
 
 
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_E80FB0AD-3EA3-435E-87C1-2AD45E461E94-- From nobody Sun Nov 5 12:44:21 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06C913FCFE for ; Sun, 5 Nov 2017 12:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=apple.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 hT_JlIrkDSxy for ; Sun, 5 Nov 2017 12:44:17 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 1D0A013FCFA for ; Sun, 5 Nov 2017 12:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1509914656; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=euqTM9D/EzLZIPmJQ82xDwmHuDYDFe/qmmNWcqwlob0=; b=TeIXGRrRtaLgJTbCCslIO2hRXBbT2B9vOqmgfmm5p/7XQABnCjciz4pUzlfu8EFr PlyzFxoV5AbITY4QDNf/hYdySFuVntlLjPMwh5gaVZPhEcItuYbLJY1G4kTICxpI 1xVDit5aFCDIkvDd92bOrVwJR4mmneKLKa6Y7AkdURgoLj6Stw3ZAPqrfd6QTjA3 YUTrIfbLTy7IPpazm3XyT/CXYkokcfT4w1qnnSdS6vKsTyOLn3CA5FuaKLhTUuUF pm50lAz2XqDcBzciUjak4ssj/ITBm5S8vjg8kE7GbnMqWa/b0knrVej/TrhHuzTM uSrLwa9ZzGHl0KD9L7CAeg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 9E.DA.20985.0287FF95; Sun, 5 Nov 2017 12:44:16 -0800 (PST) X-AuditID: 11973e15-265ff700000051f9-da-59ff78204e40 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay4.apple.com (Apple SCV relay) with SMTP id 2C.35.31187.0287FF95; Sun, 5 Nov 2017 12:44:16 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_o51GlkEwuv/0ffaArGwhVQ)" Received: from [17.234.73.83] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OYY00M5JPLRCW30@nwk-mmpp-sz10.apple.com>; Sun, 05 Nov 2017 12:44:16 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Sun, 05 Nov 2017 12:44:14 -0800 In-reply-to: Cc: Zaheduzzaman Sarker , "taps@ietf.org" To: Michael Welzl References: X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUi2FAYrqtQ8T/S4PstDYsfZ3eyWtyJsThy 6h2zA7PHr69X2TyWLPnJ5LF69UPmAOYoLpuU1JzMstQifbsErozHNzpZCi4WVKxd59XAeCm5 i5GTQ0LARKJhzm22LkYuDiGB1UwSUxrmscEkTl1/wAxiCwkcYpS48q8OxOYVEJT4MfkeC4jN LBAmMWXGWhaI5i+MEs2bZjB1MXJwCAtISGzekwhSwyagInH82wZmiF4bic0fboLZwgLGEqff 97CAlLMIqErs6YsBCXMK2El8aH7LDjE+VmJyxxMmEFtEQE3ixPLVUHdOYpTYtWc3K8SdihIP N3WxgiQkBJawSSzfeo5lAqPQLCS3zkJy6yygfcwC6hJTpuRChLUlnry7wAphq0ks/L2ICVl8 ASPbKkah3MTMHN3MPDO9xIKCnFS95PzcTYyguJhuJ7qD8cwqq0OMAhyMSjy8Jzz+RQqxJpYV V+YeYpTmYFES59Xd+jtSSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OA5cyzilN2XUk8HTPx eFli5ZIXwSb8n3uOMKt7XC8OaZE0C36zt//f2ugFS3U+7lwaltC3+CPb6l2LJN/eXha61qL6 VvVXlntO9w7zlcX67XqrYLJgv56p0U5OnZe7tbQ2cubJBcVt85XUYj9SHymptqDxaIMem3vc qi3n+ysSGls2xuiwvFFiKc5INNRiLipOBAAtnut+bAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUi2FBcpatQ8T/SYNEZFYsfZ3eyWtyJsThy 6h2zA7PHr69X2TyWLPnJ5LF69UPmAOYoLpuU1JzMstQifbsErozHNzpZCi4WVKxd59XAeCm5 i5GTQ0LAROLU9QfMILaQwCFGiSv/6kBsXgFBiR+T77GA2MwCYRJTZqwFsrmAar4wSjRvmsHU xcjBISwgIbF5TyJIDZuAisTxbxuYIXptJDZ/uAlmCwsYS5x+38MCUs4ioCqxpy8GJMwpYCfx ofktO8T4WInJHU+YQGwRATWJE8tXs0GsmsQosWvPblaIOxUlHm7qYp3AyD8LyXmzkJw3C2gF s4C6xJQpuRBhbYkn7y6wQthqEgt/L2JCFl/AyLaKUaAoNSex0kQvsaAgJ1UvOT93EyM4jAvD dzD+W2Z1iFGAg1GJh/eEx79IIdbEsuLKXGAQcTArifAulf0fKcSbklhZlVqUH19UmpNafIhR moNFSZy3YP6PSCGB9MSS1OzU1ILUIpgsEwenVAOjhWXW/vLDn3g8+lW3uXEsjd8xXVj5Nv8p 0T+GkTKsLLweOy0TvUW/zv8o1+uroL518XNu/T1m0y+Yd7zcyX+uWVKZe/37FHmV1arnqp50 RNiffP1b0XL39Hu/RAsNj976qB57p+fgYRamdSkaKgHRZY8YZx1LK2+vqHjlMDtNZ9HkgnOX 814rsRRnJBpqMRcVJwIAKcDlJF8CAAA= Archived-At: Subject: Re: [Taps] IETF100 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 20:44:20 -0000 --Boundary_(ID_o51GlkEwuv/0ffaArGwhVQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable One quick thought on this: I think that the charter item 3 (the = recommended mechanisms for deploying a TAPS system) can and should = certainly include multiple documents. These documents we'll be talking = about are in no way mutually exclusive, so I don't think we should be = thinking of it as "hear all three and choose one of them". We may well = want to adopt all of them, or some other combination of documents, to = cover item 3. Specifically, from the charter item, we see that the idea = is plural: "Specify experimental support mechanisms ...". One proposal for approaching the charter item is to ultimately have = documents like this: - A top-level API document (like post sockets, as informed by the = specific implementation example that Gorry gives in the NEAT document) - A document on application preferences interacting with system policy = (like the socket intents draft) - A document on racing connection establishment (like = draft-pauly-taps-guidelines-01 + draft-grinnemo-taps-he-03) These different aspects don't necessarily make sense to combine, and = have different audiences for implementers. The agenda order could be modified, but since there doesn't need to be = any mutual exclusivity between the items, the current order should be = fine too. Thanks, Tommy > On Nov 5, 2017, at 12:49 AM, Michael Welzl wrote: >=20 > Hi, >=20 > It seems to me that this charter contains three items that relate to = the API: > 1) draft-trammell-taps-post-sockets-03 > 2) draft-tiesel-taps-socketintents-01 > 3) draft-fairhurst-taps-neat-00 >=20 > ...which are currently charter items 3, 4 and 6 (an unrelated - no = less important! because it describes the implementation! - item takes = position 5). Moreover, for the first one, it says "expected adoption = call targeting charter item 3=E2=80=9D. >=20 > I think it would make more sense to first hear all three proposals and = then discuss the possible adoption of one of them? >=20 > Cheers, > Michael >=20 >=20 >> On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker = > wrote: >>=20 >> Hello WG, >> =20 >> The agenda for IETF100 has been uploaded = https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/ = >> =20 >> Any comments? >> =20 >> BR >> =20 >> Zahed >> =20 >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> ANM ZAHEDUZZAMAN SARKER=20 >> Ericsson Research >>=20 >> Ericsson >> Laboratoriegr=C3=A4nd 11 >> 97128 Lule=C3=A5, Sweden >> Phone +46 10 717 37 43 >> Mobile +46 76 115 37 43 >> Office +46 76 115 37 43 >> Fax +46 920 996 21 >> zaheduzzaman.sarker@ericsson.com = >> www.ericsson.com >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> =20 >> =20 >> =20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps = > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_o51GlkEwuv/0ffaArGwhVQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable One = quick thought on this: I think that the charter item 3 (the recommended = mechanisms for deploying a TAPS system) can and should certainly include = multiple documents. These documents we'll be talking about are in no way = mutually exclusive, so I don't think we should be thinking of it as = "hear all three and choose one of them". We may well want to adopt all = of them, or some other combination of documents, to cover item 3. = Specifically, from the charter item, we see that the idea is plural: = "Specify experimental support mechanisms ...".

One proposal for = approaching the charter item is to ultimately have documents like = this:
- A top-level API document (like post = sockets, as informed by the specific implementation example that Gorry = gives in the NEAT document)
- A document on = application preferences interacting with system policy (like the socket = intents draft)
- A document on racing connection = establishment (like draft-pauly-taps-guidelines-01 = + draft-grinnemo-taps-he-03)

These different aspects don't = necessarily make sense to combine, and have different audiences for = implementers.

The agenda order could be modified, but since there doesn't = need to be any mutual exclusivity between the items, the current order = should be fine too.

Thanks,
Tommy

On Nov 5, 2017, at 12:49 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

It seems to me that this = charter contains three items that relate to the API:
1) draft-trammell-taps-post-sockets-03
2) draft-tiesel-taps-socketintents-01
3) draft-fairhurst-taps-neat-00

...which are currently charter items 3, = 4 and 6 (an unrelated - no less important! because it describes the = implementation! - item takes position 5). Moreover, for the first one, = it says "expected = adoption call targeting charter item 3=E2=80=9D.

I think it would make more sense to first hear all = three proposals and then discuss the possible adoption of one of = them?

Cheers,
Michael


On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hello = WG,
 
The agenda for = IETF100 has been uploaded https://datatracker.ietf.org/meeting/100/materials/agenda-100-t= aps/
 
Any = comments?
 
BR
 
Zahed
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
ANM ZAHEDUZZAMAN = SARKER 
Ericsson = Research

Ericsson
Laboratoriegr=C3=A4nd 11
97128 Lule=C3=A5, = Sweden
Phone +46 10 717 37 43
Mobile +46 76 = 115 37 43
Office +46 76 115 37 43
Fax +46 = 920 996 21
zaheduzzaman.sarker@ericsson.com
www.ericsson.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
 
 
 
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_o51GlkEwuv/0ffaArGwhVQ)-- From nobody Sun Nov 5 12:58:07 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E1F13FD04 for ; Sun, 5 Nov 2017 12:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 sKIPGQlEMkMq for ; Sun, 5 Nov 2017 12:58:03 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 03AF213FCEE for ; Sun, 5 Nov 2017 12:58:03 -0800 (PST) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eBRzT-0007vC-JW; Sun, 05 Nov 2017 21:57:59 +0100 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.6]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eBRzR-00053R-7G; Sun, 05 Nov 2017 21:57:59 +0100 From: Michael Welzl Message-Id: <2AC996D2-9F68-4229-827D-AAB5950E86BB@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_CD767C3A-FF14-48B2-B793-C10491CCF59D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 5 Nov 2017 21:57:57 +0100 In-Reply-To: Cc: Zaheduzzaman Sarker , "taps@ietf.org" To: Tommy Pauly References: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.6]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.079, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4E95DC5A49C7EE8441B56DF49AB3AF15A7AA7456 Archived-At: Subject: Re: [Taps] IETF100 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 20:58:06 -0000 --Apple-Mail=_CD767C3A-FF14-48B2-B793-C10491CCF59D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I almost agree :-) I agree that there should be several documents, = along the lines of what you write - but I do think there should be only = one API=E2=80=A6 Cheers, Michael =20 > On Nov 5, 2017, at 9:44 PM, Tommy Pauly wrote: >=20 > One quick thought on this: I think that the charter item 3 (the = recommended mechanisms for deploying a TAPS system) can and should = certainly include multiple documents. These documents we'll be talking = about are in no way mutually exclusive, so I don't think we should be = thinking of it as "hear all three and choose one of them". We may well = want to adopt all of them, or some other combination of documents, to = cover item 3. Specifically, from the charter item, we see that the idea = is plural: "Specify experimental support mechanisms ...". >=20 > One proposal for approaching the charter item is to ultimately have = documents like this: > - A top-level API document (like post sockets, as informed by the = specific implementation example that Gorry gives in the NEAT document) > - A document on application preferences interacting with system policy = (like the socket intents draft) > - A document on racing connection establishment (like = draft-pauly-taps-guidelines-01 + draft-grinnemo-taps-he-03) >=20 > These different aspects don't necessarily make sense to combine, and = have different audiences for implementers. >=20 > The agenda order could be modified, but since there doesn't need to be = any mutual exclusivity between the items, the current order should be = fine too. >=20 > Thanks, > Tommy >=20 >> On Nov 5, 2017, at 12:49 AM, Michael Welzl > wrote: >>=20 >> Hi, >>=20 >> It seems to me that this charter contains three items that relate to = the API: >> 1) draft-trammell-taps-post-sockets-03 >> 2) draft-tiesel-taps-socketintents-01 >> 3) draft-fairhurst-taps-neat-00 >>=20 >> ...which are currently charter items 3, 4 and 6 (an unrelated - no = less important! because it describes the implementation! - item takes = position 5). Moreover, for the first one, it says "expected adoption = call targeting charter item 3=E2=80=9D. >>=20 >> I think it would make more sense to first hear all three proposals = and then discuss the possible adoption of one of them? >>=20 >> Cheers, >> Michael >>=20 >>=20 >>> On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker = > wrote: >>>=20 >>> Hello WG, >>> =20 >>> The agenda for IETF100 has been uploaded = https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/ = >>> =20 >>> Any comments? >>> =20 >>> BR >>> =20 >>> Zahed >>> =20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> ANM ZAHEDUZZAMAN SARKER=20 >>> Ericsson Research >>>=20 >>> Ericsson >>> Laboratoriegr=C3=A4nd 11 >>> 97128 Lule=C3=A5, Sweden >>> Phone +46 10 717 37 43 >>> Mobile +46 76 115 37 43 >>> Office +46 76 115 37 43 >>> Fax +46 920 996 21 >>> zaheduzzaman.sarker@ericsson.com = >>> www.ericsson.com >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> =20 >>> =20 >>> =20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps = >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail=_CD767C3A-FF14-48B2-B793-C10491CCF59D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = almost agree  :-)    I agree that there should be several = documents, along the lines of what you write - but I do think there = should be only one API=E2=80=A6

Cheers,
Michael

 
On Nov 5, 2017, at 9:44 PM, Tommy Pauly = <tpauly@apple.com> wrote:

One quick thought on = this: I think that the charter item 3 (the recommended mechanisms for = deploying a TAPS system) can and should certainly include multiple = documents. These documents we'll be talking about are in no way mutually = exclusive, so I don't think we should be thinking of it as "hear all = three and choose one of them". We may well want to adopt all of them, or = some other combination of documents, to cover item 3. Specifically, from = the charter item, we see that the idea is plural: "Specify experimental = support mechanisms ...".

One proposal for approaching the = charter item is to ultimately have documents like this:
- A top-level API document (like post sockets, as informed by = the specific implementation example that Gorry gives in the NEAT = document)
- A document on application preferences = interacting with system policy (like the socket intents draft)
- A document on racing connection establishment = (like draft-pauly-taps-guidelines-01 = + draft-grinnemo-taps-he-03)

These different aspects don't = necessarily make sense to combine, and have different audiences for = implementers.

The agenda order could be modified, but since there doesn't = need to be any mutual exclusivity between the items, the current order = should be fine too.

Thanks,
Tommy

On Nov 5, 2017, at 12:49 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

It seems to me that this = charter contains three items that relate to the API:
1) draft-trammell-taps-post-sockets-03
2) draft-tiesel-taps-socketintents-01
3) draft-fairhurst-taps-neat-00

...which are currently charter items 3, = 4 and 6 (an unrelated - no less important! because it describes the = implementation! - item takes position 5). Moreover, for the first one, = it says "expected = adoption call targeting charter item 3=E2=80=9D.

I think it would make more sense to first hear all = three proposals and then discuss the possible adoption of one of = them?

Cheers,
Michael


On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hello = WG,
 
The agenda for = IETF100 has been uploaded https://datatracker.ietf.org/meeting/100/materials/agenda-100-t= aps/
 
Any = comments?
 
BR
 
Zahed
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
ANM ZAHEDUZZAMAN = SARKER 
Ericsson = Research

Ericsson
Laboratoriegr=C3=A4nd 11
97128 Lule=C3=A5, = Sweden
Phone +46 10 717 37 43
Mobile +46 76 = 115 37 43
Office +46 76 115 37 43
Fax +46 = 920 996 21
zaheduzzaman.sarker@ericsson.com
www.ericsson.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
 
 
 
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps


= --Apple-Mail=_CD767C3A-FF14-48B2-B793-C10491CCF59D-- From nobody Sun Nov 5 13:21:16 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D7E13FBDB for ; Sun, 5 Nov 2017 13:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=apple.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 gXXriLE7_HDG for ; Sun, 5 Nov 2017 13:21:12 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 CD11713FBBD for ; Sun, 5 Nov 2017 13:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1509916872; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JKPaar8SqIzKXKQSilaqXSVbOMrHDwFfnN3xi6Ghc3Q=; b=AVJnJlZQDwP+0HW2vg85TTOk9onLw+SwSuSwXHDpH7IItsCk0vxZUcRxjKr6YVyf 6cekUFUJICWuIKPbYoyL45n2PPbmMI/HrzUnXi9ko9FVbq1OzZwE136B6gchxPjR uPF3Iueqko4Av+VckjlH/fsBnVs7F4xQT9J2ySl9MgbjUiJkGx0CFhWvxLn+LurD Onh8fJ16bz1pBRLUkX2zDT0zsVzssAgtxzJfZ8jynJsIpcl+Opl9oDkrmUB3cwV7 SleI8k7WyebeiB56eM3ISZVzxoaMmUy2mEQmrB/JD0Gnypu2d1ruE73+xgGInHfG bT5QJzmcK0ov8nR2T24evg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id AC.6C.23913.8C08FF95; Sun, 5 Nov 2017 13:21:12 -0800 (PST) X-AuditID: 11973e13-7c9ff70000005d69-3c-59ff80c87f7c Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id 1C.00.21963.8C08FF95; Sun, 5 Nov 2017 13:21:12 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8BCozn2Ic++6IYxaAWYXCg)" Received: from [17.234.73.83] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OYY00MNLRBBCW50@nwk-mmpp-sz10.apple.com>; Sun, 05 Nov 2017 13:21:12 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Sun, 05 Nov 2017 13:21:10 -0800 In-reply-to: <2AC996D2-9F68-4229-827D-AAB5950E86BB@ifi.uio.no> Cc: Zaheduzzaman Sarker , "taps@ietf.org" To: Michael Welzl References: <2AC996D2-9F68-4229-827D-AAB5950E86BB@ifi.uio.no> X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FDorHui4X+kQfsVRYsfZ3eyWtyJsThy 6h2zA7PHr69X2TyWLPnJ5LF69UPmAOYoLpuU1JzMstQifbsEroxjs2czFvyay1ixoncNWwPj 3C7GLkZODgkBE4m709ayg9hCAquZJI7NzIOJv2vayAgRP8QosXoPWJxXQFDix+R7LCA2s0CY xK5VW9i6GLmAar4wSrzu+M/axcjBISwgIbF5TyJIDZuAisTxbxuYIXptJN78mwq2S1jAWOL0 +x6wOSwCqhIrWn8ygrRyCthJPH2TATE+VmJyxxMmEFtEQE3ixPLVUKt+Mko8vTqRBeJORYmH m7pYQRISAivYJJ63P2KcwCg0C8mts5DcOgtoB7OAusSUKbkQYW2JJ+8usELYahILfy9iQhZf wMi2ilEoNzEzRzczz1QvsaAgJ1UvOT93EyMoNqbbCe9gPL3K6hCjAAejEg/vCY9/kUKsiWXF lbmHGKU5WJTEefW2/o4UEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLgg8t2CDzpZ20xmrVj9 jDVuueXMq+q1k7pqG1fOrortOpjDK3Z90lf+69kzVhdP91fZKiu1NvmZZ8zfHKkrIp/nuPI6 7/oT0HLuEcffV2fns62XV+DT/9RX+yovu3dPxYLYV7xHu2Yd689Y01bOWc+Saizy95jeP0nv 7Ww7eH4kbUxWFPDwv6jEUpyRaKjFXFScCAB+xGjqbgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUi2FBcpXui4X+kwapZMhY/zu5ktbgTY3Hk 1DtmB2aPX1+vsnksWfKTyWP16ofMAcxRXDYpqTmZZalF+nYJXBnHZs9mLPg1l7FiRe8atgbG uV2MXYycHBICJhLvmjaC2UIChxglVu/JA7F5BQQlfky+xwJiMwuESexatYWti5ELqOYLo8Tr jv+sXYwcHMICEhKb9ySC1LAJqEgc/7aBGaLXRuLNv6nsILawgLHE6fc9YHNYBFQlVrT+ZARp 5RSwk3j6JgNifKzE5I4nTCC2iICaxInlq6FW/WSUeHp1IgvEnYoSDzd1sU5g5J+F5LxZSM6b BTSWWUBdYsqUXIiwtsSTdxdYIWw1iYW/FzEhiy9gZFvFKFCUmpNYaaSXWFCQk6qXnJ+7iREc zIXOOxiPLbM6xCjAwajEw3vC41+kEGtiWXFlLjCIOJiVRHiXyv6PFOJNSaysSi3Kjy8qzUkt PsQozcGiJM5bOP9HpJBAemJJanZqakFqEUyWiYNTqoHRNup1IbP97D3JtilLJr14Yzl5vq1y q9lBx9BvVQknNTdX1oseYf6v82z5o+fnp1/zYneIjPLn2ON5IfUS98ZPXLt5XTPebnONOf+8 6+rsr2lh+e4r+uIlNXutzzwV7zfYpMI5aarb7iOcu9dW/fHU+PGLaWu8pq26fSCrh5JVQvbi e5+tF/9WYinOSDTUYi4qTgQAyT3AQGICAAA= Archived-At: Subject: Re: [Taps] IETF100 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 21:21:15 -0000 --Boundary_(ID_8BCozn2Ic++6IYxaAWYXCg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Indeed! But, as far as I can tell, drafts like = draft-tiesel-taps-socketintents-01 are not trying to propose a top-level = API, but rather an aspect of the API. Even when we discuss the draft for what I'm referring to as the = "top-level API", I think we need to (in the spirit of the charter) not = be specifying a specific set of language-specific API calls, or a = specific framework, but the shape that instances of an API should take. = My goal coming out of TAPS would be to change the approach implementers = take when designing transport APIs, to make sure that the resulting APIs = not only support the flexibility TAPS was designed for, but also can be = standard and cross-compatible across all operating systems. Thus, we = want the documents to encompass API principles and concepts, but leave = the semantics flexible and as an exercise to the reader. Perhaps in the = examples, even give several options in different language styles, and = show how code can be easily translated between the approaches. To be specific, I would imagine that whatever API examples we have in = the various documents we write will not necessarily be part of any = specific implementation. Rather, various implementations will conform to = the principles and patterns of the API description. Apple's transport = APIs would match it, NEAT's APIs would match it, Android APIs would = match it, Windows APIs would match it, etc, etc. Thanks, Tommy > On Nov 5, 2017, at 12:57 PM, Michael Welzl wrote: >=20 > Hi, >=20 > I almost agree :-) I agree that there should be several documents, = along the lines of what you write - but I do think there should be only = one API=E2=80=A6 >=20 > Cheers, > Michael >=20 > =20 >> On Nov 5, 2017, at 9:44 PM, Tommy Pauly > wrote: >>=20 >> One quick thought on this: I think that the charter item 3 (the = recommended mechanisms for deploying a TAPS system) can and should = certainly include multiple documents. These documents we'll be talking = about are in no way mutually exclusive, so I don't think we should be = thinking of it as "hear all three and choose one of them". We may well = want to adopt all of them, or some other combination of documents, to = cover item 3. Specifically, from the charter item, we see that the idea = is plural: "Specify experimental support mechanisms ...". >>=20 >> One proposal for approaching the charter item is to ultimately have = documents like this: >> - A top-level API document (like post sockets, as informed by the = specific implementation example that Gorry gives in the NEAT document) >> - A document on application preferences interacting with system = policy (like the socket intents draft) >> - A document on racing connection establishment (like = draft-pauly-taps-guidelines-01 + draft-grinnemo-taps-he-03) >>=20 >> These different aspects don't necessarily make sense to combine, and = have different audiences for implementers. >>=20 >> The agenda order could be modified, but since there doesn't need to = be any mutual exclusivity between the items, the current order should be = fine too. >>=20 >> Thanks, >> Tommy >>=20 >>> On Nov 5, 2017, at 12:49 AM, Michael Welzl > wrote: >>>=20 >>> Hi, >>>=20 >>> It seems to me that this charter contains three items that relate to = the API: >>> 1) draft-trammell-taps-post-sockets-03 >>> 2) draft-tiesel-taps-socketintents-01 >>> 3) draft-fairhurst-taps-neat-00 >>>=20 >>> ...which are currently charter items 3, 4 and 6 (an unrelated - no = less important! because it describes the implementation! - item takes = position 5). Moreover, for the first one, it says "expected adoption = call targeting charter item 3=E2=80=9D. >>>=20 >>> I think it would make more sense to first hear all three proposals = and then discuss the possible adoption of one of them? >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>> On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker = > wrote: >>>>=20 >>>> Hello WG, >>>> =20 >>>> The agenda for IETF100 has been uploaded = https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/ = >>>> =20 >>>> Any comments? >>>> =20 >>>> BR >>>> =20 >>>> Zahed >>>> =20 >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> ANM ZAHEDUZZAMAN SARKER=20 >>>> Ericsson Research >>>>=20 >>>> Ericsson >>>> Laboratoriegr=C3=A4nd 11 >>>> 97128 Lule=C3=A5, Sweden >>>> Phone +46 10 717 37 43 >>>> Mobile +46 76 115 37 43 >>>> Office +46 76 115 37 43 >>>> Fax +46 920 996 21 >>>> zaheduzzaman.sarker@ericsson.com = >>>> www.ericsson.com >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>> =20 >>>> =20 >>>> =20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps = >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps = >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_8BCozn2Ic++6IYxaAWYXCg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Indeed! But, as far as I can tell, drafts = like draft-tiesel-taps-socketintents-01 are not trying to propose a = top-level API, but rather an aspect of the API.

Even when we discuss the draft for what = I'm referring to as the "top-level API", I think we need to (in the = spirit of the charter) not be specifying a specific set of = language-specific API calls, or a specific framework, but the shape that = instances of an API should take. My goal coming out of TAPS would be to = change the approach implementers take when designing transport APIs, to = make sure that the resulting APIs not only support the flexibility TAPS = was designed for, but also can be standard and cross-compatible across = all operating systems. Thus, we want the documents to encompass API = principles and concepts, but leave the semantics flexible and as an = exercise to the reader. Perhaps in the examples, even give several = options in different language styles, and show how code can be easily = translated between the approaches.

To be specific, I would imagine that = whatever API examples we have in the various documents we write will not = necessarily be part of any specific implementation. Rather, various = implementations will conform to the principles and patterns of the API = description. Apple's transport APIs would match it, NEAT's APIs would = match it, Android APIs would match it, Windows APIs would match it, etc, = etc.

Thanks,
Tommy

On Nov 5, 2017, at 12:57 PM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

I almost agree  :-) =    I agree that there should be several documents, along the = lines of what you write - but I do think there should be only one = API=E2=80=A6

Cheers,
Michael

 
On Nov = 5, 2017, at 9:44 PM, Tommy Pauly <tpauly@apple.com> wrote:

One quick thought on = this: I think that the charter item 3 (the recommended mechanisms for = deploying a TAPS system) can and should certainly include multiple = documents. These documents we'll be talking about are in no way mutually = exclusive, so I don't think we should be thinking of it as "hear all = three and choose one of them". We may well want to adopt all of them, or = some other combination of documents, to cover item 3. Specifically, from = the charter item, we see that the idea is plural: "Specify experimental = support mechanisms ...".

One proposal for approaching the = charter item is to ultimately have documents like this:
- A top-level API document (like post sockets, as informed by = the specific implementation example that Gorry gives in the NEAT = document)
- A document on application preferences = interacting with system policy (like the socket intents draft)
- A document on racing connection establishment = (like draft-pauly-taps-guidelines-01 = + draft-grinnemo-taps-he-03)

These different aspects don't = necessarily make sense to combine, and have different audiences for = implementers.

The agenda order could be modified, but since there doesn't = need to be any mutual exclusivity between the items, the current order = should be fine too.

Thanks,
Tommy

On Nov 5, 2017, at 12:49 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

It seems to me that this = charter contains three items that relate to the API:
1) draft-trammell-taps-post-sockets-03
2) draft-tiesel-taps-socketintents-01
3) draft-fairhurst-taps-neat-00

...which are currently charter items 3, = 4 and 6 (an unrelated - no less important! because it describes the = implementation! - item takes position 5). Moreover, for the first one, = it says "expected = adoption call targeting charter item 3=E2=80=9D.

I think it would make more sense to first hear all = three proposals and then discuss the possible adoption of one of = them?

Cheers,
Michael


On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hello = WG,
 
The agenda for = IETF100 has been uploaded https://datatracker.ietf.org/meeting/100/materials/agenda-100-t= aps/
 
Any = comments?
 
BR
 
Zahed
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
ANM ZAHEDUZZAMAN = SARKER 
Ericsson = Research

Ericsson
Laboratoriegr=C3=A4nd 11
97128 Lule=C3=A5, = Sweden
Phone +46 10 717 37 43
Mobile +46 76 = 115 37 43
Office +46 76 115 37 43
Fax +46 = 920 996 21
zaheduzzaman.sarker@ericsson.com
www.ericsson.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
 
 
 
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps


_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_8BCozn2Ic++6IYxaAWYXCg)-- From nobody Sun Nov 5 14:42:30 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E00113FD0C for ; Sun, 5 Nov 2017 14:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 wHJKjTrH8HJh for ; Sun, 5 Nov 2017 14:42:26 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 AC2C713FD0B for ; Sun, 5 Nov 2017 14:42:26 -0800 (PST) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eBTcW-0002rl-Oo; Sun, 05 Nov 2017 23:42:24 +0100 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.6]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eBTcV-0000Av-SA; Sun, 05 Nov 2017 23:42:24 +0100 From: Michael Welzl Message-Id: <8CF3A491-7F7C-4D18-AB21-EDB43BB5C409@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_4FA5F515-D628-4404-B4A6-D52ECBB276D3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 5 Nov 2017 23:42:24 +0100 In-Reply-To: Cc: Zaheduzzaman Sarker , "taps@ietf.org" To: Tommy Pauly References: <2AC996D2-9F68-4229-827D-AAB5950E86BB@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.6]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.076, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FD3FB401B02DB1844F0C0FEB8FC42D46560EA17F Archived-At: Subject: Re: [Taps] IETF100 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 22:42:29 -0000 --Apple-Mail=_4FA5F515-D628-4404-B4A6-D52ECBB276D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, =20 > On Nov 5, 2017, at 10:21 PM, Tommy Pauly wrote: >=20 > Indeed! But, as far as I can tell, drafts like = draft-tiesel-taps-socketintents-01 are not trying to propose a top-level = API, but rather an aspect of the API. I agree with everything you say here. About = draft-tiesel-taps-socketintents-01, okay - I wasn=E2=80=99t so sure = where this is heading =E2=80=A6 but both = draft-trammell-taps-post-sockets-03 and draft-fairhurst-taps-neat-00.txt = describe an abstract API. > Even when we discuss the draft for what I'm referring to as the = "top-level API", I think we need to (in the spirit of the charter) not = be specifying a specific set of language-specific API calls, or a = specific framework, but the shape that instances of an API should take. = My goal coming out of TAPS would be to change the approach implementers = take when designing transport APIs, to make sure that the resulting APIs = not only support the flexibility TAPS was designed for, but also can be = standard and cross-compatible across all operating systems. Thus, we = want the documents to encompass API principles and concepts, but leave = the semantics flexible and as an exercise to the reader. Perhaps in the = examples, even give several options in different language styles, and = show how code can be easily translated between the approaches. Yes - and these principles (also in the spirit of the charter) should be = based on the analysis of existing transports and the definition of a = minimal set of services that TAPS systems should support. I made an = effort to be reasonable in the minimum set that we=E2=80=99ve derived: - avoid getting stuck in a corner (being tied to only one protocol) - allow for one-sided deployment, with a fall-back to TCP or UDP ( = (D)TLS TBD - I think that was a very reasonable request) - not miss out on functionality that can never be offered unless it=E2=80=99= s put in the API > To be specific, I would imagine that whatever API examples we have in = the various documents we write will not necessarily be part of any = specific implementation. Rather, various implementations will conform to = the principles and patterns of the API description. Apple's transport = APIs would match it, NEAT's APIs would match it, Android APIs would = match it, Windows APIs would match it, etc, etc. I agree with all that. To be clear, this is not me arguing for or against one specific API. = I=E2=80=99m only keen on ensuring that the result matches the principles = I used for the minset, as listed above (or, if folks disagree with them, = we should discuss them). I only want TAPS to be implementable, useful = and deployable (where I think that allowing one-sided deployment is a = big deal). Cheers, Michael --Apple-Mail=_4FA5F515-D628-4404-B4A6-D52ECBB276D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

 
On Nov 5, 2017, at 10:21 PM, Tommy Pauly = <tpauly@apple.com> wrote:

Indeed! But, as far as = I can tell, drafts like draft-tiesel-taps-socketintents-01 are not = trying to propose a top-level API, but rather an aspect of the = API.

I = agree with everything you say here. About = draft-tiesel-taps-socketintents-01, okay - I wasn=E2=80=99t so sure = where this is heading =E2=80=A6 but both draft-trammell-taps-post-sockets-03 = and draft-fairhurst-taps-neat-00.txt describe an abstract = API.


Even when we discuss the = draft for what I'm referring to as the "top-level API", I think we need = to (in the spirit of the charter) not be specifying a specific set of = language-specific API calls, or a specific framework, but the shape that = instances of an API should take. My goal coming out of TAPS would be to = change the approach implementers take when designing transport APIs, to = make sure that the resulting APIs not only support the flexibility TAPS = was designed for, but also can be standard and cross-compatible across = all operating systems. Thus, we want the documents to encompass API = principles and concepts, but leave the semantics flexible and as an = exercise to the reader. Perhaps in the examples, even give several = options in different language styles, and show how code can be easily = translated between the = approaches.

Yes - and these principles (also in the spirit of = the charter) should be based on the analysis of existing transports and = the definition of a minimal set of services that TAPS systems should = support. I made an effort to be reasonable in the minimum set that = we=E2=80=99ve derived:
- avoid getting stuck in a corner = (being tied to only one protocol)
- allow for one-sided = deployment, with a fall-back to TCP or UDP ( (D)TLS TBD - I think that = was a very reasonable request)
- not miss out on functionality = that can never be offered unless it=E2=80=99s put in the = API


To be specific, I would imagine that whatever = API examples we have in the various documents we write will not = necessarily be part of any specific implementation. Rather, various = implementations will conform to the principles and patterns of the API = description. Apple's transport APIs would match it, NEAT's APIs would = match it, Android APIs would match it, Windows APIs would match it, etc, = etc.

I = agree with all that.

To be clear, = this is not me arguing for or against one specific API. I=E2=80=99m only = keen on ensuring that the result matches the principles I used for the = minset, as listed above (or, if folks disagree with them, we should = discuss them).  I only want TAPS to be implementable, useful and = deployable (where I think that allowing one-sided deployment is a big = deal).

Cheers,
Michael

= --Apple-Mail=_4FA5F515-D628-4404-B4A6-D52ECBB276D3-- From nobody Mon Nov 6 00:38:00 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5494613FB4E for ; Mon, 6 Nov 2017 00:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rUGIGXtS_5Vx for ; Mon, 6 Nov 2017 00:37:55 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB1C13F963 for ; Mon, 6 Nov 2017 00:37:55 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id E89A31B001C4; Mon, 6 Nov 2017 08:37:19 +0000 (GMT) Message-ID: <5A001F42.8020403@erg.abdn.ac.uk> Date: Mon, 06 Nov 2017 08:37:22 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Welzl CC: Zaheduzzaman Sarker , "taps@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] IETF100 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 08:37:58 -0000 It seems to me there are many ideas that could come forward if the work in TAPS progresses. To me the three IDs we currently have are quite different - and they seem to have different design goals. I suggest if the group is thinking of accepting work against the third item in the charter that it would be good to spend a little time to look at these proposals and then to explore how the various proposals fit with the "subset of Transport Services" resulting from the second charter item. Best wishes, Gorry On 05/11/2017, 07:49, Michael Welzl wrote: > Hi, > > It seems to me that this charter contains three items that relate to > the API: > 1) draft-trammell-taps-post-sockets-03 > 2) draft-tiesel-taps-socketintents-01 > 3) draft-fairhurst-taps-neat-00 > > ...which are currently charter items 3, 4 and 6 (an unrelated - no > less important! because it describes the implementation! - item takes > position 5). Moreover, for the first one, it says "expected adoption > call targeting charter item 3”. > > I think it would make more sense to first hear all three proposals and > then discuss the possible adoption of one of them? > > Cheers, > Michael > > >> On Nov 4, 2017, at 11:14 PM, Zaheduzzaman Sarker >> > > wrote: >> >> Hello WG, >> The agenda for IETF100 has been >> uploaded_https://datatracker.ietf.org/meeting/100/materials/agenda-100-taps/_ >> Any comments? >> BR >> Zahed >> *===============================================================================* >> *ANM ZAHEDUZZAMAN SARKER >> *Ericsson Research >> >> *Ericsson >> *Laboratoriegränd 11 >> 97128 Luleå, Sweden >> Phone +46 10 717 37 43 >> Mobile +46 76 115 37 43 >> Office +46 76 115 37 43 >> Fax +46 920 996 21 >> zaheduzzaman.sarker@ericsson.com >> >> _www.ericsson.com_ >> =============================================================================== >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Nov 7 01:05:21 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C07B13FCF4 for ; Tue, 7 Nov 2017 01:05:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 gETGJFuP_2hd for ; Tue, 7 Nov 2017 01:05:13 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 7533113FCC7 for ; Tue, 7 Nov 2017 01:04:18 -0800 (PST) X-AuditID: c1b4fb2d-bf5ff7000000268d-9a-5a017710ae86 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 92.FC.09869.017710A5; Tue, 7 Nov 2017 10:04:16 +0100 (CET) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 7 Nov 2017 10:04:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XJWQBy+gzShkkeMvEOe9vw8FHNdALuErnN1i/UbBUyg=; b=kZtOrVgBrGdTQs3EY8Q6nHbcM4WGPKqAhSLtsZj+0RUsOmN9QqPcd4zxTd1J88Y+JeMMMogsvGuz51FLIt2/S62kew0SPJ7NtES0Q2aTNkqiBzsYfJpnPuKjh9GNE0dVw6ApO8zzoEYvrg0bbkWEqYaj4MCRiEhGu1+s9A3TI0w= Received: from HE1PR07MB3260.eurprd07.prod.outlook.com (10.170.246.27) by HE1PR07MB3257.eurprd07.prod.outlook.com (10.170.246.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Tue, 7 Nov 2017 09:04:14 +0000 Received: from HE1PR07MB3260.eurprd07.prod.outlook.com ([fe80::c91:47f7:1319:ce12]) by HE1PR07MB3260.eurprd07.prod.outlook.com ([fe80::c91:47f7:1319:ce12%13]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 09:04:14 +0000 From: Zaheduzzaman Sarker To: "gorry@erg.abdn.ac.uk" , Michael Welzl CC: "taps@ietf.org" Thread-Topic: [Taps] IETF100 meeting agenda uploaded Thread-Index: AdNVuez3Jhzg+3IaQ2u+xfg/p42lVAAULywAADPzSQAAMzr2gA== Date: Tue, 7 Nov 2017 09:04:14 +0000 Message-ID: References: <5A001F42.8020403@erg.abdn.ac.uk> In-Reply-To: <5A001F42.8020403@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [192.176.1.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3257; 6:kLIX07JEhf9Xvv8TzTe4K1GeWCgiUztkLk/TodqJzviX+zMgz+kOjKM5GjLX+L8rnigqqJaTQLpNaAc8lfWIbUSJiEj6qQcaNY8HbrU+vV6th/GbSXjcO97VkCxEdJ/+DNyiZRGlFWoyiqBfCYACWxUycOqsTTZWi9jzAUxs6EtWZQsU6n6tCjAU3AeJBaDEfdlUQF+SkaqHVLuZmSDWS8fYGTxLK1zzycUGHv/3+y7c7+7X0pqPgfBXkLIymYg76oiQN5cA1/u2Xr/b8jIBd47a4zM/ZmlBU1EJqi0IWq6teyVKIhJFVr+nkNFkeDCR95xo7c0QObR+g2j2Pj9Cld5BW+0gaCkEjAqWG7JkDJY=; 5:Bl+QJ+fICq+QvkIk0sNFD2ROXPACm9xDXh0SYviRz3EDNTcru+OsXnNLjURPsV2xu/BZfZZoGsJh0PgRTxwZf7gh6NLllgcxKty6rpP1R94C0x/S8uurdftcVU/h882hL8D90ako50Pnju4MM69rps4UWEzqFKB6QtHzOWCnI54=; 24:y8huDwyIAJlj8j3UgHI49HRGLPQJYefWDmFqSb07hXdo0Tcacsk/yWwNEi/rTlY40X/wTW9u9nQtxjkZ30dHQi8h5OxhDNlckA6N7nY+/us=; 7:luiPfEDcYdsDV1j/6xS5+RaIechtiF0hfDYNQpJNDl3C13dHo1WrtmoeuN+OAHmAqMEWjmlmXG8eacrGKg9Ut2h0vfzW92k3ezZnlhtBU4+03dJEJ7TxjzJP9x/pIc9ZuKL/JWjW4Z4+EVVhbh1a/wfIVsakBAHUvJIk4vHkz0Otn0kdjaqJHU1RmBBnmEccXK3eCsYugIarsoWg7vlFFvJabcrAtu+aZ6ZPZXQqEUu2x3DBzVzLPzcFCa+b7vxg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5e75b594-bc24-4f29-875b-08d525be84d1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR07MB3257; x-ms-traffictypediagnostic: HE1PR07MB3257: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(202460600054446); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(3231021)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3257; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3257; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(189002)(24454002)(199003)(377424004)(53546010)(82746002)(189998001)(966005)(86362001)(8676002)(3846002)(102836003)(36756003)(14454004)(6116002)(83506002)(3660700001)(81156014)(76176999)(50986999)(54356999)(81166006)(4326008)(8936002)(2906002)(478600001)(3280700002)(25786009)(68736007)(5660300001)(2900100001)(561944003)(7736002)(316002)(6486002)(6512007)(6306002)(6436002)(305945005)(6506006)(110136005)(83716003)(6246003)(33656002)(101416001)(58126008)(2950100002)(106356001)(97736004)(5250100002)(2501003)(99286004)(105586002)(66066001)(53936002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3257; H:HE1PR07MB3260.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5e75b594-bc24-4f29-875b-08d525be84d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 09:04:14.4818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3257 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUyM2K7t65AOWOUwbSDShav22YzWvw4u5PV 4k6MA7NHz+cXTB5Llvxk8li9+iFzAHMUl01Kak5mWWqRvl0CV8aKvj/sBU9UK94fXMzawPhC pYuRk0NCwERi3fndzF2MXBxCAocZJR6efMkE4RxnlGg7+wEswyLQyyyx9+cyRpAWIYGpTBI9 K50hqh4wSlxZ18HaxcjBwSZgI/F4sR9IjYhAuMSkBzNZQMLMAsoS+5/WgoSFBYwlTr/vYYEo MZGYteIXK4TtJLHv9w+w8SwCKhIXWr6DxXkF7CXeLWlnhVi1hVFi4d9usCJOAT2JQ+cngQ1i FBCT+H5qDROIzSwgLtH0ZSUrxGsCEkv2nGeGsEUlXj7+B3amKFBv+/9aiNZkialfW9kgShQk 3s09DWXLSlyaD7KKC8g+xC7RfWsv1Bw9ia0T3zJC2L4Sx9ZcYIYomskoMeFJH1S3lsTESauh joiROHuglwnCzpZoP3sNquEKq8TNXzdZJzAazEJy+CxwgGlKrN+lDxH2kOi9+5IVwlaUmNL9 kH0WOGAEJU7OfMKygJF1FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgcjm45bfuDsbVrx0P MQpwMCrx8H5KYYwSYk0sK67MPcQowcGsJMK7XZ0hSog3JbGyKrUoP76oNCe1+BCjNAeLkjiv w74LEUIC6YklqdmpqQWpRTBZJg5OqQZGk895G75rCj0Uqu8Se+p0ZdtybYGfpZ2fPtltqFnL uiZY8Y6RzKzKjWdWFmjbqH/6EfE44I7D5cTMd338+V/NE5LYZY+46j8R9bJ6PMVvoSH76ndN j0xlzvTFt/r/MLXd5Z0fekfgvZ/4XqbpwrO9KpkiZzSpFsqozPBP3bTq6k1XUxYR9ntKLMUZ iYZazEXFiQAJZiOfKgMAAA== Archived-At: Subject: Re: [Taps] IETF100 meeting agenda uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 09:05:20 -0000 SGksDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyBhbmQgdGhvdWdodHMsIGl0IGlzIGEgZ29v ZCBkaXNjdXNzaW9uIGdvaW5nIG9uIGhlcmUuIEkgdGhpbmsgd2UgY2FuIGNvbnRpbnVlIHRoZSBk aXNjdXNzaW9uIGF0IHRoZSBtZWV0aW5nIGFzIHdlIGhhdmUgbW9yZSB0aW1lIGFjY29yZGluZyB0 byB0aGUgY3VycmVudCBhZ2VuZGEgdGltZS4gVGhlIHByb3Bvc2FsIGlzIHRvIGhhdmUgYSBzZXBh cmF0ZSBzbG90IGF0IHRoZSBJRVRGMTAwIG1lZXRpbmcgdG8gZGlzY3VzcyBob3cgdG8gYWRkcmVz cyB0aGUgY2hhcnRlciBpdGVtIDMg4oCTIG11bHRpcGxlIGRvY3VtZW50cywgbXVsdGlwbGUgaW1w bGVtZW50YXRpb25zIGV0Yy4NCg0KQmFzZWQgb24gdGhlIGRpc2N1c3Npb24gaGVyZSBJIHdpbGwg a2VlcCB0aGUgcHJlc2VudGF0aW9uIG9yZGVyIGFzIGl0IGlzLiBUaGUgaW5pdGlhbCB0aGlua2lu ZyBiZWhpbmQgdGhlIG9yZGVyIHdhcyB0aGF0IFRvbW15IHdvdWxkIHRhbGsgYWJvdXQgcmFjaW5n IGNvbmRpdGlvbiBhbmQgZmFsbC1iYWNrcyBhbmQgR29ycnkgd291bGQgdGVsbCBhYm91dCB3aGF0 IHBvbGljaWVzIGFuZCBBUEkgb3B0aW9ucyBORUFUIHRvb2sgdG8gYWRkcmVzcyB0aGUgc2ltaWxh ciBhc3BlY3RzLiBIZW5jZSwgdGhleSBraW5kIG9mIGZpdCB0b2dldGhlci4NCg0KVXBkYXRlZCBh Z2VuZGEgaGVyZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAwL21hdGVy aWFscy9hZ2VuZGEtMTAwLXRhcHMvIA0KDQoNCkJSDQoNClphaGVkIA0KDQoNCg0KT24gMjAxNy0x MS0wNiwgMDk6MzgsICJHb3JyeSBGYWlyaHVyc3QiIDxnb3JyeUBlcmcuYWJkbi5hYy51az4gd3Jv dGU6DQoNCiAgICANCiAgICBJdCBzZWVtcyB0byBtZSB0aGVyZSBhcmUgbWFueSBpZGVhcyB0aGF0 IGNvdWxkIGNvbWUgZm9yd2FyZCBpZiB0aGUgd29yayANCiAgICBpbiBUQVBTIHByb2dyZXNzZXMu DQogICAgDQogICAgVG8gbWUgdGhlIHRocmVlIElEcyB3ZSBjdXJyZW50bHkgaGF2ZSBhcmUgcXVp dGUgZGlmZmVyZW50IC0gYW5kIHRoZXkgDQogICAgc2VlbSB0byBoYXZlIGRpZmZlcmVudCBkZXNp Z24gZ29hbHMuIEkgc3VnZ2VzdCBpZiB0aGUgZ3JvdXAgaXMgdGhpbmtpbmcgDQogICAgb2YgYWNj ZXB0aW5nIHdvcmsgYWdhaW5zdCB0aGUgdGhpcmQgaXRlbSBpbiB0aGUgY2hhcnRlciB0aGF0IGl0 IHdvdWxkIGJlIA0KICAgIGdvb2QgdG8gc3BlbmQgYSBsaXR0bGUgdGltZSB0byBsb29rIGF0IHRo ZXNlIHByb3Bvc2FscyBhbmQgdGhlbiB0byANCiAgICBleHBsb3JlIGhvdyB0aGUgdmFyaW91cyBw cm9wb3NhbHMgZml0IHdpdGggdGhlICJzdWJzZXQgb2YgVHJhbnNwb3J0IA0KICAgIFNlcnZpY2Vz IiByZXN1bHRpbmcgZnJvbSB0aGUgc2Vjb25kIGNoYXJ0ZXIgaXRlbS4NCiAgICANCiAgICBCZXN0 IHdpc2hlcywNCiAgICANCiAgICBHb3JyeQ0KICAgIA0KICAgIE9uIDA1LzExLzIwMTcsIDA3OjQ5 LCBNaWNoYWVsIFdlbHpsIHdyb3RlOg0KICAgID4gSGksDQogICAgPg0KICAgID4gSXQgc2VlbXMg dG8gbWUgdGhhdCB0aGlzIGNoYXJ0ZXIgY29udGFpbnMgdGhyZWUgaXRlbXMgdGhhdCByZWxhdGUg dG8gDQogICAgPiB0aGUgQVBJOg0KICAgID4gMSkgZHJhZnQtdHJhbW1lbGwtdGFwcy1wb3N0LXNv Y2tldHMtMDMNCiAgICA+IDIpIGRyYWZ0LXRpZXNlbC10YXBzLXNvY2tldGludGVudHMtMDENCiAg ICA+IDMpIGRyYWZ0LWZhaXJodXJzdC10YXBzLW5lYXQtMDANCiAgICA+DQogICAgPiAuLi53aGlj aCBhcmUgY3VycmVudGx5IGNoYXJ0ZXIgaXRlbXMgMywgNCBhbmQgNiAoYW4gdW5yZWxhdGVkIC0g bm8gDQogICAgPiBsZXNzIGltcG9ydGFudCEgYmVjYXVzZSBpdCBkZXNjcmliZXMgdGhlIGltcGxl bWVudGF0aW9uISAtIGl0ZW0gdGFrZXMgDQogICAgPiBwb3NpdGlvbiA1KS4gTW9yZW92ZXIsIGZv ciB0aGUgZmlyc3Qgb25lLCBpdCBzYXlzICJleHBlY3RlZCBhZG9wdGlvbiANCiAgICA+IGNhbGwg dGFyZ2V0aW5nIGNoYXJ0ZXIgaXRlbSAz4oCdLg0KICAgID4NCiAgICA+IEkgdGhpbmsgaXQgd291 bGQgbWFrZSBtb3JlIHNlbnNlIHRvIGZpcnN0IGhlYXIgYWxsIHRocmVlIHByb3Bvc2FscyBhbmQg DQogICAgPiB0aGVuIGRpc2N1c3MgdGhlIHBvc3NpYmxlIGFkb3B0aW9uIG9mIG9uZSBvZiB0aGVt Pw0KICAgID4NCiAgICA+IENoZWVycywNCiAgICA+IE1pY2hhZWwNCiAgICA+DQogICAgPg0KICAg ID4+IE9uIE5vdiA0LCAyMDE3LCBhdCAxMToxNCBQTSwgWmFoZWR1enphbWFuIFNhcmtlciANCiAg ICA+PiA8emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20gDQogICAgPj4gPG1haWx0bzp6 YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KICAgID4+DQogICAgPj4g SGVsbG8gV0csDQogICAgPj4gVGhlIGFnZW5kYSBmb3IgSUVURjEwMCBoYXMgYmVlbiANCiAgICA+ PiB1cGxvYWRlZF9odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAwL21hdGVy aWFscy9hZ2VuZGEtMTAwLXRhcHMvXw0KICAgID4+IEFueSBjb21tZW50cz8NCiAgICA+PiBCUg0K ICAgID4+IFphaGVkDQogICAgPj4gKj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0qDQogICAgPj4gKkFO TSBaQUhFRFVaWkFNQU4gU0FSS0VSDQogICAgPj4gKkVyaWNzc29uIFJlc2VhcmNoDQogICAgPj4N CiAgICA+PiAqRXJpY3Nzb24NCiAgICA+PiAqTGFib3JhdG9yaWVncsOkbmQgMTENCiAgICA+PiA5 NzEyOCBMdWxlw6UsIFN3ZWRlbg0KICAgID4+IFBob25lICs0NiAxMCA3MTcgMzcgNDMNCiAgICA+ PiBNb2JpbGUgKzQ2IDc2IDExNSAzNyA0Mw0KICAgID4+IE9mZmljZSArNDYgNzYgMTE1IDM3IDQz DQogICAgPj4gRmF4ICs0NiA5MjAgOTk2IDIxDQogICAgPj4gemFoZWR1enphbWFuLnNhcmtlckBl cmljc3Nvbi5jb20gDQogICAgPj4gPG1haWx0bzp6YWhlZHV6emFtYW4uc2Fya2VyQGVyaWNzc29u LmNvbT4NCiAgICA+PiBfd3d3LmVyaWNzc29uLmNvbV8gPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29t Lz4NCiAgICA+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogICAgPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+PiBUYXBzIG1haWxpbmcgbGlz dA0KICAgID4+IFRhcHNAaWV0Zi5vcmcgPG1haWx0bzpUYXBzQGlldGYub3JnPg0KICAgID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGFwcw0KICAgID4NCiAgICA+DQog ICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICA+IFRhcHMgbWFpbGluZyBsaXN0DQogICAgPiBUYXBzQGlldGYub3JnDQogICAgPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RhcHMNCiAgICANCiAgICANCg0K From nobody Fri Nov 10 17:44:02 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3131272E1 for ; Fri, 10 Nov 2017 17:44:00 -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 uOIVM-IdjqZN for ; Fri, 10 Nov 2017 17:43:58 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 0D1EC127201 for ; Fri, 10 Nov 2017 17:43:58 -0800 (PST) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eDKpw-0005NH-Ds for taps@ietf.org; Sat, 11 Nov 2017 02:43:56 +0100 Received: from [66.96.215.225] (helo=[10.0.0.203]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eDKpv-0002PE-7I for taps@ietf.org; Sat, 11 Nov 2017 02:43:56 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sat, 11 Nov 2017 09:43:51 +0800 To: "taps@ietf.org" X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 66.96.215.225 is neither permitted nor denied by domain of ifi.uio.no) client-ip=66.96.215.225; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.203]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 673156698A984A80FBEEEFC03A032F32E5F0E548 Archived-At: Subject: [Taps] Review of draft-trammell-taps-post-sockets-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 01:44:01 -0000 Dear all, Because of the planned request for draft-trammell-taps-post-sockets-03 = to become a WG item, I gave the draft another close read and decided to = write a review based on this. I hope it's useful. To me, post-sockets aims in the right direction - I like a number of = things about it: the introduction of higher-layer concepts such as the = carrier and association; I suspect that the long-term association = management could also be implemented one-sided, which is nice. I like = the idea of "forking" a carrier, which would clearly translate into = doing multi-streaming "under the hood" whenever that's possible (side = note: from the list on pages 7/8, it seems that *only* "Listener" can be = forked. Why not a Source? This seems odd to me). Finally, obviously I = also agree that being message-oriented is the right way to go. On the negative side, I still see several problems here (actually almost = nothing has changed from --02 to -03), listed below: The biggest problem I see is that this has very limited usage scenarios, = as it requires a post-socket system on both sides (there's quite a bit = of functionality in there that won't work otherwise - to give an = illustrative example: "When a Carrier is forked, its corresponding = Carrier at the remote endpoint receives a fork request, .."). I find it = particularly disappointing because, in my opinion, it wouldn't take much = to make this able to fall-back to TCP such that e.g. a post-sockets = client could talk to an existing TCP server. Anyway, what IS this = falling back to? If you add functionality both on the sender and = receiver side, you require a post-sockets system on both sides - and = then you could just as well consistently run over UDP or TCP or HTTP/2 = or whatever else you want, without any fall-backs (and as this develops = new transport functionality, we're then really moving away from the TAPS = charter). I think we must better understand what types of fall-backs are = envisioned here. The document talks about "asynchronous reception", as if this was a = feature that would only be attainable with a novel approach, and/or a = message-based transport. I see having a callback-based API and a = socket-style API as largely orthogonal from the protocol below: one can = of course also write a callback-based API over TCP... the real problem = is to know after how much received data the receiving app should be = notified, by whatever means - that's just a general dilemma, and not a = new problem, as the PUSH bit in RFC 793 shows. Messages may seem to make = this easier, but then you have to start wondering how large can messages = be, how we should handle partial messages... e.g., you may need a signal = from the receiver-side TAPS system to the app to say "you have stored = half a message, but please throw this data block away now, you'll never = get the rest". You have some discussion of partial messages in this = draft, and we've been around that block with SCTP. IMO, the right = approach is to leave all of that out: define a short max limit, and let = an application take care of splitting into smaller messages itself = (since you have message dependencies, why do you need to have large = messages too, and not just smaller sub-messages that all sequentially = depend on another?). This also makes prioritization more meaningful. Generally, the draft just leaves many questions unanswered at this = stage, as it stays at a rather high level and lists most services just = as examples, saying that more could be possible. If it's that vague, how = should anybody implement such a system? Here's a list of transport = features (from minset) that we will lose if we don't offer them to an = application, and that I didn't see mentioned in post-sockets (sorry if I = missed some!). Some of them may seem a bit odd and unimportant, others = less so (this is from appendix A2, where "T" and "U" mean "can be = supported with a fall-back to TCP and UDP, respectively): o T,U: Specify number of attempts and/or timeout for the first establishment message o T: Change timeout for aborting connection (using retransmit limit or time value) o T: Suggest timeout to the peer o T,U: Disable Nagle algorithm o T,U: Notification of Excessive Retransmissions (early warning below abortion threshold) o T,U: Specify DSCP field o T,U: Notification of ICMP error message arrival o T,U: Set Cookie life value o T,U: Disable checksum when sending o T,U: Disable checksum requirement when receiving o T,U: Specify checksum coverage used by the sender o T,U: Specify minimum checksum coverage required by receiver o T,U: Specify DF field o T,U: Get max. transport-message size that may be sent using a non- fragmented IP packet from the configured interface o T,U: Get max. transport-message size that may be received from the configured interface o T,U: Obtain ECN field o T,U: Enable and configure a "Low Extra Delay Background Transfer" o T,U: Request not to delay the acknowledgement (SACK) of a message o T,U: Notification that the stack has no more user data to send =46rom this list, a few functions that I would consider important are: - DSCP, and enabling and configuring LEDBAT-like behavior: these two = could be lumped together in a higher-level request, but they're not just = a priority. Sure, your message "niceness" could be translated into a = DSCP choice, but I mean that an app may want to be able to control more = (e.g. do a general per-carrier configuration for low latency or LBE, for = example). Speaking of LEDBAT, post-sockets also doesn't say anything = about whether the transport is congestion controlled or not (which = translates into: does the app have to worry about it?). Another = congestion control thing: access to the ECN flag in case of UDP should = also be covered in some form. - Notification that the stack has no more user data to send: this is the = TCP_NOWAIT_LOWAT function. Hmmm... wait! At first I thought the binding = to an .OnAcked() event handler can't be done with TCP, but if the = post-sockets layer would intelligently use TCP_NOWAIT_LOWAT, then you = could pull this off. - Get max. transport-message size that may be sent using a = non-fragmented IP packet from the configured interface: this is useful = to avoid fragmentation overhead, and - Specify DF field =3D> if we fall back to UDP, we need this in order to = do PMTUD. ... and then there's also the need for early configuration of some = things to guide protocol choice, which I wrote as a decision tree in = draft-ietf-taps-minset-00. While I agree with your idea of specifying a = limited set of protocols to use - we do the same with policy in NEAT - = that can't be all: a TAPS system should probably prevent, e.g., first = picking UDP and then getting a request for reliability. That brings us = back to the question about what you're planning to fall back to, of = course. I hope this was helpful, cheers, Michael From nobody Fri Nov 10 18:06:35 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB935128BA2 for ; Fri, 10 Nov 2017 18:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=apple.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 N5XZIitdYva7 for ; Fri, 10 Nov 2017 18:06:31 -0800 (PST) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 83DEA12778E for ; Fri, 10 Nov 2017 18:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510365990; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hO0pTNnY+zkLF4ulGPubCgY9uRiKH5iq+JHOknsoT+o=; b=eKDGcoSrDH0eOJ9H7clBY5kgiDo2g/rbWQlgBLQivImd+EaJ8mTn1ce5/hpkhQkl jSgIIOse/NVZkymzRtUy1TSRFetKDsXCIzKYu9Oc/vupmhUINifGq6OztvK3G83G 9JAdL26DDuOAzxVVnW3weF2uXOOq991jyICahmFQoPZi8cJhMN1kYmHCvbcySVZV 0hCFlTCwHr+uw7jAGwbUB7SUI/rYbEW/peaEgEWqT+IIWVn/OlWWHvbODP+QSAeu OoMOkYCDsXI5Xdn56fhE4C9yf1Xy/w/hv8jhv2VCwcxWK6Wr1Qf1IgywsdgbKuO5 m470ipMvtF3JGgfc9Y3lGg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 2F.29.29340.62B560A5; Fri, 10 Nov 2017 18:06:30 -0800 (PST) X-AuditID: 11ab0217-df6059c00000729c-17-5a065b26686c Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay8.apple.com (Apple SCV relay) with SMTP id F4.FE.22651.62B560A5; Fri, 10 Nov 2017 18:06:30 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.56.75] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZ800C0UDU5EM60@nwk-mmpp-sz09.apple.com>; Fri, 10 Nov 2017 18:06:30 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Sat, 11 Nov 2017 10:06:04 +0800 Cc: "taps@ietf.org" Content-transfer-encoding: quoted-printable Message-id: References: To: Michael Welzl X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FCYpqsWzRZl8HCZhsWPsztZLe7EODB5 LFnyk8lj9eqHzAFMUVw2Kak5mWWpRfp2CVwZR7peMxb8ca94s3kBSwPjTssuRk4OCQETid7f b9i7GLk4hATWMknMvTGBESZx+NpyqMRBRol17y4ygSR4BQQlfky+xwJiMwtoSXx/1MoCUfSF UWLB1F6gDg4OYQEJic17EkFqhAUcJc5/mAI2lE1AReL4tw3MIDangJ1E4+T7YDaLgKrEn/dt TBAzlSUez2qEmq8t8eTdBVaIvTYSm5oXgdUICdhKXDy6D8wWEVCTOLF8NRvE0YoSDzd1sYLc IyHwl1Vi4tyNjBMYhWchuXsWkrtnIdmxgJF5FaNwbmJmjm5mnpGxXmJBQU6qXnJ+7iZGUGiv ZhLfwfj5teEhRgEORiUeXgMntigh1sSy4srcQ4zSHCxK4rx3tv6OFBJITyxJzU5NLUgtii8q zUktPsTIxMEp1cA4v+vNhgyHy7UzZcVOr7uue7xwvX9ssfzx3282fOUrfSSp9Ftc/oL9U5+8 dV8EL771mLds8aMUJe2LshIajxMYb4g7HOa8XSSp4BAgkn9aNX/Co4p74rK3qzYE1y6z+NRt urorkOt9XGJm8GrWgjnPojpd7m4Jfui26EClUDyrUvkhPk7tP0uVWIozEg21mIuKEwFGu9gb TgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUi2FAcoKsWzRZlcHq/oMWPsztZLe7EODB5 LFnyk8lj9eqHzAFMUVw2Kak5mWWpRfp2CVwZR7peMxb8ca94s3kBSwPjTssuRk4OCQETicPX lrN3MXJxCAkcZJRY9+4iE0iCV0BQ4sfkeywgNrOAlsT3R60sEEVfGCUWTO0F6uDgEBaQkNi8 JxGkRljAUeL8hymMIDabgIrE8W8bmEFsTgE7icbJ98FsFgFViT/v25ggZipLPJ7VCDVfW+LJ uwusEHttJDY1LwKrERKwlbh4dB+YLSKgJnFi+Wo2iKMVJR5u6mKdwCgwC8mps5CcOgvJ2AWM zKsYBYpScxIrLfQSCwpyUvWS83M3MYIDsTBtB2PTcqtDjAIcjEo8vAZObFFCrIllxZW5hxgl OJiVRHjZwoBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeTszGKKEBNITS1KzU1MLUotgskwcnFIN jPvePGL9svpE94GmF51bd3z8eGc/1+G3Z4SOvFt38XWU6517tU2aiWrTj73ds3m9wIbfQdPE hbd/WCf9p8jzlPv27uSisJS51/ZOPnfM9//NS4uOhk+0f3j2w9QvKW2BG8QLK/6/aUzfUnvF t/2XaWtVnNO1qvMOVTVWEQcmvilcJBbVunb99sW/lFiKMxINtZiLihMBZdVcE0ACAAA= Archived-At: Subject: Re: [Taps] Review of draft-trammell-taps-post-sockets-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 02:06:33 -0000 Hi Michael, Just a couple initial notes that may help: - The version diff you should look at is between -01 and -03. -02 is the = same as -03, but had a typo. - You've mentioned previously that you thought that Post requires both = peers to use that API. That is absolutely not the case in any way. = Having implemented Post myself, I am only communicating to "legacy" = servers that know nothing about Post. I think this fundamental = understanding needs to be cleared up before coming to any conclusions. = We can discuss during the WG. - The point of the API is to give the shape of the application = interaction, which is why you find it general. I believe that many of = the protocol-specific options like you mention (disabling Nagle, = retransmissions, etc) don't belong to this main abstract API draft, but = to a different document that goes into how to configure options that can = be used for setups like TCP/UDP. Again, in my implementation of Post, = all of these options exist as part of the Configuration object mentioned = in the draft. However, as I'll discuss in the WG, I believe that the = general shape of the API needs to be defined to be more-forward looking = than just what we've specified with the minset for TCP/UDP/SCTP. = Essentially, these become a set of Configuration options that can be = used, but as transport protocols continue to evolve (and when we need = more protocol-specific options), we need to be able to expand. Certain = aspects of the minset, like the connection state management, are of = course general and common enough to be part of the highest level of API = description. Thanks, Tommy > On Nov 11, 2017, at 9:43 AM, Michael Welzl wrote: >=20 > Dear all, >=20 > Because of the planned request for draft-trammell-taps-post-sockets-03 = to become a WG item, I gave the draft another close read and decided to = write a review based on this. I hope it's useful. >=20 > To me, post-sockets aims in the right direction - I like a number of = things about it: the introduction of higher-layer concepts such as the = carrier and association; I suspect that the long-term association = management could also be implemented one-sided, which is nice. I like = the idea of "forking" a carrier, which would clearly translate into = doing multi-streaming "under the hood" whenever that's possible (side = note: from the list on pages 7/8, it seems that *only* "Listener" can be = forked. Why not a Source? This seems odd to me). Finally, obviously I = also agree that being message-oriented is the right way to go. >=20 >=20 > On the negative side, I still see several problems here (actually = almost nothing has changed from --02 to -03), listed below: >=20 > The biggest problem I see is that this has very limited usage = scenarios, as it requires a post-socket system on both sides (there's = quite a bit of functionality in there that won't work otherwise - to = give an illustrative example: "When a Carrier is forked, its = corresponding Carrier at the remote endpoint receives a fork request, = .."). I find it particularly disappointing because, in my opinion, it = wouldn't take much to make this able to fall-back to TCP such that e.g. = a post-sockets client could talk to an existing TCP server. Anyway, what = IS this falling back to? If you add functionality both on the sender and = receiver side, you require a post-sockets system on both sides - and = then you could just as well consistently run over UDP or TCP or HTTP/2 = or whatever else you want, without any fall-backs (and as this develops = new transport functionality, we're then really moving away from the TAPS = charter). I think we must better understand what types of fall-backs are = envisioned here. >=20 > The document talks about "asynchronous reception", as if this was a = feature that would only be attainable with a novel approach, and/or a = message-based transport. I see having a callback-based API and a = socket-style API as largely orthogonal from the protocol below: one can = of course also write a callback-based API over TCP... the real problem = is to know after how much received data the receiving app should be = notified, by whatever means - that's just a general dilemma, and not a = new problem, as the PUSH bit in RFC 793 shows. Messages may seem to make = this easier, but then you have to start wondering how large can messages = be, how we should handle partial messages... e.g., you may need a signal = from the receiver-side TAPS system to the app to say "you have stored = half a message, but please throw this data block away now, you'll never = get the rest". You have some discussion of partial messages in this = draft, and we've been around that block with SCTP. IMO, the right = approach is to lea > ve all of that out: define a short max limit, and let an application = take care of splitting into smaller messages itself (since you have = message dependencies, why do you need to have large messages too, and = not just smaller sub-messages that all sequentially depend on another?). = This also makes prioritization more meaningful. >=20 > Generally, the draft just leaves many questions unanswered at this = stage, as it stays at a rather high level and lists most services just = as examples, saying that more could be possible. If it's that vague, how = should anybody implement such a system? Here's a list of transport = features (from minset) that we will lose if we don't offer them to an = application, and that I didn't see mentioned in post-sockets (sorry if I = missed some!). Some of them may seem a bit odd and unimportant, others = less so (this is from appendix A2, where "T" and "U" mean "can be = supported with a fall-back to TCP and UDP, respectively): >=20 > o T,U: Specify number of attempts and/or timeout for the first > establishment message > o T: Change timeout for aborting connection (using retransmit limit > or time value) > o T: Suggest timeout to the peer > o T,U: Disable Nagle algorithm > o T,U: Notification of Excessive Retransmissions (early warning > below abortion threshold) > o T,U: Specify DSCP field > o T,U: Notification of ICMP error message arrival > o T,U: Set Cookie life value > o T,U: Disable checksum when sending > o T,U: Disable checksum requirement when receiving > o T,U: Specify checksum coverage used by the sender > o T,U: Specify minimum checksum coverage required by receiver > o T,U: Specify DF field > o T,U: Get max. transport-message size that may be sent using a non- > fragmented IP packet from the configured interface > o T,U: Get max. transport-message size that may be received from the > configured interface > o T,U: Obtain ECN field > o T,U: Enable and configure a "Low Extra Delay Background Transfer" > o T,U: Request not to delay the acknowledgement (SACK) of a message > o T,U: Notification that the stack has no more user data to send >=20 >=20 > =46rom this list, a few functions that I would consider important are: >=20 > - DSCP, and enabling and configuring LEDBAT-like behavior: these two = could be lumped together in a higher-level request, but they're not just = a priority. Sure, your message "niceness" could be translated into a = DSCP choice, but I mean that an app may want to be able to control more = (e.g. do a general per-carrier configuration for low latency or LBE, for = example). Speaking of LEDBAT, post-sockets also doesn't say anything = about whether the transport is congestion controlled or not (which = translates into: does the app have to worry about it?). Another = congestion control thing: access to the ECN flag in case of UDP should = also be covered in some form. >=20 > - Notification that the stack has no more user data to send: this is = the TCP_NOWAIT_LOWAT function. Hmmm... wait! At first I thought the = binding to an .OnAcked() event handler can't be done with TCP, but if = the post-sockets layer would intelligently use TCP_NOWAIT_LOWAT, then = you could pull this off. >=20 > - Get max. transport-message size that may be sent using a = non-fragmented IP packet from the configured interface: this is useful = to avoid fragmentation overhead, and >=20 > - Specify DF field =3D> if we fall back to UDP, we need this in order = to do PMTUD. >=20 >=20 > ... and then there's also the need for early configuration of some = things to guide protocol choice, which I wrote as a decision tree in = draft-ietf-taps-minset-00. While I agree with your idea of specifying a = limited set of protocols to use - we do the same with policy in NEAT - = that can't be all: a TAPS system should probably prevent, e.g., first = picking UDP and then getting a request for reliability. That brings us = back to the question about what you're planning to fall back to, of = course. >=20 >=20 > I hope this was helpful, >=20 > cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Nov 10 18:37:02 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDDA124B0A for ; Fri, 10 Nov 2017 18:37:01 -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 zw06su9SKghs for ; Fri, 10 Nov 2017 18:36:56 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 298C41200C1 for ; Fri, 10 Nov 2017 18:36:56 -0800 (PST) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eDLfC-0000xj-I3; Sat, 11 Nov 2017 03:36:54 +0100 Received: from [66.96.215.225] (helo=[10.0.0.203]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eDLfB-000Fw9-L9; Sat, 11 Nov 2017 03:36:54 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: Date: Sat, 11 Nov 2017 10:36:48 +0800 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> References: To: Tommy Pauly X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 66.96.215.225 is neither permitted nor denied by domain of ifi.uio.no) client-ip=66.96.215.225; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.203]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A0674091AB7EC61986D7D40CFF519B82CB8D171F Archived-At: Subject: Re: [Taps] Review of draft-trammell-taps-post-sockets-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 02:37:01 -0000 > On Nov 11, 2017, at 10:06 AM, Tommy Pauly wrote: >=20 > Hi Michael, >=20 > Just a couple initial notes that may help: >=20 > - The version diff you should look at is between -01 and -03. -02 is = the same as -03, but had a typo. >=20 > - You've mentioned previously that you thought that Post requires both = peers to use that API. That is absolutely not the case in any way. = Having implemented Post myself, I am only communicating to "legacy" = servers that know nothing about Post. I think this fundamental = understanding needs to be cleared up before coming to any conclusions. = We can discuss during the WG. Oh?! That would be fantastic!! But I stumbled over a number of things = that require a system on the other side, or they just couldn=E2=80=99t = happen (like the =E2=80=9Ccarrier forking=E2=80=9D notification I quoted = below - but there were more). If you say you can talk to a =E2=80=9Clegacy= =E2=80=9D server that knows nothing about Post, WHAT does that server = speak? Legacy which protocol? Maybe it=E2=80=99s just a matter of me = thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me :) > - The point of the API is to give the shape of the application = interaction, which is why you find it general. I believe that many of = the protocol-specific options like you mention (disabling Nagle, = retransmissions, etc) don't belong to this main abstract API draft, but = to a different document that goes into how to configure options that can = be used for setups like TCP/UDP. Again, in my implementation of Post, = all of these options exist as part of the Configuration object mentioned = in the draft. However, as I'll discuss in the WG, I believe that the = general shape of the API needs to be defined to be more-forward looking = than just what we've specified with the minset for TCP/UDP/SCTP. = Essentially, these become a set of Configuration options that can be = used, but as transport protocols continue to evolve (and when we need = more protocol-specific options), we need to be able to expand. Certain = aspects of the minset, like the connection state management, are of = course general and common enough to be part of the highest level of API = description. It=E2=80=99s clear to me that we want a higher abstraction level than = what the list from minset has - e.g., rather than a DSCP value, it would = be better to specify general requirements (low latency or such) for a = carrier. Rather than saying =E2=80=9Cdisable Nagle=E2=80=9D, we could = also say =E2=80=9C low latency, even if it comes at the cost of some = overhead=E2=80=9D - we do such things in the NEAT API too. You=E2=80=99re = focused on the interaction with the application (e.g. callback-based = instead of traditional socket-style) - which is fine, but I think = doesn=E2=80=99t have much to do with the actual protocol choice. As for being more forward-looking, I wonder what the new transport = features are that we=E2=80=99re missing out on (things that apps really = see). I follow QUIC from a slightly too large distance (I simply run out = of cycles there :( ), but so far I=E2=80=99m not sure there=E2=80=99s = anything we=E2=80=99d be missing (but that=E2=80=99s maybe also because = I=E2=80=99m not an HTTP/2 expert either). Except security of course, but = there the argument is perhaps that it=E2=80=99s enough to consider = falling back to TLS? As for how you represent Nagle etc. in your code, that sounds good to = me, but I see an issue in that so much transport functionality is simply = not covered by the draft. E.g., the packet sizes / fragmentation thing = is important too =E2=80=A6 yes that=E2=80=99s lower level stuff, but = UDP-based applications will only get inefficient if they don=E2=80=99t = get this information exposed, which risks having app programmers move to = the old ways again IMO. So, the general design approach of post-sockets is IMO fine, but what = I=E2=80=99m missing is a long section with the nitty-gritty details on = how such a system would really be implemented (not the happy eyeballing = bit, this is fine to be elsewhere - but =E2=80=9Chow would this work = with current protocols=E2=80=9D). If I was to implement it from the = current draft, I=E2=80=99d have a ton of question marks - e.g. the draft = convinced me that there must be a system on both sides (this issue is = also not discussed in the draft). Cheers, Michael From nobody Fri Nov 10 19:58:17 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC03128D19 for ; Fri, 10 Nov 2017 19:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=apple.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 Dcu3m5loh74y for ; Fri, 10 Nov 2017 19:58:08 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 51983124D68 for ; Fri, 10 Nov 2017 19:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510372688; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IcW1AaVoCeXxIOpunQkBsxz8Q+IIbSyi9h0wpuEsDqo=; b=gkffx3BE1AzeTlovv5yHdA1uEnccesRh3hvOSirug70HCb3u1EZ7h1bmPZUSwJul op85YZRMfdDXUb7E5bj3ZzHiYNI2IHV99XNmlXNDNNx7WG6ezrWFv2Zo4YU2EW71 V7klr7/xlzc6ck3GSFJcw1b+sw+kTWLOSziLIvCaOk6XShEeB9/UlxTZ2s99W7T5 xjFDpLsTgyNc0e2OM9VyqYiHp6Mp4qkoEQYtjMNaAWLIxzmnuKa+vgwIpgHiLAG/ iAC4BBPVoCd+yX8t47+nTpVbLtSN1qH2lw/BveE6XNKlT5tZc7q5MbKSC8OwBg/k an1fcUuBHZxB6hgQZmuSQA==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id B7.4C.16042.055760A5; Fri, 10 Nov 2017 19:58:08 -0800 (PST) X-AuditID: 11973e12-801fd9c000003eaa-8f-5a06755089a6 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay3.apple.com (Apple SCV relay) with SMTP id C8.07.12852.F45760A5; Fri, 10 Nov 2017 19:58:07 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PLSWVqghKLmb5sBYL1ktbA)" Received: from [17.234.53.248] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZ800C0WJ0TPQ50@nwk-mmpp-sz12.apple.com>; Fri, 10 Nov 2017 19:58:07 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> Date: Sat, 11 Nov 2017 11:58:03 +0800 In-reply-to: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> Cc: "taps@ietf.org" To: Michael Welzl References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FAYrBtQyhZlMHMBi8WPsztZLe7EODB5 LFnyk8lj9eqHzAFMUVw2Kak5mWWpRfp2CVwZiy/dYix4WlHR0NnK2sD4PbmLkZNDQsBE4mT3 cfYuRi4OIYHVTBJXZ/WxwCQWd5+GShxilLi5bANYgldAUOLH5HtgNrNAmMSHc/Ohir4ySkxs ncPaxcjBISwgIbF5TyJIDZuAisTxbxuYIXptJDaffABmCws4Spz/MIURxGYRUJU4tWEFK4jN KWAn0bCxAWq+ssTjWY1gtoiAmsSJ5avZQGwhgSWMEuffBEMcqijxcFMXK8gNEgJT2CSOfzjM NoFRaBaSW2chuXUW0HnMAuoSU6bkQoS1JZ68u8AKYatJLPy9iAlZfAEj2ypGodzEzBzdzDwT vcSCgpxUveT83E2MoDiYbie0g/HUKqtDjAIcjEo8vAZObFFCrIllxZW5hxilOViUxHlTXzFE CQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCMq7kYvUMuWqvsX0jCiQcnY2N6PklW1NX/SZ3I fM5gxZJDz9lltMMUTN+4PVysqKh9sa3DJOhoV+PHJefENf+uOPxB2OzXtlnPPP/3+9+3/zQ1 5A3Ta8+ZGephvgbKn2ZGf9uU21jwJ94twLOKs2bD6ixv08eJhaIqSh5p8imr5A9MCeO/vkmJ pTgj0VCLuag4EQDXArjUZAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FB8Rte/lC3K4MU/G4sfZ3eyWtyJcWDy WLLkJ5PH6tUPmQOYorhsUlJzMstSi/TtErgyFl+6xVjwtKKiobOVtYHxe3IXIyeHhICJxOLu 0+xdjFwcQgKHGCVuLtvAApLgFRCU+DH5HpjNLBAm8eHcfKiir4wSE1vnsHYxcnAIC0hIbN6T CFLDJqAicfzbBmaIXhuJzScfgNnCAo4S5z9MYQSxWQRUJU5tWMEKYnMK2Ek0bGyAmq8s8XhW I5gtIqAmcWL5ajYQW0hgCaPE+TfBEIcqSjzc1MU6gZF/FpLzZiE5bxbQRcwC6hJTpuRChLUl nry7wAphq0ks/L2ICVl8ASPbKkaBotScxEpjvcSCgpxUveT83E2M4LAtDN7B+GeZ1SFGAQ5G JR5eAye2KCHWxLLiylxgGHEwK4nwsoUBhXhTEiurUovy44tKc1KLDzFKc7AoifN2ZDBECQmk J5akZqemFqQWwWSZODilGhiXbDt88e7z4IaW3lufbGZoKt9rNu89cbV8vS6vK+tiQab73EcF +DqjO4+0Z/PWFZg1JEf8KrvyPenZ5HMRSx/8n/aXvZGptGTSEtvtt2Y1uUYumbjune9NMRXH Rp4Q2duVqeKPu/bs/+V2Z8fEhSFeGYrra3/VLI4rEtvLNrHz6y4ZPclK1UAlluKMREMt5qLi RACmU4qvVwIAAA== Archived-At: Subject: Re: [Taps] Review of draft-trammell-taps-post-sockets-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 03:58:14 -0000 --Boundary_(ID_PLSWVqghKLmb5sBYL1ktbA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Nov 11, 2017, at 10:36 AM, Michael Welzl = wrote: >=20 >=20 >> On Nov 11, 2017, at 10:06 AM, Tommy Pauly wrote: >>=20 >> Hi Michael, >>=20 >> Just a couple initial notes that may help: >>=20 >> - The version diff you should look at is between -01 and -03. -02 is = the same as -03, but had a typo. >>=20 >> - You've mentioned previously that you thought that Post requires = both peers to use that API. That is absolutely not the case in any way. = Having implemented Post myself, I am only communicating to "legacy" = servers that know nothing about Post. I think this fundamental = understanding needs to be cleared up before coming to any conclusions. = We can discuss during the WG. >=20 > Oh?! That would be fantastic!! But I stumbled over a number of = things that require a system on the other side, or they just couldn=E2=80=99= t happen (like the =E2=80=9Ccarrier forking=E2=80=9D notification I = quoted below - but there were more). If you say you can talk to a = =E2=80=9Clegacy=E2=80=9D server that knows nothing about Post, WHAT does = that server speak? Legacy which protocol? Maybe it=E2=80=99s just a = matter of me thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me = :) So, since Post (and TAPS in general) isn't defining any new protocol = features, we need to of course be compatible with all existing = protocols. Certainly, some functionality is a bit degenerate in some = cases. Whatever the server speaks, the client needs to conform to. So, we use = our Post implementation for raw TCP, raw UDP, TLS over TCP, HTTP/2 = Streams over TLS over TCP, QUIC streams over UDP, etc. These are all = standard server configurations, but Post offers a client application a = single set of APIs to talk over any of these protocols. In the case of "Carrier Forking", that's essentially what you say to the = protocol stack when you want to open a new stream to the same place. So, = when I call "fork Carrier", it turns into: - For raw UDP/TCP or TLS (or anything that is mono-streamed), open a new = five-tuple to the same remote endpoint - For HTTP/2 and QUIC, open a new stream on the same connection >=20 >=20 >> - The point of the API is to give the shape of the application = interaction, which is why you find it general. I believe that many of = the protocol-specific options like you mention (disabling Nagle, = retransmissions, etc) don't belong to this main abstract API draft, but = to a different document that goes into how to configure options that can = be used for setups like TCP/UDP. Again, in my implementation of Post, = all of these options exist as part of the Configuration object mentioned = in the draft. However, as I'll discuss in the WG, I believe that the = general shape of the API needs to be defined to be more-forward looking = than just what we've specified with the minset for TCP/UDP/SCTP. = Essentially, these become a set of Configuration options that can be = used, but as transport protocols continue to evolve (and when we need = more protocol-specific options), we need to be able to expand. Certain = aspects of the minset, like the connection state management, are of = course general and common enough to be part of the highest level of API = description. >=20 > It=E2=80=99s clear to me that we want a higher abstraction level than = what the list from minset has - e.g., rather than a DSCP value, it would = be better to specify general requirements (low latency or such) for a = carrier. Rather than saying =E2=80=9Cdisable Nagle=E2=80=9D, we could = also say =E2=80=9C low latency, even if it comes at the cost of some = overhead=E2=80=9D - we do such things in the NEAT API too. You=E2=80=99re = focused on the interaction with the application (e.g. callback-based = instead of traditional socket-style) - which is fine, but I think = doesn=E2=80=99t have much to do with the actual protocol choice. >=20 > As for being more forward-looking, I wonder what the new transport = features are that we=E2=80=99re missing out on (things that apps really = see). I follow QUIC from a slightly too large distance (I simply run out = of cycles there :( ), but so far I=E2=80=99m not sure there=E2=80=99s = anything we=E2=80=99d be missing (but that=E2=80=99s maybe also because = I=E2=80=99m not an HTTP/2 expert either). Except security of course, but = there the argument is perhaps that it=E2=80=99s enough to consider = falling back to TLS? QUIC is using TLS 1.3, so it can give equivalent security properties to = HTTP/2. Doing fallback between these is definitely an important feature. = I think this flexibility is why the API needs to allow per-protocol = configs. >=20 > As for how you represent Nagle etc. in your code, that sounds good to = me, but I see an issue in that so much transport functionality is simply = not covered by the draft. E.g., the packet sizes / fragmentation thing = is important too =E2=80=A6 yes that=E2=80=99s lower level stuff, but = UDP-based applications will only get inefficient if they don=E2=80=99t = get this information exposed, which risks having app programmers move to = the old ways again IMO. A Post API definitely allows access to IP-packet level configuration and = metadata. However, you're right that the draft doesn't specify this in = detail now. I still think that may be a separate doc, but yeah. >=20 > So, the general design approach of post-sockets is IMO fine, but what = I=E2=80=99m missing is a long section with the nitty-gritty details on = how such a system would really be implemented (not the happy eyeballing = bit, this is fine to be elsewhere - but =E2=80=9Chow would this work = with current protocols=E2=80=9D). If I was to implement it from the = current draft, I=E2=80=99d have a ton of question marks - e.g. the draft = convinced me that there must be a system on both sides (this issue is = also not discussed in the draft). Getting feedback on how to clarify this for the implementer will be = really important, so thanks for this feedback! I'd also like to discuss = with the WG the scope of various documents that we want to produce. If = you have one document that does the abstract connection-management and = I/O API and all the protocol options and the racing/fallback strategy, = that would be a very long and complex doc. Best, Tommy >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_PLSWVqghKLmb5sBYL1ktbA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Nov 11, 2017, at 10:36 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:


On Nov = 11, 2017, at 10:06 AM, Tommy Pauly <tpauly@apple.com> wrote:

Hi Michael,

Just a couple = initial notes that may help:

- The version = diff you should look at is between -01 and -03. -02 is the same as -03, = but had a typo.

- You've mentioned = previously that you thought that Post requires both peers to use that = API. That is absolutely not the case in any way. Having implemented Post = myself, I am only communicating to "legacy" servers that know nothing = about Post. I think this fundamental understanding needs to be cleared = up before coming to any conclusions. We can discuss during the WG.

Oh?!  That would be = fantastic!!  But I stumbled over a number of things that require a = system on the other side, or they just couldn=E2=80=99t happen (like the = =E2=80=9Ccarrier forking=E2=80=9D notification I quoted below - but = there were more). If you say you can talk to a =E2=80=9Clegacy=E2=80=9D = server that knows nothing about Post, WHAT does that server speak? = Legacy which protocol?  Maybe it=E2=80=99s just a matter of me = thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me =   :)

So, since Post (and TAPS in general) isn't = defining any new protocol features, we need to of course be compatible = with all existing protocols. Certainly, some functionality is a bit = degenerate in some cases.

Whatever = the server speaks, the client needs to conform to. So, we use our Post = implementation for raw TCP, raw UDP, TLS over TCP, HTTP/2 Streams over = TLS over TCP, QUIC streams over UDP, etc. These are all standard server = configurations, but Post offers a client application a single set of = APIs to talk over any of these protocols.

In the case of "Carrier Forking", that's = essentially what you say to the protocol stack when you want to open a = new stream to the same place. So, when I call "fork Carrier", it turns = into:
- For raw UDP/TCP or TLS (or anything that is = mono-streamed), open a new five-tuple to the same remote = endpoint
- For HTTP/2 and QUIC, open a new stream on the same = connection



- The point of the API is to give the shape of = the application interaction, which is why you find it general. I believe = that many of the protocol-specific options like you mention (disabling = Nagle, retransmissions, etc) don't belong to this main abstract API = draft, but to a different document that goes into how to configure = options that can be used for setups like TCP/UDP. Again, in my = implementation of Post, all of these options exist as part of the = Configuration object mentioned in the draft. However, as I'll discuss in = the WG, I believe that the general shape of the API needs to be defined = to be more-forward looking than just what we've specified with the = minset for TCP/UDP/SCTP. Essentially, these become a set of = Configuration options that can be used, but as transport protocols = continue to evolve (and when we need more protocol-specific options), we = need to be able to expand. Certain aspects of the minset, like the = connection state management, are of course general and common enough to = be part of the highest level of API description.

It=E2=80=99s clear to me that we = want a higher abstraction level than what the list from minset has - = e.g., rather than a DSCP value, it would be better to specify general = requirements (low latency or such) for a carrier. Rather than saying = =E2=80=9Cdisable Nagle=E2=80=9D, we could also say =E2=80=9C low = latency, even if it comes at the cost of some overhead=E2=80=9D - we do = such things in the NEAT API too. You=E2=80=99re focused on the = interaction with the application (e.g. callback-based instead of = traditional socket-style) - which is fine, but I think doesn=E2=80=99t = have much to do with the actual protocol choice.

As for being more forward-looking, I wonder what the new = transport features are that we=E2=80=99re missing out on (things that = apps really see). I follow QUIC from a slightly too large distance (I = simply run out of cycles there :(  ), but so far I=E2=80=99m not = sure there=E2=80=99s anything we=E2=80=99d be missing  (but = that=E2=80=99s maybe also because I=E2=80=99m not an HTTP/2 expert = either). Except security of course, but there the argument is perhaps = that it=E2=80=99s enough to consider falling back to TLS?

QUIC is = using TLS 1.3, so it can give equivalent security properties to HTTP/2. = Doing fallback between these is definitely an important feature. I think = this flexibility is why the API needs to allow per-protocol = configs.


As for how you = represent Nagle etc. in your code, that sounds good to me, but I see an = issue in that so much transport functionality is simply not covered by = the draft. E.g., the packet sizes / fragmentation thing is important too = =E2=80=A6 yes that=E2=80=99s lower level stuff, but UDP-based = applications will only get inefficient if they don=E2=80=99t get this = information exposed, which risks having app programmers move to the old = ways again IMO.

A Post API definitely allows access to IP-packet = level configuration and metadata. However, you're right that the draft = doesn't specify this in detail now. I still think that may be a separate = doc, but yeah.


So, the = general design approach of post-sockets is IMO fine, but what I=E2=80=99m = missing is a long section with the nitty-gritty details on how such a = system would really be implemented (not the happy eyeballing bit, this = is fine to be elsewhere - but =E2=80=9Chow would this work with current = protocols=E2=80=9D). If I was to implement it from the current draft, = I=E2=80=99d have a ton of question marks - e.g. the draft convinced me = that there must be a system on both sides (this issue is also not = discussed in the draft).

Getting feedback on how to clarify this for the = implementer will be really important, so thanks for this feedback! I'd = also like to discuss with the WG the scope of various documents that we = want to produce. If you have one document that does the abstract = connection-management and I/O API and all the = protocol options and the racing/fallback = strategy, that would be a very long and complex doc.

Best,
Tommy


Cheers,
Michael

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_PLSWVqghKLmb5sBYL1ktbA)-- From nobody Fri Nov 10 22:09:32 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E096612943E for ; Fri, 10 Nov 2017 22:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 R5K9k1OBV4L5 for ; Fri, 10 Nov 2017 22:09:27 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 A2672129431 for ; Fri, 10 Nov 2017 22:09:26 -0800 (PST) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eDOyr-0000cg-0m; Sat, 11 Nov 2017 07:09:25 +0100 Received: from dhcp-9539.meeting.ietf.org ([31.133.149.57]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eDOyo-000BDN-Jq; Sat, 11 Nov 2017 07:09:24 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0D73195E-2ED9-423A-9758-AFFAF62145F7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 11 Nov 2017 14:09:18 +0800 In-Reply-To: <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> Cc: "taps@ietf.org" To: Tommy Pauly References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 31.133.149.57 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.149.57; envelope-from=michawe@ifi.uio.no; helo=dhcp-9539.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.050, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 19AEE2E191BE77123A0D29EEDB30354F1874BA90 Archived-At: Subject: Re: [Taps] Review of draft-trammell-taps-post-sockets-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 06:09:30 -0000 --Apple-Mail=_0D73195E-2ED9-423A-9758-AFFAF62145F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, In line: > On Nov 11, 2017, at 11:58 AM, Tommy Pauly wrote: >=20 >=20 >=20 >> On Nov 11, 2017, at 10:36 AM, Michael Welzl > wrote: >>=20 >>=20 >>> On Nov 11, 2017, at 10:06 AM, Tommy Pauly > wrote: >>>=20 >>> Hi Michael, >>>=20 >>> Just a couple initial notes that may help: >>>=20 >>> - The version diff you should look at is between -01 and -03. -02 is = the same as -03, but had a typo. >>>=20 >>> - You've mentioned previously that you thought that Post requires = both peers to use that API. That is absolutely not the case in any way. = Having implemented Post myself, I am only communicating to "legacy" = servers that know nothing about Post. I think this fundamental = understanding needs to be cleared up before coming to any conclusions. = We can discuss during the WG. >>=20 >> Oh?! That would be fantastic!! But I stumbled over a number of = things that require a system on the other side, or they just couldn=E2=80=99= t happen (like the =E2=80=9Ccarrier forking=E2=80=9D notification I = quoted below - but there were more). If you say you can talk to a = =E2=80=9Clegacy=E2=80=9D server that knows nothing about Post, WHAT does = that server speak? Legacy which protocol? Maybe it=E2=80=99s just a = matter of me thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me = :) >=20 > So, since Post (and TAPS in general) isn't defining any new protocol = features, we need to of course be compatible with all existing = protocols. Certainly, some functionality is a bit degenerate in some = cases. >=20 > Whatever the server speaks, the client needs to conform to. So, we use = our Post implementation for raw TCP, raw UDP, TLS over TCP, HTTP/2 = Streams over TLS over TCP, QUIC streams over UDP, etc. These are all = standard server configurations, but Post offers a client application a = single set of APIs to talk over any of these protocols. Oh, great! But then you can=E2=80=99t guarantee that a message arrives = as a message in case of raw TCP, or you assume application-level = framing. This is what I=E2=80=99ve been proposing, but the post-sockets = draft reads entirely different from that. > In the case of "Carrier Forking", that's essentially what you say to = the protocol stack when you want to open a new stream to the same place. = So, when I call "fork Carrier", it turns into: > - For raw UDP/TCP or TLS (or anything that is mono-streamed), open a = new five-tuple to the same remote endpoint > - For HTTP/2 and QUIC, open a new stream on the same connection Sure, that=E2=80=99s what I thought it would. Now, with SCTP, you = wouldn=E2=80=99t get a =E2=80=9Cfork request=E2=80=9D equivalent on the = other side: the client would just start using a new stream, and that=E2=80= =99s it. (=E2=80=9Crequest=E2=80=9D also indicates the possibility to = say no, which also doesn=E2=80=99t exist in SCTP AFAIK, at least not in = the API - this would be a =E2=80=9Cstream reset=E2=80=9D). Now, in = QUIC, I don=E2=80=99t know exactly how that is, but I would have thought = it=E2=80=99s the same - you just go ahead and use a new stream. No = =E2=80=9Cfork request=E2=80=9D on the other side - just a new stream (in = post, carrier) being used. >>> - The point of the API is to give the shape of the application = interaction, which is why you find it general. I believe that many of = the protocol-specific options like you mention (disabling Nagle, = retransmissions, etc) don't belong to this main abstract API draft, but = to a different document that goes into how to configure options that can = be used for setups like TCP/UDP. Again, in my implementation of Post, = all of these options exist as part of the Configuration object mentioned = in the draft. However, as I'll discuss in the WG, I believe that the = general shape of the API needs to be defined to be more-forward looking = than just what we've specified with the minset for TCP/UDP/SCTP. = Essentially, these become a set of Configuration options that can be = used, but as transport protocols continue to evolve (and when we need = more protocol-specific options), we need to be able to expand. Certain = aspects of the minset, like the connection state management, are of = course general and common enough to be part of the highest level of API = description. >>=20 >> It=E2=80=99s clear to me that we want a higher abstraction level than = what the list from minset has - e.g., rather than a DSCP value, it would = be better to specify general requirements (low latency or such) for a = carrier. Rather than saying =E2=80=9Cdisable Nagle=E2=80=9D, we could = also say =E2=80=9C low latency, even if it comes at the cost of some = overhead=E2=80=9D - we do such things in the NEAT API too. You=E2=80=99re = focused on the interaction with the application (e.g. callback-based = instead of traditional socket-style) - which is fine, but I think = doesn=E2=80=99t have much to do with the actual protocol choice. >>=20 >> As for being more forward-looking, I wonder what the new transport = features are that we=E2=80=99re missing out on (things that apps really = see). I follow QUIC from a slightly too large distance (I simply run out = of cycles there :( ), but so far I=E2=80=99m not sure there=E2=80=99s = anything we=E2=80=99d be missing (but that=E2=80=99s maybe also because = I=E2=80=99m not an HTTP/2 expert either). Except security of course, but = there the argument is perhaps that it=E2=80=99s enough to consider = falling back to TLS? >=20 > QUIC is using TLS 1.3, so it can give equivalent security properties = to HTTP/2. Doing fallback between these is definitely an important = feature. I think this flexibility is why the API needs to allow = per-protocol configs. Sure, but I think (and that was my point) this doesn=E2=80=99t change = anything about the stuff above (security is in your separate document) - = so what exactly are the =E2=80=9Cmore forward looking=E2=80=9D = requirements except for these security needs? >> As for how you represent Nagle etc. in your code, that sounds good to = me, but I see an issue in that so much transport functionality is simply = not covered by the draft. E.g., the packet sizes / fragmentation thing = is important too =E2=80=A6 yes that=E2=80=99s lower level stuff, but = UDP-based applications will only get inefficient if they don=E2=80=99t = get this information exposed, which risks having app programmers move to = the old ways again IMO. >=20 > A Post API definitely allows access to IP-packet level configuration = and metadata. However, you're right that the draft doesn't specify this = in detail now. I still think that may be a separate doc, but yeah. I wouldn=E2=80=99t mind that (though it=E2=80=99s not up to me to = decide), but =E2=80=94 >> So, the general design approach of post-sockets is IMO fine, but what = I=E2=80=99m missing is a long section with the nitty-gritty details on = how such a system would really be implemented (not the happy eyeballing = bit, this is fine to be elsewhere - but =E2=80=9Chow would this work = with current protocols=E2=80=9D). If I was to implement it from the = current draft, I=E2=80=99d have a ton of question marks - e.g. the draft = convinced me that there must be a system on both sides (this issue is = also not discussed in the draft). >=20 > Getting feedback on how to clarify this for the implementer will be = really important, so thanks for this feedback! I'd also like to discuss = with the WG the scope of various documents that we want to produce. If = you have one document that does the abstract connection-management and = I/O API and all the protocol options and the racing/fallback strategy, = that would be a very long and complex doc. Great - I=E2=80=99m happy that this is constructive! Regarding the = requests I=E2=80=99m making about post sockets, a reason I think more of = these implementation level considerations need to be in the draft is = that this gave me so many hiccups of the sort =E2=80=9Cbut then you need = it on both sides=E2=80=9D, =E2=80=9Cbut then you need to add a lot more = protocol functionality=E2=80=9D, =E2=80=9Cbut do you think you could do = that?=E2=80=9D =E2=80=A6 etc. I guess no matter if there are multiple docs or one, any document for = charter item 3 should leave its reader with the warm feeling of = understanding how this could be implemented. To figure out these details, I=E2=80=99d like to mention that the minset = is here to help :-) (that=E2=80=99s what it=E2=80=99s meant for). = Yes it=E2=80=99s too low-level to be a good API proposal in its own = right, but that=E2=80=99s also not the point - it tells you what can and = can=E2=80=99t be done. Every decision in it can be traced back to = specific reasoning based on the original RFCs; even if you end up = disagreeing with reasoning X about a mechanism Y from a RFC Z, at least = you know precisely what you=E2=80=99re doing in relation to the TCP, = MPTCP, SCTP, UDP, UDP-Lite and LEDBAT specs). Cheers, Michael --Apple-Mail=_0D73195E-2ED9-423A-9758-AFFAF62145F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

In = line:

On Nov 11, 2017, at 11:58 AM, Tommy Pauly = <tpauly@apple.com> wrote:



On Nov 11, 2017, at 10:36 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:


On Nov = 11, 2017, at 10:06 AM, Tommy Pauly <tpauly@apple.com> wrote:

Hi Michael,

Just a couple = initial notes that may help:

- The version = diff you should look at is between -01 and -03. -02 is the same as -03, = but had a typo.

- You've mentioned = previously that you thought that Post requires both peers to use that = API. That is absolutely not the case in any way. Having implemented Post = myself, I am only communicating to "legacy" servers that know nothing = about Post. I think this fundamental understanding needs to be cleared = up before coming to any conclusions. We can discuss during the WG.

Oh?!  That would be = fantastic!!  But I stumbled over a number of things that require a = system on the other side, or they just couldn=E2=80=99t happen (like the = =E2=80=9Ccarrier forking=E2=80=9D notification I quoted below - but = there were more). If you say you can talk to a =E2=80=9Clegacy=E2=80=9D = server that knows nothing about Post, WHAT does that server speak? = Legacy which protocol?  Maybe it=E2=80=99s just a matter of me = thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me =   :)

So, since Post (and TAPS in general) = isn't defining any new protocol features, we need to of course be = compatible with all existing protocols. Certainly, some functionality is = a bit degenerate in some cases.

Whatever the server speaks, the client = needs to conform to. So, we use our Post implementation for raw TCP, raw = UDP, TLS over TCP, HTTP/2 Streams over TLS over TCP, QUIC streams over = UDP, etc. These are all standard server configurations, but Post offers = a client application a single set of APIs to talk over any of these = protocols.

Oh, great!  But then you can=E2=80=99t guarantee = that a message arrives as a message in case of raw TCP, or you assume = application-level framing. This is what I=E2=80=99ve been proposing, but = the post-sockets draft reads entirely different from that.


In the case of "Carrier Forking", that's = essentially what you say to the protocol stack when you want to open a = new stream to the same place. So, when I call "fork Carrier", it turns = into:
- For raw UDP/TCP or TLS (or anything that is = mono-streamed), open a new five-tuple to the same remote = endpoint
- For HTTP/2 and QUIC, open a new stream = on the same connection

Sure, that=E2=80=99s what I thought it would. Now, = with SCTP, you wouldn=E2=80=99t get a =E2=80=9Cfork request=E2=80=9D = equivalent on the other side: the client would just start using a new = stream, and that=E2=80=99s it.  (=E2=80=9Crequest=E2=80=9D also = indicates the possibility to say no, which also doesn=E2=80=99t exist in = SCTP AFAIK, at least not in the API - this would be a =E2=80=9Cstream = reset=E2=80=9D).  Now, in QUIC, I don=E2=80=99t know exactly how = that is, but I would have thought it=E2=80=99s the same - you just go = ahead and use a new stream. No =E2=80=9Cfork request=E2=80=9D on the = other side - just a new stream (in post, carrier) being = used.


- The = point of the API is to give the shape of the application interaction, = which is why you find it general. I believe that many of the = protocol-specific options like you mention (disabling Nagle, = retransmissions, etc) don't belong to this main abstract API draft, but = to a different document that goes into how to configure options that can = be used for setups like TCP/UDP. Again, in my implementation of Post, = all of these options exist as part of the Configuration object mentioned = in the draft. However, as I'll discuss in the WG, I believe that the = general shape of the API needs to be defined to be more-forward looking = than just what we've specified with the minset for TCP/UDP/SCTP. = Essentially, these become a set of Configuration options that can be = used, but as transport protocols continue to evolve (and when we need = more protocol-specific options), we need to be able to expand. Certain = aspects of the minset, like the connection state management, are of = course general and common enough to be part of the highest level of API = description.

It=E2=80=99s = clear to me that we want a higher abstraction level than what the list = from minset has - e.g., rather than a DSCP value, it would be better to = specify general requirements (low latency or such) for a carrier. Rather = than saying =E2=80=9Cdisable Nagle=E2=80=9D, we could also say =E2=80=9C = low latency, even if it comes at the cost of some overhead=E2=80=9D - we = do such things in the NEAT API too. You=E2=80=99re focused on the = interaction with the application (e.g. callback-based instead of = traditional socket-style) - which is fine, but I think doesn=E2=80=99t = have much to do with the actual protocol choice.

As for being more forward-looking, I wonder what the new = transport features are that we=E2=80=99re missing out on (things that = apps really see). I follow QUIC from a slightly too large distance (I = simply run out of cycles there :(  ), but so far I=E2=80=99m not = sure there=E2=80=99s anything we=E2=80=99d be missing  (but = that=E2=80=99s maybe also because I=E2=80=99m not an HTTP/2 expert = either). Except security of course, but there the argument is perhaps = that it=E2=80=99s enough to consider falling back to TLS?

QUIC is using TLS 1.3, so it can give equivalent = security properties to HTTP/2. Doing fallback between these is = definitely an important feature. I think this flexibility is why the API = needs to allow per-protocol = configs.

Sure, = but I think (and that was my point) this doesn=E2=80=99t change anything = about the stuff above (security is in your separate document) - so what = exactly are the =E2=80=9Cmore forward looking=E2=80=9D requirements = except for these security needs?


As for how you represent = Nagle etc. in your code, that sounds good to me, but I see an issue in = that so much transport functionality is simply not covered by the draft. = E.g., the packet sizes / fragmentation thing is important too =E2=80=A6 = yes that=E2=80=99s lower level stuff, but UDP-based applications will = only get inefficient if they don=E2=80=99t get this information exposed, = which risks having app programmers move to the old ways again IMO.

A Post API definitely allows access to = IP-packet level configuration and metadata. However, you're right that = the draft doesn't specify this in detail now. I still think that may be = a separate doc, but yeah.

I wouldn=E2=80=99t mind that (though it=E2=80=99s not = up to me to decide), but =E2=80=94

So, the general design = approach of post-sockets is IMO fine, but what I=E2=80=99m missing is a = long section with the nitty-gritty details on how such a system would = really be implemented (not the happy eyeballing bit, this is fine to be = elsewhere - but =E2=80=9Chow would this work with current protocols=E2=80=9D= ). If I was to implement it from the current draft, I=E2=80=99d have a = ton of question marks - e.g. the draft convinced me that there must be a = system on both sides (this issue is also not discussed in the draft).

Getting feedback on how to clarify this = for the implementer will be really important, so thanks for this = feedback! I'd also like to discuss with the WG the scope of various = documents that we want to produce. If you have one document that does = the abstract connection-management and I/O API and all the protocol options and the racing/fallback strategy, that would be a = very long and complex doc.

Great - I=E2=80=99m happy that this is = constructive!  Regarding the requests I=E2=80=99m making about post = sockets, a reason I think more of these implementation level = considerations need to be in the draft is that this gave me so many = hiccups of the sort =E2=80=9Cbut then you need it on both sides=E2=80=9D, = =E2=80=9Cbut then you need to add a lot more protocol functionality=E2=80=9D= , =E2=80=9Cbut do you think you could do that?=E2=80=9D =E2=80=A6 = etc.
I guess no matter if there are multiple docs or one, any = document for charter item 3 should leave its reader with the warm = feeling of understanding how this could be implemented.

To figure out these details, I=E2=80=99d like to = mention that the minset is here to help  :-)    (that=E2=80= =99s what it=E2=80=99s meant for). Yes it=E2=80=99s too low-level to be = a good API proposal in its own right, but that=E2=80=99s also not the = point - it tells you what can and can=E2=80=99t be done. Every decision = in it can be traced back to specific reasoning based on the original = RFCs; even if you end up disagreeing with reasoning X about a mechanism = Y from a RFC Z, at least you know precisely what you=E2=80=99re doing in = relation to the TCP, MPTCP, SCTP, UDP, UDP-Lite and LEDBAT = specs).

Cheers,
Michael

= --Apple-Mail=_0D73195E-2ED9-423A-9758-AFFAF62145F7-- From nobody Sun Nov 12 08:31:11 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB961205D3 for ; Sun, 12 Nov 2017 08:31:09 -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 6vAawb0nu3xz for ; Sun, 12 Nov 2017 08:31:07 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 800E91200F3 for ; Sun, 12 Nov 2017 08:31:07 -0800 (PST) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eDvA1-0002w7-TB for taps@ietf.org; Sun, 12 Nov 2017 17:31:05 +0100 Received: from dhcp-9539.meeting.ietf.org ([31.133.149.57]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eDv9g-000DuG-CW for taps@ietf.org; Sun, 12 Nov 2017 17:31:05 +0100 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 00:30:40 +0800 References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> To: "taps@ietf.org" In-Reply-To: Message-Id: <4EF62BB5-7638-4C3D-98A6-F1F081ABF216@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 31.133.149.57 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.149.57; envelope-from=michawe@ifi.uio.no; helo=dhcp-9539.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.125, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2AFCD679A5144F796C895D2740E53DB335848B6F Archived-At: Subject: [Taps] API design: dependencies or buffer control? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 16:31:10 -0000 Hi, Another thought related to the post-sockets draft: Post-sockets lets an application programmer define dependencies. = That=E2=80=99s good, because dependencies exist, but it comes at the = cost of complexity. My gut feeling tells me: if you have dependencies to take care of, = it=E2=80=99s best to leave the data with the application and not hand it = over to the transport at all until the last minute. Controlling the buffer with something like TCP_NOTSENT_LOWAT would be a = way for an application to only give the most recent, relevant data to = the transport, and decide to throw away data on its own in case a = preceding message was thrown away (which it might learn from transport). I haven=E2=80=99t written code that uses TCP_NOTSENT_LOWAT myself, but I = would guess that the trade-off in using this is: if you set this value = low, you have more control over the buffer and can be more efficient in = your decisions, but the disadvantage is that the transport permanently = comes back to you and says =E2=80=9Cempty, empty, empty, =E2=80=A6.=E2=80=9D= - which may be inconvenient / inefficient for the programmer. If I=E2=80=99m right with all my musings here, then for an application = that has block dependencies, the design should depend on what is easier = to handle: defining priorities towards the transport layer on one side, = or dealing with the transport calling us quickly all the time because = its buffer is about to run empty, plus handling dependencies in the = application on the other. I don=E2=80=99t know - which one IS easier? I=E2=80=99d love to see this discussed a little, and I=E2=80=99d also = love to know if my interpretation of the trade-off in this email is even = correct. Cheers, Michael From nobody Sun Nov 12 15:54:10 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6756C1243F6 for ; Sun, 12 Nov 2017 15:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 t2zG5QeacqLV for ; Sun, 12 Nov 2017 15:54:07 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (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 374DC1205F0 for ; Sun, 12 Nov 2017 15:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510530845; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WVg1xZCvvJgZEYswmZQsmH66sQlIcjlUtkdeuo0XfbQ=; b=HIuiiod0P+vPdWXxgAz+3jsMg4kZW3SnWPlmoGNHCRREHc42veWSMXP3fFLK/w2D nZpoCO3OlOsRN90kIC3kuqOS72QId0phIvI227wzkLMY9sxJkDqZVqIpllRBkgZ2 eIpdQ2OhfeCnEZ/yklqAWLDM+Y5buoz6YR9Ce+VHKmIMazHnTINE9m/A3YCWZgQz 3P//JQWgJlSKKoyeoBMiy13uMvin4psLtdMJukap36SdVS0S+LUMddpBFveX+DyF tGyoWqOx2EUx0UW2xWRrQLSlLNWe/phIAA+f/FWMDyOVD8bbzPhmkiaHdDtXVYUA 94V7k4fq1kYknZHGqlp+/A==; Received: from relay2.asia.apple.com ( [17.82.200.16]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 2C.63.07591.D1FD80A5; Mon, 13 Nov 2017 07:54:05 +0800 (MYT) X-AuditID: 1152fe11-8b3ff70000001da7-98-5a08df1df998 Received: from echium.asia.apple.com ( [17.84.80.65]) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id 09.AC.31851.D1FD80A5; Mon, 13 Nov 2017 07:54:05 +0800 (MYT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.235.154.204] by echium.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZB005UQX24LE50@echium.asia.apple.com>; Mon, 13 Nov 2017 07:54:05 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <4EF62BB5-7638-4C3D-98A6-F1F081ABF216@ifi.uio.no> Date: Mon, 13 Nov 2017 07:54:04 +0800 Cc: "taps@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <98F9BFDF-0343-4846-A0F8-F3AF60168B5A@apple.com> References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> <4EF62BB5-7638-4C3D-98A6-F1F081ABF216@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUiGHRCQFf2PkeUwf9X0hY/zu5ktbgT48Dk sWTJTyaP1asfMgcwRXHZpKTmZJalFunbJXBlbOxLL3goXfHuzgLGBsYLYl2MnBwSAiYSry/9 ZQSxhQRWMkkc3J8DE9/d1AsV38goMWlxIojNKyAo8WPyPZYuRg4OZgF1iSlTcrsYuYBKPjFK tN4/yAYSFxaQkNi8B6xcWMBeYvOcJSwgNpuAisTxbxuYQUo4Bewkzr4Cm8IioCrRtz0UpIJZ QFni8axGFghbW+LJuwusEEttJL5/vsYOsWk/k0TflrfMIAkRATWJE8tXs0FcrCjxcFMXK0iR hEAHm8SavX/YJjAKz0Jy9SyEq2ch2bGAkXkVo3huYmaObmaeoV5icWaiXmJBQU6qXnJ+7iZG cFj/E9zBOHWh4SFGAQ5GJR5e4eMcUUKsiWXFlbmHGCU4mJVEeP2esUcJ8aYkVlalFuXHF5Xm pBYfYpTmYFES5+2L/BQpJJCeWJKanZpakFoEk2Xi4JRqYFwt6XJfslbt7hQRBRPJf9+Xfr1x xoX50/2q0ol7Z3UyquRv8Mtbf9OR6/RkGclZIkmzp578OenR3eD3LJ4cKoHpm1tnZUcWHDOY fv/QJcN10x5ZJk1Vem79RFKuyPVFdZ1i5otnbHtN3q/8sEN7X21bdF1Dy6a68Icn56xc8G/q ndsuzacPiN5QYinOSDTUYi4qTgQA5aNju2cCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUiGBLgqCt7nyPK4MZVYYsfZ3eyWtyJcWDy WLLkJ5PH6tUPmQOYorhsUlJzMstSi/TtErgyNvalFzyUrnh3ZwFjA+MFsS5GTg4JAROJ3U29 jCC2kMBGRolJixNBbF4BQYkfk++xdDFycDALqEtMmZLbxcgFVPKJUaL1/kE2kLiwgITE5j1g 5cIC9hKb5yxhAbHZBFQkjn/bwAxSwilgJ3H2FdgUFgFVib7toSAVzALKEo9nNbJA2NoST95d YIVYaiPx/fM1dohN+5kk+ra8ZQZJiAioSZxYvpoN4mJFiYebulgnMArMQnLoLIRDZyEZu4CR eRWjaFFqTmKlkV5icWaiXmJBQU6qXnJ+7iZGUCAGnRDYwTjrkMEhRgEORiUeXsbjHFFCrIll xZW5hxglOJiVRHj9nrFHCfGmJFZWpRblxxeV5qQWH2KU5mBREufVjPoUKSSQnliSmp2aWpBa BJNl4uCUamAUUklh9Pe7EFqjPuOqdmr5Ea81MlJ/IvMkTb/Kxje7ftnJLqTxTeFFMt8k5/2a E/1DFwVpfAoz6Pv1pa6J/UGFVn5E9s8qv+D9S1a5c9hONJoVckqWy//kssfbXfhWrDDz7mf9 wSex+o/1eZaVzwoct5/j3dcYkd0mzH5tn4P4/JvPDr+QDlRiKc5INNRiLipOBAB4lOLjQAIA AA== Archived-At: Subject: Re: [Taps] API design: dependencies or buffer control? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 23:54:09 -0000 The code I work with does TCP_NOTSENT_LOWAT by default, so we have a = fair amount of experience with it. If you're using sockets with = TCP_NOTSENT_LOWAT, and you're doing asynchronous non-blocking socket = operations, then you don't have the annoyance of getting these "empty" = callbacks you're referring to=E2=80=94it just changes how aggressively = the writable event fires, making it back off a bit. With a Post-like API, having something directly like TCP_NOTSENT_LOWAT = doesn't make much sense. Instead, the implementation may internally use = that, but the equivalent application feedback is the completion that is = returned based on the write messages. The timing of when the stack = indicates when something has been written allows the application to = understand the back-pressure properties of the transport, and if it able = to generate or fetch data more slowly to match the back-pressure, it = can. Otherwise, it can simply keep writing and the data will get = enqueued within the library. Dependencies between the messages that are being written, then, doesn't = actually come into play much here. Dependencies are hints to the = implementation and protocol stack of how to order work when scheduling = to send (PRE-WRITE). TCP_NOTSENT_LOWAT or the completions to indicate = that writes have completed are all about signaling back to the = application to provide back-pressure (POST-WRITE). Does that help clarify things? Thanks, Tommy > On Nov 13, 2017, at 12:30 AM, Michael Welzl = wrote: >=20 > Hi, >=20 > Another thought related to the post-sockets draft: >=20 > Post-sockets lets an application programmer define dependencies. = That=E2=80=99s good, because dependencies exist, but it comes at the = cost of complexity. > My gut feeling tells me: if you have dependencies to take care of, = it=E2=80=99s best to leave the data with the application and not hand it = over to the transport at all until the last minute. >=20 > Controlling the buffer with something like TCP_NOTSENT_LOWAT would be = a way for an application to only give the most recent, relevant data to = the transport, and decide to throw away data on its own in case a = preceding message was thrown away (which it might learn from transport). >=20 > I haven=E2=80=99t written code that uses TCP_NOTSENT_LOWAT myself, but = I would guess that the trade-off in using this is: if you set this value = low, you have more control over the buffer and can be more efficient in = your decisions, but the disadvantage is that the transport permanently = comes back to you and says =E2=80=9Cempty, empty, empty, =E2=80=A6.=E2=80=9D= - which may be inconvenient / inefficient for the programmer. >=20 > If I=E2=80=99m right with all my musings here, then for an application = that has block dependencies, the design should depend on what is easier = to handle: defining priorities towards the transport layer on one side, = or dealing with the transport calling us quickly all the time because = its buffer is about to run empty, plus handling dependencies in the = application on the other. >=20 > I don=E2=80=99t know - which one IS easier? >=20 > I=E2=80=99d love to see this discussed a little, and I=E2=80=99d also = love to know if my interpretation of the trade-off in this email is even = correct. >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Sun Nov 12 16:07:31 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBA4126C25 for ; Sun, 12 Nov 2017 16:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 rv1kgp7GdcSb for ; Sun, 12 Nov 2017 16:07:28 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (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 6A5341200C5 for ; Sun, 12 Nov 2017 16:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510531645; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aVegTsdvXB8yKJ2j8YXj9bwYdLOEVvsMIWH5ZPBZMr8=; b=oeEj8EWhHRSe/Lb91cRT/6jrGS3dQ5N+dcoJCICJhQBgUClxTSw1ZPuBQDHQCRF7 pZTF7fGOJaimTkR6hZCKN8O3lZXTPxUzB6NN8hZVjwlkPYaje7Z2BJG+ZpJOdIi7 cPw2KJOdykqSWbuCDlGszspvUauGXnriwJtSpTobsz8ZWqHpBhuZeQQFrRPiGaQZ gqilaPCe9/x/2KBKvnXQoGHywUoNWrmfH+zlvTm7mjxbkxXpkbszB2mFRlnW3Cfo hIfIPGY8gUCrLha3o4MwDVBdmo/XkqdC1SVWQG/rHUFa5dQ7qOPUQIoiHIfbKppe IHzPne3gIaE1H3j3q5BpQw==; Received: from relay2.asia.apple.com ( [17.82.200.16]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 21.93.07591.D32E80A5; Mon, 13 Nov 2017 08:07:25 +0800 (MYT) X-AuditID: 1152fe11-8b3ff70000001da7-b2-5a08e23da9b4 Received: from echium.asia.apple.com ( [17.84.80.65]) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id E5.FC.31851.D32E80A5; Mon, 13 Nov 2017 08:07:25 +0800 (MYT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MhHKMV8zJ59LeOanbVQlPA)" Received: from [17.235.154.204] by echium.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZB0053TXOCLE60@echium.asia.apple.com>; Mon, 13 Nov 2017 08:07:25 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <9E765BA0-5A2A-47CD-A13F-1ED379F235EB@apple.com> Date: Mon, 13 Nov 2017 08:07:24 +0800 In-reply-to: Cc: "taps@ietf.org" To: Michael Welzl References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUiGHRCQNf2EUeUwc/lqhY/zu5ktbgT48Dk sWTJTyaP1asfMgcwRXHZpKTmZJalFunbJXBlPJv8m61g2gfGiokXetgaGC+eYOxi5OSQEDCR eHrgLXMXIxeHkMBKJokJa9awwiT6prcwQiQ2MkrMP/qVBSTBKyAo8WPyPTCbWSBM4uH0uVBF nxglvm2aCdTNwSEsICGxeU8iSA2bgIrE8W8bmCF6bSQ6Lx9kB7GFBRwlzn+YwghSziKgKtE+ gwMkzClgJ3F11TxWiPHKEo9nNYKtEhFQkzixfDUbxKpuJolfO3eyQxyqKPFwUxcrSEJCYAGb xKUP0xgnMArNQnLrLCS3zgLaxyygLjFlSi5EWFviybsLrBC2msTC34uYkMUXMLKtYhTPTczM 0c3MM9RLLM5M1EssKMhJ1UvOz93ECI6Kf4I7GKcuNDzEKMDBqMTDK3ycI0qINbGsuDL3EKME B7OSCO+R+0Ah3pTEyqrUovz4otKc1OJDjNIcLErivH2RnyKFBNITS1KzU1MLUotgskwcnFIN jAHXFyRH2E+0XrEo4umP7ffrV2i/aM5rM2a+YRIz2aKwbFZgwa6G7Q0FHAb7z/sdrra0ibkR fDBPNVA6UO27ofVWvkY55sN7Tlddt9MKSzmrUbi0f+7Txxkukg1tPtzftil/Xii55ffGt/+W VPhvnMK06FXm9YAb3q4GXyalfvypqlmydlbzDyWW4oxEQy3mouJEAF45uL2GAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUiGBLgqGv7iCPK4P19KYsfZ3eyWtyJcWDy WLLkJ5PH6tUPmQOYorhsUlJzMstSi/TtErgynk3+zVYw7QNjxcQLPWwNjBdPMHYxcnJICJhI 9E1vAbK5OIQENjJKzD/6lQUkwSsgKPFj8j0wm1kgTOLh9LlQRZ8YJb5tmsnaxcjBISwgIbF5 TyJIDZuAisTxbxuYIXptJDovH2QHsYUFHCXOf5jCCFLOIqAq0T6DAyTMKWAncXXVPFaI8coS j2c1gq0SEVCTOLF8NRvEqm4miV87d7JDHKoo8XBTF+sERv5ZSM6bheS8WUArmAXUJaZMyYUI a0s8eXeBFcJWk1j4exETsvgCRrZVjKJFqTmJlUZ6icWZiXqJBQU5qXrJ+bmbGEFBHHRCYAfj rEMGhxgFOBiVeHgZj3NECbEmlhVX5h5ilOBgVhLhPXIfKMSbklhZlVqUH19UmpNafIhRmoNF SZxXM+pTpJBAemJJanZqakFqEUyWiYNTqoHRruzQn3PSTtmW4T/qpvRfnuWrNH1R6C/PZe9j l+lrPXzRHLbGkL+56O/t5qW7AtS7/5hbNyw99WAS70UXrtUZuU1mvP8q1s9sTzx4Q+aZVJXq y2pm7pdHnm2SSfH2Elo24Vpbn+0/3p6j85ecEn0ackSolT8x6oH+iQsHJucLX5niuymjzfK9 EktxRqKhFnNRcSIAsmu7fV4CAAA= Archived-At: Subject: Re: [Taps] Review of draft-trammell-taps-post-sockets-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 00:07:29 -0000 --Boundary_(ID_MhHKMV8zJ59LeOanbVQlPA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Nov 11, 2017, at 2:09 PM, Michael Welzl wrote: >=20 > Hi, >=20 > In line: >=20 >> On Nov 11, 2017, at 11:58 AM, Tommy Pauly > wrote: >>=20 >>=20 >>=20 >>> On Nov 11, 2017, at 10:36 AM, Michael Welzl > wrote: >>>=20 >>>=20 >>>> On Nov 11, 2017, at 10:06 AM, Tommy Pauly > wrote: >>>>=20 >>>> Hi Michael, >>>>=20 >>>> Just a couple initial notes that may help: >>>>=20 >>>> - The version diff you should look at is between -01 and -03. -02 = is the same as -03, but had a typo. >>>>=20 >>>> - You've mentioned previously that you thought that Post requires = both peers to use that API. That is absolutely not the case in any way. = Having implemented Post myself, I am only communicating to "legacy" = servers that know nothing about Post. I think this fundamental = understanding needs to be cleared up before coming to any conclusions. = We can discuss during the WG. >>>=20 >>> Oh?! That would be fantastic!! But I stumbled over a number of = things that require a system on the other side, or they just couldn=E2=80=99= t happen (like the =E2=80=9Ccarrier forking=E2=80=9D notification I = quoted below - but there were more). If you say you can talk to a = =E2=80=9Clegacy=E2=80=9D server that knows nothing about Post, WHAT does = that server speak? Legacy which protocol? Maybe it=E2=80=99s just a = matter of me thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me = :) >>=20 >> So, since Post (and TAPS in general) isn't defining any new protocol = features, we need to of course be compatible with all existing = protocols. Certainly, some functionality is a bit degenerate in some = cases. >>=20 >> Whatever the server speaks, the client needs to conform to. So, we = use our Post implementation for raw TCP, raw UDP, TLS over TCP, HTTP/2 = Streams over TLS over TCP, QUIC streams over UDP, etc. These are all = standard server configurations, but Post offers a client application a = single set of APIs to talk over any of these protocols. >=20 > Oh, great! But then you can=E2=80=99t guarantee that a message = arrives as a message in case of raw TCP, or you assume application-level = framing. This is what I=E2=80=99ve been proposing, but the post-sockets = draft reads entirely different from that. Messages do indeed "always work", but they may be degenerate. There's no = new protocols here, just ways of looking at them: - UDP: One message per datagram - TCP: Entire stream is one big message that only ever ends when that = half of the stream closes - TLS: Generally viewed like TLS, but can view one record as one message=20= - HTTP/QUIC: One message per request/response (so, framing) - Length-value framing on streams, as used by some protocols (like IKEv2 = over TCP): one message per L-V frame Etc, etc. That is what the draft does say in Section 2.2. Note how a TCP stream is = the message in some cases. A Message is the unit of communication between applications. Messages can represent relatively small structures, such as requests in a request/response protocol such as HTTP; relatively large structures, such as files of arbitrary size in a filesystem; and structures of indeterminate length, such as a stream of bytes in a protocol like TCP. >=20 >=20 >> In the case of "Carrier Forking", that's essentially what you say to = the protocol stack when you want to open a new stream to the same place. = So, when I call "fork Carrier", it turns into: >> - For raw UDP/TCP or TLS (or anything that is mono-streamed), open a = new five-tuple to the same remote endpoint >> - For HTTP/2 and QUIC, open a new stream on the same connection >=20 > Sure, that=E2=80=99s what I thought it would. Now, with SCTP, you = wouldn=E2=80=99t get a =E2=80=9Cfork request=E2=80=9D equivalent on the = other side: the client would just start using a new stream, and that=E2=80= =99s it. (=E2=80=9Crequest=E2=80=9D also indicates the possibility to = say no, which also doesn=E2=80=99t exist in SCTP AFAIK, at least not in = the API - this would be a =E2=80=9Cstream reset=E2=80=9D). Now, in = QUIC, I don=E2=80=99t know exactly how that is, but I would have thought = it=E2=80=99s the same - you just go ahead and use a new stream. No = =E2=80=9Cfork request=E2=80=9D on the other side - just a new stream (in = post, carrier) being used. The term "fork-request" is misleading, yes. It really should just say: = "forking a carrier creates a new flow to the same Remote, which may be a = new stream on a multiplexing protocol. The protocol will handle any = required signaling to the remote to open a new stream, based on the = protocol". >=20 >=20 >>>> - The point of the API is to give the shape of the application = interaction, which is why you find it general. I believe that many of = the protocol-specific options like you mention (disabling Nagle, = retransmissions, etc) don't belong to this main abstract API draft, but = to a different document that goes into how to configure options that can = be used for setups like TCP/UDP. Again, in my implementation of Post, = all of these options exist as part of the Configuration object mentioned = in the draft. However, as I'll discuss in the WG, I believe that the = general shape of the API needs to be defined to be more-forward looking = than just what we've specified with the minset for TCP/UDP/SCTP. = Essentially, these become a set of Configuration options that can be = used, but as transport protocols continue to evolve (and when we need = more protocol-specific options), we need to be able to expand. Certain = aspects of the minset, like the connection state management, are of = course general and common enough to be part of the highest level of API = description. >>>=20 >>> It=E2=80=99s clear to me that we want a higher abstraction level = than what the list from minset has - e.g., rather than a DSCP value, it = would be better to specify general requirements (low latency or such) = for a carrier. Rather than saying =E2=80=9Cdisable Nagle=E2=80=9D, we = could also say =E2=80=9C low latency, even if it comes at the cost of = some overhead=E2=80=9D - we do such things in the NEAT API too. You=E2=80=99= re focused on the interaction with the application (e.g. callback-based = instead of traditional socket-style) - which is fine, but I think = doesn=E2=80=99t have much to do with the actual protocol choice. >>>=20 >>> As for being more forward-looking, I wonder what the new transport = features are that we=E2=80=99re missing out on (things that apps really = see). I follow QUIC from a slightly too large distance (I simply run out = of cycles there :( ), but so far I=E2=80=99m not sure there=E2=80=99s = anything we=E2=80=99d be missing (but that=E2=80=99s maybe also because = I=E2=80=99m not an HTTP/2 expert either). Except security of course, but = there the argument is perhaps that it=E2=80=99s enough to consider = falling back to TLS? >>=20 >> QUIC is using TLS 1.3, so it can give equivalent security properties = to HTTP/2. Doing fallback between these is definitely an important = feature. I think this flexibility is why the API needs to allow = per-protocol configs. >=20 > Sure, but I think (and that was my point) this doesn=E2=80=99t change = anything about the stuff above (security is in your separate document) - = so what exactly are the =E2=80=9Cmore forward looking=E2=80=9D = requirements except for these security needs? I'm trying to distinguish certain aspects of the minset that are: a) fundamental to all transports, that we have reason to believe will be = the case for all future transports in some fashion CONNECT, SEND, RECEIVE, CLOSE, etc b) derived from the protocols we happened to survey or based on current = semantics (sockets), based on what exists Things I see in the NEAT draft like SET_MIN_CHECKSUM_COVERAGE, = SET_TTL, SET_LOW_WATERMARK. Important to have, but often the values the = application needs to set relate to which protocol might be used, and may = have different requirements for future protocols. So, there's a set of things in category (a) that should be stable as the = main API go forward for quite a while, while things in category (b) may = belong as configuration properties, in a list that may shrink or expand = over time as new developments are made. >=20 >=20 >>> As for how you represent Nagle etc. in your code, that sounds good = to me, but I see an issue in that so much transport functionality is = simply not covered by the draft. E.g., the packet sizes / fragmentation = thing is important too =E2=80=A6 yes that=E2=80=99s lower level stuff, = but UDP-based applications will only get inefficient if they don=E2=80=99t= get this information exposed, which risks having app programmers move = to the old ways again IMO. >>=20 >> A Post API definitely allows access to IP-packet level configuration = and metadata. However, you're right that the draft doesn't specify this = in detail now. I still think that may be a separate doc, but yeah. >=20 > I wouldn=E2=80=99t mind that (though it=E2=80=99s not up to me to = decide), but =E2=80=94 >=20 >=20 >>> So, the general design approach of post-sockets is IMO fine, but = what I=E2=80=99m missing is a long section with the nitty-gritty details = on how such a system would really be implemented (not the happy = eyeballing bit, this is fine to be elsewhere - but =E2=80=9Chow would = this work with current protocols=E2=80=9D). If I was to implement it = from the current draft, I=E2=80=99d have a ton of question marks - e.g. = the draft convinced me that there must be a system on both sides (this = issue is also not discussed in the draft). >>=20 >> Getting feedback on how to clarify this for the implementer will be = really important, so thanks for this feedback! I'd also like to discuss = with the WG the scope of various documents that we want to produce. If = you have one document that does the abstract connection-management and = I/O API and all the protocol options and the racing/fallback strategy, = that would be a very long and complex doc. >=20 > Great - I=E2=80=99m happy that this is constructive! Regarding the = requests I=E2=80=99m making about post sockets, a reason I think more of = these implementation level considerations need to be in the draft is = that this gave me so many hiccups of the sort =E2=80=9Cbut then you need = it on both sides=E2=80=9D, =E2=80=9Cbut then you need to add a lot more = protocol functionality=E2=80=9D, =E2=80=9Cbut do you think you could do = that?=E2=80=9D =E2=80=A6 etc. > I guess no matter if there are multiple docs or one, any document for = charter item 3 should leave its reader with the warm feeling of = understanding how this could be implemented. >=20 > To figure out these details, I=E2=80=99d like to mention that the = minset is here to help :-) (that=E2=80=99s what it=E2=80=99s meant = for). Yes it=E2=80=99s too low-level to be a good API proposal in its = own right, but that=E2=80=99s also not the point - it tells you what can = and can=E2=80=99t be done. Every decision in it can be traced back to = specific reasoning based on the original RFCs; even if you end up = disagreeing with reasoning X about a mechanism Y from a RFC Z, at least = you know precisely what you=E2=80=99re doing in relation to the TCP, = MPTCP, SCTP, UDP, UDP-Lite and LEDBAT specs). >=20 > Cheers, > Michael --Boundary_(ID_MhHKMV8zJ59LeOanbVQlPA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Nov 11, 2017, at 2:09 PM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

In = line:

On Nov 11, 2017, at 11:58 AM, Tommy Pauly <tpauly@apple.com> = wrote:



On Nov = 11, 2017, at 10:36 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:


On Nov = 11, 2017, at 10:06 AM, Tommy Pauly <tpauly@apple.com> wrote:

Hi Michael,

Just a couple = initial notes that may help:

- The version = diff you should look at is between -01 and -03. -02 is the same as -03, = but had a typo.

- You've mentioned = previously that you thought that Post requires both peers to use that = API. That is absolutely not the case in any way. Having implemented Post = myself, I am only communicating to "legacy" servers that know nothing = about Post. I think this fundamental understanding needs to be cleared = up before coming to any conclusions. We can discuss during the WG.

Oh?!  That would be = fantastic!!  But I stumbled over a number of things that require a = system on the other side, or they just couldn=E2=80=99t happen (like the = =E2=80=9Ccarrier forking=E2=80=9D notification I quoted below - but = there were more). If you say you can talk to a =E2=80=9Clegacy=E2=80=9D = server that knows nothing about Post, WHAT does that server speak? = Legacy which protocol?  Maybe it=E2=80=99s just a matter of me = thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me =   :)

So, since Post (and TAPS in general) = isn't defining any new protocol features, we need to of course be = compatible with all existing protocols. Certainly, some functionality is = a bit degenerate in some cases.

Whatever the server speaks, the client = needs to conform to. So, we use our Post implementation for raw TCP, raw = UDP, TLS over TCP, HTTP/2 Streams over TLS over TCP, QUIC streams over = UDP, etc. These are all standard server configurations, but Post offers = a client application a single set of APIs to talk over any of these = protocols.

Oh, great!  But then you can=E2=80=99t guarantee = that a message arrives as a message in case of raw TCP, or you assume = application-level framing. This is what I=E2=80=99ve been proposing, but = the post-sockets draft reads entirely different from = that.

Messages do indeed "always work", but they may be = degenerate. There's no new protocols here, just ways of looking at = them:

- UDP: One message per = datagram
- TCP: Entire stream is one big message that only = ever ends when that half of the stream closes
- TLS: Generally = viewed like TLS, but can view one record as one = message 
- HTTP/QUIC: One message per request/response = (so, framing)
- Length-value framing on streams, as used by = some protocols (like IKEv2 over TCP): one message per L-V = frame
Etc, etc.

That is = what the draft does say in Section 2.2. Note how a TCP stream is the = message in some cases.

A Message is the unit of =
communication between applications.
   Messages can represent relatively small structures, such as requests
   in a request/response protocol such as HTTP; relatively large
   structures, such as files of arbitrary size in a filesystem; and
   structures of indeterminate length, such as a stream of bytes in a
   protocol like TCP.




In the case of = "Carrier Forking", that's essentially what you say to the protocol stack = when you want to open a new stream to the same place. So, when I call = "fork Carrier", it turns into:
- For raw UDP/TCP or = TLS (or anything that is mono-streamed), open a new five-tuple to the = same remote endpoint
- For HTTP/2 and QUIC, open a = new stream on the same = connection

Sure, that=E2=80=99s what I thought it = would. Now, with SCTP, you wouldn=E2=80=99t get a =E2=80=9Cfork = request=E2=80=9D equivalent on the other side: the client would just = start using a new stream, and that=E2=80=99s it.  (=E2=80=9Crequest=E2= =80=9D also indicates the possibility to say no, which also doesn=E2=80=99= t exist in SCTP AFAIK, at least not in the API - this would be a = =E2=80=9Cstream reset=E2=80=9D).  Now, in QUIC, I don=E2=80=99t = know exactly how that is, but I would have thought it=E2=80=99s the same = - you just go ahead and use a new stream. No =E2=80=9Cfork request=E2=80=9D= on the other side - just a new stream (in post, carrier) being = used.

The term "fork-request" is misleading, yes. It = really should just say: "forking a carrier creates a new flow to the = same Remote, which may be a new stream on a multiplexing protocol. The = protocol will handle any required signaling to the remote to open a new = stream, based on the protocol".



- The point of the API = is to give the shape of the application interaction, which is why you = find it general. I believe that many of the protocol-specific options = like you mention (disabling Nagle, retransmissions, etc) don't belong to = this main abstract API draft, but to a different document that goes into = how to configure options that can be used for setups like TCP/UDP. = Again, in my implementation of Post, all of these options exist as part = of the Configuration object mentioned in the draft. However, as I'll = discuss in the WG, I believe that the general shape of the API needs to = be defined to be more-forward looking than just what we've specified = with the minset for TCP/UDP/SCTP. Essentially, these become a set of = Configuration options that can be used, but as transport protocols = continue to evolve (and when we need more protocol-specific options), we = need to be able to expand. Certain aspects of the minset, like the = connection state management, are of course general and common enough to = be part of the highest level of API description.

It=E2=80=99s clear to me that we = want a higher abstraction level than what the list from minset has - = e.g., rather than a DSCP value, it would be better to specify general = requirements (low latency or such) for a carrier. Rather than saying = =E2=80=9Cdisable Nagle=E2=80=9D, we could also say =E2=80=9C low = latency, even if it comes at the cost of some overhead=E2=80=9D - we do = such things in the NEAT API too. You=E2=80=99re focused on the = interaction with the application (e.g. callback-based instead of = traditional socket-style) - which is fine, but I think doesn=E2=80=99t = have much to do with the actual protocol choice.

As for being more forward-looking, I wonder what the new = transport features are that we=E2=80=99re missing out on (things that = apps really see). I follow QUIC from a slightly too large distance (I = simply run out of cycles there :(  ), but so far I=E2=80=99m not = sure there=E2=80=99s anything we=E2=80=99d be missing  (but = that=E2=80=99s maybe also because I=E2=80=99m not an HTTP/2 expert = either). Except security of course, but there the argument is perhaps = that it=E2=80=99s enough to consider falling back to TLS?

QUIC is using TLS 1.3, so it can give equivalent = security properties to HTTP/2. Doing fallback between these is = definitely an important feature. I think this flexibility is why the API = needs to allow per-protocol configs.

Sure, but I think (and that was my = point) this doesn=E2=80=99t change anything about the stuff above = (security is in your separate document) - so what exactly are the = =E2=80=9Cmore forward looking=E2=80=9D requirements except for these = security needs?

I'm trying to distinguish certain aspects of the = minset that are:
a) fundamental to all transports, that we = have reason to believe will be the case for all future transports in = some fashion
CONNECT, SEND, RECEIVE, CLOSE, = etc
b) derived from the protocols we happened to survey or = based on current semantics (sockets), based on what = exists
= Things I see in the NEAT draft = like SET_MIN_CHECKSUM_COVERAGE, SET_TTL, SET_LOW_WATERMARK.= Important to have, but often the values the application needs to set = relate to which protocol might be used, and may have different = requirements for future protocols.

So,= there's a set of things in category (a) that should be stable as the = main API go forward for quite a while, while things in category (b) may = belong as configuration properties, in a list that may shrink or expand = over time as new developments are made.



As for how you represent = Nagle etc. in your code, that sounds good to me, but I see an issue in = that so much transport functionality is simply not covered by the draft. = E.g., the packet sizes / fragmentation thing is important too =E2=80=A6 = yes that=E2=80=99s lower level stuff, but UDP-based applications will = only get inefficient if they don=E2=80=99t get this information exposed, = which risks having app programmers move to the old ways again IMO.

A Post API definitely allows access to = IP-packet level configuration and metadata. However, you're right that = the draft doesn't specify this in detail now. I still think that may be = a separate doc, but yeah.

I wouldn=E2=80=99t mind that (though = it=E2=80=99s not up to me to decide), but =E2=80=94


So, the general design = approach of post-sockets is IMO fine, but what I=E2=80=99m missing is a = long section with the nitty-gritty details on how such a system would = really be implemented (not the happy eyeballing bit, this is fine to be = elsewhere - but =E2=80=9Chow would this work with current protocols=E2=80=9D= ). If I was to implement it from the current draft, I=E2=80=99d have a = ton of question marks - e.g. the draft convinced me that there must be a = system on both sides (this issue is also not discussed in the draft).

Getting feedback on how to clarify this = for the implementer will be really important, so thanks for this = feedback! I'd also like to discuss with the WG the scope of various = documents that we want to produce. If you have one document that does = the abstract connection-management and I/O API and all the protocol options and the racing/fallback strategy, that would be a = very long and complex doc.

Great - I=E2=80=99m = happy that this is constructive!  Regarding the requests I=E2=80=99m = making about post sockets, a reason I think more of these implementation = level considerations need to be in the draft is that this gave me so = many hiccups of the sort =E2=80=9Cbut then you need it on both sides=E2=80= =9D, =E2=80=9Cbut then you need to add a lot more protocol = functionality=E2=80=9D, =E2=80=9Cbut do you think you could do that?=E2=80= =9D =E2=80=A6 etc.
I guess no matter if there are = multiple docs or one, any document for charter item 3 should leave its = reader with the warm feeling of understanding how this could be = implemented.

To = figure out these details, I=E2=80=99d like to mention that the minset is = here to help  :-)    (that=E2=80=99s what it=E2=80=99s = meant for). Yes it=E2=80=99s too low-level to be a good API proposal in = its own right, but that=E2=80=99s also not the point - it tells you what = can and can=E2=80=99t be done. Every decision in it can be traced back = to specific reasoning based on the original RFCs; even if you end up = disagreeing with reasoning X about a mechanism Y from a RFC Z, at least = you know precisely what you=E2=80=99re doing in relation to the TCP, = MPTCP, SCTP, UDP, UDP-Lite and LEDBAT specs).

Cheers,
Michael

= --Boundary_(ID_MhHKMV8zJ59LeOanbVQlPA)-- From nobody Sun Nov 12 18:08:49 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10265127909 for ; Sun, 12 Nov 2017 18:08:48 -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 VM3NxNf6n6a5 for ; Sun, 12 Nov 2017 18:08:45 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 B51A3126CB6 for ; Sun, 12 Nov 2017 18:08:45 -0800 (PST) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eE4B1-000Aef-P4; Mon, 13 Nov 2017 03:08:43 +0100 Received: from dhcp-9539.meeting.ietf.org ([31.133.149.57]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eE4B0-000BUx-U7; Mon, 13 Nov 2017 03:08:43 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <98F9BFDF-0343-4846-A0F8-F3AF60168B5A@apple.com> Date: Mon, 13 Nov 2017 10:08:38 +0800 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> <4EF62BB5-7638-4C3D-98A6-F1F081ABF216@ifi.uio.no> <98F9BFDF-0343-4846-A0F8-F3AF60168B5A@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 31.133.149.57 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.149.57; envelope-from=michawe@ifi.uio.no; helo=dhcp-9539.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.050, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DA09234ADCA038F933594423A5F4434536F36961 Archived-At: Subject: Re: [Taps] API design: dependencies or buffer control? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:08:48 -0000 > On Nov 13, 2017, at 7:54 AM, Tommy Pauly wrote: >=20 > The code I work with does TCP_NOTSENT_LOWAT by default, so we have a = fair amount of experience with it. I figured :-) AFAIK think Stuart invented it=E2=80=A6 > If you're using sockets with TCP_NOTSENT_LOWAT, and you're doing = asynchronous non-blocking socket operations, then you don't have the = annoyance of getting these "empty" callbacks you're referring to=E2=80=94i= t just changes how aggressively the writable event fires, making it back = off a bit. Ah, ok, sure. > With a Post-like API, having something directly like TCP_NOTSENT_LOWAT = doesn't make much sense. Instead, the implementation may internally use = that, but the equivalent application feedback is the completion that is = returned based on the write messages. The timing of when the stack = indicates when something has been written allows the application to = understand the back-pressure properties of the transport, and if it able = to generate or fetch data more slowly to match the back-pressure, it = can. Otherwise, it can simply keep writing and the data will get = enqueued within the library. I mean, the way you describe it here, the application has no means to = say how much it wants the layers below to buffer. I think that would be = useful, no? A big buffer is more convenient (based on the number write returns), a = smaller buffer lets the application have control over the data until the = last minute. But then, doesn=E2=80=99t this amount to the same "nuisance vs. control = of data until the last minute" trade-off that I described? > Dependencies between the messages that are being written, then, = doesn't actually come into play much here. Dependencies are hints to the = implementation and protocol stack of how to order work when scheduling = to send (PRE-WRITE). TCP_NOTSENT_LOWAT or the completions to indicate = that writes have completed are all about signaling back to the = application to provide back-pressure (POST-WRITE). I understand the functionality is separate, but you can achieve the same = with it: from an application=E2=80=99s point of view, if I have blocks = with dependencies and if you allow me to tune the buffer below the write = call, then I can decide until the last minute that I=E2=80=99d rather = not send a certain data block. I guess additionally offering to describe dependencies doesn=E2=80=99t = hurt anyway, btw =E2=80=A6 what made me worried about the complexity is = the possibility that these dependencies would change over time, and then = the application would want to send an update to post-sockets. I guess = the easy way out is not to offer such dynamics (as indeed in this case = an application might be better off handling it in the way I describe = above?). Cheers, Michael From nobody Sun Nov 12 18:16:40 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B13212714F for ; Sun, 12 Nov 2017 18:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Gp_QUMhu8kTQ for ; Sun, 12 Nov 2017 18:16:35 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 022881252BA for ; Sun, 12 Nov 2017 18:16:35 -0800 (PST) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eE4Ib-000B3y-DH for taps@ietf.org; Mon, 13 Nov 2017 03:16:33 +0100 Received: from dhcp-9539.meeting.ietf.org ([31.133.149.57]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eE4IY-0006LT-F2; Mon, 13 Nov 2017 03:16:33 +0100 From: Michael Welzl Message-Id: <69EED2CF-2515-4C2E-B1BD-70B3001B217B@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_F8A244C6-8778-4893-89AF-20AA4067FCFC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 10:16:26 +0800 In-Reply-To: <9E765BA0-5A2A-47CD-A13F-1ED379F235EB@apple.com> Cc: "taps@ietf.org" To: Tommy Pauly References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> <9E765BA0-5A2A-47CD-A13F-1ED379F235EB@apple.com> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 31.133.149.57 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.149.57; envelope-from=michawe@ifi.uio.no; helo=dhcp-9539.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.001, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7710765543E1C9AD3A56D57F8EB57BDF1EC8EE8A Archived-At: Subject: Re: [Taps] Review of draft-trammell-taps-post-sockets-03 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:16:39 -0000 --Apple-Mail=_F8A244C6-8778-4893-89AF-20AA4067FCFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2017, at 8:07 AM, Tommy Pauly wrote: >=20 >=20 >=20 >> On Nov 11, 2017, at 2:09 PM, Michael Welzl > wrote: >>=20 >> Hi, >>=20 >> In line: >>=20 >>> On Nov 11, 2017, at 11:58 AM, Tommy Pauly > wrote: >>>=20 >>>=20 >>>=20 >>>> On Nov 11, 2017, at 10:36 AM, Michael Welzl > wrote: >>>>=20 >>>>=20 >>>>> On Nov 11, 2017, at 10:06 AM, Tommy Pauly > wrote: >>>>>=20 >>>>> Hi Michael, >>>>>=20 >>>>> Just a couple initial notes that may help: >>>>>=20 >>>>> - The version diff you should look at is between -01 and -03. -02 = is the same as -03, but had a typo. >>>>>=20 >>>>> - You've mentioned previously that you thought that Post requires = both peers to use that API. That is absolutely not the case in any way. = Having implemented Post myself, I am only communicating to "legacy" = servers that know nothing about Post. I think this fundamental = understanding needs to be cleared up before coming to any conclusions. = We can discuss during the WG. >>>>=20 >>>> Oh?! That would be fantastic!! But I stumbled over a number of = things that require a system on the other side, or they just couldn=E2=80=99= t happen (like the =E2=80=9Ccarrier forking=E2=80=9D notification I = quoted below - but there were more). If you say you can talk to a = =E2=80=9Clegacy=E2=80=9D server that knows nothing about Post, WHAT does = that server speak? Legacy which protocol? Maybe it=E2=80=99s just a = matter of me thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me = :) >>>=20 >>> So, since Post (and TAPS in general) isn't defining any new protocol = features, we need to of course be compatible with all existing = protocols. Certainly, some functionality is a bit degenerate in some = cases. >>>=20 >>> Whatever the server speaks, the client needs to conform to. So, we = use our Post implementation for raw TCP, raw UDP, TLS over TCP, HTTP/2 = Streams over TLS over TCP, QUIC streams over UDP, etc. These are all = standard server configurations, but Post offers a client application a = single set of APIs to talk over any of these protocols. >>=20 >> Oh, great! But then you can=E2=80=99t guarantee that a message = arrives as a message in case of raw TCP, or you assume application-level = framing. This is what I=E2=80=99ve been proposing, but the post-sockets = draft reads entirely different from that. >=20 > Messages do indeed "always work", but they may be degenerate. There's = no new protocols here, just ways of looking at them: >=20 > - UDP: One message per datagram > - TCP: Entire stream is one big message that only ever ends when that = half of the stream closes > - TLS: Generally viewed like TLS, but can view one record as one = message=20 > - HTTP/QUIC: One message per request/response (so, framing) > - Length-value framing on streams, as used by some protocols (like = IKEv2 over TCP): one message per L-V frame > Etc, etc. >=20 > That is what the draft does say in Section 2.2. Note how a TCP stream = is the message in some cases. >=20 > A Message is the unit of communication between applications. > Messages can represent relatively small structures, such as = requests > in a request/response protocol such as HTTP; relatively large > structures, such as files of arbitrary size in a filesystem; and > structures of indeterminate length, such as a stream of bytes in a > protocol like TCP. I read this; how is this efficient? Are you suggesting to open and = close connections to signal that a message is over? Otherwise, how can you know it is? The length of a message is determined = by the application... >>> In the case of "Carrier Forking", that's essentially what you say to = the protocol stack when you want to open a new stream to the same place. = So, when I call "fork Carrier", it turns into: >>> - For raw UDP/TCP or TLS (or anything that is mono-streamed), open a = new five-tuple to the same remote endpoint >>> - For HTTP/2 and QUIC, open a new stream on the same connection >>=20 >> Sure, that=E2=80=99s what I thought it would. Now, with SCTP, you = wouldn=E2=80=99t get a =E2=80=9Cfork request=E2=80=9D equivalent on the = other side: the client would just start using a new stream, and that=E2=80= =99s it. (=E2=80=9Crequest=E2=80=9D also indicates the possibility to = say no, which also doesn=E2=80=99t exist in SCTP AFAIK, at least not in = the API - this would be a =E2=80=9Cstream reset=E2=80=9D). Now, in = QUIC, I don=E2=80=99t know exactly how that is, but I would have thought = it=E2=80=99s the same - you just go ahead and use a new stream. No = =E2=80=9Cfork request=E2=80=9D on the other side - just a new stream (in = post, carrier) being used. >=20 > The term "fork-request" is misleading, yes. It really should just say: = "forking a carrier creates a new flow to the same Remote, which may be a = new stream on a multiplexing protocol. The protocol will handle any = required signaling to the remote to open a new stream, based on the = protocol=E2=80=9D. Ok; the remote must not have a chance to refuse it, then, because the = protocol may not really signal anything all before you get your first = byte of data. >>>>> - The point of the API is to give the shape of the application = interaction, which is why you find it general. I believe that many of = the protocol-specific options like you mention (disabling Nagle, = retransmissions, etc) don't belong to this main abstract API draft, but = to a different document that goes into how to configure options that can = be used for setups like TCP/UDP. Again, in my implementation of Post, = all of these options exist as part of the Configuration object mentioned = in the draft. However, as I'll discuss in the WG, I believe that the = general shape of the API needs to be defined to be more-forward looking = than just what we've specified with the minset for TCP/UDP/SCTP. = Essentially, these become a set of Configuration options that can be = used, but as transport protocols continue to evolve (and when we need = more protocol-specific options), we need to be able to expand. Certain = aspects of the minset, like the connection state management, are of = course general and common enough to be part of the highest level of API = description. >>>>=20 >>>> It=E2=80=99s clear to me that we want a higher abstraction level = than what the list from minset has - e.g., rather than a DSCP value, it = would be better to specify general requirements (low latency or such) = for a carrier. Rather than saying =E2=80=9Cdisable Nagle=E2=80=9D, we = could also say =E2=80=9C low latency, even if it comes at the cost of = some overhead=E2=80=9D - we do such things in the NEAT API too. You=E2=80=99= re focused on the interaction with the application (e.g. callback-based = instead of traditional socket-style) - which is fine, but I think = doesn=E2=80=99t have much to do with the actual protocol choice. >>>>=20 >>>> As for being more forward-looking, I wonder what the new transport = features are that we=E2=80=99re missing out on (things that apps really = see). I follow QUIC from a slightly too large distance (I simply run out = of cycles there :( ), but so far I=E2=80=99m not sure there=E2=80=99s = anything we=E2=80=99d be missing (but that=E2=80=99s maybe also because = I=E2=80=99m not an HTTP/2 expert either). Except security of course, but = there the argument is perhaps that it=E2=80=99s enough to consider = falling back to TLS? >>>=20 >>> QUIC is using TLS 1.3, so it can give equivalent security properties = to HTTP/2. Doing fallback between these is definitely an important = feature. I think this flexibility is why the API needs to allow = per-protocol configs. >>=20 >> Sure, but I think (and that was my point) this doesn=E2=80=99t change = anything about the stuff above (security is in your separate document) - = so what exactly are the =E2=80=9Cmore forward looking=E2=80=9D = requirements except for these security needs? >=20 > I'm trying to distinguish certain aspects of the minset that are: > a) fundamental to all transports, that we have reason to believe will = be the case for all future transports in some fashion > CONNECT, SEND, RECEIVE, CLOSE, etc > b) derived from the protocols we happened to survey or based on = current semantics (sockets), based on what exists > Things I see in the NEAT draft like SET_MIN_CHECKSUM_COVERAGE, = SET_TTL, SET_LOW_WATERMARK. Important to have, but often the values the = application needs to set relate to which protocol might be used, and may = have different requirements for future protocols. >=20 > So, there's a set of things in category (a) that should be stable as = the main API go forward for quite a while, while things in category (b) = may belong as configuration properties, in a list that may shrink or = expand over time as new developments are made. Hmm. Not sure I buy that e.g. set_min_checksum_coverage has any = dependency on the protocol. As for set_low_watermark, see my other = email about that matter: the point is, the application should have some = means to tune the size of the buffer below it, I believe. Cheers, Michael --Apple-Mail=_F8A244C6-8778-4893-89AF-20AA4067FCFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 13, 2017, at 8:07 AM, Tommy Pauly <tpauly@apple.com> = wrote:



On Nov 11, 2017, at 2:09 PM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

In = line:

On Nov 11, 2017, at 11:58 AM, Tommy Pauly <tpauly@apple.com> = wrote:



On Nov = 11, 2017, at 10:36 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:


On Nov = 11, 2017, at 10:06 AM, Tommy Pauly <tpauly@apple.com> wrote:

Hi Michael,

Just a couple = initial notes that may help:

- The version = diff you should look at is between -01 and -03. -02 is the same as -03, = but had a typo.

- You've mentioned = previously that you thought that Post requires both peers to use that = API. That is absolutely not the case in any way. Having implemented Post = myself, I am only communicating to "legacy" servers that know nothing = about Post. I think this fundamental understanding needs to be cleared = up before coming to any conclusions. We can discuss during the WG.

Oh?!  That would be = fantastic!!  But I stumbled over a number of things that require a = system on the other side, or they just couldn=E2=80=99t happen (like the = =E2=80=9Ccarrier forking=E2=80=9D notification I quoted below - but = there were more). If you say you can talk to a =E2=80=9Clegacy=E2=80=9D = server that knows nothing about Post, WHAT does that server speak? = Legacy which protocol?  Maybe it=E2=80=99s just a matter of me = thinking TCP, and you thinking TLS=E2=80=A6 dunno! Tell me =   :)

So, since Post (and TAPS in general) = isn't defining any new protocol features, we need to of course be = compatible with all existing protocols. Certainly, some functionality is = a bit degenerate in some cases.

Whatever the server speaks, the client = needs to conform to. So, we use our Post implementation for raw TCP, raw = UDP, TLS over TCP, HTTP/2 Streams over TLS over TCP, QUIC streams over = UDP, etc. These are all standard server configurations, but Post offers = a client application a single set of APIs to talk over any of these = protocols.

Oh, great!  But then you can=E2=80=99t guarantee = that a message arrives as a message in case of raw TCP, or you assume = application-level framing. This is what I=E2=80=99ve been proposing, but = the post-sockets draft reads entirely different from = that.

Messages do indeed "always work", but = they may be degenerate. There's no new protocols here, just ways of = looking at them:

- UDP: One message per datagram
- TCP: = Entire stream is one big message that only ever ends when that half of = the stream closes
- TLS: Generally viewed like TLS, = but can view one record as one message 
- = HTTP/QUIC: One message per request/response (so, framing)
- Length-value framing on streams, as used by some protocols = (like IKEv2 over TCP): one message per L-V frame
Etc,= etc.

That is = what the draft does say in Section 2.2. Note how a TCP stream is the = message in some cases.

A Message is the unit of communication between applications.
   Messages can represent relatively small structures, such as requests
   in a request/response protocol such as HTTP; relatively large
   structures, such as files of arbitrary size in a filesystem; and
   structures of indeterminate length, such as a stream of bytes in a
   protocol like TCP.

I read this; how is this efficient?  Are you = suggesting to open and close connections to signal that a message is = over?
Otherwise, how can you know it is? The length of a = message is determined by the application...


In the = case of "Carrier Forking", that's essentially what you say to the = protocol stack when you want to open a new stream to the same place. So, = when I call "fork Carrier", it turns into:
- For = raw UDP/TCP or TLS (or anything that is mono-streamed), open a new = five-tuple to the same remote endpoint
- For HTTP/2 = and QUIC, open a new stream on the same = connection

Sure, that=E2=80=99s what I thought it = would. Now, with SCTP, you wouldn=E2=80=99t get a =E2=80=9Cfork = request=E2=80=9D equivalent on the other side: the client would just = start using a new stream, and that=E2=80=99s it.  (=E2=80=9Crequest=E2= =80=9D also indicates the possibility to say no, which also doesn=E2=80=99= t exist in SCTP AFAIK, at least not in the API - this would be a = =E2=80=9Cstream reset=E2=80=9D).  Now, in QUIC, I don=E2=80=99t = know exactly how that is, but I would have thought it=E2=80=99s the same = - you just go ahead and use a new stream. No =E2=80=9Cfork request=E2=80=9D= on the other side - just a new stream (in post, carrier) being = used.

The term "fork-request" is misleading, = yes. It really should just say: "forking a carrier creates a new flow to = the same Remote, which may be a new stream on a multiplexing protocol. = The protocol will handle any required signaling to the remote to open a = new stream, based on the = protocol=E2=80=9D.

Ok; the remote must not have a chance to refuse = it, then, because the protocol may not really signal anything all before = you get your first byte of data.


- The point of the API is to give the shape of the = application interaction, which is why you find it general. I believe = that many of the protocol-specific options like you mention (disabling = Nagle, retransmissions, etc) don't belong to this main abstract API = draft, but to a different document that goes into how to configure = options that can be used for setups like TCP/UDP. Again, in my = implementation of Post, all of these options exist as part of the = Configuration object mentioned in the draft. However, as I'll discuss in = the WG, I believe that the general shape of the API needs to be defined = to be more-forward looking than just what we've specified with the = minset for TCP/UDP/SCTP. Essentially, these become a set of = Configuration options that can be used, but as transport protocols = continue to evolve (and when we need more protocol-specific options), we = need to be able to expand. Certain aspects of the minset, like the = connection state management, are of course general and common enough to = be part of the highest level of API description.

It=E2=80=99s clear to me that we = want a higher abstraction level than what the list from minset has - = e.g., rather than a DSCP value, it would be better to specify general = requirements (low latency or such) for a carrier. Rather than saying = =E2=80=9Cdisable Nagle=E2=80=9D, we could also say =E2=80=9C low = latency, even if it comes at the cost of some overhead=E2=80=9D - we do = such things in the NEAT API too. You=E2=80=99re focused on the = interaction with the application (e.g. callback-based instead of = traditional socket-style) - which is fine, but I think doesn=E2=80=99t = have much to do with the actual protocol choice.

As for being more forward-looking, I wonder what the new = transport features are that we=E2=80=99re missing out on (things that = apps really see). I follow QUIC from a slightly too large distance (I = simply run out of cycles there :(  ), but so far I=E2=80=99m not = sure there=E2=80=99s anything we=E2=80=99d be missing  (but = that=E2=80=99s maybe also because I=E2=80=99m not an HTTP/2 expert = either). Except security of course, but there the argument is perhaps = that it=E2=80=99s enough to consider falling back to TLS?

QUIC is using TLS 1.3, so it can give equivalent = security properties to HTTP/2. Doing fallback between these is = definitely an important feature. I think this flexibility is why the API = needs to allow per-protocol configs.

Sure, but I think (and that was my = point) this doesn=E2=80=99t change anything about the stuff above = (security is in your separate document) - so what exactly are the = =E2=80=9Cmore forward looking=E2=80=9D requirements except for these = security needs?

I'm trying to distinguish certain = aspects of the minset that are:
a) fundamental to = all transports, that we have reason to believe will be the case for all = future transports in some fashion
CONNECT, = SEND, RECEIVE, CLOSE, etc
b) derived from the = protocols we happened to survey or based on current semantics (sockets), = based on what exists
Things I see in the NEAT draft = like SET_MIN_CHECKSUM_COVERAGE, SET_TTL, SET_LOW_WATERMARK.= Important to have, but often the values the application needs to set = relate to which protocol might be used, and may have different = requirements for future protocols.

So, there's a set of things in category = (a) that should be stable as the main API go forward for quite a while, = while things in category (b) may belong as configuration properties, in = a list that may shrink or expand over time as new developments are = made.

Hmm. Not sure I buy that e.g. = set_min_checksum_coverage has any dependency on the protocol.  As = for set_low_watermark, see my other email about that matter: the point = is, the application should have some means to tune the size of the = buffer below it, I believe.

Cheers,
Michael

= --Apple-Mail=_F8A244C6-8778-4893-89AF-20AA4067FCFC-- From nobody Sun Nov 12 18:36:58 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A091289B5 for ; Sun, 12 Nov 2017 18:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=apple.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 vOYaAAYiJF1E for ; Sun, 12 Nov 2017 18:36:55 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) (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 87F8C128B37 for ; Sun, 12 Nov 2017 18:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510540588; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1ymtv+j7hBOueafn+Rf/dHLmR9GIkHtD40kS/7USOls=; b=gwOxVBCWbXj4aF3wA4jZdQto9PPfOTwe4bdiePBEE1v+oup35/EKAit/eA9KCskI Bh0xX4dyGj9/DzSL9lGEPB9pkpu/xpOdamy3HvsYRWJLo9c9+1xptL9g0p5fx4iZ kZtyPdhWFissiyljyQilcnq85K6yfDhJLi0paHND/UDfACHzsUdayCeXvfSXqODs z1gcBSD1sU6nlcUqO2ted3Z0wsynCqkBRwrpqB7uRRC86OJ8HOoblPZPgQuvFKen jUg/FhfsHmLSz7AWCIkU3UJNT+Ahk5T4seXQ3g+PG3Bitr7Txsfc12K6Tdxj9Ail cruEPYMyq2luQl+TDo7QoQ==; Received: from relay1.asia.apple.com ( [17.82.200.18]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 62.1A.05091.C25090A5; Mon, 13 Nov 2017 10:36:28 +0800 (MYT) X-AuditID: 1152fe06-a100e9c0000013e3-90-5a09052cdb39 Received: from echium.asia.apple.com ( [17.84.80.65]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 23.0F.23340.C25090A5; Mon, 13 Nov 2017 10:36:28 +0800 (MYT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.235.154.204] by echium.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZC002864KSFL00@echium.asia.apple.com>; Mon, 13 Nov 2017 10:36:28 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Mon, 13 Nov 2017 10:36:27 +0800 Cc: "taps@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <1EC37784-46F1-4E35-93D7-A63413277C61@apple.com> References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> <4EF62BB5-7638-4C3D-98A6-F1F081ABF216@ifi.uio.no> <98F9BFDF-0343-4846-A0F8-F3AF60168B5A@apple.com> To: Michael Welzl X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUiGHRCSFeHlTPK4HmbpsWPsztZLe7EODB5 LFnyk8lj9eqHzAFMUVw2Kak5mWWpRfp2CVwZ3fNOMxZ0yFUcbP7I1MC4XKKLkZNDQsBE4taU T4xdjFwcQgIrmSQaF3xkgUksfTuBFSKxkVHi3rJ77CAJXgFBiR+T7wEVcXAwC6hLTJmSC1Hz iVGi8UMLE0hcWEBCYvOeRJByYQF7ic1zloDNZBNQkTj+bQMziM0pYCdxqOEhG0g5i4CqxJuJ CSBhZgFlicezGlkgbG2JJ+8usEJstZHYOPkW1DnLmCVWffnBBJIQEVCTOLF8NRvEzYoSDzd1 gRVJCPSwSSzb8IF1AqPwLCRnz0I4exaSHQsYmVcxiucmZuboZuYZ6SUWZybqJRYU5KTqJefn bmIEh/c/th2MC14bHmIU4GBU4uGd+IYjSog1say4MvcQowQHs5II75H7QCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8vZGfIoUE0hNLUrNTUwtSi2CyTBycUg2MyqnxnYcsVshcLW7bvOex9+8J SzYZ/cthzrjUa/hhl5J31I5l4VpO8XHhSr1qzicWPZmyo1VTVn5LkpPqrw+Nz4QseapWC1w4 Z6h/enWus/i1L7yaLqujbxdEdPB2+rycuqie1z2n2bb7Nz/3mpKTmxyWPd8x9bXHvjjfJ6vb 7z2dv1l3gdY/JZbijERDLeai4kQAHhMj8WsCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUiGBLgqKvDyhllsGujssWPsztZLe7EODB5 LFnyk8lj9eqHzAFMUVw2Kak5mWWpRfp2CVwZ3fNOMxZ0yFUcbP7I1MC4XKKLkZNDQsBEYunb CaxdjFwcQgIbGSXuLbvHDpLgFRCU+DH5HksXIwcHs4C6xJQpuRA1nxglGj+0MIHEhQUkJDbv SQQpFxawl9g8ZwkLiM0moCJx/NsGZhCbU8BO4lDDQzaQchYBVYk3ExNAwswCyhKPZzWyQNja Ek/eXWCF2GojsXHyLahzljFLrPrygwkkISKgJnFi+Wo2iJsVJR5u6mKdwCgwC8mlsxAunYVk 7AJG5lWMokWpOYmVhnqJxZmJeokFBTmpesn5uZsYQeEYdEJoB+PH/QaHGAU4GJV4eJe84YgS Yk0sK67MPcQowcGsJMJ75D5QiDclsbIqtSg/vqg0J7X4EKM0B4uSOK9m1KdIIYH0xJLU7NTU gtQimCwTB6dUA+Ok6cET13Vw7cwyuR3P2q9ea+/Hw36i+c2+BUr/fa+Er7u/qmXHss/zZ6W8 tmvIPHWqJ9eP503qzl2pRW8zH5wNXN23rOp2nY2Ruhj3WuXLpwOdv6hKVD2Mti1MdHtlZRsw Zf7lV3tNV21cwi5U8vY8b5HZyahzvW4CZ5S8difPnrWP1X2TI68SS3FGoqEWc1FxIgBgXTZm QwIAAA== Archived-At: Subject: Re: [Taps] API design: dependencies or buffer control? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:36:57 -0000 > On Nov 13, 2017, at 10:08 AM, Michael Welzl = wrote: >=20 >=20 >> On Nov 13, 2017, at 7:54 AM, Tommy Pauly wrote: >>=20 >> The code I work with does TCP_NOTSENT_LOWAT by default, so we have a = fair amount of experience with it. >=20 > I figured :-) AFAIK think Stuart invented it=E2=80=A6 >=20 >=20 >> If you're using sockets with TCP_NOTSENT_LOWAT, and you're doing = asynchronous non-blocking socket operations, then you don't have the = annoyance of getting these "empty" callbacks you're referring to=E2=80=94i= t just changes how aggressively the writable event fires, making it back = off a bit. >=20 > Ah, ok, sure. >=20 >=20 >> With a Post-like API, having something directly like = TCP_NOTSENT_LOWAT doesn't make much sense. Instead, the implementation = may internally use that, but the equivalent application feedback is the = completion that is returned based on the write messages. The timing of = when the stack indicates when something has been written allows the = application to understand the back-pressure properties of the transport, = and if it able to generate or fetch data more slowly to match the = back-pressure, it can. Otherwise, it can simply keep writing and the = data will get enqueued within the library. >=20 > I mean, the way you describe it here, the application has no means to = say how much it wants the layers below to buffer. I think that would be = useful, no? > A big buffer is more convenient (based on the number write returns), a = smaller buffer lets the application have control over the data until the = last minute. > But then, doesn=E2=80=99t this amount to the same "nuisance vs. = control of data until the last minute" trade-off that I described? It can control exactly how much is buffered, since it knows when the = data has been actually sent. If you never fail the enqueue of data into = the API, you can put as much or as little into the buffer as you want. = Since you don't just have a single "writable" callback from a socket, = you actually get much more control. >=20 >=20 >> Dependencies between the messages that are being written, then, = doesn't actually come into play much here. Dependencies are hints to the = implementation and protocol stack of how to order work when scheduling = to send (PRE-WRITE). TCP_NOTSENT_LOWAT or the completions to indicate = that writes have completed are all about signaling back to the = application to provide back-pressure (POST-WRITE). >=20 > I understand the functionality is separate, but you can achieve the = same with it: from an application=E2=80=99s point of view, if I have = blocks with dependencies and if you allow me to tune the buffer below = the write call, then I can decide until the last minute that I=E2=80=99d = rather not send a certain data block. Since the app knows which blocks are outstanding, you can always wait to = schedule the block, and you don't need to add dependencies. The = dependencies are useful when you want to express that if there is = internal re-ordering within a protocol, it can make sure that certain = relationships between data are maintained. >=20 > I guess additionally offering to describe dependencies doesn=E2=80=99t = hurt anyway, btw =E2=80=A6 what made me worried about the complexity is = the possibility that these dependencies would change over time, and then = the application would want to send an update to post-sockets. I guess = the easy way out is not to offer such dynamics (as indeed in this case = an application might be better off handling it in the way I describe = above?). >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Sun Nov 12 21:38:16 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA29126FB3 for ; Sun, 12 Nov 2017 21:38:14 -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, 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 uF5O8zcn52OV for ; Sun, 12 Nov 2017 21:38:11 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 865E9124D6C for ; Sun, 12 Nov 2017 21:38:11 -0800 (PST) Received: from dhcp-8a57.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:f517:9d7a:74c:7f79]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id AB3921B00127 for ; Mon, 13 Nov 2017 05:37:53 +0000 (GMT) Message-ID: <5A092FB0.7010303@erg.abdn.ac.uk> Date: Mon, 13 Nov 2017 13:37:52 +0800 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: taps@ietf.org References: <151055129025.21446.15096095650129153630.idtracker@ietfa.amsl.com> In-Reply-To: <151055129025.21446.15096095650129153630.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] New Version Notification for draft-fairhurst-taps-neat-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:38:14 -0000 We've just posted a minor rev to the ID. It contains corrections to INIT_FLOW; fixes to typos. It also includes a diagram, which we did not have time to draw before the meeting, but seemed useful for a discussion. Gorry On 13/11/2017, 13:34, internet-drafts@ietf.org wrote: > A new version of I-D, draft-fairhurst-taps-neat-01.txt > has been successfully submitted by Godred Fairhurst and posted to the > IETF repository. > > Name: draft-fairhurst-taps-neat > Revision: 01 > Title: The NEAT Interface to Transport Services > Document date: 2017-11-13 > Group: Individual Submission > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-fairhurst-taps-neat-01.txt > Status: https://datatracker.ietf.org/doc/draft-fairhurst-taps-neat/ > Htmlized: https://tools.ietf.org/html/draft-fairhurst-taps-neat-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-fairhurst-taps-neat-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-fairhurst-taps-neat-01 > > Abstract: > The NEAT System provides an example of a system designed to implement > the TAPS Transport Services. This document presents the transport > services that the NEAT User API provides to an application or upper- > layer protocol. It also describes primitives needed to interface to > the NEAT Policy Manager and how policies can be adjusted to match the > API behaviour to the properties required by an application or upper- > layer protocol using the NEAT User API. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Mon Nov 13 02:15:53 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF00129485 for ; Mon, 13 Nov 2017 02:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YNKzg_KV81Wi for ; Mon, 13 Nov 2017 02:15:51 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 12771124BE8 for ; Mon, 13 Nov 2017 02:15:50 -0800 (PST) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eEBmP-0002p0-3t for taps@ietf.org; Mon, 13 Nov 2017 11:15:49 +0100 Received: from dhcp-82c4.meeting.ietf.org ([31.133.130.196]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eEBmD-00078O-86; Mon, 13 Nov 2017 11:15:49 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <1EC37784-46F1-4E35-93D7-A63413277C61@apple.com> Date: Mon, 13 Nov 2017 18:15:32 +0800 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <38E6A4C0-14E2-4DBA-BFDF-6C16CD058B04@ifi.uio.no> References: <7F6D4FB0-3D41-4E06-BD11-54D897FA5345@ifi.uio.no> <3702C080-9EEA-441C-96C3-5A2A1FCC7ABA@apple.com> <4EF62BB5-7638-4C3D-98A6-F1F081ABF216@ifi.uio.no> <98F9BFDF-0343-4846-A0F8-F3AF60168B5A@apple.com> <1EC37784-46F1-4E35-93D7-A63413277C61@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 31.133.130.196 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.130.196; envelope-from=michawe@ifi.uio.no; helo=dhcp-82c4.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.056, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 85E9734BF1F42B0F9DA50A685C0495004AD1A3FF Archived-At: Subject: Re: [Taps] API design: dependencies or buffer control? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 10:15:53 -0000 Hi, This is me trying to conclude this with a text proposal fort he draft, = for the record and for the group - in line: > On Nov 13, 2017, at 10:36 AM, Tommy Pauly wrote: >=20 >=20 >=20 >> On Nov 13, 2017, at 10:08 AM, Michael Welzl = wrote: >>=20 >>=20 >>> On Nov 13, 2017, at 7:54 AM, Tommy Pauly wrote: >>>=20 >>> The code I work with does TCP_NOTSENT_LOWAT by default, so we have a = fair amount of experience with it. >>=20 >> I figured :-) AFAIK think Stuart invented it=E2=80=A6 >>=20 >>=20 >>> If you're using sockets with TCP_NOTSENT_LOWAT, and you're doing = asynchronous non-blocking socket operations, then you don't have the = annoyance of getting these "empty" callbacks you're referring to=E2=80=94i= t just changes how aggressively the writable event fires, making it back = off a bit. >>=20 >> Ah, ok, sure. >>=20 >>=20 >>> With a Post-like API, having something directly like = TCP_NOTSENT_LOWAT doesn't make much sense. Instead, the implementation = may internally use that, but the equivalent application feedback is the = completion that is returned based on the write messages. The timing of = when the stack indicates when something has been written allows the = application to understand the back-pressure properties of the transport, = and if it able to generate or fetch data more slowly to match the = back-pressure, it can. Otherwise, it can simply keep writing and the = data will get enqueued within the library. >>=20 >> I mean, the way you describe it here, the application has no means to = say how much it wants the layers below to buffer. I think that would be = useful, no? >> A big buffer is more convenient (based on the number write returns), = a smaller buffer lets the application have control over the data until = the last minute. >> But then, doesn=E2=80=99t this amount to the same "nuisance vs. = control of data until the last minute" trade-off that I described? >=20 > It can control exactly how much is buffered, since it knows when the = data has been actually sent. If you never fail the enqueue of data into = the API, you can put as much or as little into the buffer as you want. = Since you don't just have a single "writable" callback from a socket, = you actually get much more control. Tommy and I talked in person; Tommy explained to me that the application = knows about the state of the buffer below because it gets a callback = whenever the post sockets system is sending something. This may mean a = lot of callbacks, but I guess that isn=E2=80=99t a real problem. This = sounds good to me - you don=E2=80=99t need to adjust the buffer this = way, you just keep it small by waiting for a callback if you want - but = then, the text in the post-sockets draft needs to be very clear about = this procedure in my opinion. Specifically, now there=E2=80=99s only this text in there: *** Carriers also provide .OnSent(), .OnAcked(), and .OnExpired() calls for binding default send event handlers to the Carrier, and .OnClosed() for handling passive close notifications. *** =E2=80=A6 which should be expanded to explain exactly when these events = are fired. So, OnSent fires whenever post sockets sends a message (and = returns what? Any parameters?) And FWIW, from this text, OnAck could be a transport layer event, which = may not even be visible=E2=80=A6 when is this expected to fire? >>> Dependencies between the messages that are being written, then, = doesn't actually come into play much here. Dependencies are hints to the = implementation and protocol stack of how to order work when scheduling = to send (PRE-WRITE). TCP_NOTSENT_LOWAT or the completions to indicate = that writes have completed are all about signaling back to the = application to provide back-pressure (POST-WRITE). >>=20 >> I understand the functionality is separate, but you can achieve the = same with it: from an application=E2=80=99s point of view, if I have = blocks with dependencies and if you allow me to tune the buffer below = the write call, then I can decide until the last minute that I=E2=80=99d = rather not send a certain data block. >=20 > Since the app knows which blocks are outstanding, you can always wait = to schedule the block, and you don't need to add dependencies. The = dependencies are useful when you want to express that if there is = internal re-ordering within a protocol, it can make sure that certain = relationships between data are maintained. Also for the record, from the conversation, we agree that: - this is useful to have, - but it should be static, i.e. not allowing the application to change = dependencies it has once specified. This should also be written in the draft. Cheers, Michael From nobody Mon Nov 13 16:20:21 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0A1288A9 for ; Mon, 13 Nov 2017 16:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 GIV_T9JSx5YL for ; Mon, 13 Nov 2017 16:20:18 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (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 2FDF41200CF for ; Mon, 13 Nov 2017 16:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510618815; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8yYbSr/o7K56/hRoAz4rYQl0MZYYrJVCbZogECB4mx0=; b=LNbg5VGT9ca+1n/SsEIKGQa1dkrfxKvhtvmknYSlyInPi1JqM4BEpnZd4pajUROC WRaIuodrPXsvfTPluQipmwbAbik+PUbe70G7p85VaGdhuic6ueDyIrdrRi9lXXFF j3OVInH68PX81gcQIJLfXiq/fS1e4g+OvH+4WobWrEHXTHDIJ8xx68fP7nWGboI/ zu0rgcLTmR8HoQhc+a91ZbBlr/iwTyxzThCixTel7YVs+pMfTOx/f5mHy4JosBOK qso5YEW8+hc6KBGZQwGbzSrY8LF0V0H3fkQAdOeCUAhYgO8jDgi5TELmKXKeX3dM fzeR9qovtZcuYVcku/oJig==; Received: from relay1.asia.apple.com ( [17.82.200.18]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id B1.A0.07591.FB63A0A5; Tue, 14 Nov 2017 08:20:15 +0800 (MYT) X-AuditID: 1152fe11-8cbff70000001da7-b5-5a0a36bf1319 Received: from sng-mmpp-sz02.asia.apple.com ( [17.84.80.27]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id BC.D1.23340.FB63A0A5; Tue, 14 Nov 2017 08:20:15 +0800 (MYT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qHrzD+79HyBacvu/S/LTpg)" Received: from [17.235.149.253] by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZD00FXNSXQOH20@sng-mmpp-sz02.asia.apple.com>; Tue, 14 Nov 2017 08:20:15 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Tue, 14 Nov 2017 08:20:14 +0800 In-reply-to: <7403AB1A-33FC-461A-B88F-B8DB8FC08881@ifi.uio.no> Cc: "taps@ietf.org" To: Michael Welzl References: <150871580801.24896.1276317669567869148@ietfa.amsl.com> <7403AB1A-33FC-461A-B88F-B8DB8FC08881@ifi.uio.no> X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUiGHRCSHe/GVeUwfGXchY/zu5ktbgT48Dk sWTJTyaP1asfMgcwRXHZpKTmZJalFunbJXBlfPrwirXg8HLGitYLrcwNjLt6GbsYOTkkBEwk mrZ9Y+5i5OIQEljJJNFx6wUzTOLqnzmMEIkdjBKtTS/BOngFBCV+TL7HAmIzC4RJdG2/DdYg JNDAJHFuamEXIweHsICExOY9iSBhNgEViePfNjCDhHkFbCRObQabIixgKzFt13JWEJtFQFVi //L5YDangJ3EmjcrmSCmK0s8ntUItklEQE3ixPLVbCBjhATKJX7fsIW4UlHi4aYuVpArJQQW sEn82DCNaQKj0Cwkh85CcugsoHZmAXWJKVNyIcLaEk/eXWCFsNUkFv5exIQsvoCRbRWjeG5i Zo5uZp6hXmJxZqJeYkFBTqpecn7uJkZwPPwT3ME4daHhIUYBDkYlHl4ZRa4oIdbEsuLK3EOM EhzMSiK8FrxAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rx9kZ8ihQTSE0tSs1NTC1KLYLJMHJxS DYyz6rZpFx3RsU9lWP07Y2tHSvQVwXeLA1uEzjkfSemV8W1kn2q8n3nODb3sPYoOd5Yaqm4+ /q2poeHuisdeS+auPTE1JK3s5ERGEfuS/d0s7YfiXmWnJH/+9C3qj/5qqzf9V77PtpyxSfXw ql0i/XwlzCeOVnU+eS3x+8vyuTyXn4Qp1IR6XGRXYinOSDTUYi4qTgQAtlcvn4MCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUiGBIgrbvfjCvK4MA7IYsfZ3eyWtyJcWDy WLLkJ5PH6tUPmQOYorhsUlJzMstSi/TtErgyPn14xVpweDljReuFVuYGxl29jF2MnBwSAiYS V//MAbK5OIQEdjBKtDa9BEvwCghK/Jh8jwXEZhYIk+jafpsZxBYSaGCSODe1sIuRg0NYQEJi 855EkDCbgIrE8W8bmEHCvAI2Eqc2g00RFrCVmLZrOSuIzSKgKrF/+Xwwm1PATmLNm5VMENOV JR7PagTbJCKgJnFi+Wo2kDFCAuUSv2/YQlypKPFwUxfrBEb+WUhum4XktllAHcwC6hJTpuRC hLUlnry7wAphq0ks/L2ICVl8ASPbKkbRotScxEpDvcTizES9xIKCnFS95PzcTYyg8A06IbSD 8eN+g0OMAhyMSjy8pxS5ooRYE8uKK3MPMUpwMCuJ8FrwAoV4UxIrq1KL8uOLSnNSiw8xSnOw KInzakZ9ihQSSE8sSc1OTS1ILYLJMnFwSjUwcjc7RP86fodJsuly3+J7k1JPqokGK1UxnH3+ Kyek4dUBAYOXGlLbznqEim3Wdnp2duG+dzxVRd/TxF921Hxct5YtwSo6Rr3d4VvuKdGmZ8uS y/58ydKX/D/7iJFHmcSbf7Xcr2NTa7q32yxM0xQUtlptEn5c8uQktfM7q6b063zaF5xxwq5V iaU4I9FQi7moOBEAYGjPBlsCAAA= Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-minset-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:20:20 -0000 --Boundary_(ID_qHrzD+79HyBacvu/S/LTpg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable A couple initial comments on the minset document: In Section 4: - Title should be "4. A MinSet Abstract Interface" not "4. An MinSet = Abstract Interface" For this: 3. Not offer any of the transport features of these protocols and the LEDBAT congestion control mechanism that do not require application-specific knowledge (to give maximum flexibility to a TAPS system) Could this be written as "that can be performed automatically" or = something, rather than "do not require application-specific knowledge"? = It ends up having a lot of negatives that get confusing. I'd like to see the reference removed to Post Sockets indicating that it = would require any protocol changes or the system on both ends. As = discussed on the other thread, Post does not require any changes to the = peer for compatibility. TLS: We can discuss in the group, but I think that security can stay a = separate document for now. You wouldn't "fall back" to TLS=E2=80=94TLS = is just something you can use underneath the TAPS API, and you either = have security or you don't. That shouldn't be changing underneath you. General: Much of the document is phrased in terms of "fall-back" to TCP, UDP, = etc. While I understand where this is coming from, I'm wondering from a = larger perspective if this is the right framing. As the document reads = now, there's this underlying normative assumption that "TCP and UDP are = less preferred" and MPTCP or SCTP etc is preferred over them. This may = be true for some systems, but maybe not always. The set of transports = that a TAPS system may eventually use hopefully won't be just limited to = the set in the survey, but include things like QUIC, etc. And depending = on the scenario, maybe we prefer something over TCP, and then fall-back = to some other less preferred mode. Or, the application may not allow = falling back at all, but simply wants to reuse its transport code that = uses a TAPS API between different protocols it uses for different, = mutually exclusive scenarios. So, I would be tempted to change the first two requirements from: 1. Support one-sided deployment with a fall-back to TCP (or UDP) 2. Offer all the transport features of (MP)TCP, UDP(-Lite), LEDBAT and SCTP that require application-specific knowledge To: 1. Support basic functionality required for all transports (the=20 minimal set for TCP and UDP) 2. Offer all extended transport features that require application- specific knowledge (such as options for (MP)TCP, UDP(-Lite), = LEDBAT and SCTP) Then, for each feature listed, you have essentially this format: o [Feature name] Protocols: SCTP [Description] Fall-back to TCP: [do nothing/not supported] Fall-back to UDP: [do nothing/not supported] How about something like: o [Feature name] Supported by: SCTP Ignored by: TCP Incompatible with: UDP [Description] This way, we list how each protocol will treat it, but we're not making = normative preferential statements, and we're not relying on the notion = of falling back. I think "falling back" is something that belongs in = documents around happy eyeballs and racing, etc, and baking in which = protocol is a fallback and which is the primary may be quite misleading = to implementers. Thoughts? Best, Tommy > On Oct 23, 2017, at 4:38 PM, Michael Welzl wrote: >=20 > Hi everyone, >=20 > This update addresses 2 out of 3 major comments that we got at the = last meeting: >=20 > 1) also fall-back to UDP =3D> done. This turned out to be much = easier than I thought because the set of transport features for which = TCP is a possible fall-back is, with *one* exception (receiving a = message) strictly a superset of transport features for which UDP is a = possible fall-back. Sorry for the clumsy sentence but the point is, = TCP itself is of course *not* strictly a superset of UDP itself, but = that doesn=E2=80=99t matter. Anyway, because of this superset = relationship, we were able to just mark limitations that arise when = requiring to fall back to UDP with (!UDP). >=20 > 2) make it clearer that the abstract interface description of the min = set is *not* an API proposal =3D> done. I hope this is now clear enough = for folks. >=20 > 3) make it less TCP-specific, also consider fall-back to e.g. TLS =3D> = not done. Maybe next time? >=20 > Thanks for the very useful feedback, everyone who was there last time! >=20 > Also, there are now considerations on how to begin. With the minset as = it was, it is possible for TAPS to choose UDP as a protocol and for the = application to later request reliability. At least such deadlocks must = be prevented - I=E2=80=99m not claiming that what we put in there is = generally ideal (in fact the text explains why it isn=E2=80=99t), but it = is one possible approach that avoids such deadlocks. >=20 >=20 > Chairs: I=E2=80=99d like to request a 20-minute slot for this update, = if possible (I think this should be enough including discussions, as my = presentation would probably fit in about 10 minutes). >=20 > Cheers, > Michael >=20 >=20 >=20 >> On Oct 23, 2017, at 1:43 AM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Transport Services WG of the IETF. >>=20 >> Title : A Minimal Set of Transport Services for TAPS = Systems >> Authors : Michael Welzl >> Stein Gjessing >> Filename : draft-ietf-taps-minset-00.txt >> Pages : 53 >> Date : 2017-10-22 >>=20 >> Abstract: >> This draft recommends a minimal set of IETF Transport Services >> offered by end systems supporting TAPS, and gives guidance on >> choosing among the available mechanisms and protocols. It is based >> on the set of transport features given in the TAPS document draft- >> ietf-taps-transports-usage-08. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-taps-minset-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_qHrzD+79HyBacvu/S/LTpg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable A = couple initial comments on the minset document:

In Section 4:

- Title should be "4.  A MinSet Abstract Interface" not "4.  An MinSet Abstract Interface"

For this:

3.  Not offer any of the =
transport features of these protocols and
       the LEDBAT congestion control mechanism that do not require
       application-specific knowledge (to give maximum flexibility to a
       TAPS system)

Could this be written as "that can be performed = automatically" or something, rather than "do not require = application-specific knowledge"? It ends up having a lot of negatives = that get confusing.

I'd like to see the reference removed to Post Sockets = indicating that it would require any protocol changes or the system on = both ends. As discussed on the other thread, Post does not require any = changes to the peer for compatibility.

TLS:

We can discuss in the group, but I = think that security can stay a separate document for now. You wouldn't = "fall back" to TLS=E2=80=94TLS is just something you can use underneath = the TAPS API, and you either have security or you don't. That shouldn't = be changing underneath you.

General:

Much of the document is phrased in terms of "fall-back" to = TCP, UDP, etc. While I understand where this is coming from, I'm = wondering from a larger perspective if this is the right framing. As the = document reads now, there's this underlying normative assumption that = "TCP and UDP are less preferred" and MPTCP or SCTP etc is preferred over = them. This may be true for some systems, but maybe not always. The set = of transports that a TAPS system may eventually use hopefully won't be = just limited to the set in the survey, but include things like QUIC, = etc. And depending on the scenario, maybe we prefer something over TCP, = and then fall-back to some other less preferred mode. Or, the = application may not allow falling back at all, but simply wants to reuse = its transport code that uses a TAPS API between different protocols it = uses for different, mutually exclusive scenarios.
So, I would be tempted to change the = first two requirements from:

   1.  Support one-sided =
deployment with a fall-back to TCP (or UDP)
  =
 2.  Offer all the transport features of (MP)TCP, UDP(-Lite), =
LEDBAT
       and SCTP that =
require application-specific knowledge

To:

   1.  Support basic =
functionality required for all transports (the 
	minimal =
set for TCP and UDP)
   2.  Offer =
all extended transport features that require application-
	=
specific knowledge (such as options for (MP)TCP, UDP(-Lite), =
LEDBAT
    =
   and SCTP)

Then, for =
each feature listed, you have essentially this format:

   o  [Feature name]
      Protocols: SCTP
      [Description]
      Fall-back to TCP: [do nothing/not supported]
      Fall-back to UDP: [do nothing/not supported]

How about = something like:

   o  [Feature name]
      Supported by: SCTP
      Ignored by: TCP
      Incompatible with: =
UDP
      [Description]

This way, we list how each =
protocol will treat it, but we're not making normative preferential =
statements, and we're not relying on the notion of falling back. I think =
"falling back" is something that belongs in documents around happy =
eyeballs and racing, etc, and baking in which protocol is a =
fallback and which is the primary may be quite misleading to =
implementers.

Thoughts?

Best,
Tommy


On Oct 23, 2017, at 4:38 PM, = Michael Welzl <michawe@ifi.uio.no> wrote:

Hi = everyone,

This update addresses 2 out of 3 = major comments that we got at the last meeting:

1) also fall-back to UDP  =3D> done.  This = turned out to be much easier than I thought because the set of transport = features for which TCP is a possible fall-back is, with *one* exception = (receiving a message) strictly a superset of transport features for = which UDP is a possible fall-back.   Sorry for the clumsy = sentence but the point is, TCP itself is of course *not* strictly a = superset of UDP itself, but that doesn=E2=80=99t matter.  Anyway, = because of this superset relationship, we were able to just mark = limitations that arise when requiring to fall back to UDP with = (!UDP).

2) make it clearer that the = abstract interface description of the min set is *not* an API proposal = =3D> done. I hope this is now clear enough for folks.
3) make it less TCP-specific, also consider fall-back to = e.g. TLS =3D> not done. Maybe next time?

Thanks for the very useful feedback, everyone who was there = last time!

Also, there are now = considerations on how to begin. With the minset as it was, it is = possible for TAPS to choose UDP as a protocol and for the application to = later request reliability. At least such deadlocks must be prevented - = I=E2=80=99m not claiming that what we put in there is generally ideal = (in fact the text explains why it isn=E2=80=99t), but it is one possible = approach that avoids such deadlocks.


Chairs: I=E2=80=99d like to request a 20-minute slot for this = update, if possible  (I think this should be enough including = discussions, as my presentation would probably fit in about 10 = minutes).

Cheers,
Michael



On Oct 23, 2017, at 1:43 AM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work = item of the Transport Services WG of the IETF.

      Title =           : A Minimal = Set of Transport Services for TAPS Systems
=       Authors =         : Michael Welzl
=             &n= bsp;           Stei= n Gjessing
Filename =        : = draft-ietf-taps-minset-00.txt
Pages =           : 53
= Date =            : = 2017-10-22

Abstract:
=  This draft recommends a minimal set of IETF Transport Services
 offered by end systems supporting TAPS, and gives = guidance on
 choosing among the available mechanisms = and protocols.  It is based
 on the set of = transport features given in the TAPS document draft-
=  ietf-taps-transports-usage-08.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-minset/
There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-taps-minset-00https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-00=


Please note that it may = take a couple of minutes from the time of submission
until = the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_qHrzD+79HyBacvu/S/LTpg)-- From nobody Mon Nov 13 16:36:23 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7089C1242F5 for ; Mon, 13 Nov 2017 16:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 xRq27YqE-exC for ; Mon, 13 Nov 2017 16:36:20 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 3A7841200CF for ; Mon, 13 Nov 2017 16:36:20 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id n134so8007326itg.1 for ; Mon, 13 Nov 2017 16:36:20 -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=IOg0QS1BJ2Lxb323LN/nskxrtW+zUgQAYhwXjln3tdo=; b=HDnHQiKe9dybbaA39iAXkXE/iBtsjoHIP4ltcR1CNRRVychYTKYp5yWcX5wRIVMmyj H970usd1bW1ZSWKSuVbP6b1q8gCo98G4BJqWO9Mo1h4YaJBq/+Omy2o28K5KMlTP7QZ/ +avHloBoCnV1HxLPW4GjhKm0HmTRtHRJKKPeeUIKYmnVT1Te7K/uiQ6KcXR6WGvPLJwa kd2gLIJalmJHjeMbUSXh7P7O4w4cfwGomDZmlGZO38zKl0kGQ5BKGa89t8nTptCgX41J KSxtHAgKA8aCGEt0fYZ2mKKNkg7LY9iFlF3KL4uWGEcS4TtyMmCbfKN4nQ1mpg7n1Wx3 8SZg== 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=IOg0QS1BJ2Lxb323LN/nskxrtW+zUgQAYhwXjln3tdo=; b=iSPHYseuJsRmwPmPiDRW94J7BrvKWLhAgWiHBE0Y8CX8n8lGjVof59CL/eE8r2kzpX cLPac23P6FOI4VE7N/cgzhD15agBmJSk2vEu9n2NWu1s8zdn6+Ec9EZfD5a21RXeeYST LKVU+LfRsWh7og1hD7tEvirjiC/fEiN3TxjYCVqfYoxVnFWFjmIsbK1H12N/U6/5NSiV HyrfgwZjvrmnsEvyBRKLYvFtr2yOB4X/Il2D/8jys9VpEAC+7VA2m/ORgxW69a+SHPjB RRE3KdeKVSZcXOECHJNySu0vujlg703BRBQlhj4HU6EkRKz8xE0/aC7XG1COBVE1dkAJ gRNw== X-Gm-Message-State: AJaThX6RF+FxzYa0pUOb7iz5HTowdR+rVCeUuRu6hBmplerdDGuu4Vuo YlvCVGgo5m9YY+ZfHD/Onaw1Tzq2oYctSM/MI20= X-Google-Smtp-Source: AGs4zMbjq+qeMnR8Rj3A7WQIwa1as+w2hDx9lGqCf3B7/m8ekW4kix5TUdS6rzCVWPQ9JtuTQBNA6qVdcGQNhaVm5t4= X-Received: by 10.36.182.2 with SMTP id g2mr13395938itf.72.1510619779388; Mon, 13 Nov 2017 16:36:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.33.202 with HTTP; Mon, 13 Nov 2017 16:36:18 -0800 (PST) In-Reply-To: References: <150871580801.24896.1276317669567869148@ietfa.amsl.com> <7403AB1A-33FC-461A-B88F-B8DB8FC08881@ifi.uio.no> From: Christopher Wood Date: Tue, 14 Nov 2017 08:36:18 +0800 Message-ID: To: Tommy Pauly Cc: Michael Welzl , "taps@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-minset-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:36:21 -0000 On Tue, Nov 14, 2017 at 8:20 AM, Tommy Pauly wrote: > TLS: > > We can discuss in the group, but I think that security can stay a separat= e > document for now. You wouldn't "fall back" to TLS=E2=80=94TLS is just som= ething you > can use underneath the TAPS API, and you either have security or you don'= t. > That shouldn't be changing underneath you. Agreed. Encryption is a property of the connection and the TAPS API must enable it. If configured, it must always be used, regardless of how connection establishment is done. Best, Chris From nobody Mon Nov 13 17:08:13 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254591205F0 for ; Mon, 13 Nov 2017 17:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 g3o17BPommFx for ; Mon, 13 Nov 2017 17:08:08 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 0B143126579 for ; Mon, 13 Nov 2017 17:08:08 -0800 (PST) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eEPhu-0002xc-E8 for taps@ietf.org; Tue, 14 Nov 2017 02:08:06 +0100 Received: from dhcp-9539.meeting.ietf.org ([31.133.149.57]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eEPhs-0001EO-A9; Tue, 14 Nov 2017 02:08:06 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DE2F7D5E-B1DC-42F1-9FDE-BD5A713561C1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 09:08:02 +0800 In-Reply-To: Cc: "taps@ietf.org" To: Tommy Pauly References: <150871580801.24896.1276317669567869148@ietfa.amsl.com> <7403AB1A-33FC-461A-B88F-B8DB8FC08881@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 31.133.149.57 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.149.57; envelope-from=michawe@ifi.uio.no; helo=dhcp-9539.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.141, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0A8B5700BF843A4C5D8D3CDB211B28B238C941CB Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-minset-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:08:11 -0000 --Apple-Mail=_DE2F7D5E-B1DC-42F1-9FDE-BD5A713561C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, In line: > On Nov 14, 2017, at 8:20 AM, Tommy Pauly wrote: >=20 > A couple initial comments on the minset document: >=20 > In Section 4: >=20 > - Title should be "4. A MinSet Abstract Interface" not "4. An MinSet = Abstract Interface=E2=80=9D Ack, > For this: >=20 > 3. Not offer any of the transport features of these protocols and > the LEDBAT congestion control mechanism that do not require > application-specific knowledge (to give maximum flexibility to = a > TAPS system) >=20 > Could this be written as "that can be performed automatically" or = something, rather than "do not require application-specific knowledge"? = It ends up having a lot of negatives that get confusing. Agreed, > I'd like to see the reference removed to Post Sockets indicating that = it would require any protocol changes or the system on both ends. As = discussed on the other thread, Post does not require any changes to the = peer for compatibility. Absolutely! No problem > TLS: >=20 > We can discuss in the group, but I think that security can stay a = separate document for now. You wouldn't "fall back" to TLS=E2=80=94TLS = is just something you can use underneath the TAPS API, and you either = have security or you don't. That shouldn't be changing underneath you. Agreed, > General: >=20 > Much of the document is phrased in terms of "fall-back" to TCP, UDP, = etc. While I understand where this is coming from, I'm wondering from a = larger perspective if this is the right framing. As the document reads = now, there's this underlying normative assumption that "TCP and UDP are = less preferred" and MPTCP or SCTP etc is preferred over them. This may = be true for some systems, but maybe not always. The set of transports = that a TAPS system may eventually use hopefully won't be just limited to = the set in the survey, but include things like QUIC, etc. And depending = on the scenario, maybe we prefer something over TCP, and then fall-back = to some other less preferred mode. Or, the application may not allow = falling back at all, but simply wants to reuse its transport code that = uses a TAPS API between different protocols it uses for different, = mutually exclusive scenarios. >=20 > So, I would be tempted to change the first two requirements from: >=20 > 1. Support one-sided deployment with a fall-back to TCP (or UDP) > 2. Offer all the transport features of (MP)TCP, UDP(-Lite), LEDBAT > and SCTP that require application-specific knowledge >=20 > To: >=20 > 1. Support basic functionality required for all transports (the=20 > minimal set for TCP and UDP) > 2. Offer all extended transport features that require application- > specific knowledge (such as options for (MP)TCP, UDP(-Lite), = LEDBAT > and SCTP) >=20 > Then, for each feature listed, you have essentially this format: >=20 > o [Feature name] > Protocols: SCTP > [Description] > Fall-back to TCP: [do nothing/not supported] > Fall-back to UDP: [do nothing/not supported] >=20 > How about something like: >=20 > o [Feature name] > Supported by: SCTP > Ignored by: TCP > Incompatible with: UDP > [Description] >=20 > This way, we list how each protocol will treat it, but we're not = making normative preferential statements, and we're not relying on the = notion of falling back. I think "falling back" is something that belongs = in documents around happy eyeballs and racing, etc, and baking in which = protocol is a fallback and which is the primary may be quite misleading = to implementers. I completely agree! That was easy :) Cheers, Michael --Apple-Mail=_DE2F7D5E-B1DC-42F1-9FDE-BD5A713561C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

In = line:


On = Nov 14, 2017, at 8:20 AM, Tommy Pauly <tpauly@apple.com> = wrote:

A couple initial = comments on the minset document:

In Section 4:

- Title should be "4.  A MinSet = Abstract Interface" not "4.  An MinSet = Abstract Interface=E2=80=9D

Ack,


For this:

3.  Not offer any of the =
transport features of these protocols and
       the LEDBAT congestion control mechanism that do not require
       application-specific knowledge (to give maximum flexibility to a
       TAPS system)

Could this be written as "that can be performed = automatically" or something, rather than "do not require = application-specific knowledge"? It ends up having a lot of negatives = that get confusing.

Agreed,


I'd like to see the = reference removed to Post Sockets indicating that it would require any = protocol changes or the system on both ends. As discussed on the other = thread, Post does not require any changes to the peer for = compatibility.

Absolutely! No problem


TLS:

We can discuss in the group, but I think that security can = stay a separate document for now. You wouldn't "fall back" to TLS=E2=80=94= TLS is just something you can use underneath the TAPS API, and you = either have security or you don't. That shouldn't be changing underneath = you.

Agreed,


General:

Much of the document is = phrased in terms of "fall-back" to TCP, UDP, etc. While I understand = where this is coming from, I'm wondering from a larger perspective if = this is the right framing. As the document reads now, there's this = underlying normative assumption that "TCP and UDP are less preferred" = and MPTCP or SCTP etc is preferred over them. This may be true for some = systems, but maybe not always. The set of transports that a TAPS system = may eventually use hopefully won't be just limited to the set in the = survey, but include things like QUIC, etc. And depending on the = scenario, maybe we prefer something over TCP, and then fall-back to some = other less preferred mode. Or, the application may not allow falling = back at all, but simply wants to reuse its transport code that uses a = TAPS API between different protocols it uses for different, mutually = exclusive scenarios.

So, I would be tempted to change the first two requirements = from:

   1.  Support one-sided =
deployment with a fall-back to TCP (or UDP)
  =
 2.  Offer all the transport features of (MP)TCP, UDP(-Lite), =
LEDBAT
       and SCTP that =
require application-specific knowledge

To:

   1.  Support basic =
functionality required for all transports (the 
	minimal =
set for TCP and UDP)
   2.  Offer =
all extended transport features that require application-
	=
specific knowledge (such as options for (MP)TCP, UDP(-Lite), =
LEDBAT
    =
   and SCTP)

Then, for =
each feature listed, you have essentially this format:

   o  [Feature name]
      Protocols: SCTP
      [Description]
      Fall-back to TCP: [do nothing/not supported]
      Fall-back to UDP: [do nothing/not supported]

How about = something like:

   o  [Feature name]
      Supported by: SCTP
      Ignored by: TCP
      Incompatible with: =
UDP
      [Description]

This way, we list how each =
protocol will treat it, but we're not making normative preferential =
statements, and we're not relying on the notion of falling back. I think =
"falling back" is something that belongs in documents around happy =
eyeballs and racing, etc, and baking in which protocol is a =
fallback and which is the primary may be quite misleading to =
implementers.

I completely agree!

That was easy  :)

Cheers,
Michael

= --Apple-Mail=_DE2F7D5E-B1DC-42F1-9FDE-BD5A713561C1--