From nobody Tue Aug 1 00:33:53 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830E3132A17 for ; Tue, 1 Aug 2017 00:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-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=jisc.ac.uk 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 vwP5mAnm4xVV for ; Tue, 1 Aug 2017 00:33:49 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E81132A1A for ; Tue, 1 Aug 2017 00:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1501572824; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=1qDTyH9wYLuo7faI2ICs9UpAGiegCzxf81/zOgzkws0=; b=Vn/wUM6GpDXiLtrdGP4OnhpCByPuvuGLMGLjvNEVi4UW5XwIKEJ1e5zAmGNMkzIURcbkY03XkzuCtqf4R9kQ70x3XaU0ckgxZfPDlN8NwxqtYIa1DVnjFOIFJe6JAInAxk0SEsP9ZxHN6rNMXC8k69HmbE1qDOUkhy/RgPEryUo= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0152.outbound.protection.outlook.com [213.199.180.152]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-24-RGhAfRf9OEGM0XFN7NlpQQ-1; Tue, 01 Aug 2017 08:33:40 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB260.eurprd07.prod.outlook.com (10.242.17.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Tue, 1 Aug 2017 07:33:39 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.010; Tue, 1 Aug 2017 07:33:38 +0000 From: Tim Chown To: Brian E Carpenter CC: Fred Baker , "Ruediger.Geib@telekom.de" , "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "roland.bless@kit.edu" Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS92Kl1ri+DvfXuU2Ope9bkqrAk6JIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQgAA8IACAADlBgIAAuqQA Date: Tue, 1 Aug 2017 07:33:38 +0000 Message-ID: References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> In-Reply-To: <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:3d25:de87:64aa:5fc9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB260; 20:apYtCT7QTXjblNGeYoup4epXuQZ3/yU2RHN5EszCsZhf8S6T3hB2mK01wI3rRzZuBLxlZPznFHmuRmfANyx7GTqZ7vCj3sS6cXrCj1mp4IeNdI0qZ2Vm7IB+4UgbNZeno0p9Vvf6Mfjhb13v6orxsiJtVXke7ycA6mzC1jo7IVA= x-ms-office365-filtering-correlation-id: 7813c08e-e791-4bb5-d0c4-08d4d8afa07d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB260; x-ms-traffictypediagnostic: AM3PR07MB260: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB260; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB260; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39400400002)(39840400002)(377454003)(24454002)(199003)(189002)(81166006)(3660700001)(81156014)(8676002)(36756003)(8936002)(50226002)(6306002)(54906002)(5250100002)(99286003)(33656002)(6512007)(53936002)(305945005)(7736002)(6436002)(6916009)(42882006)(2950100002)(53546010)(6486002)(6116002)(102836003)(2900100001)(229853002)(86362001)(105586002)(106356001)(6246003)(6506006)(74482002)(14454004)(82746002)(5660300001)(57306001)(72206003)(25786009)(3280700002)(93886004)(2906002)(97736004)(189998001)(68736007)(39060400002)(50986999)(110136004)(76176999)(38730400002)(478600001)(4326008)(83716003)(101416001)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB260; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2017 07:33:38.9090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB260 X-MC-Unique: RGhAfRf9OEGM0XFN7NlpQQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 07:33:51 -0000 PiBPbiAzMSBKdWwgMjAxNywgYXQgMjE6MjUsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMDEvMDgvMjAxNyAwNTowMCwgRnJl ZCBCYWtlciB3cm90ZToNCj4+IA0KPj4+IE9uIEp1bCAzMSwgMjAxNywgYXQgNjozNCBBTSwgUnVl ZGlnZXIuR2VpYkB0ZWxla29tLmRlIHdyb3RlOg0KPj4+IA0KPj4+IERTQ1AgMDAwMDAxIG1pZ2h0 IGJlIGFuIG9wdGlvbi4gTm8gb3RoZXIgSUVURiByZWNvbW1lbmRlZCBEU0NQIGlzIHJlLW1hcmtl ZCB0byB0aGlzIG9uZS4gSXQgaXMgdG8gc29tZSBleHRlbnQgUkZDNDU5NCBjb21wYXRpYmxlIGFu ZCBSRkM4MTAwIGNvdWxkIGNvcGUgd2l0aCBpdCBpZiBkZWZhdWx0IHRyYW5zcG9ydCBpcyBhcHBs aWVkLiANCj4+IA0KPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzI0NzQjc2VjdGlv bi02IGluZGljYXRlcyB0aGF0IDAwMDAwMSBpcyBleHBlcmltZW50YWwvbG9jYWwgdXNlLCBhdmFp bGFibGUgZm9yIHN0YW5kYXJkcyBhbGxvY2F0aW9uIG9ubHkgYXMgbmVjZXNzYXJ5LiANCj4gDQo+ ICJXZSBSRUNPTU1FTkQgdGhhdCB0aGUgRFNDUCB2YWx1ZShzKSBvZiB0aGUNCj4gdW5zdXBwb3J0 ZWQgc2VydmljZSBjbGFzcyBiZSBjaGFuZ2VkIHRvIDAwMHh4MSBvbiBpbmdyZXNzIGFuZA0KPiBj aGFuZ2VkIGJhY2sgdG8gb3JpZ2luYWwgdmFsdWUocykgb24gZWdyZXNzLi4uIg0KPiANCj4gVGhh dCBpcyBhIGxvY2FsIHVzZSB3aXRoaW4gYSBkb21haW4sIGNvbXBsZXRlbHkgY29tcGF0aWJsZSB3 aXRoIGJvdGgNCj4gcG9vbHMgMiBhbmQgMyB3aGljaCBhcmUgYm90aCBkZWZpbmVkIGFzIGZvciBs b2NhbCB1c2UuIFNvIDAwMDAwMQ0KPiBpcyByZWFsbHkgbm90IHN1aXRhYmxlIGZvciBzdGFuZGFy ZHMgdHJhY2sgcmVjb21tZW5kYXRpb24sIHVudGlsDQo+IHBvb2wgMSBpcyBmdWxsLg0KPiANCj4+ IFBvb2wgMSBpcyAzMiBjb2RlIHBvaW50cywgb2Ygd2hpY2ggSSBiZWxpZXZlIDIwIGFyZSBpbiB1 c2UgKGZpZ3VyZSAzIG9mIFJGQyA0NTk0KS4gSSdkIHJhdGhlciBub3QgZGlwIGludG8gcG9vbCAz IHVubmVjZXNzYXJpbHkuIElzIHRoZXJlIGFub3RoZXIgb3B0aW9uPw0KPiANCj4gMDAwMDEwIGlz IGp1c3QgZmluZS4gV2h5IGFyZSB3ZSBzdGlsbCBkaXNjdXNzaW5nIHRoaXM/DQoNClRoZSBjb25j ZXJuIGV4cHJlc3NlZCBpbiBQcmFndWUgd2FzIHRoYXQgYSBudW1iZXIgb2YgYXNzaWduZWQgY29k ZSBwb2ludHMgbWF5IGdldCBibGVhY2hlZCB0byAyLiBBbmQgdGhhdCBzdWNoIGJsZWFjaGluZyBp cyBjb21tb24gZW5vdWdoIHRoYXQgaXQgd291bGQgbmV2ZXIgYmUgZXJhZGljYXRlZC4NCg0KU2Vl IHNsaWRlIDQgb2YgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk5L21hdGVy aWFscy9zbGlkZXMtOTktdHN2d2ctc2Vzc2ItMzFtZWFzdXJlbWVudHMtY29uY2VybmluZy10aGUt ZHNjcC1mb3ItYS1sZS1waGINCg0KTm90IHNheWluZyBJIGFncmVlIHdpdGggdGhhdCwgYnV0IHRo YXTigJlzIHdoeSB3ZSBhcmUgc3RpbGwgZGlzY3Vzc2luZyBpdC4NCg0KVGlt From nobody Tue Aug 1 01:22:27 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86F132B97 for ; Tue, 1 Aug 2017 01:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 Jd_KU0uHo-JA for ; Tue, 1 Aug 2017 01:22:24 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 64581127978 for ; Tue, 1 Aug 2017 01:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1501575743; x=1533111743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fLEpDXbAsJefvpUwgY4/mThkos3ph1PaIdaaKOVIeUo=; b=LTekYCksyCd2N8EXXNV9t2JkPkq/y0NaTNFDVzxMZBpdQpMMhq66dOYt haazXEwChwRVaJU7W4gLqtBUfbNpd1Se8v8NT/M5jEYSzQ87EwBLQMtQg aPciLUw3hkyl5xaEYT9ytVZ3uNtpgBAWd3Yt59vdyJAhW6bnzMnVldNAh 6OKN3qyREB1K2TIkIlVlxHJNZEB5NFEt5HxpwlMby0y41/SGs7PHft2p8 gxKSSTX0OFtbWtP8gPpzMus/klOVo0CKzx/rsCZ1iRaqnOUFO1KXoH0vM TVdPoYrr7HxLaTVwaJHTbRrA1jT0Y1m+ozbNJljpqS8VggrmFfJTU2fR8 g==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2017 10:22:19 +0200 X-IronPort-AV: E=Sophos;i="5.41,305,1498514400"; d="scan'208";a="710079479" Received: from he105655.emea1.cds.t-internal.com ([10.169.118.87]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 01 Aug 2017 10:22:18 +0200 Received: from HE105654.EMEA1.cds.t-internal.com (10.169.118.86) by HE105655.emea1.cds.t-internal.com (10.169.118.87) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 1 Aug 2017 10:22:18 +0200 Received: from HE105654.EMEA1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6]) by HE105654.emea1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6%26]) with mapi id 15.00.1263.000; Tue, 1 Aug 2017 10:22:17 +0200 From: To: CC: , , , , Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS9w2o4prCs8a2Uk2hjK9vt7Sn6aJIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQgAAbQwCAADlBgIAAr3OAgAAl4JA= Date: Tue, 1 Aug 2017 08:22:17 +0000 Message-ID: References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> In-Reply-To: <5980256F.7060100@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.160.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 08:22:26 -0000 R29ycnksIA0KDQpTb21lIG5ldyBjb21tZW50cyBhdCB0aGUgZW5kLg0KDQpSdWVkaWdlcg0KUkc+ ICBEU0NQIDAwMDAwMSBtaWdodCBiZSBhbiBvcHRpb24uIE5vIG90aGVyIElFVEYgcmVjb21tZW5k ZWQgRFNDUCANCmlzIHJlLW1hcmtlZCB0byB0aGlzIG9uZS4gSXQgaXMgdG8gc29tZSBleHRlbnQg UkZDNDU5NCBjb21wYXRpYmxlIGFuZCANClJGQzgxMDAgY291bGQgY29wZSB3aXRoIGl0IGlmIGRl ZmF1bHQgdHJhbnNwb3J0IGlzIGFwcGxpZWQuDQoNCkZyZWQNCkZCPiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMjQ3NCNzZWN0aW9uLTYgaW5kaWNhdGVzIHRoYXQgMDAwMDAxIA0KaXMg ZXhwZXJpbWVudGFsL2xvY2FsIHVzZSwgYXZhaWxhYmxlIGZvciBzdGFuZGFyZHMgYWxsb2NhdGlv biBvbmx5IGFzIG5lY2Vzc2FyeS4NCjQ1OTc+ICJXZSBSRUNPTU1FTkQgdGhhdCB0aGUgRFNDUCB2 YWx1ZShzKSBvZiB0aGUgdW5zdXBwb3J0ZWQgc2VydmljZSBjbGFzcyANCjQ1OTc+IGJlIGNoYW5n ZWQgdG8gMDAweHgxIG9uIGluZ3Jlc3MgYW5kIGNoYW5nZWQgYmFjayB0byBvcmlnaW5hbCB2YWx1 ZShzKSANCjQ1OTc+IG9uIGVncmVzcy4uLiINCg0KQnJpYW4NCkJDID4gVGhhdCBpcyBhIGxvY2Fs IHVzZSB3aXRoaW4gYSBkb21haW4sIGNvbXBsZXRlbHkgY29tcGF0aWJsZSB3aXRoIGJvdGggDQpC QyA+IHBvb2xzIDIgYW5kIDMgd2hpY2ggYXJlIGJvdGggZGVmaW5lZCBhcyBmb3IgbG9jYWwgdXNl LiBTbyAwMDAwMDEgaXMgDQpCQyA+IHJlYWxseSBub3Qgc3VpdGFibGUgZm9yIHN0YW5kYXJkcyB0 cmFjayByZWNvbW1lbmRhdGlvbiwgdW50aWwgcG9vbCAxIA0KQkMgPiBpcyBmdWxsLg0KLi4uLg0K QkM+IDAwMDAxMCBpcyBqdXN0IGZpbmUuIFdoeSBhcmUgd2Ugc3RpbGwgZGlzY3Vzc2luZyB0aGlz Pw0KDQpHb3JyeQ0KR0Y+Li4uLnRoZXJlIGlzIHJlYXNvbmFibGUgZG91YnQgdGhhdCBhIExFIHNl cnZpY2UgY2FuIGJlIHNhZmVseSBkZXBsb3llZA0KYWNyb3NzIHRoZSBJbnRlcm5ldCB1c2luZyBh IGNvZGVwb2ludCBvZiAwMDAwMTAuDQoNCkdGPiBUaGVyZSBzZWVtcyBldmlkZW5jZSB0aGF0IHRo ZXJlIGFyZSBzdGlsbCBldmVuIG5vdyBkZXBsb3llZCByb3V0ZXJzIA0KdGhhdCBoYXZlIG5vdCBh ZGp1c3RlZCB0aGVpciByZW1hcmtpbmcgYmVoYXZpb3VyIGFmdGVyIHRoZSBJRVRGIA0KZGVwcmVj YXRlZCBUb1MgUHJlY2VkZW5jZSBibGVhY2hpbmcuIA0KDQpbUkcyXSBUcnVlLiBJIHByZWZlciBh IGNvcmUtcm91dGVyIHRvIGJlIGFibGUgdG8gcmUtbWFyayBEU0NQcyBieSBiaXQtbWFzayBhdCAg DQppbnRlcmNvbm5lY3Rpb24gaW50ZXJmYWNlcyByYXRoZXIgdGhhbiBEU0NQIGJ5IERTQ1AuIFRo ZSBjb25maWcgZWZmb3J0IHRvIGN1c3RvbWl6ZSANCnJlLW1hcmtpbmcgb24gYSBEU0NQIGJ5IERT Q1AgYmFzaXMgaXMgaGlnaC4gQW4gZWFzeSB0byBjb25maWd1cmUgYWx0ZXJuYXRpdmUgaXMgdG8g Y2xhc3NpZnkgDQpieSBiaXQtbWFzayBhbmQgcmUtbWFyayB0byBhIHNpbmdsZSBEU0NQLiBHb3Jy eSwgZG8geW91IGhhdmUgYW55IHByZWZlcmVuY2UgaGVyZT8NCg0KR0Y+Li4uLkEgcGFja2V0IHRo YXQgdXNlcyBBRiBtYXJraW5nIGFuZCBlbmNvdW50ZXJzIFRvUyBQcmVjZWRlbmNlIGJsZWFjaGlu ZyANCndvdWxkIGV4cGVyZWluY2UgQUYxMSwgQUYyMSwgQUYzMSwgQUY0MSBlbWVyZ2luZyByZW1h cmtlZCB0byBhIGNvZGVwb2ludCANCm9mIDAwMDAxMCwgYW5kIEFGMTIsIEFGMjIsIEFGMzIsIEFG NDIsIFZBIHdvdWxkIGVtZXJnZSBhcyAwMDAxMDAsIGV0Yy4NCg0KR0Y+IEJlY2F1c2UgdGhlIExF IFBIQiBpcyBhIGxvd2VyIGVmZm9ydCBQSEIsIGltcGxlbWVudGluZyBhIFBIQiB3aXRoIGEgY29k ZXBvaW50IA0Kb2YgMDAwMDEwIHdvdWxkIHJlc3VsdCBpbiBzb21lIHRyYWZmaWMgb3JpZ2luYWxs eSBtYXJrZWQgYXMgQUZ4MSBiZWluZyBhc3NpZ25lZCBhIA0KbG93ZXIgZWZmb3J0IHRoYW4gQUZ4 MSBvciBBRngyLiANCg0KW1JHMl0gVGhhdCdzIGEgcmVhc29uYWJsZSBhbmFseXNpcy4gQSBuZXR3 b3JrIHNlbmRpbmcgdmFyaW91cyBEU0NQIGludG8gbXkgZG9tYWluIA0Kd2l0aG91dCBpbmZvcm1p bmcgbXkgTk9DIG9yIHNldHRpbmcgdXAgYW4gU0xBIGlzIG5vdCBjb25zZXJ2YXRpdmUgd2l0aCB3 aGF0IGl0IHNlbmRzIA0KaW4gbXkgZXllcy4gSWYgcmVjZWl2aW5nIG5ldHdvcmtzIGFyZSBleHBl Y3RlZCB0byBiZSBzdXBwb3J0aXZlIHJhdGhlciB0aGFuIGxpYmVyYWwgb25seSANCmluIHRoYXQg Y2FzZSBhbmQgYXJlIGV4cGVjdGVkIHRvIG1haW50YWluIHRoZSBvcmlnaW5hbCBEaWZmc2VydiBj b2Rpbmcgc2Vuc2Ugb2YgYSANCm5vbi1jb29wZXJhdGl2ZSBzZW5kZXIsIGFzIGRlc2NyaWJlZCBi eSBHb3JyeSwgSSB0aGluayBEU0NQIDAwMDAwMSBmb3IgTEUgaXMgYSBnb29kIA0KY2hvaWNlLiBU aGF0IGFsbG93cyB0byBtYWludGFpbiBiaXQtbWFzayBiYXNlZCByZS1tYXJraW5nIHdoaWxlIG1h aW50YWluaW5nIHRoZSBvcmlnaW5hbCANCkRpZmZzZXJ2IGludGVudCBvZiBub24tY29vcGVyYXRp dmUgbmV0d29ya3MsIHNvIEkgaWdub3JlZCB0aGUgcG9vbHMuIA0KDQpSZWdhcmRzLCBSdWVkaWdl cg0KDQo= From nobody Tue Aug 1 01:52:43 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53456132C3E for ; Tue, 1 Aug 2017 01:52:41 -0700 (PDT) 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] 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 Yzhq7NXNRt_Z for ; Tue, 1 Aug 2017 01:52:39 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 589631328D8 for ; Tue, 1 Aug 2017 01:52:39 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dcSuq-0007Kt-CI; Tue, 01 Aug 2017 10:52:36 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 4F54CB00955; Tue, 1 Aug 2017 10:52:36 +0200 (CEST) To: Ruediger.Geib@telekom.de, gorry@erg.abdn.ac.uk Cc: tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Tue, 1 Aug 2017 10:52:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1501577556.435254835 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 08:52:41 -0000 Hi, Am 01.08.2017 um 10:22 schrieb Ruediger.Geib@telekom.de:> GF> There seems evidence that there are still even now deployed routers > that have not adjusted their remarking behaviour after the IETF > deprecated ToS Precedence bleaching. > > [RG2] True. I prefer a core-router to be able to re-mark DSCPs by bit-mask at > interconnection interfaces rather than DSCP by DSCP. The config effort to customize > re-marking on a DSCP by DSCP basis is high. An easy to configure alternative is to classify > by bit-mask and re-mark to a single DSCP. Gorry, do you have any preference here? Hmm, RFC2474 states that the DSCP is unstructured: "The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. With some exceptions noted below, the mapping of codepoints to PHBs MUST be configurable. A DS-compliant node MUST support the logical equivalent of a configurable mapping table from codepoints to PHBs" IMHO it shouldn't be difficult to have a mapping table from each DSCP to a PHB. The mapping table should initially only contain mappings to the default PHB (no need to remark anything then). Configuring DSCP remarking by using bitmasks is IMHO not RFC2474 compliant and a broken concept causing the trouble we just ran into. Regards, Roland From nobody Tue Aug 1 02:49:19 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A98132CC3 for ; Tue, 1 Aug 2017 02:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 Zmuy78EStcLi for ; Tue, 1 Aug 2017 02:49:17 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [80.149.113.196]) (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 8B3FA132035 for ; Tue, 1 Aug 2017 02:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1501580956; x=1533116956; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=neoVBym4ETRcilGJusMnd5CoaK/T4gGObBasRak/Dys=; b=CRfFy7s5XY+JN4QETmDmCpB3SxS8vo1vhs/ER/OkEdZ/dqsiD2M2mbpM EEniqRgMk0zX5BY8JTrcQH+2uq6LF+xKvx8nuY+a4VtOtCNyxcmqhMlUg K/YaRiTNNT/eZFx7MOBHcrzHZPt+hAqEtUjFIjxhGRxl2rrH4rjkk3zNx +vaX4dOSPjqE5zU5pvvFGOGGyEAy3kQOFOvo1RA6CMGgCII6KOrWS60JA cfO1vEMBGqJHcwkzilKB+2vGVE16L3EP81kF19ag9GMNYiZOnWRBt4Gp3 f6MzyNvUv6qndFSI0wd9MWqhuS8LeuljubFcusjuERmcPGqilAsjx3Cm1 Q==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT31.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2017 11:49:12 +0200 X-IronPort-AV: E=Sophos;i="5.41,305,1498514400"; d="scan'208";a="1361821415" Received: from he105655.emea1.cds.t-internal.com ([10.169.118.87]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 01 Aug 2017 11:49:12 +0200 Received: from HE105654.EMEA1.cds.t-internal.com (10.169.118.86) by HE105655.emea1.cds.t-internal.com (10.169.118.87) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 1 Aug 2017 11:49:12 +0200 Received: from HE105654.EMEA1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6]) by HE105654.emea1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6%26]) with mapi id 15.00.1263.000; Tue, 1 Aug 2017 11:49:12 +0200 From: To: CC: , Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS9w2o4prCs8a2Uk2hjK9vt7Sn6aJIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQgAAbQwCAADlBgIAAr3OAgAAl4JD///thAIAAI+UQ Date: Tue, 1 Aug 2017 09:49:11 +0000 Message-ID: References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.160.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 09:49:19 -0000 SGkgUm9sYW5kLA0KDQpBRiBjbGFzc2VzIGFyZSBzdHJ1Y3R1cmVkIHNldHMgb2YgRFNDUC4gVGhl aXIgZGVmaW5pdGlvbiBzdGFydHMgd2l0aCBhIGJpdC1tYXNrIGJhc2VkIG9uIERTQ1AgYml0cyAw LTIsIHJlc3VsdGluZyBpbiBBRm54IG5vdGF0aW9uLiBUaGlzIG5vdGF0aW9uIGFsc28gY29ycmVz cG9uZHMgdG8gQ1NuIGRlZmluaXRpb25zLCByZXN1bHRpbmcgaW4gdXAgdG8gNCBzdGFuZGFyZCBE U0NQcyBzaGFyaW5nIHRoZSBzYW1lIGJpdHMgMC0yLiANCg0KVG8gY29uZmlndXJlIHJlLW1hcmtp bmcgb2YgYW4gQUYgY2xhc3Mgb3Igb2YgZWlnaHQgRFNDUHMgSSBuZWVkIF9wZXIgRFNDUF8gOg0K DQotIGEgY2xhc3MgZGVmaW5pdGlvbg0KLSBhbiBhc3NpZ25tZW50IG9mIGEgcmVjZWl2ZWQgRFND UCB0byBhIGNsYXNzDQotIGEgcmUtbWFyayBvcmRlciBvZiB0aGUgY2xhc3MgdG8gbXkgaW50ZXJu YWwgRFNDUA0KDQpJZiBhIHByb3ZpZGVyIG9wZXJhdGVzIE1QTFMsIHRoZSBudW1iZXIgb2YgVHJl YXRtZW50IEFnZ3JlZ2F0ZXMvUEhCcyBvZmZlcmVkIGF0IGludGVyY29ubmVjdGlvbiBpcyBvZnRl biAzIG9yIDQuIFRoZSBvcHRpb25zIHRoYXQgSSBhbSBhd2FyZSBvZiBhcmU6DQotIGEgYml0LW1h c2sgYmFzZWQgcmUtbWFyayBhbGxvd3MgdG8gdHJhbnNwb3J0IGFuZCBtYWludGFpbiB1cCB0byA4 IERTQ1AgYnkgYSAiMyBsaW5lIGNvbmZpZ3VyYXRpb24iDQotIGEgRFNDUCBiYXNlZCByZS1tYXJr IGNvbWJpbmVkIHdpdGggYSBiaXQtbWFzayBiYXNlZCBjbGFzc2lmaWNhdGlvbiBhbGxvd3MgdG8g dHJhbnNwb3J0IHVwIHRvIG4gDQogICBEU0NQIGJ5IGEgIjMgbGluZSBjb25maWd1cmF0aW9uIiBh bmQgdGhleSBhcmUgYWxsIHJlLW1hcmtlZCB0byBhIHNpbmdsZSBEU0NQLg0KLSBhIERTQ1AgYmFz ZWQgcmUtbWFyayBhaW1pbmcgb24gbWFpbnRhaW5pbmcgZGlmZmVyZW50IHJlcXVpcmVzICJuKjMg bGluZXMgb2YgY29uZmlndXJhdGlvbiIgZm9yIG4gRFNDUC4NCi0gVGhlcmUncyBubyBiaW5kaW5n IHN0YW5kYXJkIG9uIERpZmZzZXJ2IGNsYXNzL2NvZGVwb2ludCBhc3NpZ25tZW50IGF0IGludGVy Y29ubmVjdGlvbi4gU2V0dGluZyB1cCANCiAgYSBwZXIgY2FycmllciBwZXIgRFNDUCB0byBEU0NQ IGFuZCBjbGFzcyBtYXBwaW5nIHNjaGVtZSBpcyByZXF1aXJpbmcgc29tZSBlZmZvcnQgKG5lZ290 aWF0aW9uLCANCiAgY29uZmlndXJhdGlvbiwgb3BlcmF0aW9uKS4gSSdtIHRyeWluZyB0byBhdm9p ZCB0aGF0Lg0KDQpUbyBtZSwgdHdvIGNob2ljZXMgdG8gbWFrZSBvcGVyYXRpb25hbCBzZW5zZToN Ci0gZWl0aGVyIGJpdC1tYXNrIGJhc2VkIERTQ1AgcmUtbWFyayB3aXRoIHVwIHRvIDggRFNDUCBw ZXIgTVBMUyBUcmVhdG1lbnQgQWdncmVnYXRlDQotIG9yIERTQ1AgYmFzZWQgcmUtbWFyayB3aXRo IGEgc2luZ2xlIERTQ1AgcGVyIE1QTFMgVHJlYXRtZW50IEFnZ3JlZ2F0ZS4NCg0KUmVnYXJkcywg DQoNClJ1ZWRpZ2VyDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9u OiBCbGVzcywgUm9sYW5kIChUTSkgW21haWx0bzpyb2xhbmQuYmxlc3NAa2l0LmVkdV0gDQpHZXNl bmRldDogRGllbnN0YWcsIDEuIEF1Z3VzdCAyMDE3IDEwOjUzDQpBbjogR2VpYiwgUsO8ZGlnZXIg PFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT47IGdvcnJ5QGVyZy5hYmRuLmFjLnVrDQpDYzogdHN2 d2dAaWV0Zi5vcmcNCkJldHJlZmY6IFJlOiBbdHN2d2ddIENPTU1FTlQgUExFQVNFOiBXaGljaCBE U0NQIHZhbHVlIHNob3VsZCB3ZSB1c2UgZm9yIExFIFBIQj8NCg0KSGksDQoNCkFtIDAxLjA4LjIw MTcgdW0gMTA6MjIgc2NocmllYiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGU6PiBHRj4gVGhlcmUg c2VlbXMgZXZpZGVuY2UgdGhhdCB0aGVyZSBhcmUgc3RpbGwgZXZlbiBub3cgZGVwbG95ZWQgcm91 dGVycw0KPiB0aGF0IGhhdmUgbm90IGFkanVzdGVkIHRoZWlyIHJlbWFya2luZyBiZWhhdmlvdXIg YWZ0ZXIgdGhlIElFVEYgDQo+IGRlcHJlY2F0ZWQgVG9TIFByZWNlZGVuY2UgYmxlYWNoaW5nLg0K PiANCj4gW1JHMl0gVHJ1ZS4gSSBwcmVmZXIgYSBjb3JlLXJvdXRlciB0byBiZSBhYmxlIHRvIHJl LW1hcmsgRFNDUHMgYnkgDQo+IGJpdC1tYXNrIGF0IGludGVyY29ubmVjdGlvbiBpbnRlcmZhY2Vz IHJhdGhlciB0aGFuIERTQ1AgYnkgRFNDUC4gVGhlIA0KPiBjb25maWcgZWZmb3J0IHRvIGN1c3Rv bWl6ZSByZS1tYXJraW5nIG9uIGEgRFNDUCBieSBEU0NQIGJhc2lzIGlzIGhpZ2guIA0KPiBBbiBl YXN5IHRvIGNvbmZpZ3VyZSBhbHRlcm5hdGl2ZSBpcyB0byBjbGFzc2lmeSBieSBiaXQtbWFzayBh bmQgcmUtbWFyayB0byBhIHNpbmdsZSBEU0NQLiBHb3JyeSwgZG8geW91IGhhdmUgYW55IHByZWZl cmVuY2UgaGVyZT8NCg0KSG1tLCBSRkMyNDc0IHN0YXRlcyB0aGF0IHRoZSBEU0NQIGlzIHVuc3Ry dWN0dXJlZDoNCiAgIlRoZSBEU0NQIGZpZWxkIGlzIGRlZmluZWQgYXMgYW4NCiAgIHVuc3RydWN0 dXJlZCBmaWVsZCB0byBmYWNpbGl0YXRlIHRoZSBkZWZpbml0aW9uIG9mIGZ1dHVyZSBwZXItaG9w DQogICBiZWhhdmlvcnMuDQoNCiAgIFdpdGggc29tZSBleGNlcHRpb25zIG5vdGVkIGJlbG93LCB0 aGUgbWFwcGluZyBvZiBjb2RlcG9pbnRzIHRvIFBIQnMNCiAgIE1VU1QgYmUgY29uZmlndXJhYmxl LiAgQSBEUy1jb21wbGlhbnQgbm9kZSBNVVNUIHN1cHBvcnQgdGhlIGxvZ2ljYWwNCiAgIGVxdWl2 YWxlbnQgb2YgYSBjb25maWd1cmFibGUgbWFwcGluZyB0YWJsZSBmcm9tIGNvZGVwb2ludHMgdG8g UEhCcyINCg0KSU1ITyBpdCBzaG91bGRuJ3QgYmUgZGlmZmljdWx0IHRvIGhhdmUgYSBtYXBwaW5n IHRhYmxlIGZyb20gZWFjaCBEU0NQIHRvIGEgUEhCLiBUaGUgbWFwcGluZyB0YWJsZSBzaG91bGQg aW5pdGlhbGx5IG9ubHkgY29udGFpbiBtYXBwaW5ncyB0byB0aGUgZGVmYXVsdCBQSEIgKG5vIG5l ZWQgdG8gcmVtYXJrIGFueXRoaW5nIHRoZW4pLg0KQ29uZmlndXJpbmcgRFNDUCByZW1hcmtpbmcg YnkgdXNpbmcgYml0bWFza3MgaXMgSU1ITyBub3QgUkZDMjQ3NCBjb21wbGlhbnQgYW5kIGEgYnJv a2VuIGNvbmNlcHQgY2F1c2luZyB0aGUgdHJvdWJsZSB3ZSBqdXN0IHJhbiBpbnRvLg0KDQpSZWdh cmRzLA0KIFJvbGFuZA0KDQo= From nobody Tue Aug 1 03:46:54 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06358132064 for ; Tue, 1 Aug 2017 03:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ycflN0kG5s9U for ; Tue, 1 Aug 2017 03:46:47 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE713206D for ; Tue, 1 Aug 2017 03:46:47 -0700 (PDT) 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 C284F1B00078; Tue, 1 Aug 2017 11:46:21 +0100 (BST) Message-ID: <59805BFB.8080201@erg.abdn.ac.uk> Date: Tue, 01 Aug 2017 11:46:19 +0100 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: Ruediger.Geib@telekom.de CC: roland.bless@kit.edu, tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 10:46:52 -0000 Hi, So, as I see it this advice applies when devices are configured in a consistent fashion - and could be useful to note for the draft. We'd like the MPLS core to behave "well", and I'd hope that people configuring MPLS will understand how AF is to be treated. My thread was about what happens when you have to work over a path where the entire path has not been correctly configured. I'd much prefer to avoide surprises if DSCP-marked (or re-marked) traffic reaches an AP (or some other device) that has been updated to map the LE codepoint to a LE PHB. I'd hate to think we specify a scheme that can often result in impacting just a part of an AF Class, inverting the ordering of the treatments --, I don't feel good about introducing new opportnities for such priority inversion across the sets of AF codepoints, even if this may be a result of misconfiguration or legacy behaviours. Gorry On 01/08/2017, 10:49, Ruediger.Geib@telekom.de wrote: > Hi Roland, > > AF classes are structured sets of DSCP. Their definition starts with a bit-mask based on DSCP bits 0-2, resulting in AFnx notation. This notation also corresponds to CSn definitions, resulting in up to 4 standard DSCPs sharing the same bits 0-2. > > To configure re-marking of an AF class or of eight DSCPs I need _per DSCP_ : > > - a class definition > - an assignment of a received DSCP to a class > - a re-mark order of the class to my internal DSCP > > If a provider operates MPLS, the number of Treatment Aggregates/PHBs offered at interconnection is often 3 or 4. The options that I am aware of are: > - a bit-mask based re-mark allows to transport and maintain up to 8 DSCP by a "3 line configuration" > - a DSCP based re-mark combined with a bit-mask based classification allows to transport up to n > DSCP by a "3 line configuration" and they are all re-marked to a single DSCP. > - a DSCP based re-mark aiming on maintaining different requires "n*3 lines of configuration" for n DSCP. > - There's no binding standard on Diffserv class/codepoint assignment at interconnection. Setting up > a per carrier per DSCP to DSCP and class mapping scheme is requiring some effort (negotiation, > configuration, operation). I'm trying to avoid that. > > To me, two choices to make operational sense: > - either bit-mask based DSCP re-mark with up to 8 DSCP per MPLS Treatment Aggregate > - or DSCP based re-mark with a single DSCP per MPLS Treatment Aggregate. > > Regards, > > Ruediger > > > -----Ursprüngliche Nachricht----- > Von: Bless, Roland (TM) [mailto:roland.bless@kit.edu] > Gesendet: Dienstag, 1. August 2017 10:53 > An: Geib, Rüdiger; gorry@erg.abdn.ac.uk > Cc: tsvwg@ietf.org > Betreff: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? > > Hi, > > Am 01.08.2017 um 10:22 schrieb Ruediger.Geib@telekom.de:> GF> There seems evidence that there are still even now deployed routers >> that have not adjusted their remarking behaviour after the IETF >> deprecated ToS Precedence bleaching. >> >> [RG2] True. I prefer a core-router to be able to re-mark DSCPs by >> bit-mask at interconnection interfaces rather than DSCP by DSCP. The >> config effort to customize re-marking on a DSCP by DSCP basis is high. >> An easy to configure alternative is to classify by bit-mask and re-mark to a single DSCP. Gorry, do you have any preference here? > Hmm, RFC2474 states that the DSCP is unstructured: > "The DSCP field is defined as an > unstructured field to facilitate the definition of future per-hop > behaviors. > > With some exceptions noted below, the mapping of codepoints to PHBs > MUST be configurable. A DS-compliant node MUST support the logical > equivalent of a configurable mapping table from codepoints to PHBs" > > IMHO it shouldn't be difficult to have a mapping table from each DSCP to a PHB. The mapping table should initially only contain mappings to the default PHB (no need to remark anything then). > Configuring DSCP remarking by using bitmasks is IMHO not RFC2474 compliant and a broken concept causing the trouble we just ran into. > > Regards, > Roland > From nobody Tue Aug 1 13:28:14 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40CE13170E for ; Tue, 1 Aug 2017 13:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jVVWPZcg242 for ; Tue, 1 Aug 2017 13:28:10 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 AEE3812ECB7 for ; Tue, 1 Aug 2017 13:28:10 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id z129so12120135pfb.3 for ; Tue, 01 Aug 2017 13:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V68Y/c449u4ElV371wvrTN4m5e6FLcsYWz+UpgTQs3s=; b=jWVZM7dXq5L3TVdlA9MLWf9DgRR+Ue/f5b515ZTya+3sUMwIVqhcL/hipiYo/zBBYD PEpKtUXxJtG4YbCdMXeKjD+dCMR3U3nqjsFDrbMq/NPHRoA0L1boNmeG10zJkRzTNVQ7 CVQQNK1cNH1OnOcK5CJyHgFICekDzqMkTLMP48UMsIhqof/K0YujkBpiGx7ab2YHh6h/ 0vx2C1qE4ODXim29DH6t5ab/WE9rB96iN1Q1gUxyOY6CauKYWmT/jy/bf/RDLTmUJh2q bdQjpHruLvHCBfhfT+wt32zZ4AEuKxiyV6zQkljKzw8YOPQd7xhwbfLz9Kaw0M40ZSVf G0Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=V68Y/c449u4ElV371wvrTN4m5e6FLcsYWz+UpgTQs3s=; b=rHjAXMpD3RV1A6HVAdiBiltqiEJ6/M4Tm/IPrOxWDo+QqC+2yHqOXmz/iV15fucqpR OGz3TUKJ7WDhBrpavxOjrzi3zUGL3P+bQDnAamu5Slrw0UxOHnSMVKskHgyOSMIL10I3 OmMp5QZf/paNBtnprN1ptNSaMq5YczrEox+iC3hllH84hoG4kCv7t2uKLn3sVZDITlk7 9ocE/lQMdzcVBwA+RJMQ6RRchmunzSaoYGYw0M4ylRcf6Y3rpwJ/49/YKYObK9EkxaCD B3CPh9IOXfbQWKNXx3yGQShbvOS4+O+vCpPspcYJcuPj6Hy6scco+Re6H0Ws+ev3JbaP S9MA== X-Gm-Message-State: AIVw11191y21kpEVxGwiuoaubEwcNU4mSSU0dAihIwchNZlp6XU54WiX Zaa0fb6PMaR/njNU X-Received: by 10.99.180.8 with SMTP id s8mr6283209pgf.166.1501619289902; Tue, 01 Aug 2017 13:28:09 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t8sm57046772pgq.68.2017.08.01.13.28.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 13:28:09 -0700 (PDT) To: "Bless, Roland (TM)" , Ruediger.Geib@telekom.de, gorry@erg.abdn.ac.uk Cc: tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 2 Aug 2017 08:28:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:28:12 -0000 On 01/08/2017 20:52, Bless, Roland (TM) wrote: > Hi, > > Am 01.08.2017 um 10:22 schrieb Ruediger.Geib@telekom.de:> GF> There > seems evidence that there are still even now deployed routers >> that have not adjusted their remarking behaviour after the IETF >> deprecated ToS Precedence bleaching. >> >> [RG2] True. I prefer a core-router to be able to re-mark DSCPs by bit-mask at >> interconnection interfaces rather than DSCP by DSCP. The config effort to customize >> re-marking on a DSCP by DSCP basis is high. An easy to configure alternative is to classify >> by bit-mask and re-mark to a single DSCP. Gorry, do you have any preference here? > > Hmm, RFC2474 states that the DSCP is unstructured: > "The DSCP field is defined as an > unstructured field to facilitate the definition of future per-hop > behaviors. > > With some exceptions noted below, the mapping of codepoints to PHBs > MUST be configurable. A DS-compliant node MUST support the logical > equivalent of a configurable mapping table from codepoints to PHBs" This is the fundamental point (and it is entirely the result of ISP people who were active in the diffserv WG that we have this rule, by the way). If an operator doesn't support this, anything can happen. DSCPs are not end-to-end. DSCP to behaviour mappings are not end-to-end. If you ignore this, things *will* go wrong. Trying to arrange things so that some arbitrary bit-masking of DCSP values will produce predictable results *will* fail in some cases. I think it's futile. Fundamentally I don't care which arbitrary bit pattern is recommended for LE, as long as it doesn't clash with a CS code point. But if you encroach on pool 3 I think that requires a formal update to RFC2474 or at least some very careful wording of the IANA considerations. > IMHO it shouldn't be difficult to have a mapping table > from each DSCP to a PHB. The mapping table should > initially only contain mappings to the default PHB > (no need to remark anything then). > Configuring DSCP remarking by using bitmasks is IMHO > not RFC2474 compliant and a broken concept causing > the trouble we just ran into. And you shouldn't fix broken products by fiddling with a standard; that rewards the makers of broken products. Regards Brian > > Regards, > Roland > > . > From nobody Tue Aug 1 23:57:05 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D080129B61 for ; Tue, 1 Aug 2017 23:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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=telekom.de 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 LXoCTuVZOTmO for ; Tue, 1 Aug 2017 23:57:02 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 4D0D6124C27 for ; Tue, 1 Aug 2017 23:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1501657021; x=1533193021; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=91UPtW6T5Ej1v9ejFT54KX9UtmueXIruAUhhP0QMByA=; b=vm24t1juHidUdbcGDR9DjqE3K+Ip4gvNQAl1eU+WidCnGs17VxR7VCyY L55XolBVZO4AG3GvLJKFRGycj5tqTkKXPT0m4AErVG1Sqw3aiddpnJvS6 yaYXYc4UCIV9hYL37TiOTfdQ11Y86xSAXbRZb3H2TyTILmwGHSx2Qs1lS XAhtEeG1CQhu2mB2dAq5zZrKdXV0nYGJKaP/bC7zFpo0EuiOlbdsB4A5/ DSTw7KC8c8d6ohqo+8YIokLZmWCKzDauWgTDYiaLM2Sz31chgSI702pRn 4R0YKxgNrtV8MHHKPP0umYApaNvLP0DBPq8+424KiAp44Oxd8fdoXrUhS g==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 08:56:58 +0200 X-IronPort-AV: E=Sophos;i="5.41,310,1498514400"; d="scan'208";a="1362312347" Received: from he105654.emea1.cds.t-internal.com ([10.169.118.86]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 02 Aug 2017 08:56:58 +0200 Received: from HE105654.EMEA1.cds.t-internal.com (10.169.118.86) by HE105654.emea1.cds.t-internal.com (10.169.118.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 2 Aug 2017 08:56:58 +0200 Received: from HE105654.EMEA1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6]) by HE105654.emea1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6%26]) with mapi id 15.00.1263.000; Wed, 2 Aug 2017 08:56:58 +0200 From: To: CC: , Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS9w2o4prCs8a2Uk2hjK9vt7Sn6aJIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQgAAbQwCAADlBgIAAr3OAgAAl4JD///thAIAAI+UQ///74YCAAWiAMA== Date: Wed, 2 Aug 2017 06:56:58 +0000 Message-ID: <59d67d4a2f6546d1b8d8cb154ba25e66@HE105654.emea1.cds.t-internal.com> References: <595F4D19.9030502@erg.abdn.ac.uk> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> <59805BFB.8080201@erg.abdn.ac.uk> In-Reply-To: <59805BFB.8080201@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.160.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 06:57:04 -0000 R29ycnksDQoNCldoYXQgYXJlIHRoZSBvcHRpb25zPyANCg0KSW4gZ2VuZXJhbCwgSSBkaXNsaWtl IGEgcG9saWN5IG9mIHNlbmRpbmcgRFNDUCBtYXJrZWQgcGFja2V0cyBhY3Jvc3MgYW4gaW50ZXJj b25uZWN0aW9uIHdpdGhvdXQgYW4gU0xBIGFuZCBleHBlY3RpbmcgdGhlIHJlY2VpdmVyIHRvIGVu c3VyZSByZWFzb25hYmxlIERpZmZzZXJ2IHRyZWF0bWVudC4gIA0KDQpMZXQncyBhc3N1bWUgdGhh dCB0aGUgcmVjZWl2aW5nIG5ldHdvcmsgdHJpZXMgdG8gYmUgZnJpZW5kbHkuIEkgZnVydGhlciBh c3N1bWUgYml0LW1hc2sgYmFzZWQgcmUtbWFya2luZyBhdCB0aGUgcmVjZWl2ZXIgc2lkZToNCg0K YSkgd2l0aG91dCB0b3VjaGluZyB0aGUgRFNDUCBwb29scw0KDQogLSBSRkMyNTk3IHJlY29tbWVu ZHMgdG8gdXNlIEFGbjEgYW5kIEFGbjIsIGlmIG9ubHkgdHdvIGRyb3AgDQogICBsZXZlbHMgYXJl IGFwcGxpZWQuIExFIGNvdWxkIHRoZW4gdXNlIDAwMDExMC4gSWYgYW55IGpva2VyIHNlbmRzIA0K ICAgRUYgMTAxMTEwIGFjcm9zcyBhbiBpbnRlcmNvbm5lY3Rpb24gd2l0aG91dCBhbiBTTEEgYW5k IHdpdGhvdXQgDQogICAgY2FyaW5nIGFib3V0IHJlLW1hcmtpbmcgdGhlIHBhY2tldHMgYXQgdGhl IHNlbmRpbmcgcm91dGVyLCBpdCANCiAgICBpcyByZS1tYXJrZWQgdG8gTEUuIE15IHBlcnNvbmFs IHRha2U6IGZhaXIgZW5vdWdoIGluIHRoYXQgDQogICAgY2FzZS4gSG93ZXZlciBhbnkgQUZuMyB0 cmFmZmljIHdpbGwgYmUgdHJlYXRlZCBsaWtlIHRoYXQuIFRoZSANCiAgICBwYWNrZXRzIG15IHNl ZSBoaWdoZXIgZHJvcHMgdGhhbiBBRm4xIGFuZCBBRm4yIGFuZCBhIHJlYWwgDQogICBBRm4gZmxv dyBtYXkgYmUgcmUtb3JkZXJlZC4gU28gZmFyIEknbSBub3QgYXdhcmUgb2YgZGVwbG95bWVudHMg DQogICAgbWFraW5nIHJlYWwgdXNlIG9mIEFGbjEtMyBhcyBkZXNpZ25lZC4NCg0KLSBMRSBjb3Vs ZCB1c2UgMDAwMDEwLiBUaGVuIGl0IG1pZ2h0IGhpdCBBRm4xIGFuZCB0aGVuIEFGbjEgbWF5IA0K ICAgc2VlIGhpZ2hlciBkcm9wcyBhbmQgdGhlIEFGbiBmbG93IG1heSBiZSByZS1vcmRlcmVkLg0K DQotIFdlIHN0aWNrIHdpdGggQ1MxLiBUaGlzIHdpbGwgYmUgcmUtbWFya2VkIHRvIERlZmF1bHQg aW4gdGhlIGFib3ZlIA0KICBjYXNlLiBUbyBtZTogd29yc3QgY2hvaWNlIG9mIGFsbC4NCg0KYikg dXNpbmcgYSBwb29sIDMgRFNDUA0KDQpJZiBEU0NQIDAwMDAwMSBpcyB1c2VkIGZvciBMRSwgdGhl cmUncyBubyBpc3N1ZSB3aXRoIHJlLW1hcmtlZCBBRiBvciBFRi4gV2UgaG93ZXZlciBoYXZlIGFu IGlzc3VlIHdpdGhpbiBJRVRGLg0KDQpSZWdhcmRzLCANCg0KUnVlZGlnZXINCg0KDQotLS0tLVVy c3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IEdvcnJ5IEZhaXJodXJzdCBbbWFpbHRv OmdvcnJ5QGVyZy5hYmRuLmFjLnVrXSANCkdlc2VuZGV0OiBEaWVuc3RhZywgMS4gQXVndXN0IDIw MTcgMTI6NDYNCkFuOiBHZWliLCBSw7xkaWdlciA8UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPg0K Q2M6IHJvbGFuZC5ibGVzc0BraXQuZWR1OyB0c3Z3Z0BpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFt0 c3Z3Z10gQ09NTUVOVCBQTEVBU0U6IFdoaWNoIERTQ1AgdmFsdWUgc2hvdWxkIHdlIHVzZSBmb3Ig TEUgUEhCPw0KDQpIaSwNCg0KU28sIGFzIEkgc2VlIGl0IHRoaXMgYWR2aWNlIGFwcGxpZXMgd2hl biBkZXZpY2VzIGFyZSBjb25maWd1cmVkIGluIGEgY29uc2lzdGVudCBmYXNoaW9uIC0gYW5kIGNv dWxkIGJlIHVzZWZ1bCB0byBub3RlIGZvciB0aGUgZHJhZnQuIFdlJ2QgbGlrZSB0aGUgTVBMUyBj b3JlIHRvIGJlaGF2ZSAid2VsbCIsIGFuZCBJJ2QgaG9wZSB0aGF0IHBlb3BsZSBjb25maWd1cmlu ZyBNUExTIHdpbGwgdW5kZXJzdGFuZCBob3cgQUYgaXMgdG8gYmUgdHJlYXRlZC4NCg0KTXkgdGhy ZWFkIHdhcyBhYm91dCB3aGF0IGhhcHBlbnMgd2hlbiB5b3UgaGF2ZSB0byB3b3JrIG92ZXIgYSBw YXRoIHdoZXJlIHRoZSBlbnRpcmUgcGF0aCBoYXMgbm90IGJlZW4gY29ycmVjdGx5IGNvbmZpZ3Vy ZWQuIEknZCBtdWNoIHByZWZlciB0byBhdm9pZGUgc3VycHJpc2VzIGlmIERTQ1AtbWFya2VkIChv ciByZS1tYXJrZWQpIHRyYWZmaWMgcmVhY2hlcyBhbiBBUCAob3Igc29tZSBvdGhlciBkZXZpY2Up IHRoYXQgaGFzIGJlZW4gdXBkYXRlZCB0byBtYXAgdGhlIExFIGNvZGVwb2ludCB0byBhIExFIFBI Qi4gSSdkIGhhdGUgdG8gdGhpbmsgd2Ugc3BlY2lmeSBhIHNjaGVtZSB0aGF0IGNhbiBvZnRlbiBy ZXN1bHQgaW4gaW1wYWN0aW5nIGp1c3QgYSBwYXJ0IG9mIGFuIEFGIENsYXNzLCBpbnZlcnRpbmcg dGhlIG9yZGVyaW5nIG9mIHRoZSB0cmVhdG1lbnRzIC0tLCBJIGRvbid0IGZlZWwgZ29vZCBhYm91 dCBpbnRyb2R1Y2luZyBuZXcgb3Bwb3J0bml0aWVzIGZvciBzdWNoIHByaW9yaXR5IGludmVyc2lv biBhY3Jvc3MgdGhlIHNldHMgb2YgQUYgY29kZXBvaW50cywgZXZlbiBpZiB0aGlzIG1heSBiZSBh IHJlc3VsdCBvZiBtaXNjb25maWd1cmF0aW9uIG9yIGxlZ2FjeSBiZWhhdmlvdXJzLg0KDQpHb3Jy eQ0KDQpPbiAwMS8wOC8yMDE3LCAxMDo0OSwgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlIHdyb3Rl Og0KPiBIaSBSb2xhbmQsDQo+DQo+IEFGIGNsYXNzZXMgYXJlIHN0cnVjdHVyZWQgc2V0cyBvZiBE U0NQLiBUaGVpciBkZWZpbml0aW9uIHN0YXJ0cyB3aXRoIGEgYml0LW1hc2sgYmFzZWQgb24gRFND UCBiaXRzIDAtMiwgcmVzdWx0aW5nIGluIEFGbnggbm90YXRpb24uIFRoaXMgbm90YXRpb24gYWxz byBjb3JyZXNwb25kcyB0byBDU24gZGVmaW5pdGlvbnMsIHJlc3VsdGluZyBpbiB1cCB0byA0IHN0 YW5kYXJkIERTQ1BzIHNoYXJpbmcgdGhlIHNhbWUgYml0cyAwLTIuDQo+DQo+IFRvIGNvbmZpZ3Vy ZSByZS1tYXJraW5nIG9mIGFuIEFGIGNsYXNzIG9yIG9mIGVpZ2h0IERTQ1BzIEkgbmVlZCBfcGVy IERTQ1BfIDoNCj4NCj4gLSBhIGNsYXNzIGRlZmluaXRpb24NCj4gLSBhbiBhc3NpZ25tZW50IG9m IGEgcmVjZWl2ZWQgRFNDUCB0byBhIGNsYXNzDQo+IC0gYSByZS1tYXJrIG9yZGVyIG9mIHRoZSBj bGFzcyB0byBteSBpbnRlcm5hbCBEU0NQDQo+DQo+IElmIGEgcHJvdmlkZXIgb3BlcmF0ZXMgTVBM UywgdGhlIG51bWJlciBvZiBUcmVhdG1lbnQgQWdncmVnYXRlcy9QSEJzIG9mZmVyZWQgYXQgaW50 ZXJjb25uZWN0aW9uIGlzIG9mdGVuIDMgb3IgNC4gVGhlIG9wdGlvbnMgdGhhdCBJIGFtIGF3YXJl IG9mIGFyZToNCj4gLSBhIGJpdC1tYXNrIGJhc2VkIHJlLW1hcmsgYWxsb3dzIHRvIHRyYW5zcG9y dCBhbmQgbWFpbnRhaW4gdXAgdG8gOCBEU0NQIGJ5IGEgIjMgbGluZSBjb25maWd1cmF0aW9uIg0K PiAtIGEgRFNDUCBiYXNlZCByZS1tYXJrIGNvbWJpbmVkIHdpdGggYSBiaXQtbWFzayBiYXNlZCBj bGFzc2lmaWNhdGlvbiBhbGxvd3MgdG8gdHJhbnNwb3J0IHVwIHRvIG4NCj4gICAgIERTQ1AgYnkg YSAiMyBsaW5lIGNvbmZpZ3VyYXRpb24iIGFuZCB0aGV5IGFyZSBhbGwgcmUtbWFya2VkIHRvIGEg c2luZ2xlIERTQ1AuDQo+IC0gYSBEU0NQIGJhc2VkIHJlLW1hcmsgYWltaW5nIG9uIG1haW50YWlu aW5nIGRpZmZlcmVudCByZXF1aXJlcyAibiozIGxpbmVzIG9mIGNvbmZpZ3VyYXRpb24iIGZvciBu IERTQ1AuDQo+IC0gVGhlcmUncyBubyBiaW5kaW5nIHN0YW5kYXJkIG9uIERpZmZzZXJ2IGNsYXNz L2NvZGVwb2ludCBhc3NpZ25tZW50IGF0IGludGVyY29ubmVjdGlvbi4gU2V0dGluZyB1cA0KPiAg ICBhIHBlciBjYXJyaWVyIHBlciBEU0NQIHRvIERTQ1AgYW5kIGNsYXNzIG1hcHBpbmcgc2NoZW1l IGlzIHJlcXVpcmluZyBzb21lIGVmZm9ydCAobmVnb3RpYXRpb24sDQo+ICAgIGNvbmZpZ3VyYXRp b24sIG9wZXJhdGlvbikuIEknbSB0cnlpbmcgdG8gYXZvaWQgdGhhdC4NCj4NCj4gVG8gbWUsIHR3 byBjaG9pY2VzIHRvIG1ha2Ugb3BlcmF0aW9uYWwgc2Vuc2U6DQo+IC0gZWl0aGVyIGJpdC1tYXNr IGJhc2VkIERTQ1AgcmUtbWFyayB3aXRoIHVwIHRvIDggRFNDUCBwZXIgTVBMUyANCj4gVHJlYXRt ZW50IEFnZ3JlZ2F0ZQ0KPiAtIG9yIERTQ1AgYmFzZWQgcmUtbWFyayB3aXRoIGEgc2luZ2xlIERT Q1AgcGVyIE1QTFMgVHJlYXRtZW50IEFnZ3JlZ2F0ZS4NCj4NCj4gUmVnYXJkcywNCj4NCj4gUnVl ZGlnZXINCj4NCj4NCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246 IEJsZXNzLCBSb2xhbmQgKFRNKSBbbWFpbHRvOnJvbGFuZC5ibGVzc0BraXQuZWR1XQ0KPiBHZXNl bmRldDogRGllbnN0YWcsIDEuIEF1Z3VzdCAyMDE3IDEwOjUzDQo+IEFuOiBHZWliLCBSw7xkaWdl cjxSdWVkaWdlci5HZWliQHRlbGVrb20uZGU+OyBnb3JyeUBlcmcuYWJkbi5hYy51aw0KPiBDYzog dHN2d2dAaWV0Zi5vcmcNCj4gQmV0cmVmZjogUmU6IFt0c3Z3Z10gQ09NTUVOVCBQTEVBU0U6IFdo aWNoIERTQ1AgdmFsdWUgc2hvdWxkIHdlIHVzZSBmb3IgTEUgUEhCPw0KPg0KPiBIaSwNCj4NCj4g QW0gMDEuMDguMjAxNyB1bSAxMDoyMiBzY2hyaWViIFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTo+ ICBHRj4gIFRoZXJlIA0KPiBzZWVtcyBldmlkZW5jZSB0aGF0IHRoZXJlIGFyZSBzdGlsbCBldmVu IG5vdyBkZXBsb3llZCByb3V0ZXJzDQo+PiB0aGF0IGhhdmUgbm90IGFkanVzdGVkIHRoZWlyIHJl bWFya2luZyBiZWhhdmlvdXIgYWZ0ZXIgdGhlIElFVEYgDQo+PiBkZXByZWNhdGVkIFRvUyBQcmVj ZWRlbmNlIGJsZWFjaGluZy4NCj4+DQo+PiBbUkcyXSBUcnVlLiBJIHByZWZlciBhIGNvcmUtcm91 dGVyIHRvIGJlIGFibGUgdG8gcmUtbWFyayBEU0NQcyBieSANCj4+IGJpdC1tYXNrIGF0IGludGVy Y29ubmVjdGlvbiBpbnRlcmZhY2VzIHJhdGhlciB0aGFuIERTQ1AgYnkgRFNDUC4gVGhlIA0KPj4g Y29uZmlnIGVmZm9ydCB0byBjdXN0b21pemUgcmUtbWFya2luZyBvbiBhIERTQ1AgYnkgRFNDUCBi YXNpcyBpcyBoaWdoLg0KPj4gQW4gZWFzeSB0byBjb25maWd1cmUgYWx0ZXJuYXRpdmUgaXMgdG8g Y2xhc3NpZnkgYnkgYml0LW1hc2sgYW5kIHJlLW1hcmsgdG8gYSBzaW5nbGUgRFNDUC4gR29ycnks IGRvIHlvdSBoYXZlIGFueSBwcmVmZXJlbmNlIGhlcmU/DQo+IEhtbSwgUkZDMjQ3NCBzdGF0ZXMg dGhhdCB0aGUgRFNDUCBpcyB1bnN0cnVjdHVyZWQ6DQo+ICAgICJUaGUgRFNDUCBmaWVsZCBpcyBk ZWZpbmVkIGFzIGFuDQo+ICAgICB1bnN0cnVjdHVyZWQgZmllbGQgdG8gZmFjaWxpdGF0ZSB0aGUg ZGVmaW5pdGlvbiBvZiBmdXR1cmUgcGVyLWhvcA0KPiAgICAgYmVoYXZpb3JzLg0KPg0KPiAgICAg V2l0aCBzb21lIGV4Y2VwdGlvbnMgbm90ZWQgYmVsb3csIHRoZSBtYXBwaW5nIG9mIGNvZGVwb2lu dHMgdG8gUEhCcw0KPiAgICAgTVVTVCBiZSBjb25maWd1cmFibGUuICBBIERTLWNvbXBsaWFudCBu b2RlIE1VU1Qgc3VwcG9ydCB0aGUgbG9naWNhbA0KPiAgICAgZXF1aXZhbGVudCBvZiBhIGNvbmZp Z3VyYWJsZSBtYXBwaW5nIHRhYmxlIGZyb20gY29kZXBvaW50cyB0byBQSEJzIg0KPg0KPiBJTUhP IGl0IHNob3VsZG4ndCBiZSBkaWZmaWN1bHQgdG8gaGF2ZSBhIG1hcHBpbmcgdGFibGUgZnJvbSBl YWNoIERTQ1AgdG8gYSBQSEIuIFRoZSBtYXBwaW5nIHRhYmxlIHNob3VsZCBpbml0aWFsbHkgb25s eSBjb250YWluIG1hcHBpbmdzIHRvIHRoZSBkZWZhdWx0IFBIQiAobm8gbmVlZCB0byByZW1hcmsg YW55dGhpbmcgdGhlbikuDQo+IENvbmZpZ3VyaW5nIERTQ1AgcmVtYXJraW5nIGJ5IHVzaW5nIGJp dG1hc2tzIGlzIElNSE8gbm90IFJGQzI0NzQgY29tcGxpYW50IGFuZCBhIGJyb2tlbiBjb25jZXB0 IGNhdXNpbmcgdGhlIHRyb3VibGUgd2UganVzdCByYW4gaW50by4NCj4NCj4gUmVnYXJkcywNCj4g ICBSb2xhbmQNCj4NCg0K From nobody Wed Aug 2 00:40:46 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D3B132091 for ; Wed, 2 Aug 2017 00:40:44 -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, RCVD_IN_DNSWL_MED=-2.3, 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 EtIUJqx3EGao for ; Wed, 2 Aug 2017 00:40:43 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 D877B124234 for ; Wed, 2 Aug 2017 00:40:42 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dcoGl-0002NU-9o; Wed, 02 Aug 2017 09:40:39 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 34F17B007EA; Wed, 2 Aug 2017 09:40:39 +0200 (CEST) To: Brian E Carpenter , Ruediger.Geib@telekom.de, gorry@erg.abdn.ac.uk Cc: tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Wed, 2 Aug 2017 09:40:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1501659639.439526847 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 07:40:45 -0000 Hi, comments inline. Am 01.08.2017 um 22:28 schrieb Brian E Carpenter: > On 01/08/2017 20:52, Bless, Roland (TM) wrote: >> Hi, >> >> Am 01.08.2017 um 10:22 schrieb Ruediger.Geib@telekom.de:> GF> There >> seems evidence that there are still even now deployed routers >>> that have not adjusted their remarking behaviour after the IETF >>> deprecated ToS Precedence bleaching. >>> >>> [RG2] True. I prefer a core-router to be able to re-mark DSCPs by bit-mask at >>> interconnection interfaces rather than DSCP by DSCP. The config effort to customize >>> re-marking on a DSCP by DSCP basis is high. An easy to configure alternative is to classify >>> by bit-mask and re-mark to a single DSCP. Gorry, do you have any preference here? >> >> Hmm, RFC2474 states that the DSCP is unstructured: >> "The DSCP field is defined as an >> unstructured field to facilitate the definition of future per-hop >> behaviors. >> >> With some exceptions noted below, the mapping of codepoints to PHBs >> MUST be configurable. A DS-compliant node MUST support the logical >> equivalent of a configurable mapping table from codepoints to PHBs" > > This is the fundamental point (and it is entirely the result of ISP > people who were active in the diffserv WG that we have this rule, by the > way). If an operator doesn't support this, anything can happen. > > DSCPs are not end-to-end. DSCP to behaviour mappings are not end-to-end. > If you ignore this, things *will* go wrong. Trying to arrange things so > that some arbitrary bit-masking of DCSP values will produce predictable > results *will* fail in some cases. I think it's futile. > > Fundamentally I don't care which arbitrary bit pattern is recommended > for LE, as long as it doesn't clash with a CS code point. But if > you encroach on pool 3 I think that requires a formal update to RFC2474 > or at least some very careful wording of the IANA considerations. I'm not sure that the experienced behavior is actually better if we use a DSCP from pool 3, since it may already be used in some domain internally for local use. >> IMHO it shouldn't be difficult to have a mapping table >> from each DSCP to a PHB. The mapping table should >> initially only contain mappings to the default PHB >> (no need to remark anything then). >> Configuring DSCP remarking by using bitmasks is IMHO >> not RFC2474 compliant and a broken concept causing >> the trouble we just ran into. > > And you shouldn't fix broken products by fiddling with a standard; > that rewards the makers of broken products. +1 Regards, Roland From nobody Wed Aug 2 01:48:34 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61FA131D2F for ; Wed, 2 Aug 2017 01:48:32 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 HcAMJ1N5YsPA for ; Wed, 2 Aug 2017 01:48:31 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 74940131C9D for ; Wed, 2 Aug 2017 01:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1501663710; x=1533199710; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/Y3Lcmd35pzlA1CNCGQ8SW9XMoggCpZYrk67l0RRsJE=; b=yqrbg4qZFfs24EE7brbPfyb6Xi7x/YNnQ7BIQATXPkd0ShOhCj6yfhS3 gOL+Ctd+M4+p+OzRCbCjK/6X09vw5+On5yvridOcykSLfADgjBmfAKxOd CqbeXWLblhT8i4aAxvObGF/p4P7Brn/G9hn8pqvjvk/a9MWci6tuZK7PB jsKIlaEUA1XTv8lgH3BsDECr5oFBscvFQImpl3BbbytYp+y3dfKAEYp4A yk2lEwGnimoRietXGP5WT9fnRFYVM73uSGbntlJTf5ruTlzKiknbVNRmo t5mpc3TdARalYUyD2bN+vaSL4fMDXUQnpAox+W23Sorm+wL83xV2j7tdi w==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 10:48:28 +0200 X-IronPort-AV: E=Sophos;i="5.41,310,1498514400"; d="scan'208";a="710715539" Received: from he105658.emea1.cds.t-internal.com ([10.169.118.88]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 02 Aug 2017 10:48:19 +0200 Received: from HE105654.EMEA1.cds.t-internal.com (10.169.118.86) by HE105658.emea1.cds.t-internal.com (10.169.118.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 2 Aug 2017 10:48:14 +0200 Received: from HE105654.EMEA1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6]) by HE105654.emea1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6%26]) with mapi id 15.00.1263.000; Wed, 2 Aug 2017 10:48:14 +0200 From: To: CC: Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS9w2o4prCs8a2Uk2hjK9vt7Sn6aJIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQgAAbQwCAADlBgIAAr3OAgAAl4JD///thAIAAwlOAgAC76ICAACgpAA== Date: Wed, 2 Aug 2017 08:48:14 +0000 Message-ID: References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.160.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:48:33 -0000 SGkgUm9sYW5kLA0KDQppbiBhbiBNUExTIGRvbWFpbiwgb25lIGdlbmVyYWxseSBtYXkgYXNzaWdu IGEgYnVuY2ggb2YgRFNDUCB0byBhIA0Kc2luZ2xlIFRyZWF0bWVudCBBZ2dyZWdhdGUgLyBQSEIu IFRoYXQgSSB0aGluayBpcyBxdWl0ZSB1c2VmdWwuIA0KVW5mb3J0dW5hdGVseSB0aGUgdG9wIGxh YmVsIGlzIHJlbW92ZWQgYmVmb3JlIHRoZSBsYXN0IE1QTFMgDQpkb21haW4gcm91dGVyIGlzIHJl YWNoZWQuIFRoZW4gYW4gdW5rbm93biBhbmQgbm90IHJlLW1hcmtlZCANCkRTQ1AgaXMgbm90IGFj Y2VwdGFibGUuIEhlbmNlIHlvdXIgZ3VpZGFuY2UgYmVsb3cgaXNuJ3QgYXBwbGljYWJsZSBpbiAN CmFsbCBuZXR3b3Jrcy4NCg0KVGhlcmUgaXMgYSBmYWlybHkgc2ltcGxlIGFuZCB1c2VmdWwgb3B0 aW9uIGFsbG93aW5nIHRvIGNvbWJpbmUgVHJlYXRtZW50IA0KQWdncmVnYXRlcywgRGlmZnNlcnYg Zm9yd2FyZGluZyBhY3Jvc3MgYW4gTVBMUyBkb21haW4gYW5kIA0KbWFpbnRlbmFuY2Ugb2YgbXVs dGlwbGUgRFNDUC4gUGVyIFRyZWF0bWVudCBBZ2dyZWdhdGU6DQotIGNsYXNzaWZ5IERTQ1BzIGJ5 IGJpdC1tYXNrIGF0IGluZ3Jlc3MuDQotIHJlLW1hcmsgRFNDUHMgYnkgYml0IG1hc2sgYXQgaW5n cmVzcy4NCi0gRGlmZnNlcnYgZm9yd2FyZGluZyBieSBUcmVhdG1lbnQgQWdncmVnYXRlDQotIGNs YXNzaWZ5IGFuZCBmb3J3YXJkIGJ5IGluZGl2aWR1YWwgRFNDUCBhdCB0aGUgZWdyZXNzIChpZiBk ZXNpcmVkKQ0KLSBzYW1lIGhvbGRzIGZvciBuZXh0IGRvbWFpbg0KDQpUaGUgb3RoZXIgc2ltcGxl IG9wdGlvbiBJIHNlZSB3aXRob3V0IGJpdCBtYXNrIGJhc2VkIHJlLW1hcmsgaXMsIA0KYWdhaW4g cGVyIFRyZWF0bWVudCBBZ2dyZWdhdGU6DQotIGNsYXNzaWZ5IERTQ1BzIGJ5IGJpdC1tYXNrIGF0 IGluZ3Jlc3MuDQotIHJlLW1hcmsgdG8gX2Egc2luZ2xlIERTQ1BfIGF0IGluZ3Jlc3MuDQotIERp ZmZzZXJ2IGZvcndhcmRpbmcgYnkgVHJlYXRtZW50IEFnZ3JlZ2F0ZSANCi0gY2xhc3NpZnkgYW5k IGZvcndhcmQgYnkgdGhpcyBzaW5nbGUgRFNDUCBhdCB0aGUgZWdyZXNzDQotIHNhbWUgaG9sZHMg Zm9yIG5leHQgZG9tYWluDQoNCkkgcHJlZmVyIGEgc2ltcGxlIHNvbHV0aW9uIChhbmQgYSBzdGFu ZGFyZGl6ZWQgb25lLCBpZiBwb3NzaWJsZSkuIA0KDQpPZiBjb3Vyc2UgaXQgaXMgdGVjaG5pY2Fs bHkgcG9zc2libGUgdG8gc2V0IHVwIGFuZCBtYWludGFpbiBwZXIgRFNDUCB0byANClBIQiBhbmQg aW5kaXZpZHVhbCBEU0NQIHJlLW1hcmsgdGFibGVzLCBjdXN0b21pemVkIGZvciBlYWNoIA0KaW50 ZXJjb25uZWN0aW9uLiBJbnRlcmNvbm5lY3Rpb24gRFNDUHMgYXJlIG5vdCBzdGFuZGFyZGl6ZWQu DQpNYW55IGNhcnJpZXJzIG9wZXJhdGUgbXVsdGlwbGUgaW50ZXJjb25uZWN0aW9ucy4gDQoNClJl Z2FyZHMsIA0KDQpSdWVkaWdlcg0KDQo+PiBJTUhPIGl0IHNob3VsZG4ndCBiZSBkaWZmaWN1bHQg dG8gaGF2ZSBhIG1hcHBpbmcgdGFibGUgZnJvbSBlYWNoIERTQ1AgDQo+PiB0byBhIFBIQi4gVGhl IG1hcHBpbmcgdGFibGUgc2hvdWxkIGluaXRpYWxseSBvbmx5IGNvbnRhaW4gbWFwcGluZ3MgdG8g DQo+PiB0aGUgZGVmYXVsdCBQSEIgKG5vIG5lZWQgdG8gcmVtYXJrIGFueXRoaW5nIHRoZW4pLg0K Pj4gQ29uZmlndXJpbmcgRFNDUCByZW1hcmtpbmcgYnkgdXNpbmcgYml0bWFza3MgaXMgSU1ITyBu b3QgUkZDMjQ3NCANCj4+IGNvbXBsaWFudCBhbmQgYSBicm9rZW4gY29uY2VwdCBjYXVzaW5nIHRo ZSB0cm91YmxlIHdlIGp1c3QgcmFuIGludG8uDQo+IA0KPiBBbmQgeW91IHNob3VsZG4ndCBmaXgg YnJva2VuIHByb2R1Y3RzIGJ5IGZpZGRsaW5nIHdpdGggYSBzdGFuZGFyZDsgDQo+IHRoYXQgcmV3 YXJkcyB0aGUgbWFrZXJzIG9mIGJyb2tlbiBwcm9kdWN0cy4NCg0KKzENCg0KUmVnYXJkcywNCiBS b2xhbmQNCg0K From nobody Wed Aug 2 05:12:14 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A15131D08 for ; Wed, 2 Aug 2017 05:12:13 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 Eq9mY4XXuEyX for ; Wed, 2 Aug 2017 05:12:10 -0700 (PDT) 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 E7E9B131D01 for ; Wed, 2 Aug 2017 05:12:09 -0700 (PDT) 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 000131B0023F; Wed, 2 Aug 2017 13:11:42 +0100 (BST) Message-ID: <5981C17D.40409@erg.abdn.ac.uk> Date: Wed, 02 Aug 2017 13:11:41 +0100 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: Brian E Carpenter CC: "Bless, Roland (TM)" , Ruediger.Geib@telekom.de, tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 12:12:13 -0000 Thanks Brian, see below On 01/08/2017, 21:28, Brian E Carpenter wrote: > On 01/08/2017 20:52, Bless, Roland (TM) wrote: >> Hi, >> >> Am 01.08.2017 um 10:22 schrieb Ruediger.Geib@telekom.de:> GF> There >> seems evidence that there are still even now deployed routers >>> that have not adjusted their remarking behaviour after the IETF >>> deprecated ToS Precedence bleaching. >>> >>> [RG2] True. I prefer a core-router to be able to re-mark DSCPs by bit-mask at >>> interconnection interfaces rather than DSCP by DSCP. The config effort to customize >>> re-marking on a DSCP by DSCP basis is high. An easy to configure alternative is to classify >>> by bit-mask and re-mark to a single DSCP. Gorry, do you have any preference here? >> Hmm, RFC2474 states that the DSCP is unstructured: >> "The DSCP field is defined as an >> unstructured field to facilitate the definition of future per-hop >> behaviors. >> >> With some exceptions noted below, the mapping of codepoints to PHBs >> MUST be configurable. A DS-compliant node MUST support the logical >> equivalent of a configurable mapping table from codepoints to PHBs" > This is the fundamental point (and it is entirely the result of ISP > people who were active in the diffserv WG that we have this rule, by the > way). If an operator doesn't support this, anything can happen. > > DSCPs are not end-to-end. DSCP to behaviour mappings are not end-to-end. > If you ignore this, things *will* go wrong. Trying to arrange things so > that some arbitrary bit-masking of DCSP values will produce predictable > results *will* fail in some cases. I think it's futile. I agree! (To me a key issue is whether standardising a codepoint for the LE service may result in a specific failure mode that requires our attention.) > Fundamentally I don't care which arbitrary bit pattern is recommended > for LE, as long as it doesn't clash with a CS code point. But if > you encroach on pool 3 I think that requires a formal update to RFC2474 > or at least some very careful wording of the IANA considerations. Thanks, this seems correct. It's not to be taken lightly, but the Chairs could explore this approach, working with IANA, if there is a justification to go ahead. >> IMHO it shouldn't be difficult to have a mapping table >> from each DSCP to a PHB. The mapping table should >> initially only contain mappings to the default PHB >> (no need to remark anything then). >> Configuring DSCP remarking by using bitmasks is IMHO >> not RFC2474 compliant and a broken concept causing >> the trouble we just ran into. > And you shouldn't fix broken products by fiddling with a standard; > that rewards the makers of broken products. To this, I'd add that if we allocate from a different pool for LE - it will be because the need is different for a "less than default" treatment. > Regards > Brian Best wishes, Gorry >> Regards, >> Roland >> >> . >> From nobody Wed Aug 2 05:31:36 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082F613207C for ; Wed, 2 Aug 2017 05:31:36 -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, RCVD_IN_DNSWL_MED=-2.3, 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 d-pTr2sgnz0Q for ; Wed, 2 Aug 2017 05:31:33 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 2F05F13207B for ; Wed, 2 Aug 2017 05:31:33 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1dcsoC-00009B-Ji; Wed, 02 Aug 2017 14:31:28 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 8489BB004E9; Wed, 2 Aug 2017 14:31:28 +0200 (CEST) To: Ruediger.Geib@telekom.de Cc: tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <78edc807-90a5-66d2-4639-30f32d14240e@kit.edu> Date: Wed, 2 Aug 2017 14:31:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1501677088.715167130 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 12:31:36 -0000 Hi Rüdiger, Am 02.08.2017 um 10:48 schrieb Ruediger.Geib@telekom.de: > in an MPLS domain, one generally may assign a bunch of DSCP to a > single Treatment Aggregate / PHB. That I think is quite useful. > Unfortunately the top label is removed before the last MPLS > domain router is reached. Then an unknown and not re-marked > DSCP is not acceptable. Hence your guidance below isn't applicable in > all networks. Thanks for pointing out MPLS/DiffServ interworking problems. I'm more a DiffServ purist so I wasn't aware of such operational problems. In summary, the whole DiffServ deployment seems to be getting more complex by integrating MPLS constraints. I'm also not aware how common an AF deployment is, since you quoted (in your last mail) that bit-masking AF classes can be quite useful. So if I understood your statements correctly, it is not possible to carry a DSCP x in an MPLS aggregate and then use the same DSCP x at the egress to the next domain? > There is a fairly simple and useful option allowing to combine Treatment > Aggregates, Diffserv forwarding across an MPLS domain and > maintenance of multiple DSCP. Per Treatment Aggregate: > - classify DSCPs by bit-mask at ingress. > - re-mark DSCPs by bit mask at ingress. > - Diffserv forwarding by Treatment Aggregate > - classify and forward by individual DSCP at the egress (if desired) > - same holds for next domain > > The other simple option I see without bit mask based re-mark is, > again per Treatment Aggregate: > - classify DSCPs by bit-mask at ingress. > - re-mark to _a single DSCP_ at ingress. > - Diffserv forwarding by Treatment Aggregate > - classify and forward by this single DSCP at the egress > - same holds for next domain > > I prefer a simple solution (and a standardized one, if possible). Speaking as DiffServ purist, DSCP classification _by bit-mask_ is non-conforming to RFC 2474. > Of course it is technically possible to set up and maintain per DSCP to > PHB and individual DSCP re-mark tables, customized for each > interconnection. Interconnection DSCPs are not standardized. > Many carriers operate multiple interconnections. The DiffServ architecture indeed requires to have agreements for each interconnection. However, in case you don't have negotiated any special treatment, a mapping of "any DSCP -> default PHB" should work. But if I understood you correctly, an incoming DSCP x may not be acceptable for the next DS domain, so you must remark? Regards, Roland From nobody Wed Aug 2 07:48:32 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B3B13211C for ; Wed, 2 Aug 2017 07:48:31 -0700 (PDT) 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, RP_MATCHES_RCVD=-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=telekom.de 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 pzbh1tjPZ16X for ; Wed, 2 Aug 2017 07:48:29 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 CABFF131CA2 for ; Wed, 2 Aug 2017 07:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1501685301; x=1533221301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y9DsVp9+IZx/Lgd+Bf0MiRTmCblpzwXoSS6aPJoDahA=; b=F74jJdrBEyTN2qJhTSmTfvTiPKoyf6XwP5RwL1Mk9kmbhWTMxuSOm1Dn JdISgZAhWfzZLItjl6v7Joy1YtbhJP3NxFj3/sFdTNujO3lVy/IWA/lTb D7EMGB/g/8AWwdOeWtXkyApDFHE8GFlxQZ47/7Jsl+n+U2qU3Y1Eko5Gg raxvMMtXBeLMGAVjgwCUPnqcDtaGtUlhSdoF/O5tUTPLFgh+GvYwkt99A n3Iik5RFS+dl9uPvgXDTM4rWvHGg37qFdssu5iKkjyx3jM2Dv+lekMfnU UibfVsqE+cKEbEBCTpe2q0NdNURu84ILWDGYzknPefgIjfjCG0V/ukqRb Q==; Received: from q4de8ssaz61.gppng.telekom.de ([10.206.166.200]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 16:48:19 +0200 X-IronPort-AV: E=Sophos;i="5.41,311,1498514400"; d="scan'208";a="1226976335" Received: from he105654.emea1.cds.t-internal.com ([10.169.118.86]) by q4de8ssazdv.gppng.telekom.de with ESMTP/TLS/AES256-SHA; 02 Aug 2017 16:48:18 +0200 Received: from HE105654.EMEA1.cds.t-internal.com (10.169.118.86) by HE105654.emea1.cds.t-internal.com (10.169.118.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 2 Aug 2017 16:48:18 +0200 Received: from HE105654.EMEA1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6]) by HE105654.emea1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6%26]) with mapi id 15.00.1263.000; Wed, 2 Aug 2017 16:48:18 +0200 From: To: CC: Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS9w2o4prCs8a2Uk2hjK9vt7Sn6aJIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQgAAbQwCAADlBgIAAr3OAgAAl4JD///thAIAAwlOAgAC76ICAACgpAIAAKRgAgAA+g8A= Date: Wed, 2 Aug 2017 14:48:18 +0000 Message-ID: <89e6092bcd4f488699ac2cef715482e4@HE105654.emea1.cds.t-internal.com> References: <595F4D19.9030502@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> <78edc807-90a5-66d2-4639-30f32d14240e@kit.edu> In-Reply-To: <78edc807-90a5-66d2-4639-30f32d14240e@kit.edu> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.160.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 14:48:31 -0000 SGkgUm9sYW5kLA0KDQp0aGUgcHJvYmxlbSB3aXRoIHVua25vd24gRFNDUHMgYXJpc2VzIG9uIHRo ZSBfZG9tYWluIGludGVybmFsDQppbmdyZXNzIGludGVyZmFjZV8gb2YgdGhlIE1QTFMgZWdyZXNz IGVkZ2Ugcm91dGVyLCBhbmQgdHJhZmZpYyANCmxlYXZpbmcgdGhlIGRvbWFpbiBpcyBjb25jZXJu ZWQuDQoNCkl0J3Mgc3VmZmljaWVudCBpZiBhIHZlbmRvciBhbGxvd3MgY2xhc3NpZmljYXRpb24g YmFzZWQgb24gRFNDUCByYW5nZXMuIA0KSSBjYW4gY29uZmlndXJlIGEgYmVoYXZpb3VyIGxpa2Ug YSBiaXQgbWFzayAoYXMgdGhlc2UgYXJlIHNwZWNpZmljIA0KRFNDUCByYW5nZXMpLiBDb3VsZCBi ZSBEU0NQIGJpdHMgMC0xLCBiaXRzIDAtMiB0aGF0IHdheS4NCg0KQ29tbW9ubHkgdXNlZCBNUExT IFNob3J0IFBpcGUncyBQZW4tdWx0aW1hdGUgSG9wIFBvcHBpbmcgKFBIUCkgYWRkcyB0aGUgDQpj b21wbGV4aXR5IGhlcmUuIEkgZG91YnQgaXQgd2lsbCBiZSByZW1vdmVkIG9yIGFkYXB0ZWQgZHVl IHRvIERpZmZzZXJ2IGlzc3Vlcy4NCg0KSSdtIHRyeWluZyB0byBiZSBwcmFnbWF0aWMgYW5kIGZp Z3VyZSBvdXQgaG93IHRvIG1lZXQgYSBtYXhpbXVtIG9mIA0KY29uc3RyYWludHMgd2hpbGUgZmlu ZGluZyBhIHNpbXBsZSBzb2x1dGlvbi4gSW4gdGhlIGVuZCwgYW4gYWRtaW5pc3RyYXRpdmUgDQpv YnN0YWNsZSBsaWtlIGEgcG9vbCBkaXNjdXNzaW9uIG1pZ2h0IGJlIHNpbXBsZXIgdG8gcGFzcyB0 aGFuIHJ1bm5pbmcgaW50byANCmNvbmZsaWN0cyB3aXRoIGRlcGxveWVkIHNvbHV0aW9ucy4gSSBj YW4ndCBjbGFpbSB0byBrbm93IA0KYWxsIHNvbHV0aW9ucyB3aGljaCBzZWUgZGVwbG95bWVudCB3 aXRoaW4gRGV1dHNjaGUgVGVsZWtvbSdzIGVudGlyZSANCm5ldHdvcmsuIElmIGFueWJvZHkga25v d3MgdGhhdCBmb3IgYSBiaWdnZXIgY29tcGFueSwgcGxlYXNlIHNwZWFrIHVwLg0KDQpSZWdhcmRz LCBSdWVkaWdlcg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IEJs ZXNzLCBSb2xhbmQgKFRNKSBbbWFpbHRvOnJvbGFuZC5ibGVzc0BraXQuZWR1XSANCkdlc2VuZGV0 OiBNaXR0d29jaCwgMi4gQXVndXN0IDIwMTcgMTQ6MzENCkFuOiBHZWliLCBSw7xkaWdlciA8UnVl ZGlnZXIuR2VpYkB0ZWxla29tLmRlPg0KQ2M6IHRzdndnQGlldGYub3JnDQpCZXRyZWZmOiBSZTog W3RzdndnXSBDT01NRU5UIFBMRUFTRTogV2hpY2ggRFNDUCB2YWx1ZSBzaG91bGQgd2UgdXNlIGZv ciBMRSBQSEI/DQoNCkhpIFLDvGRpZ2VyLA0KDQpBbSAwMi4wOC4yMDE3IHVtIDEwOjQ4IHNjaHJp ZWIgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlOg0KPiBpbiBhbiBNUExTIGRvbWFpbiwgb25lIGdl bmVyYWxseSBtYXkgYXNzaWduIGEgYnVuY2ggb2YgRFNDUCB0byBhIA0KPiBzaW5nbGUgVHJlYXRt ZW50IEFnZ3JlZ2F0ZSAvIFBIQi4gVGhhdCBJIHRoaW5rIGlzIHF1aXRlIHVzZWZ1bC4NCj4gVW5m b3J0dW5hdGVseSB0aGUgdG9wIGxhYmVsIGlzIHJlbW92ZWQgYmVmb3JlIHRoZSBsYXN0IE1QTFMg ZG9tYWluIA0KPiByb3V0ZXIgaXMgcmVhY2hlZC4gVGhlbiBhbiB1bmtub3duIGFuZCBub3QgcmUt bWFya2VkIERTQ1AgaXMgbm90IA0KPiBhY2NlcHRhYmxlLiBIZW5jZSB5b3VyIGd1aWRhbmNlIGJl bG93IGlzbid0IGFwcGxpY2FibGUgaW4gYWxsIA0KPiBuZXR3b3Jrcy4NCg0KVGhhbmtzIGZvciBw b2ludGluZyBvdXQgTVBMUy9EaWZmU2VydiBpbnRlcndvcmtpbmcgcHJvYmxlbXMuDQpJJ20gbW9y ZSBhIERpZmZTZXJ2IHB1cmlzdCBzbyBJIHdhc24ndCBhd2FyZSBvZiBzdWNoIG9wZXJhdGlvbmFs IHByb2JsZW1zLiBJbiBzdW1tYXJ5LCB0aGUgd2hvbGUgRGlmZlNlcnYgZGVwbG95bWVudCBzZWVt cyB0byBiZSBnZXR0aW5nIG1vcmUgY29tcGxleCBieSBpbnRlZ3JhdGluZyBNUExTIGNvbnN0cmFp bnRzLiBJJ20gYWxzbyBub3QgYXdhcmUgaG93IGNvbW1vbiBhbiBBRiBkZXBsb3ltZW50IGlzLCBz aW5jZSB5b3UgcXVvdGVkIChpbiB5b3VyIGxhc3QgbWFpbCkgdGhhdCBiaXQtbWFza2luZyBBRiBj bGFzc2VzIGNhbiBiZSBxdWl0ZSB1c2VmdWwuIFNvIGlmIEkgdW5kZXJzdG9vZCB5b3VyIHN0YXRl bWVudHMgY29ycmVjdGx5LCBpdCBpcyBub3QgcG9zc2libGUgdG8gY2FycnkgYSBEU0NQIHggaW4g YW4gTVBMUyBhZ2dyZWdhdGUgYW5kIHRoZW4gdXNlIHRoZSBzYW1lIERTQ1AgeCBhdCB0aGUgZWdy ZXNzIHRvIHRoZSBuZXh0IGRvbWFpbj8NCg0KPiBUaGVyZSBpcyBhIGZhaXJseSBzaW1wbGUgYW5k IHVzZWZ1bCBvcHRpb24gYWxsb3dpbmcgdG8gY29tYmluZSANCj4gVHJlYXRtZW50IEFnZ3JlZ2F0 ZXMsIERpZmZzZXJ2IGZvcndhcmRpbmcgYWNyb3NzIGFuIE1QTFMgZG9tYWluIGFuZCANCj4gbWFp bnRlbmFuY2Ugb2YgbXVsdGlwbGUgRFNDUC4gUGVyIFRyZWF0bWVudCBBZ2dyZWdhdGU6DQo+IC0g Y2xhc3NpZnkgRFNDUHMgYnkgYml0LW1hc2sgYXQgaW5ncmVzcy4NCj4gLSByZS1tYXJrIERTQ1Bz IGJ5IGJpdCBtYXNrIGF0IGluZ3Jlc3MuDQo+IC0gRGlmZnNlcnYgZm9yd2FyZGluZyBieSBUcmVh dG1lbnQgQWdncmVnYXRlDQo+IC0gY2xhc3NpZnkgYW5kIGZvcndhcmQgYnkgaW5kaXZpZHVhbCBE U0NQIGF0IHRoZSBlZ3Jlc3MgKGlmIGRlc2lyZWQpDQo+IC0gc2FtZSBob2xkcyBmb3IgbmV4dCBk b21haW4NCj4gDQo+IFRoZSBvdGhlciBzaW1wbGUgb3B0aW9uIEkgc2VlIHdpdGhvdXQgYml0IG1h c2sgYmFzZWQgcmUtbWFyayBpcywgYWdhaW4gDQo+IHBlciBUcmVhdG1lbnQgQWdncmVnYXRlOg0K PiAtIGNsYXNzaWZ5IERTQ1BzIGJ5IGJpdC1tYXNrIGF0IGluZ3Jlc3MuDQo+IC0gcmUtbWFyayB0 byBfYSBzaW5nbGUgRFNDUF8gYXQgaW5ncmVzcy4NCj4gLSBEaWZmc2VydiBmb3J3YXJkaW5nIGJ5 IFRyZWF0bWVudCBBZ2dyZWdhdGUNCj4gLSBjbGFzc2lmeSBhbmQgZm9yd2FyZCBieSB0aGlzIHNp bmdsZSBEU0NQIGF0IHRoZSBlZ3Jlc3MNCj4gLSBzYW1lIGhvbGRzIGZvciBuZXh0IGRvbWFpbg0K PiANCj4gSSBwcmVmZXIgYSBzaW1wbGUgc29sdXRpb24gKGFuZCBhIHN0YW5kYXJkaXplZCBvbmUs IGlmIHBvc3NpYmxlKS4gDQoNClNwZWFraW5nIGFzIERpZmZTZXJ2IHB1cmlzdCwgRFNDUCBjbGFz c2lmaWNhdGlvbiBfYnkgYml0LW1hc2tfIGlzIG5vbi1jb25mb3JtaW5nIHRvIFJGQyAyNDc0Lg0K DQo+IE9mIGNvdXJzZSBpdCBpcyB0ZWNobmljYWxseSBwb3NzaWJsZSB0byBzZXQgdXAgYW5kIG1h aW50YWluIHBlciBEU0NQIA0KPiB0byBQSEIgYW5kIGluZGl2aWR1YWwgRFNDUCByZS1tYXJrIHRh YmxlcywgY3VzdG9taXplZCBmb3IgZWFjaCANCj4gaW50ZXJjb25uZWN0aW9uLiBJbnRlcmNvbm5l Y3Rpb24gRFNDUHMgYXJlIG5vdCBzdGFuZGFyZGl6ZWQuDQo+IE1hbnkgY2FycmllcnMgb3BlcmF0 ZSBtdWx0aXBsZSBpbnRlcmNvbm5lY3Rpb25zLiANCg0KVGhlIERpZmZTZXJ2IGFyY2hpdGVjdHVy ZSBpbmRlZWQgcmVxdWlyZXMgdG8gaGF2ZSBhZ3JlZW1lbnRzIGZvciBlYWNoIGludGVyY29ubmVj dGlvbi4gSG93ZXZlciwgaW4gY2FzZSB5b3UgZG9uJ3QgaGF2ZSBuZWdvdGlhdGVkIGFueSBzcGVj aWFsIHRyZWF0bWVudCwgYSBtYXBwaW5nIG9mICJhbnkgRFNDUCAtPiBkZWZhdWx0IFBIQiIgc2hv dWxkIHdvcmsuIEJ1dCBpZiBJIHVuZGVyc3Rvb2QgeW91IGNvcnJlY3RseSwgYW4gaW5jb21pbmcg RFNDUCB4IG1heSBub3QgYmUgYWNjZXB0YWJsZSBmb3IgdGhlIG5leHQgRFMgZG9tYWluLCBzbyB5 b3UgbXVzdCByZW1hcms/DQoNClJlZ2FyZHMsDQogUm9sYW5kDQoNCg== From nobody Wed Aug 2 12:36:40 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1894513215D for ; Wed, 2 Aug 2017 12:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=akamai.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 yQn_Fi40YvsU for ; Wed, 2 Aug 2017 12:36:36 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 94112132152 for ; Wed, 2 Aug 2017 12:36:36 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v72JVRWj025310; Wed, 2 Aug 2017 20:35:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=RGEGaH3WmFCcH4qUFJOnS2UOqyTQs9iEq1uaw2aPSYM=; b=AgT3fUGMLrjMcxOWNYtR3BByNmknwU98Vdlmmh8+4xAOasPaxX3nqc9o+OZ7HumzouY5 oHE0rzfI3BS23eFW/EY/pyYZjJbABGgDKDGbk/RFuJXDrTtzluEwVnk9HNK/qfHYg6qW iJT1jA9e1TGEc1RQUvruvNOccUTv0p/jSrC6/qJTEGfgg2DFC2hGAibAUGuIeyQlpJ91 3SvT0ybGfq++YmpHwpSBX8gMVicb3mPTFiW08q46fP2AcXa5IswKYi8mMkC9M2yyt57t BmA0KkDxkfkM9diqofUPQWp9j/JBER2N+LUUc7wZkk9qQzgB9Wf4+x/CxsRPO6KSlsCZ cQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2c3a96u142-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Aug 2017 20:35:51 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v72JV07V016672; Wed, 2 Aug 2017 15:35:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c0npur3us-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 02 Aug 2017 15:35:50 -0400 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com (172.27.123.104) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 2 Aug 2017 12:35:49 -0700 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com ([172.27.123.104]) by usma1ex-dag1mb4.msg.corp.akamai.com ([172.27.123.104]) with mapi id 15.00.1263.000; Wed, 2 Aug 2017 15:35:49 -0400 From: "Holland, Jake" To: Bob Briscoe , "Black, David" CC: tsvwg IETF list Thread-Topic: [tsvwg] UDP/IP outer as an IP-shim-IP tunnel and AMT as an example Thread-Index: AQHTATpWcMufBKCos0GexqMVi+a8vKJxWFUA Date: Wed, 2 Aug 2017 19:35:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.223] Content-Type: multipart/alternative; boundary="_000_BFEDD3D071B9415F90279A2EED767895akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708020315 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708020315 Archived-At: Subject: Re: [tsvwg] UDP/IP outer as an IP-shim-IP tunnel and AMT as an example X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 19:36:39 -0000 --_000_BFEDD3D071B9415F90279A2EED767895akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQm9iLA0KDQpUaGFua3MgZm9yIGxvb2tpbmcgaW50byBteSBBTVQgcXVlc3Rpb24gYW5kIGZv bGxvd2luZyB1cC4NCg0KQSBmZXcgY29tbWVudHMgYW5kIHF1ZXN0aW9uczoNCjEuIEkgYWdyZWUg dGhhdCB5b3VyIHByb3Bvc2VkIGFkZGl0aW9uIGNvdmVycyBhIGdhcCB0aGF0IHdhcyBpbXBsaWVk IGJ1dCBub3Qgc3RhdGVkIGJ5IHNlY3Rpb24gNC4zIG9mIFJGQyA2MDQwLg0KDQoyLiBJ4oCZbSBu b3QgdW5kZXJzdGFuZGluZyBzb21ldGhpbmc6IHdoYXQgaXMgaXQgYWJvdXQgYSBwcm90b2NvbCB0 aGF0IG1ha2VzIGl0IGEgZ2VuZXJpYyBJUC1pbnNpZGUtVURQIGVuY2Fwc3VsYXRpb24gdGhhdCBk b2VzbuKAmXQgbmVlZCB0byBiZSBleHBsaWNpdGx5IG1lbnRpb25lZCBieSB0aGUgc2hpbS11cGRh dGUsIHZzLiBlbmNhcHN1bGF0aW9ucyB0aGF0IGRvIG5lZWQgYW4gZXhwbGljaXQgdXBkYXRlPw0K DQpNYXliZSBJ4oCZbSBtaXN1bmRlcnN0YW5kaW5nLCBidXQgYW4gQU1UIERhdGEgcGFja2V0ICho dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQ1MCNzZWN0aW9uLTUuMS42KSBvbiB0aGUg d2lyZSBsb29rcyBsaWtlIFtMMl0tSVAtVURQLUFNVC1JUC0uLi4sIGFuZCBJIHRoaW5rIGl04oCZ cyBjb3JyZWN0IHRoYXQgdGhlIG5ldyBFQ04gcmVxdWlyZW1lbnRzIGluIHNlY3Rpb24gNCB3b3Vs ZCBhcHBseSBpbiBhIHdheSB0aGF0IEkgZG9u4oCZdCBzZWUgaG93IGl04oCZcyBkaWZmZXJlbnQg ZnJvbSBHUkUgb3IgVGVyZWRvLiAoRXhjZXB0IG1heWJlIHRoYXQgaXTigJlzIHVubGlrZWx5IGV2 ZXIgdG8gY2FycnkgVENQIGluIHRoZSBpbm5lciBJUDsgaXMgdGhhdCB0aGUgZGlzdGluZ3Vpc2hp bmcgZmFjdG9yPykNCg0KZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0tMDQgcHJv cG9zZXMgdG8gdXBkYXRlIFRlcmVkbyBhbmQgR1JFIGJ1dCBub3QgQU1ULCBldmVuIHRob3VnaCBp dCBzZWVtcyBmcm9tIHNlY3Rpb24gNS4xIHRoYXQgYm90aCBHUkUgYW5kIFRlcmVkbyBhbHNvIGhh dmUgdGhlIHNhbWUga2luZCBvZiDigJxwcm9iYWJseSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMg YXJlIGFscmVhZHkgY29tcGF0aWJsZS1tb2RlIGluIHByYWN0aWNl4oCdIHN0YXR1cyB1bmRlciBS RkMgNjA0MC4gQnV0IEnigJltIG5vdCBjbGVhciBvbiB3aHkgc29tZSBvZiB0aGUgcHJvdG9jb2xz IGdldCBhbiBleHBsaWNpdCBtZW50aW9uIGFuZCBvdGhlcnMgZG9u4oCZdC4NCg0KMy4gUmVsYXRl ZDogV2hhdCBtYWtlcyBpdCBpbXByYWN0aWNhbCB0byB1cGRhdGUgYWxsIHRoZSBJUC1pbnNpZGUt VURQIFJGQ3M/DQoNCkl0IHNlZW1zIHRvIG1lIGxpa2UgaXQgd291bGQgYmUgdXNlZnVsLCBiZWNh dXNlIHdoZXRoZXIgSeKAmW0gYW4gaW1wbGVtZW50ZXIgb3IgYSBuZXR3b3JrIG9wZXJhdG9yLCBp ZiBJIGltcGxlbWVudCBvciBkZXBsb3kgYSBwcm90b2NvbCBzdWNoIGFzIEFNVCwgdG9kYXkgSSBn ZXQgbm8gaGludCBmcm9tIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDUwIG9yIGZy b20gdGhlIFJGQyBpbmRleCB0aGF0IEkgaGF2ZSBhbnkgcmVzcG9uc2liaWxpdGllcyByZWdhcmRp bmcgRUNOLg0KDQpCdXQgaWYgdGhlIHBhZ2UgZm9yIFJGQyA3NDUwIGhhZCB0aGUg4oCcVXBkYXRl ZCBieeKAnSBsaW5rIGF0IHRoZSB0b3AgcG9pbnRpbmcgdG8gdGhlIG5ldyB1cGRhdGUtc2hpbSBk b2N1bWVudCwgYm90aCB0aGVzZSBjYXNlcyBzZWVtIG11Y2ggbW9yZSBsaWtlbHkgdG8gaGF2ZSB0 aGVpciBFQ04gYmVoYXZpb3IgY29uc2lkZXJlZCBkdXJpbmcgYSBub3JtYWwgcm91bmQgb2YgZHVl IGRpbGlnZW5jZS4NCg0KSXQgYWxzbyBzZWVtcyBqdXN0aWZpYWJsZSB0byB1cGRhdGUgYWxsIHN1 Y2ggcHJvdG9jb2xzLCBiZWNhdXNlIHNlY3Rpb24gNCBvZiBkcmFmdC1pZXRmLXRzdndnLXJmYzYw NDB1cGRhdGUtc2hpbS0wNCBkb2VzIGltcG9zZSBuZXcgcmVxdWlyZW1lbnRzLCBldmVuIGlmIChh cyBzZWN0aW9uIDQgYXJndWVzKSB0aGUgcmVxdWlyZW1lbnRzIGFyZSBub3QgZXhwZWN0ZWQgdG8g Y2hhbmdlIGFueSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbuKAmXMgYWN0dWFsIGNvbXBsaWFuY2Ug c3RhdHVzLCBzaW5jZSBpdOKAmXMgcHJvYmFibHkgYWxyZWFkeSBkb2luZyBjb21wYXRpYmxlLW1v ZGUuDQoNCklzIHRoZXJlIGEgZ29vZCBsaXN0IG9mIGV4aXN0aW5nIElQLXNoaW0tSVAgdHVubmVs IHByb3RvY29scyB0aGF0IHRoZSA2MDQwIHVwZGF0ZS1zaGltIGRvY3VtZW50IGFwcGxpZXMgdG8/ IElzIGl0IGZlYXNpYmxlIHRvIGluY2x1ZGUgb25lIGluIHRoaXMgZG9jdW1lbnQsIHdoZXRoZXIg b3Igbm90IHRoaXMgZG9jdW1lbnQgd2lsbCBleHBsaWNpdGx5IHVwZGF0ZSB0aGVtPw0KDQpUb2Rh eSB0aGF0IHByb2plY3Qgc2VlbXMgdG8gYmUgbGVmdCBhcyBhbiBleGVyY2lzZSBmb3IgdGhlIG5l dHdvcmsgb3BlcmF0b3IsIGlmIFJGQzgwODUvQkNQMTQ1IGlzIHRoZSBzdWdnZXN0ZWQgYW5zd2Vy Lg0KDQpLaW5kIHJlZ2FyZHMsIGFuZCB0aGFua3MgYWdhaW4uDQoNCkpha2UNCg0KDQpPbiA3LzIw LzE3LCAyOjI2IEFNLCAiQm9iIEJyaXNjb2UiIDxpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0bzpp ZXRmQGJvYmJyaXNjb2UubmV0Pj4gd3JvdGU6DQoNCkRhdmlkIChhcyBkb2Mgc2hlcGhlcmQpLA0K DQpJbiB0aGUgdHN2d2cgbXRnIG9uVHVlLCBpdCB3YXMgc3VnZ2VzdGVkIHRoYXQgQU1UIG91Z2h0 IHRvIGJlIGluY2x1ZGVkIGluIHRoZSBsaXN0IG9mIFJGQ3MgdGhhdCBkZWZpbmUgYSBuZXcgSVAt c2hpbS1JUCB0dW5uZWxsaW5nIHByb3RvY29sLg0KDQpJIHNhaWQgdGhhdCBJIGhhZCBhY3R1YWxs eSBsb29rZWQgYXQgdGhpcyBhbmQgZGVjaWRlZCBub3QgdG8gaW5jbHVkZSBpdC4gSSBub3cgcmVt ZW1iZXIgd2h5LiBJdCB3YXMgY29zIEFNVCBpcyBqdXN0IHVzaW5nIFVEUC1JUCBlbmNhcHN1bGF0 aW9uLCBub3QgcmVhbGx5IGRlZmluaW5nIGEgbmV3IGVuY2Fwc3VsYXRpb24uDQoNCk5vbmV0aGVs ZXNzIHRoYW5rcyB0byB0aGUgZ3V5IHdobyBjYW1lIHRvIHRoZSBtaWMgKHNyeSBJIGNhbid0IHJl bWVtYmVyIHRoZSBuYW1lIC0gSSB0aGluayBmcm9tIEFrYW1haSkgZm9yIG1ha2luZyBtZSByZXZp c2l0IHRoaXMuIEl0IGlkZW50aWZpZXMgYSBnYXA6IHJmYzYwNDB1cGRhdGUtc2hpbSBkb2Vzbid0 IG1lbnRpb24gZ2VuZXJhbCB1c2Ugb2YgVURQLUlQIGVuY2Fwc3VsYXRpb24uIEl0IG9ubHkgbWVu dGlvbnMgdGhlIHNwZWNpZmljIGNhc2Ugb2YgR1VFIChnZW5lcmljIFVEUCBlbmNhcHN1bGF0aW9u KS4NCg0KVGhlIHdheSBJIHByb3Bvc2UgdG8gaGFuZGxlIHRoaXMgaXMgdG8gYWRkIGEgYnVsbGV0 IGluIDUuICBJUC1pbi1JUCBUdW5uZWxzIHdpdGggVGlnaHRseSBDb3VwbGVkIFNoaW0gSGVhZGVy czxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rv b2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEdHN2d2ctMkRyZmM2MDQwdXBkYXRlLTJE c2hpbS0yRDA0LTIzc2VjdGlvbi0yRDUmZD1Ed01EYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpn JnI9YnFuRlJPaXZEb180aUY4WjNSNER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZtPVZNMzJWVU8w OFVGOFFuYTJOMksyTGVYWGF4RUp1UzViWGFXeGx2S1NTYWMmcz1ESGo0REV6VC10ZE5LZ0tKa3VE N3dyeXpLVFpDRXlzVGNxMVhuU1V3dkdvJmU9PiBmb3IgVURQIHR1bm5lbHMuIFRoZW4gYWRkIHRo ZSBmb2xsb3dpbmcgY292ZXJpbmcgZ2VuZXJhbCB1c2Ugb2YgVURQLUlQIGVuY2Fwc3VsYXRpb24s IGdpdmluZyBBTVQgYXMgb25lIGV4YW1wbGUgb2YgaXQ6DQoNCiAgICAgIDUuMS54IFVEUCBUdW5u ZWxzDQoNCg0KDQogICAgICBTZWN0aW9uIDMuMS4xMSBvZiB0aGUgVURQIHVzYWdlIGd1aWRlbGlu ZXMgaW4gUkZDIDgwODUgYWxyZWFkeQ0KDQogICAgICBleHBsYWlucyB0aGF0IGEgdHVubmVsIHRo YXQgZW5jYXBzdWxhdGVzIGFuIElQIGhlYWRlciB3aXRoaW4gYQ0KDQogICAgICBVRFAvSVAgZGF0 YWdyYW0sIGUuZy4gQXV0b21hdGljIE11bHRpY2FzdCBUdW5uZWxpbmcgKEFNVA0KDQogICAgICBb UkZDNzQ1MF0pLCBuZWVkcyB0byBmb2xsb3cgUkZDIDYwNDAgd2hlbiBwcm9wYWdhdGluZyB0aGUg RUNODQoNCiAgICAgIGZpZWxkIGJldHdlZW4gaW5uZXIgYW5kIG91dGVyIElQIGhlYWRlcnMuDQoN Cg0KDQogICAgICBUaGUgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gNCB1cGRhdGUgUkZDIDYwNDAs IHNvIHRoZXkgYWRkDQoNCiAgICAgIHRoZSBpbXBvcnRhbnQsIGJ1dCBwcmV2aW91c2x5IHVuc3Rh dGVkIHJlcXVpcmVtZW50IHRoYXQsIGlmDQoNCiAgICAgIHRoZSBVRFAgdHVubmVsIGVncmVzcyBk b2VzIG5vdCwgb3IgbWlnaHQgbm90LCBzdXBwb3J0IEVDTg0KDQogICAgICBwcm9wYWdhdGlvbiwg YSBsZWdhY3kgVURQIHR1bm5lbCBpbmdyZXNzIGhhcyB0byB6ZXJvIHRoZSBvdXRlcg0KDQogICAg ICBFQ04gZmllbGQsIGUuZy4gYnkgY29uZmlndXJhdGlvbi4NCg0KDQpEbyBhbnkgUkZDJ3MgbmVl ZCB0byBiZSB1cGRhdGVkPyBOby4NCkdpdmVuIHRoZSBVRFAgdHVubmVsbGluZyBzZWN0aW9uIG9m IFJGQyA4MDg1IChVRFAgdXNhZ2UgZ3VpZGVsaW5lcykgYWxyZWFkeSByZWZlcnMgdG8gUkZDIDYw NDAsIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB1cGRhdGUgZXZlcnkgUkZDIHRoYXQgdXNlcyBV RFAgVHVubmVsbGluZyB0byByZWZlciB0byBSRkMgNjA0MC4NCg0KSXQgd291bGQgYmUgaWRlYWws IGJ1dCBwZXJoYXBzIGltcHJhY3RpY2FsLg0KDQoNCg0KQm9iDQoNCg0KLS0NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJp c2NvZS5uZXQvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw LTNBX19ib2JicmlzY29lLm5ldF8mZD1Ed01EYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9 YnFuRlJPaXZEb180aUY4WjNSNER5TldLYmJNZVhyMExPZ0xuRWxUMU9vayZtPVZNMzJWVU8wOFVG OFFuYTJOMksyTGVYWGF4RUp1UzViWGFXeGx2S1NTYWMmcz1zTG1NSWExcGE0ODhuX0c1UFVwTG91 MGFZYUZ3WHhTWXowTjlhaVNldXcwJmU9Pg0K --_000_BFEDD3D071B9415F90279A2EED767895akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <9E70B7721522DB47996744EE012C1230@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvdXJpZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSBCb2IsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+VGhhbmtzIGZvciBsb29raW5nIGludG8gbXkgQU1UIHF1ZXN0aW9uIGFuZCBmb2xsb3dpbmcg dXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QSBmZXcgY29tbWVudHMgYW5kIHF1ZXN0aW9u czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4xLiBJIGFncmVlIHRoYXQg eW91ciBwcm9wb3NlZCBhZGRpdGlvbiBjb3ZlcnMgYSBnYXAgdGhhdCB3YXMgaW1wbGllZCBidXQg bm90IHN0YXRlZCBieSBzZWN0aW9uIDQuMyBvZiBSRkMgNjA0MC4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjIuIEnigJltIG5vdCB1bmRlcnN0YW5kaW5nIHNvbWV0aGluZzogd2hhdCBpcyBp dCBhYm91dCBhIHByb3RvY29sIHRoYXQgbWFrZXMgaXQgYSBnZW5lcmljIElQLWluc2lkZS1VRFAg ZW5jYXBzdWxhdGlvbiB0aGF0IGRvZXNu4oCZdCBuZWVkIHRvIGJlIGV4cGxpY2l0bHkgbWVudGlv bmVkIGJ5IHRoZSBzaGltLXVwZGF0ZSwgdnMuDQogZW5jYXBzdWxhdGlvbnMgdGhhdCBkbyBuZWVk IGFuIGV4cGxpY2l0IHVwZGF0ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5NYXliZSBJ4oCZ bSBtaXN1bmRlcnN0YW5kaW5nLCBidXQgYW4gQU1UIERhdGEgcGFja2V0ICg8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQ1MCNzZWN0aW9uLTUuMS42KSI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc0NTAjc2VjdGlvbi01LjEuNik8L2E+IG9uIHRoZSB3aXJl IGxvb2tzDQogbGlrZSBbTDJdLUlQLVVEUC1BTVQtSVAtLi4uLCBhbmQgSSB0aGluayBpdOKAmXMg Y29ycmVjdCB0aGF0IHRoZSBuZXcgRUNOIHJlcXVpcmVtZW50cyBpbiBzZWN0aW9uIDQgd291bGQg YXBwbHkgaW4gYSB3YXkgdGhhdCBJIGRvbuKAmXQgc2VlIGhvdyBpdOKAmXMgZGlmZmVyZW50IGZy b20gR1JFIG9yIFRlcmVkby4gKEV4Y2VwdCBtYXliZSB0aGF0IGl04oCZcyB1bmxpa2VseSBldmVy IHRvIGNhcnJ5IFRDUCBpbiB0aGUgaW5uZXIgSVA7IGlzIHRoYXQgdGhlIGRpc3Rpbmd1aXNoaW5n DQogZmFjdG9yPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5kcmFmdC1pZXRmLXRzdndnLXJm YzYwNDB1cGRhdGUtc2hpbS0wNCBwcm9wb3NlcyB0byB1cGRhdGUgVGVyZWRvIGFuZCBHUkUgYnV0 IG5vdCBBTVQsIGV2ZW4gdGhvdWdoIGl0IHNlZW1zIGZyb20gc2VjdGlvbiA1LjEgdGhhdCBib3Ro IEdSRSBhbmQgVGVyZWRvIGFsc28gaGF2ZSB0aGUgc2FtZSBraW5kIG9mIOKAnHByb2JhYmx5DQog ZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IGNvbXBhdGlibGUtbW9kZSBpbiBw cmFjdGljZeKAnSBzdGF0dXMgdW5kZXIgUkZDIDYwNDAuIEJ1dCBJ4oCZbSBub3QgY2xlYXIgb24g d2h5IHNvbWUgb2YgdGhlIHByb3RvY29scyBnZXQgYW4gZXhwbGljaXQgbWVudGlvbiBhbmQgb3Ro ZXJzIGRvbuKAmXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+My4gUmVsYXRlZDogV2hhdCBt YWtlcyBpdCBpbXByYWN0aWNhbCB0byB1cGRhdGUgYWxsIHRoZSBJUC1pbnNpZGUtVURQIFJGQ3M/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SXQgc2VlbXMgdG8gbWUgbGlrZSBpdCB3b3VsZCBi ZSB1c2VmdWwsIGJlY2F1c2Ugd2hldGhlciBJ4oCZbSBhbiBpbXBsZW1lbnRlciBvciBhIG5ldHdv cmsgb3BlcmF0b3IsIGlmIEkgaW1wbGVtZW50IG9yIGRlcGxveSBhIHByb3RvY29sIHN1Y2ggYXMg QU1ULCB0b2RheSBJIGdldCBubyBoaW50IGZyb20gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc0NTANCiBvciBmcm9tIHRoZSBSRkMgaW5kZXggdGhhdCBJIGhhdmUgYW55IHJlc3BvbnNp YmlsaXRpZXMgcmVnYXJkaW5nIEVDTi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5CdXQgaWYg dGhlIHBhZ2UgZm9yIFJGQyA3NDUwIGhhZCB0aGUg4oCcVXBkYXRlZCBieeKAnSBsaW5rIGF0IHRo ZSB0b3AgcG9pbnRpbmcgdG8gdGhlIG5ldyB1cGRhdGUtc2hpbSBkb2N1bWVudCwgYm90aCB0aGVz ZSBjYXNlcyBzZWVtIG11Y2ggbW9yZSBsaWtlbHkgdG8gaGF2ZSB0aGVpciBFQ04gYmVoYXZpb3Ig Y29uc2lkZXJlZA0KIGR1cmluZyBhIG5vcm1hbCByb3VuZCBvZiBkdWUgZGlsaWdlbmNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkl0IGFsc28gc2VlbXMganVzdGlmaWFibGUgdG8gdXBkYXRl IGFsbCBzdWNoIHByb3RvY29scywgYmVjYXVzZSBzZWN0aW9uIDQgb2YgZHJhZnQtaWV0Zi10c3Z3 Zy1yZmM2MDQwdXBkYXRlLXNoaW0tMDQgZG9lcyBpbXBvc2UgbmV3IHJlcXVpcmVtZW50cywgZXZl biBpZiAoYXMgc2VjdGlvbiA0IGFyZ3VlcykgdGhlIHJlcXVpcmVtZW50cw0KIGFyZSBub3QgZXhw ZWN0ZWQgdG8gY2hhbmdlIGFueSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbuKAmXMgYWN0dWFsIGNv bXBsaWFuY2Ugc3RhdHVzLCBzaW5jZSBpdOKAmXMgcHJvYmFibHkgYWxyZWFkeSBkb2luZyBjb21w YXRpYmxlLW1vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SXMgdGhlcmUgYSBnb29kIGxp c3Qgb2YgZXhpc3RpbmcgSVAtc2hpbS1JUCB0dW5uZWwgcHJvdG9jb2xzIHRoYXQgdGhlIDYwNDAg dXBkYXRlLXNoaW0gZG9jdW1lbnQgYXBwbGllcyB0bz8gSXMgaXQgZmVhc2libGUgdG8gaW5jbHVk ZSBvbmUgaW4gdGhpcyBkb2N1bWVudCwgd2hldGhlciBvciBub3QgdGhpcyBkb2N1bWVudA0KIHdp bGwgZXhwbGljaXRseSB1cGRhdGUgdGhlbT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Ub2Rh eSB0aGF0IHByb2plY3Qgc2VlbXMgdG8gYmUgbGVmdCBhcyBhbiBleGVyY2lzZSBmb3IgdGhlIG5l dHdvcmsgb3BlcmF0b3IsIGlmIFJGQzgwODUvQkNQMTQ1IGlzIHRoZSBzdWdnZXN0ZWQgYW5zd2Vy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPktpbmQgcmVnYXJkcywgYW5kIHRoYW5rcyBhZ2Fp bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5KYWtlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiA3LzIwLzE3LCAyOjI2IEFNLCAmcXVvdDtCb2IgQnJpc2NvZSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPmlldGZAYm9iYnJpc2NvZS5u ZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RGF2aWQgKGFzIGRv YyBzaGVwaGVyZCksPGJyPg0KPGJyPg0KSW4gdGhlIHRzdndnIG10ZyBvblR1ZSwgaXQgd2FzIHN1 Z2dlc3RlZCB0aGF0IEFNVCBvdWdodCB0byBiZSBpbmNsdWRlZCBpbiB0aGUgbGlzdCBvZiBSRkNz IHRoYXQgZGVmaW5lIGEgbmV3IElQLXNoaW0tSVAgdHVubmVsbGluZyBwcm90b2NvbC48YnI+DQo8 YnI+DQpJIHNhaWQgdGhhdCBJIGhhZCBhY3R1YWxseSBsb29rZWQgYXQgdGhpcyBhbmQgZGVjaWRl ZCBub3QgdG8gaW5jbHVkZSBpdC4gSSBub3cgcmVtZW1iZXIgd2h5LiBJdCB3YXMgY29zIEFNVCBp cyBqdXN0IHVzaW5nIFVEUC1JUCBlbmNhcHN1bGF0aW9uLCBub3QgcmVhbGx5IGRlZmluaW5nIGEg bmV3IGVuY2Fwc3VsYXRpb24uPGJyPg0KPGJyPg0KTm9uZXRoZWxlc3MgdGhhbmtzIHRvIHRoZSBn dXkgd2hvIGNhbWUgdG8gdGhlIG1pYyAoc3J5IEkgY2FuJ3QgcmVtZW1iZXIgdGhlIG5hbWUgLSBJ IHRoaW5rIGZyb20gQWthbWFpKSBmb3IgbWFraW5nIG1lIHJldmlzaXQgdGhpcy4gSXQgaWRlbnRp ZmllcyBhIGdhcDogcmZjNjA0MHVwZGF0ZS1zaGltIGRvZXNuJ3QgbWVudGlvbiBnZW5lcmFsIHVz ZSBvZiBVRFAtSVAgZW5jYXBzdWxhdGlvbi4gSXQgb25seSBtZW50aW9ucyB0aGUgc3BlY2lmaWMg Y2FzZQ0KIG9mIEdVRSAoZ2VuZXJpYyBVRFAgZW5jYXBzdWxhdGlvbikuPGJyPg0KPGJyPg0KVGhl IHdheSBJIHByb3Bvc2UgdG8gaGFuZGxlIHRoaXMgaXMgdG8gYWRkIGEgYnVsbGV0IGluIDxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f dG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkR0c3Z3Zy0yRHJmYzYwNDB1cGRhdGUt MkRzaGltLTJEMDQtMjNzZWN0aW9uLTJENSZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZaYlpaY2FNRjR3 MEY0anBONkxaZyZhbXA7cj1icW5GUk9pdkRvXzRpRjhaM1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQx T29rJmFtcDttPVZNMzJWVU8wOFVGOFFuYTJOMksyTGVYWGF4RUp1UzViWGFXeGx2S1NTYWMmYW1w O3M9REhqNERFelQtdGROS2dLSmt1RDd3cnl6S1RaQ0V5c1RjcTFYblNVd3ZHbyZhbXA7ZT0iPg0K NS4mbmJzcDsgSVAtaW4tSVAgVHVubmVscyB3aXRoIFRpZ2h0bHkgQ291cGxlZCBTaGltIEhlYWRl cnM8L2E+IGZvciBVRFAgdHVubmVscy4gVGhlbiBhZGQgdGhlIGZvbGxvd2luZyBjb3ZlcmluZyBn ZW5lcmFsIHVzZSBvZiBVRFAtSVAgZW5jYXBzdWxhdGlvbiwgZ2l2aW5nIEFNVCBhcyBvbmUgZXhh bXBsZSBvZiBpdDo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDUuMS54IFVEUCBUdW5uZWxzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rp b24gMy4xLjExIG9mIHRoZSBVRFAgdXNhZ2UgZ3VpZGVsaW5lcyBpbiBSRkMgODA4NSBhbHJlYWR5 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO2V4 cGxhaW5zIHRoYXQgYSB0dW5uZWwgdGhhdCBlbmNhcHN1bGF0ZXMgYW4gSVAgaGVhZGVyIHdpdGhp biBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw O1VEUC9JUCBkYXRhZ3JhbSwgZS5nLiBBdXRvbWF0aWMgTXVsdGljYXN0IFR1bm5lbGluZyAoQU1U IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO1tSRkM3NDUwXSksIG5lZWRzIHRvIGZvbGxvdyBSRkMgNjA0MCB3aGVuIHByb3BhZ2F0aW5n IHRoZSBFQ048bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7ZmllbGQgYmV0d2VlbiBpbm5lciBhbmQgb3V0ZXIgSVAgaGVhZGVycy48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgVGhlIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDQgdXBkYXRlIFJG QyA2MDQwLCBzbyB0aGV5IGFkZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0aGUgaW1wb3J0YW50LCBidXQgcHJldmlvdXNseSB1bnN0YXRlZCBy ZXF1aXJlbWVudCB0aGF0LCBpZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0aGUgVURQIHR1bm5lbCBlZ3Jlc3MgZG9lcyBub3QsIG9yIG1pZ2h0 IG5vdCwgc3VwcG9ydCBFQ04gPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvcGFnYXRpb24sIGEgbGVnYWN5IFVEUCB0dW5uZWwgaW5n cmVzcyBoYXMgdG8gemVybyB0aGUgb3V0ZXIgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RUNOIGZpZWxkLCBlLmcuIGJ5IGNvbmZpZ3Vy YXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkRvIGFueSBSRkMncyBuZWVkIHRvIGJlIHVwZGF0ZWQ/IE5vLjxi cj4NCkdpdmVuIHRoZSBVRFAgdHVubmVsbGluZyBzZWN0aW9uIG9mIFJGQyA4MDg1IChVRFAgdXNh Z2UgZ3VpZGVsaW5lcykgYWxyZWFkeSByZWZlcnMgdG8gUkZDIDYwNDAsIEkgZG9uJ3QgdGhpbmsg d2UgbmVlZCB0byB1cGRhdGUgZXZlcnkgUkZDIHRoYXQgdXNlcyBVRFAgVHVubmVsbGluZyB0byBy ZWZlciB0byBSRkMgNjA0MC48YnI+DQo8YnI+DQpJdCB3b3VsZCBiZSBpZGVhbCwgYnV0IHBlcmhh cHMgaW1wcmFjdGljYWwuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fYm9iYnJpc2NvZS5u ZXRfJmFtcDtkPUR3TURhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPWJxbkZS T2l2RG9fNGlGOFozUjREeU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smYW1wO209Vk0zMlZVTzA4VUY4 UW5hMk4ySzJMZVhYYXhFSnVTNWJYYVd4bHZLU1NhYyZhbXA7cz1zTG1NSWExcGE0ODhuX0c1UFVw TG91MGFZYUZ3WHhTWXowTjlhaVNldXcwJmFtcDtlPSI+aHR0cDovL2JvYmJyaXNjb2UubmV0Lzwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BFEDD3D071B9415F90279A2EED767895akamaicom_-- From nobody Wed Aug 2 16:19:36 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766D91321A0 for ; Wed, 2 Aug 2017 16:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGIQ9ctumXLZ for ; Wed, 2 Aug 2017 16:19:34 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117B3131C89 for ; Wed, 2 Aug 2017 16:19:34 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id c14so27037812pgn.0 for ; Wed, 02 Aug 2017 16:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KB1JvVidHWXRry8eRKC8o6DY3ncAEXXzuOeHLB/RYVs=; b=rWqf0AU50rWIsX4KiQxKdIcmFXvgSlSvj9M9E1SaSc6XsTlBYaQ/lqIBbnm0lEnP7P rAripMBb7jfincpZq3H96p7UYWu02Q6z8jrLiXJKHFNwCh3ZzfmZFGvdDM0qI9pNoU7P /m79KOwXEvywtcAPB2m383BsNTJnkUa1ibv2lzanbMwlkowhzLJ02t87wRWRLkdqAs+6 0ZQSOviMdzvi6SpPKptOt/mvt7glyLufjnAG6PA+BmCqs44N1/r0eq9Fs37mUa1sXxdx hZilmHMDh5ENa/MTPeztR5NFrpA1ASfWz08QC/dkMX/3t1X8zlQHbHEVNxu4bADB+EQ2 tDAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KB1JvVidHWXRry8eRKC8o6DY3ncAEXXzuOeHLB/RYVs=; b=PWuS9Lhxr0Masz+pRdzI4ToefR66lvKOJMtxCzPR9XqRjuvbispJVTtUBrCa3zBlXF +sO4qPs4uxOHbpW2ybYwvhsSu8UiyL3dIrMuBy3GobtdZWS8s/3+pxBs1QeQGugQgo6L kzC/hM/++Nl1HHu64uUdYmmzbDrp7NqDjvt6K/Kt0dK2oba5Z6BAWWnNOC8eM+qL3asg Ah6o2DeRI/2069Li75BC5Whffz8/YFovkRDGkFjuKmAcwPtGodlgo04Kr/dXD3wpj37P ZpDEuXWs01kUdxky/rlVpF7d5OtwuYBCBwPzH507FLZSLMk4WPGkpngu+6NYMF4Y9Kxr fQWA== X-Gm-Message-State: AIVw111hDrmCeAwM+s46osFaoI/sFzz/FbSWpbNxUCrJaXZDZi/kfNEe xWlOP8jbCkLTiLX7 X-Received: by 10.98.23.69 with SMTP id 66mr24888188pfx.305.1501715972878; Wed, 02 Aug 2017 16:19:32 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o29sm63238135pfa.60.2017.08.02.16.19.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 16:19:32 -0700 (PDT) To: "Bless, Roland (TM)" , Ruediger.Geib@telekom.de, gorry@erg.abdn.ac.uk Cc: tsvwg@ietf.org References: <595F4D19.9030502@erg.abdn.ac.uk> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <483f53cf-f001-12c7-002f-7fb7fd1ef3f7@gmail.com> Date: Thu, 3 Aug 2017 11:19:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 23:19:35 -0000 One small remark near the end: On 02/08/2017 19:40, Bless, Roland (TM) wrote: > Hi, > > comments inline. > > Am 01.08.2017 um 22:28 schrieb Brian E Carpenter: >> On 01/08/2017 20:52, Bless, Roland (TM) wrote: >>> Hi, >>> >>> Am 01.08.2017 um 10:22 schrieb Ruediger.Geib@telekom.de:> GF> There >>> seems evidence that there are still even now deployed routers >>>> that have not adjusted their remarking behaviour after the IETF >>>> deprecated ToS Precedence bleaching. >>>> >>>> [RG2] True. I prefer a core-router to be able to re-mark DSCPs by bit-mask at >>>> interconnection interfaces rather than DSCP by DSCP. The config effort to customize >>>> re-marking on a DSCP by DSCP basis is high. An easy to configure alternative is to classify >>>> by bit-mask and re-mark to a single DSCP. Gorry, do you have any preference here? >>> >>> Hmm, RFC2474 states that the DSCP is unstructured: >>> "The DSCP field is defined as an >>> unstructured field to facilitate the definition of future per-hop >>> behaviors. >>> >>> With some exceptions noted below, the mapping of codepoints to PHBs >>> MUST be configurable. A DS-compliant node MUST support the logical >>> equivalent of a configurable mapping table from codepoints to PHBs" >> >> This is the fundamental point (and it is entirely the result of ISP >> people who were active in the diffserv WG that we have this rule, by the >> way). If an operator doesn't support this, anything can happen. >> >> DSCPs are not end-to-end. DSCP to behaviour mappings are not end-to-end. >> If you ignore this, things *will* go wrong. Trying to arrange things so >> that some arbitrary bit-masking of DCSP values will produce predictable >> results *will* fail in some cases. I think it's futile. >> >> Fundamentally I don't care which arbitrary bit pattern is recommended >> for LE, as long as it doesn't clash with a CS code point. But if >> you encroach on pool 3 I think that requires a formal update to RFC2474 >> or at least some very careful wording of the IANA considerations. > > I'm not sure that the experienced behavior is actually better if we use > a DSCP from pool 3, since it may already be used in some domain > internally for local use. True, but the original hope was that people would prefer pool 2 for local use, since there is an explicit statement in RFC2474 that pool 3 may be released for standardisation. So pool 3 is the best choice if we go outside pool 1. In any case, a domain that is actively using the local-use space presumably understands the rules about re-marking at the domain boundary. The real problem we have is with domains that don't perform correct re-marking and/or use lazy solutions for mapping to the 3 bits available in MPLS. Brian >>> IMHO it shouldn't be difficult to have a mapping table >>> from each DSCP to a PHB. The mapping table should >>> initially only contain mappings to the default PHB >>> (no need to remark anything then). >>> Configuring DSCP remarking by using bitmasks is IMHO >>> not RFC2474 compliant and a broken concept causing >>> the trouble we just ran into. >> >> And you shouldn't fix broken products by fiddling with a standard; >> that rewards the makers of broken products. > > +1 > > Regards, > Roland > > . > From nobody Fri Aug 4 16:28:52 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 808AA129AD3; Fri, 4 Aug 2017 16:28:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150188933148.18701.4807220216565950086@ietfa.amsl.com> Date: Fri, 04 Aug 2017 16:28:51 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 23:28:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Explicit Congestion Notification (ECN) Experimentation Author : David Black Filename : draft-ietf-tsvwg-ecn-experimentation-04.txt Pages : 17 Date : 2017-08-04 Abstract: This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC 3168 that would otherwise hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, and provides the rationale for reclassification of RFC 3540 as Historic; this reclassification enables new experimental use of the ECT(1) codepoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-04 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-04 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/ From nobody Fri Aug 4 16:32:18 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A38129ACD for ; Fri, 4 Aug 2017 16:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, 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=dell.com header.b=ydMMAsQt; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=xbLHZgRa 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 me_McUYkYC_V for ; Fri, 4 Aug 2017 16:32:14 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 C0AE0129A84 for ; Fri, 4 Aug 2017 16:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1501889534; x=1533425534; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/n2LLFuWgtfcv2ThoBFom+QD8lzo5L3ENOFsbPfDJ6M=; b=ydMMAsQtvwHGHHeRuRhL/IKrMKozVoKjjWJT1ddvWVU80KEI96LFzMEh gy2/zkZfUcoAUt8S3aHxX8MsXzP2SASiJo+XUVY68wPKM36qdaPMqKK6e S0xlkIYZgsMsE7k4IQEyp/E0Tbrk9MAutmFo9x833S74M3rg/CeMzOavJ 0=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 18:32:14 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2017 05:32:13 +0600 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v74NWCsp021732 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 4 Aug 2017 19:32:12 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v74NWCsp021732 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1501889533; bh=fPhEbRReYXubfh7sGz9r13vH2mk=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=xbLHZgRa5hOeClcJ1BYPyG4YDmUqKwhmyhoTkFo5+G0e/81ngkgKbm4jmFqvqk9dy AYbnm/MePIcp6h4dLMI6Ym+dcEZSVAFNAtEbxRB++Be7Uz9fytJ4EOb2x3PAPXm6qh S64N8s0QKKXmlwuaim0+LQELJj+03caKdloE8c2M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v74NWCsp021732 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd05.lss.emc.com (RSA Interceptor) for ; Fri, 4 Aug 2017 19:31:37 -0400 Received: from MXHUB316.corp.emc.com (MXHUB316.corp.emc.com [10.146.3.94]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v74NVvk6003423 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 4 Aug 2017 19:31:57 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB316.corp.emc.com ([10.146.3.94]) with mapi id 14.03.0352.000; Fri, 4 Aug 2017 19:31:57 -0400 To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt Thread-Index: AQHTDXlyRDBbyXtyZE66Nv6lP4qgYqJ02CNw Date: Fri, 4 Aug 2017 23:31:56 +0000 Message-ID: References: <150188933148.18701.4807220216565950086@ietfa.amsl.com> In-Reply-To: <150188933148.18701.4807220216565950086@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.127] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 23:32:17 -0000 QXMgZGlzY3Vzc2VkIGluIFByYWd1ZSwgdGhpcyBpcyBhIHNtYWxsIHVwZGF0ZSB0byByZXF1ZXN0 IHRoYXQgSUFOQSByZW1vdmUgdGhlIHJlZ2lzdHJhdGlvbiBvZiB0aGUgVENQIGhlYWRlciBmbGFn IHVzZWQgYnkgUkZDIDM1NDAgKEVDTiBOb25jZSkuICAgQW55IHJlYXNzaWdubWVudCBvZiB0aGF0 IGZsYWcgd2lsbCBiZSBoYW5kbGVkIGJ5IHRoZSBUQ1BNIFdHLiAgVGhpcyB1cGRhdGUgYWxzbyBj aGFuZ2VzIHRoZSBuYW1lIG9mIG9uZSBvZiB0aGUgYXJlYXMgb2YgRUNOIGV4cGVyaW1lbnRhdGlv biB0byBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgbmFtZSBvZiB0aGUgZXhwZXJpbWVudCBwcm9wb3Nl ZCBpbiB0aGF0IGFyZWEuDQoNClRoYW5rcywgLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIGludGVybmV0LQ0KPiBkcmFmdHNAaWV0Zi5vcmcNCj4gU2VudDogRnJpZGF5 LCBBdWd1c3QgNCwgMjAxNyA3OjI5IFBNDQo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4g Q2M6IHRzdndnQGlldGYub3JnDQo+IFN1YmplY3Q6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA0LnR4dA0KPiANCj4gDQo+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVHJhbnNw b3J0IEFyZWEgV29ya2luZyBHcm91cCBXRyBvZiB0aGUNCj4gSUVURi4NCj4gDQo+ICAgICAgICAg VGl0bGUgICAgICAgICAgIDogRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikg RXhwZXJpbWVudGF0aW9uDQo+ICAgICAgICAgQXV0aG9yICAgICAgICAgIDogRGF2aWQgQmxhY2sN Cj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlv bi0wNC50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDE3DQo+IAlEYXRlICAgICAgICAgICAgOiAy MDE3LTA4LTA0DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBtZW1vIHVwZGF0ZXMgUkZDIDMx NjgsIHdoaWNoIHNwZWNpZmllcyBFeHBsaWNpdCBDb25nZXN0aW9uDQo+ICAgIE5vdGlmaWNhdGlv biAoRUNOKSBhcyBhIHJlcGxhY2VtZW50IGZvciBwYWNrZXQgZHJvcHMgYXMgaW5kaWNhdG9ycyBv Zg0KPiAgICBuZXR3b3JrIGNvbmdlc3Rpb24uICBJdCByZWxheGVzIHJlc3RyaWN0aW9ucyBpbiBS RkMgMzE2OCB0aGF0IHdvdWxkDQo+ICAgIG90aGVyd2lzZSBoaW5kZXIgZXhwZXJpbWVudGF0aW9u IHRvd2FyZHMgYmVuZWZpdHMgYmV5b25kIGp1c3QgcmVtb3ZhbA0KPiAgICBvZiBsb3NzLiAgVGhp cyBtZW1vIHN1bW1hcml6ZXMgdGhlIGFudGljaXBhdGVkIGFyZWFzIG9mDQo+ICAgIGV4cGVyaW1l bnRhdGlvbiBhbmQgdXBkYXRlcyBSRkMgMzE2OCB0byBlbmFibGUgZXhwZXJpbWVudGF0aW9uIGlu DQo+ICAgIHRoZXNlIGFyZWFzLiAgQW4gRXhwZXJpbWVudGFsIFJGQyBpcyByZXF1aXJlZCB0byB0 YWtlIGFkdmFudGFnZSBvZg0KPiAgICBhbnkgb2YgdGhlc2UgZW5hYmxpbmcgdXBkYXRlcy4gIElu IGFkZGl0aW9uLCB0aGlzIG1lbW8gbWFrZXMgcmVsYXRlZA0KPiAgICB1cGRhdGVzIHRvIHRoZSBF Q04gc3BlY2lmaWNhdGlvbnMgZm9yIFJUUCBpbiBSRkMgNjY3OSBhbmQgZm9yIERDQ1AgaW4NCj4g ICAgUkZDIDQzNDEsIFJGQyA0MzQyIGFuZCBSRkMgNTYyMi4gIFRoaXMgbWVtbyBhbHNvIHJlY29y ZHMgdGhlDQo+ICAgIGNvbmNsdXNpb24gb2YgdGhlIEVDTiBOb25jZSBleHBlcmltZW50IGluIFJG QyAzNTQwLCBhbmQgcHJvdmlkZXMgdGhlDQo+ICAgIHJhdGlvbmFsZSBmb3IgcmVjbGFzc2lmaWNh dGlvbiBvZiBSRkMgMzU0MCBhcyBIaXN0b3JpYzsgdGhpcw0KPiAgICByZWNsYXNzaWZpY2F0aW9u IGVuYWJsZXMgbmV3IGV4cGVyaW1lbnRhbCB1c2Ugb2YgdGhlIEVDVCgxKQ0KPiAgICBjb2RlcG9p bnQuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt dHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi8NCj4gDQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0wNA0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLQ0KPiBleHBlcmltZW50 YXRpb24tMDQNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt dHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0wNA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCg0K From nobody Mon Aug 7 07:31:27 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9351321EC for ; Mon, 7 Aug 2017 07:31:26 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 tqARNTyaEBvt for ; Mon, 7 Aug 2017 07:31:25 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 47FCF1321F1 for ; Mon, 7 Aug 2017 07:31:25 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v77EVO5q026589 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 7 Aug 2017 14:31:24 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v77EVNx0013551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 7 Aug 2017 14:31:23 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v77EVNoE000673 for ; Mon, 7 Aug 2017 14:31:23 GMT Received: from oracle.com (/10.159.143.174) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Aug 2017 07:31:23 -0700 Date: Mon, 7 Aug 2017 10:31:20 -0400 From: Sowmini Varadhan To: tsvwg@ietf.org Message-ID: <20170807143120.GC11845@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [tsvwg] comments about draft-ietf-tsvwg-aqm-dualq-coupled-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 14:31:27 -0000 I had some questions as I was going over this document and Bob Briscoe suggested that this might be a useful discussion to share with a list, so here's a current summary, including clarifications that Bob provided for me offline In general, I liked the fact that the Appendix starts off by first discussing core concepts and then gets into the more complex overload case- this makes it easy to understand how the various blocks build on each other. In keeping with that same core -> complex flow, it might be easier to refactor Appendix A.1 a bit, so that it first goes over the enque/dequeue logic and then gets into the more complex PI-update Pseudo-code. I realize the document *is* trying to do that, but it took me some time to figure out the semantics of alpha/beta/alpha_U/beta_U (these get defined in Figure 1, but a detailed description is only available at the bottom Page 17..) What eventally helped me put things in place was the brief background that Bob offered (in the offline thread) Bob> A Proportional Integral (PI) algorithm changes the controlled variable (the Bob> loss probability p) dependent on how fast the queue is increasing (which is Bob> Proportional to excess load) and how far any standing queue is Bob> from its target (which represents the Integral of load). Two "gain Bob> factors", beta and alpha, respectively weight how strongly each of Bob> these elements alters p. Bob> The stability analysis in [PI216] recommends the values of alpha Bob> and beta (in the header file in Fig 1) on the basis that these Bob> cause the AQM to change p (loss prob) as fast as poss in response Bob> to changes in load without over-compensating and therefore causing Bob> oscillations in the queue. Bob> The recommended values of alpha and beta determine how much p ought Bob> to change if it was updated every second. It is best to update p Bob> as frequently as possible, but the actual update interval (Tupdate) Bob> is constrained by hardware performance. For link rates from 4 - Bob> 200 Mb/s, we found Tupdate=16ms is sufficient. Whatever value of Bob> Tupdate is chosen, p should change by the same amount per second, Bob> but in more smaller steps. So the gain factors used need to Bob> be scaled by (Tupdate/1s). This is why alpha_U and beta_U are Bob> used for updating p in Fig 4, where alpha_U= alpha*Tupdate and Bob> beta_U=beta*Tupdate. Some/all of this information would be useful to have in the doc, since it provides the needed brief background for dualpi2_update, within the draft itself. One follow-up question (I've not read all of [PI216] yet, it's on my reading list) - what is the general trend of Tupdate for faster link-rates? E.g., what is the expected Tupdate at 1Gb/s? It would also be helpful to define the high-level semantics of cq.time(), cq.len(), lq.len() etc. E.g. the description that Bob offered in the offline mail (below) could be added in the preamble to enque/dequeue, to improve readability (and also help an implementor quickly see what the function indirections are supposed to do). Bob> cq.time() is a function that returns the time that the head packet Bob> has been in the classic queue (cq), which is called the "service Bob> time" of the queue, or sometimes the "sojourn time". Bob> Similarly for lq.time(), cq.len() and lq.len(), where lq is the Bob> L4S queue and len() is the length in bytes. I'm still working through the doc, will get back here with additional questions/comments. Thanks --Sowmini From nobody Mon Aug 7 11:36:53 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFE31323BE for ; Mon, 7 Aug 2017 11:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 6bdIcB5Gj3eG for ; Mon, 7 Aug 2017 11:36:47 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A401132034 for ; Mon, 7 Aug 2017 11:36:47 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l82so7957968ywc.2 for ; Mon, 07 Aug 2017 11:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r7SACaAGVo5/jmUk+SsJ/nFaZStoyhHYC9crD2Nc/nI=; b=k9C91eAcCdwVxGic4D4mLFK40s7xSASYj13vl1/gABtoEZ+9TUk+A5FBZkbxZ8a9V+ 9B3+yEV6nOVAVh3TbN6PiKUcUny5RN1yn6xCdQfM/9JxHaYO966IUIfhCHAY/GsXeX6P okHI9BrQgaX5SOid1DPpxHGYxPoZUFnFoEXcIhQD1EmSOkhUKHI2BPK9EvzT9eLgnd8J FSna5B10l4tXUDbPBazW2QF5CDiItXJxWEqhaB8VNcZ9pJYL1kgsxKlKdQzpr+QoUv3A NJA/8JT/RU4uPVV6Dm8bBtkNbkFb/hnXcEGKrAJ4y2AxooENBjGGwJNUEngTJBrxmYQV WIhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r7SACaAGVo5/jmUk+SsJ/nFaZStoyhHYC9crD2Nc/nI=; b=F6WsWlUg90r5Yz4wSmVHB2ETSU9OPLw3M7rfeuJnPG0HoP44YBVEvyPzFGpM4MUoEw LA6u616QWAYFYZMRSnlfnx558fth2nchlpfq70JO5r8YkTxfpcsda9L9zQsVqK2rcu+T pgZbYJyC3nsdsIDkN6V2vXfg/ZsFNzb3z+8Y95DDzwAZqMAg0VDi4I9SfuMb2lEUu6zL oTOKdawB7R4Ore37U3I/SC6Ilx/YifzWqsCL9/CUvSPm12451x2mioW0dM2E5XfYD5kr Ms+P9VpY0lmHcDFQzh5/9KiK2XUd8Vr186/B1deXr+kc2t9ArJtvvRBMR1X7WPhGWBez TUaA== X-Gm-Message-State: AHYfb5jvso2TZx6BafSnF8xFbGYSaPH9h2FKIaL/7cyV0h+/08bigqhv h5LaqgRlUBvL0ufRts6bT4cDQXaC5g== X-Received: by 10.129.229.4 with SMTP id s4mr1264432ywl.130.1502131006350; Mon, 07 Aug 2017 11:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Mon, 7 Aug 2017 11:36:45 -0700 (PDT) In-Reply-To: References: <150188933148.18701.4807220216565950086@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Mon, 7 Aug 2017 13:36:45 -0500 Message-ID: To: "Black, David" Cc: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="089e08222cb40a33a805562e2192" Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:36:51 -0000 --089e08222cb40a33a805562e2192 Content-Type: text/plain; charset="UTF-8" Hi, David, On Fri, Aug 4, 2017 at 6:31 PM, Black, David wrote: > As discussed in Prague, this is a small update to request that IANA remove > the registration of the TCP header flag used by RFC 3540 (ECN Nonce). Any > reassignment of that flag will be handled by the TCPM WG. This update also > changes the name of one of the areas of ECN experimentation to be different > from the name of the experiment proposed in that area. > > Thanks, --David > Hi, David, I really like this draft. Thanks to you and your ACK list for your efforts - the result is very clear and complete. I have a few questions before I push the button on Last Call. They're minor enough that I don't think we need to wait for Gorry to be present for the discussion (of course, if people disagree, just let me know). I tried to offer text for most of them, but you might also answer them by saying that TSVWG needs a much smarter responsible AD ;-) ... In this text, An Experimental RFC MUST be published for any protocol or mechanism that takes advantage of any of these enabling updates. I think I know what you're saying, but this formulation confuses me because it's placing a commitment on what a future working group must do (like, what if the draft describing the experimental protocol is incoherent - can the working group Just Say No, or can the authors say "but you have to request publication, because "An Experimental RFC MUST be published ..."). Is your point that any protocol or mechanism that takes advantage of these enabling updates can't be Standards-Track? In this text, There is no need to make changes for protocols and mechanisms that are documented in Standards Track RFCs, as any Standards Track RFC can update RFC 3168 without needing a standards process exception. we've been talking using this terminology for at least a year that I can remember, but I'm not totally sure that an average IESG would even approve an Experimental draft that updated a standards-track RFC. How badly do you need to say this at all, since you're just confirming a well-understood fact that I think we all agree on? In this text, A study of the ECN behaviour of the Alexa top 1M web servers using 2014 data [Trammell15] I'm wondering whether it's useful to say "Alexa top 1M web servers" in an RFC that will probably last longer than Alexa lasts ... In this text, Significantly more aggressive sender responses to ECN are required to make effective use of such shallow queues; Datacenter ^^^^^^^^ TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. I'm tangled up in passive tense ("who is required to do what?"). Is it correct to say Significantly more aggressive sender responses to ECN are needed in order to make effective use of such shallow queues; Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. ? I see that the draft uses both the terms "shallow queues" and "nearly empty queues". Do these terms mean the same thing? If so, perhaps it's worth either picking one term, or saying that they mean the same thing. Right now, I'm trying to imagine what the difference might be, since both phrases are used. You folks are the experts on this stuff, but I'm looking at this quoted text from RFC 3168 RFC 3168 prohibits use of ECN for TCP control packets and retransmitted packets in a number of places: o "To ensure the reliable delivery of the congestion indication of the CE codepoint, an ECT codepoint MUST NOT be set in a packet unless the loss of that packet in the network would be detected by the end nodes and interpreted as an indication of congestion." (Section 5.2) o "A host MUST NOT set ECT on SYN or SYN-ACK packets." (Section 6.1.1) o "pure acknowledgement packets (e.g., packets that do not contain any accompanying data) MUST be sent with the not-ECT codepoint." (Section 6.1.4) o "This document specifies ECN-capable TCP implementations MUST NOT set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for retransmitted data packets, and that the TCP data receiver SHOULD ignore the ECN field on arriving data packets that are outside of the receiver's current window." (Section 6.1.5) o "the TCP data sender MUST NOT set either an ECT codepoint or the CWR bit on window probe packets." (Section 6.1.6) and noticing that only the text in 6.1.5 explicitly mentions the TCP data receiver ignoring the "MUST NOT set" ECN field. I took a quick spin through RFC 3168 searching for "ignore", but didn't see something that explicitly covered the other cases. Because these are "MUST NOT set" constraints, I could imagine implementers who never anticipated that an ECN(0) or ECN(1) would be set, and don't look at the field (probably good), but I can also imagine implementers validating that ECN(0) and ECN(1) are not set (probably bad). Do people have any concerns about encountering "ECT values MUST be cleared" implementations during this experiment? I suppose if some implementation that does this is deployed and you folks run the experiment, then we'll know :D ... But I wonder if it's worth making that clear for receivers, since you're updating RFC 3168 anyway? In this text, Random ECT values MUST NOT be used, as that may expose RTP to differences in network treatment of traffic marked with ECT(1) and ECT(0) and differences in associated endpoint congestion responses, is "Random ECT values" the right word? I could imagine this prohibiting using ECT(0) and ECT(1) interchangeably, but if that's what's intended, I could also imagine this prohibiting simply not explicitly setting the ECT values at all, so missing your point. I'm looking at this text As a process memo that makes no changes to existing protocols, there are no protocol security considerations. and wondering if it's current with the rest of the document. Is "no changes to existing protocols" still the right way to characterize this draft? If you wanted to say As a process memo that only adds limitations to existing protocols, there are no protocol security considerations. I'd be happy to believe you ... Thanks, Spencer > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Friday, August 4, 2017 7:29 PM > > To: i-d-announce@ietf.org > > Cc: tsvwg@ietf.org > > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Area Working Group WG of the > > IETF. > > > > Title : Explicit Congestion Notification (ECN) > Experimentation > > Author : David Black > > Filename : draft-ietf-tsvwg-ecn-experimentation-04.txt > > Pages : 17 > > Date : 2017-08-04 > > > > Abstract: > > This memo updates RFC 3168, which specifies Explicit Congestion > > Notification (ECN) as a replacement for packet drops as indicators of > > network congestion. It relaxes restrictions in RFC 3168 that would > > otherwise hinder experimentation towards benefits beyond just removal > > of loss. This memo summarizes the anticipated areas of > > experimentation and updates RFC 3168 to enable experimentation in > > these areas. An Experimental RFC is required to take advantage of > > any of these enabling updates. In addition, this memo makes related > > updates to the ECN specifications for RTP in RFC 6679 and for DCCP in > > RFC 4341, RFC 4342 and RFC 5622. This memo also records the > > conclusion of the ECN Nonce experiment in RFC 3540, and provides the > > rationale for reclassification of RFC 3540 as Historic; this > > reclassification enables new experimental use of the ECT(1) > > codepoint. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn- > > experimentation-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn- > experimentation-04 > > > > > > 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/ > > --089e08222cb40a33a805562e2192 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,

On Fri, Aug 4, 2017 at 6:31 PM, Black, David <David.Black= @dell.com> wrote:
As discussed in Prague, this is a small update to request that I= ANA remove the registration of the TCP header flag used by RFC 3540 (ECN No= nce).=C2=A0 =C2=A0Any reassignment of that flag will be handled by the TCPM= WG.=C2=A0 This update also changes the name of one of the areas of ECN exp= erimentation to be different from the name of the experiment proposed in th= at area.

Thanks, --David

Hi, David,
I really like this draft. Thanks to you and your ACK list for = your efforts - the result is very clear and complete.

<= div>I have a few questions before I push the button on Last Call. They'= re minor enough that I don't think we need to wait for Gorry to be pres= ent for the discussion (of course, if people disagree, just let me know).

I tried to offer text for most of them, but you mig= ht also answer them by saying that TSVWG needs a much smarter responsible A= D ;-) ...

In this text,

= =C2=A0 =C2=A0An Experimental RFC MUST be published for any protocol
=C2=A0 =C2=A0or mechanism that takes advantage of any of these enabling = updates.
=C2=A0 =C2=A0
I think I know what you're s= aying, but this formulation confuses me because it's placing a commitme= nt on what a future working group must do (like, what if the draft describi= ng the experimental protocol is incoherent - can the working group Just Say= No, or can the authors say "but you have to request publication, beca= use "An Experimental RFC MUST be published ...").

<= /div>
Is your point that any protocol or mechanism that takes advantage= of these enabling updates can't be Standards-Track?

In this text,=C2=A0

=C2=A0 =C2=A0There is n= o need to make changes for protocols and mechanisms that
=C2=A0 = =C2=A0are documented in Standards Track RFCs, as any Standards Track RFC
=C2=A0 =C2=A0can update RFC 3168 without needing a standards proces= s exception.
=C2=A0
we've been talking using this t= erminology for at least a year that I can remember, but I'm not totally= sure that an average IESG would even approve an Experimental draft that up= dated a standards-track RFC. How badly do you need to say this at all, sinc= e you're just confirming a well-understood fact that I think we all agr= ee on?

In this text,

=C2= =A0 =C2=A0A study of the ECN behaviour of the Alexa top 1M web
= =C2=A0 =C2=A0servers using 2014 data [Trammell15]=C2=A0
=C2=A0 = =C2=A0
I'm wondering whether it's useful to say "Ale= xa top 1M web servers" in an RFC that will probably last longer than A= lexa lasts ...

In this text,

<= div>=C2=A0 =C2=A0Significantly more aggressive sender responses to ECN
=C2=A0 =C2=A0are required to make effective use of such shallow queue= s; Datacenter
=C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^
=C2= =A0 =C2=A0TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. =C2=A0
=C2=A0 =C2=A0
I'm tangled up in passive tense ("w= ho is required to do what?"). Is it correct to say=C2=A0
=C2=A0 =C2=A0Significantly more aggressive sender responses to = ECN
=C2=A0 =C2=A0are needed in order to make effective use of suc= h shallow queues;=C2=A0
=C2=A0 =C2=A0Datacenter TCP (DCTCP) [I-D.= ietf-tcpm-dctcp] provides an example. =C2=A0

?
=C2=A0 =C2=A0
I see that the draft uses both the terms &qu= ot;shallow queues" and "nearly empty queues". Do these terms= mean the same thing? If so, perhaps it's worth either picking one term= , or saying that they mean the same thing. Right now, I'm trying to ima= gine what the difference might be, since both phrases are used.
<= br>
You folks are the experts on this stuff, but I'm looking = at this quoted text from RFC 3168

=C2=A0RFC 3168 p= rohibits use of ECN for TCP control packets and
=C2=A0 =C2=A0retr= ansmitted packets in a number of places:

=C2=A0 = =C2=A0o =C2=A0"To ensure the reliable delivery of the congestion indic= ation of
=C2=A0 =C2=A0 =C2=A0 the CE codepoint, an ECT codepoint = MUST NOT be set in a packet
=C2=A0 =C2=A0 =C2=A0 unless the loss = of that packet in the network would be detected by
=C2=A0 =C2=A0 = =C2=A0 the end nodes and interpreted as an indication of congestion."<= /div>
=C2=A0 =C2=A0 =C2=A0 (Section 5.2)

=C2= =A0 =C2=A0o =C2=A0"A host MUST NOT set ECT on SYN or SYN-ACK packets.&= quot;
=C2=A0 =C2=A0 =C2=A0 (Section 6.1.1)

=C2=A0 =C2=A0o =C2=A0"pure acknowledgement packets (e.g., packets t= hat do not contain
=C2=A0 =C2=A0 =C2=A0 any accompanying data) MU= ST be sent with the not-ECT codepoint."
=C2=A0 =C2=A0 =C2=A0= (Section 6.1.4)

=C2=A0 =C2=A0o =C2=A0"This d= ocument specifies ECN-capable TCP implementations MUST NOT
=C2=A0= =C2=A0 =C2=A0 set either ECT codepoint (ECT(0) or ECT(1)) in the IP header= for
=C2=A0 =C2=A0 =C2=A0 retransmitted data packets, and that th= e TCP data receiver SHOULD
=C2=A0 =C2=A0 =C2=A0 ignore the ECN fi= eld on arriving data packets that are outside of
=C2=A0 =C2=A0 = =C2=A0 the receiver's current window." =C2=A0(Section 6.1.5)
=

=C2=A0 =C2=A0o =C2=A0"the TCP data sender MUST NOT= set either an ECT codepoint or the
=C2=A0 =C2=A0 =C2=A0 CWR bit = on window probe packets." =C2=A0(Section 6.1.6)
=C2=A0 =C2= =A0 =C2=A0=C2=A0
and noticing that only the text in 6.1.5 explici= tly mentions the TCP data receiver ignoring the "MUST NOT set" EC= N field. I took a quick spin through RFC 3168 searching for "ignore&qu= ot;, but didn't see something that explicitly covered the other cases.<= /div>

Because these are "MUST NOT set" constra= ints, I could imagine implementers who never anticipated that an ECN(0) or = ECN(1) would be set, and don't look at the field (probably good), but I= can also imagine implementers validating that ECN(0) and ECN(1) are not se= t (probably bad). Do people have any concerns about encountering "ECT = values MUST be cleared" implementations during this experiment?
<= div>
I suppose if some implementation that does this is deplo= yed and you folks run the experiment, then we'll know :D ...
=
But I wonder if it's worth making that clear for receive= rs, since you're updating RFC 3168 anyway?

In = this text,

=C2=A0 =C2=A0 =C2=A0 Random ECT values = MUST NOT be used, as that may expose RTP to
=C2=A0 =C2=A0 =C2=A0 = differences in network treatment of traffic marked with ECT(1) and
=C2=A0 =C2=A0 =C2=A0 ECT(0) and differences in associated endpoint conges= tion
=C2=A0 =C2=A0 =C2=A0 responses,
=C2=A0 =C2=A0 =C2= =A0=C2=A0
is "Random ECT values" the right word? I coul= d imagine this prohibiting using ECT(0) and ECT(1) interchangeably, but if = that's what's intended, I could also imagine this prohibiting simpl= y not explicitly setting the ECT values at all, so missing your point.

I'm looking at this text

= =C2=A0 =C2=A0As a process memo that makes no changes to existing protocols,= there
=C2=A0 =C2=A0are no protocol security considerations.
=C2=A0 =C2=A0
and wondering if it's current with the re= st of the document. Is "no changes to existing protocols" still t= he right way to characterize this draft? If you wanted to say
=C2=A0 =C2=A0As a process memo that only adds limitations to ex= isting protocols, there
=C2=A0 =C2=A0are no protocol security con= siderations.
=C2=A0 =C2=A0
I'd be happy to believe = you ...

Thanks,

Spencer= =C2=A0


> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bo= unces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Friday, August 4, 2017 7:29 PM
> To: i-d-announce@ietf.org=
> Cc: tsvwg@ietf.org
> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation= -04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Transport Area Working Group WG of th= e
> IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Explicit Congestion Notification (ECN) Experimentation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : David Black
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tsvwg-ecn-experimentation-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 17
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-08-04
>
> Abstract:
>=C2=A0 =C2=A0 This memo updates RFC 3168, which specifies Explicit Cong= estion
>=C2=A0 =C2=A0 Notification (ECN) as a replacement for packet drops as i= ndicators of
>=C2=A0 =C2=A0 network congestion.=C2=A0 It relaxes restrictions in RFC = 3168 that would
>=C2=A0 =C2=A0 otherwise hinder experimentation towards benefits beyond = just removal
>=C2=A0 =C2=A0 of loss.=C2=A0 This memo summarizes the anticipated areas= of
>=C2=A0 =C2=A0 experimentation and updates RFC 3168 to enable experiment= ation in
>=C2=A0 =C2=A0 these areas.=C2=A0 An Experimental RFC is required to tak= e advantage of
>=C2=A0 =C2=A0 any of these enabling updates.=C2=A0 In addition, this me= mo makes related
>=C2=A0 =C2=A0 updates to the ECN specifications for RTP in RFC 6679 and= for DCCP in
>=C2=A0 =C2=A0 RFC 4341, RFC 4342 and RFC 5622.=C2=A0 This memo also rec= ords the
>=C2=A0 =C2=A0 conclusion of the ECN Nonce experiment in RFC 3540, and p= rovides the
>=C2=A0 =C2=A0 rationale for reclassification of RFC 3540 as Historic; t= his
>=C2=A0 =C2=A0 reclassification enables new experimental use of the ECT(= 1)
>=C2=A0 =C2=A0 codepoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.= org/doc/draft-ietf-tsvwg-ecn-experimentation/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/= draft-ietf-tsvwg-ecn-experimentation-04
> https://datatracker.ietf.org/do= c/html/draft-ietf-tsvwg-ecn-
> experimentation-04
>
> A diff from the previous version is available at:
> https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-tsvwg-ecn-experimentation-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/


--089e08222cb40a33a805562e2192-- From nobody Mon Aug 7 18:24:27 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984C124207 for ; Mon, 7 Aug 2017 18:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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=dell.com header.b=i9Z7kV7D; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=AFJBhNx/ 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 glrozEM5qGxn for ; Mon, 7 Aug 2017 18:24:21 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 CF254131D37 for ; Mon, 7 Aug 2017 18:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1502155457; x=1533691457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M4d5pOClI0FDGOL0YgbiFbajX9ZG8lrfblvMgOZyiLU=; b=i9Z7kV7DhiE0ON+uWRyQdYHN6NpRKtCQz525Dd0O8fTQRk4yDnPhOQ5x fnDbXyZivu87QF6z7nEZY2vU27ccQIaYV1ozAlCwadZ5pUh8p8ezsBuJU gIWXr38Kg7M9fIS6yC9MXI1TETcAB+TgMmyBOpMAvOEoCeJJu5MeVppPX w=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2017 20:24:17 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2017 07:19:00 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v781OIoA003820 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Aug 2017 21:24:19 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v781OIoA003820 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1502155460; bh=qxNkzLIXuQvOJhSdvjFn8NsUpeI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AFJBhNx//J2L4EjBJ4FHVEoINRTo0NqUD2Rz1x4j7rKQZ+DXNvljBSvxq9dAbkwMR eCf0a3eT4ZjlKGqpVtLUpkVshEE4xuNjQRIds6WVylzqmgakd1s+BtlG94sF1d0+vg 7EXcWqhPnyrLEmqNIParmATGCdJ5BfSprxT1e9v0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v781OIoA003820 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 7 Aug 2017 21:24:01 -0400 Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v781O1hG019186 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 7 Aug 2017 21:24:01 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB308.corp.emc.com ([10.146.3.34]) with mapi id 14.03.0352.000; Mon, 7 Aug 2017 21:24:00 -0400 To: "Tim Szigeti (szigeti)" , G Fairhurst , tsvwg WG CC: "Jerome Henry (jerhenry)" , Fred Baker Thread-Topic: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments Thread-Index: AdL9iKwSAOxDD+ndQlSPMOl+i2FRxAJn8UbwAi2HR9A= Date: Tue, 8 Aug 2017 01:24:00 +0000 Message-ID: References: <9603e1facabb48ec865439a997392120@XCH-RCD-010.cisco.com> In-Reply-To: <9603e1facabb48ec865439a997392120@XCH-RCD-010.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 01:24:26 -0000 Hi Tim, Many thanks for your continued efforts on this draft, and sorry for the del= ayed response. The changes generally look good - there were two areas whe= re I wanted to re-check the revised text: A) On Section 5.3, I wrote: > > I don't understand what a "trust function" is, so this looks like a cir= cular > > statement. Once "trust function" is clarified, change "RECOMMENDED to > > trust DSCP" to "RECOMMENDED to pass through DSCP" ... but the details o= f > > this clarification are crucial as this text is a potentially serious se= curity hole > as > > currently written. The revised text removes the use of the term "trust function" and is much c= learer as a result. B) > > Finally, Gorry noted: > > > > (4) I suspect the security section may benefit from a better definit= ion > > of the case where the 802.11 network forms the edge of a DS domain. = I > > suspect other people will suggest text on this. > > > > I suspect that some of the changes suggested in this review towards les= s use > > of the word "trust" will help with this concern, so I suggest that Gorr= y and I > > both take a look at the resulting text to see whether it suffices. Th= at said, it > > would help to add a reference from the security considerations text on = CS6 > > and CS7 back to section 5.4, which discusses this "edge of a DS domain"= case. > > Beyond removal of most uses of the word "trust," the security consideration= s text on CS6 and CS7 was expanded, which obviates the need for a backpoint= er, however .... this text in Section 5.4 is now subtly inconsistent with = at least the security considerations text: When business requirements and/or technical constraints and/or administrative policies require QoS markings to be passed through at the wireless edge, then it is RECOMMENDED to pass through Layer 3 DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the upstream direction, for the following reasons: CS6 and CS7 are exceptions to this "RECOMMENDED" requirement for the securi= ty reasons discussed in section 8, and because they should not be generated= by hosts for the reasons discussed in section 5.1. I have a couple of su= ggested changes. 1) Insert "with the exception of CS6 and CS7" after "in the upstream direct= ion" in the above text. 2) Add a paragraph after the itemized list to explain (mostly by citing the= two relevant sections): CS6 and CS7 are exceptions to this pass through recommendation because wireless hosts SHOULD NOT use them (see Section 5.1) and traffic with those two markings poses a threat to operation of the wired network (see Section 8.2). CS6 and CS7 SHOULD NOT be passed through to the wired network in the upstream direction unless the access point has been specifically configured to do that by a network administrator or operato= r. Does that sound reasonable? Thanks, --David > -----Original Message----- > From: Tim Szigeti (szigeti) [mailto:szigeti@cisco.com] > Sent: Thursday, July 27, 2017 6:35 PM > To: Black, David ; G Fairhurst > ; tsvwg WG > Cc: Jerome Henry (jerhenry) ; Fred Baker > > Subject: RE: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-iee= e- > 802-11 - David Black's comments >=20 > Hi David, >=20 > Thank you again for taking the time to do another round of review. >=20 > All changes you've suggested below have been made to the latest version o= f > the draft. >=20 > Thank you again for helping us find the right balance on security vs. > functionality. >=20 > -tim >=20 > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David > > Sent: Saturday, July 15, 2017 9:40 AM > > To: G Fairhurst; tsvwg WG > > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsv= wg- > > ieee-802-11 - David Black's comments > > > > In general, the -04 draft is much improved from the -01 draft. All of = my > > remaining major concerns involve uses of the word "trust" that > > > > -- Major > > > > Section 3: > > > > This document assumes and RECOMMENDS that all wireless access points > > (as the bridges between wired-and-wireless networks) support the > > ability to: > > > > [... snip ...] > > > > o trust DSCP markings set by wireless endpoint devices > > > > This instance of "trust" appears to have been overlooked. I suggest > > changing "trust" to "process." > > > > Section 5: > > > > o DSCP-Trust at the wireless access point (effectively a 1:1 DSCP- > > to-DSCP mapping) > > > > Aha, the dreaded T-word again. Suggest: DSCP-Trust -> DSCP-Passthrough= , > > as that not only removes the T-word, but is also more descriptive. Th= is also > > affects Section 5.3 ... > > > > Section 5.3: > > > > Change DSCP-Trust -> DSCP-Passthrough in section title. > > > > It is generally NOT RECOMMENDED to trust DSCP markings from > > unauthenticated and unauthorized devices, as these are typically > > considered untrusted sources. > > > > to trust DSCP markings -> to pass through DSCP markings > > > > When business requirements and/or technical constraints and/or > > administrative policies require a trust function at the wireless > > edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] > > UP markings) markings in the upstream direction, for the following > > reasons: > > > > I don't understand what a "trust function" is, so this looks like a cir= cular > > statement. Once "trust function" is clarified, change "RECOMMENDED to > > trust DSCP" to "RECOMMENDED to pass through DSCP" ... but the details o= f > > this clarification are crucial as this text is a potentially serious se= curity hole > as > > currently written. > > > > A related minor issue turns up in Section 8.1 - see below. > > > > Finally, Gorry noted: > > > > (4) I suspect the security section may benefit from a better definit= ion > > of the case where the 802.11 network forms the edge of a DS domain. = I > > suspect other people will suggest text on this. > > > > I suspect that some of the changes suggested in this review towards les= s use > > of the word "trust" will help with this concern, so I suggest that Gorr= y and I > > both take a look at the resulting text to see whether it suffices. Th= at said, it > > would help to add a reference from the security considerations text on = CS6 > > and CS7 back to section 5.4, which discusses this "edge of a DS domain" > case. > > > > -- Minor > > > > Section 2.1: > > > > Thus the QoS treatment of packets at the access point will depend on > > the position of the AP in the network infrastructure and on the WLAN > > deployment model. > > > > Needs specific examples and/or forward references to what changes with = AP > > position. > > > > Sections 5.2, 5.3 and 5.4: > > > > These sections are effectively discussing alternatives for access point > Diffserv > > functionality. That structure (do one of these three) is not clear in = the draft. > > > > Section 8.1: > > > > Additionally, Section 5.3 made it clear > > that it is generally NOT RECOMMENDED to trust DSCP markings from > > unauthorized and/or unauthenticated devices, as these are > > typically considered untrusted sources. This is especially > > relevant for IoT deployments, where tens-of-billions of devices > > are being connected to IP networks, many of which have little or > > no security. > > > > In the first sentence: "trust" -> "pass through" > > > > In the second sentence as written, "many of which" refers to "IP networ= ks" - > > I suspect that was not intended, e.g., "tens-of-billions of devices tha= t may > > have little or no security are being connected to IP networks" may be c= loser > > to what was intended. > > > > Setting a trust boundary reflective of business objectives and > > policy, such that traffic from authorized users and/or > > applications and/or endpoints will be accepted by the network; > > otherwise packet markings will be "bleached" (i.e. remarked to > > DSCP DF and/or UP 0). > > > > I have some idea of what a "trust boundary" is, but suspect that "traff= ic > > conditioning policy" may be clearer and closer to what was intended. > > > > Section 8.2: > > > > Every paragraph in this section is bidirectional in scope, applying to = both > > wired->wireless and wireless-> wired traffic, except for this paragraph= : > > > > If such marking/mapping were not controlled, then, for example, a > > malicious user could cause WLAN DoS by flooding traffic marked CS7 > > DSCP downstream. This codepoint would map by default to UP 7 and > > would be assigned to the Voice Access Category (AC_VO). Such a floo= d > > could cause Denial-of-Service to not only wireless voice > > applications, but also to all other traffic classes. > > > > I suggest making this paragraph bidirectional by providing the example = in > > both directions and then making it clear that the following paragraph: > > > > Therefore, to mitigate such an attack, it is RECOMMENDED that all > > packets marked to Diffserv Codepoints not in use over the wireless > > network be mapped to UP 0. > > > > applies to both access points and wireless device operating systems. > > > > > > -- Editorial > > > > Section 1.1: > > > > Note: [RFC4594] is intended to be viewed as a set of "project plans" > > for building all the (diffserv) furniture that one might want. Thus= , > > it describes different types of traffic expected in IP networks and > > provides guidance as to what DSCP marking(s) should be associated > > with each traffic type. As such, this document draws heavily on > > [RFC4594], [RFC5127], and [RFC8100]. > > > > The first sentence seems a bit too informal, suggest: > > > > OLD > > Note: [RFC4594] is intended to be viewed as a set of "project plans" > > for building all the (diffserv) furniture that one might want. > > NEW > > Note: [RFC4594] is intended to be viewed as a framework and guidelin= es > > for supporting Diffserv in any network, including wireless networks. > > > > Section 2.1: > > > > It is important to recognize that the wired-to-wireless edge may or > > may not equate to the edge of the Diffserv domain. > > > > equate to the edge of the Diffserv domain -> function as an edge of a > > Diffserv domain or a domain boundary. > > > > Section 8: > > > > Initial paragraph seems overly defensive, suggest: > > > > OLD > > The recommendations put forward in this document do not present any > > additional security concerns that do not already exist in wired and > > wireless devices. In fact, several of the recommendations made in > > this document serve to mitigate and protect wired and wireless > > networks from potential abuse arising from existing vulnerabilities. > > NEW > > The recommendations in this document concern existing wired and > > wireless > > network functionality, and for that reason do not add significant se= curity > > concerns. Some of the recommendations help protect wired and wirel= ess > > networks from potential abuse, e.g., as discussed further in this se= ction. > > > > Section 8.2: > > > > It should be strongly noted that in the wireless deployment model > > > > I suggest deleting "It should be strongly noted that" > > > > Thanks, --David > > > > > > > -----Original Message----- > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of G Fairhurst > > > Sent: Thursday, July 6, 2017 3:11 AM > > > To: tsvwg WG > > > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on > > > draft-ietf-tsvwg- > > > ieee-802-11-01 to conclude 10th Jul 2017 > > > > > > This email announces a second TSVWG Working Group Last Call (WGLC) > on: > > > > > > DiffServ to IEEE 802.11 Mapping > > > draft-ietf-tsvwg-ieee-802-11-01 > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01 > > > > > > This WGLC will last for about 2 weeks weeks. The purpose of this call > > > is to provide further feedback (if required) on changes made since th= e > > > first WGLC concluded. > > > > > > Comments should be sent to thetsvwg@ietf.org > > > list, although purely editorial comments may b= e > > > sent directly to the authors. Please cc: the WG chairs > > > attsvwg-chairs@ietf.org if you would > > > like the chairs to track such editorial comments as part of the WGLC > > > process. > > > > > > No IPR disclosures have been submitted directly on > > > draft-ietf-tsvwg-ieee-802-11-01 > > > > > > Thanks, > > > Gorry > > > (TSVWG Co-Chair) From nobody Tue Aug 8 12:34:08 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A22132667 for ; Tue, 8 Aug 2017 12:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmCifEWDOzEM for ; Tue, 8 Aug 2017 12:34:05 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 70093132660 for ; Tue, 8 Aug 2017 12:34:03 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l82so27592091ywc.2 for ; Tue, 08 Aug 2017 12:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iJoAxUG7TqDN8gEs3wjkrG1woFHo5cqdjAvnMssREkg=; b=AEfllQHkHd7iyBd24UVxHeB7iwo2W1yqJKii7I+Zv/S0apHQeBvGvYgoVXhs2vutUN 0/k/xfr/k1x+ET+EIWoRElR8CkVDtXcRnYrG4Aa+JXtQjZBxMFkX3R5c+IiAdoMHFwIR bxUbxHLQwQGeA+tL4qQOLF7yyZEg1Q8o08J/v0bB5tAktTgOE3q00aBo2UYLzYYzPl8e TSTrff9N+reX7neWtu+/njmtHLMLLTyG6iGuD+kAvRYfikNvItj/+t6pEn8n+T5q9c0n UMLayW0RrC+agZgsKuzJrDvDEnQ0ccYulGz6rL1Uz17vKndl3WKuJYfSiRhQszjMs/4l kNPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iJoAxUG7TqDN8gEs3wjkrG1woFHo5cqdjAvnMssREkg=; b=MBfZgFPJeYGg8jH7wS4r2pJFR7pxOZ2EMHTZEKXd2tisjCCCep83sh/3fAWrQYKfsF dFwFPfgbWSHEnluSP0LpgEXCfU0s0YQOftmEEjkKz5NeuFV6Pd7EHIvsQcOGmUJ1sY1D e/MBMpN8ydWHw+krvQmC6ftgvnnExSQHn9M8g68kswrxTxWlYy0zp45LoS/SkxEo21Pi LvkxjllR3Z+O/nA0+pUSqxdIeupZ/gEIcPm3tIPWu8tDF57WFgDx5I11xwO6RYyGQPq2 5TXTdTFLpuz71ucDHxHiOVrSo+9w1Gu/mXR4LDc4LaW08is61KE0P6ToELFHsRIQ3eMj Fpnw== X-Gm-Message-State: AHYfb5goGhVnRab0pRv3ljv3SvjKRVPD6wJut8JHCDK0BLa+nd2m952g As5NK9QJA6B+hGZ/hg+BfTwGqCKlUg== X-Received: by 10.13.213.148 with SMTP id x142mr4528546ywd.311.1502220842601; Tue, 08 Aug 2017 12:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Tue, 8 Aug 2017 12:34:02 -0700 (PDT) In-Reply-To: <20170807143120.GC11845@oracle.com> References: <20170807143120.GC11845@oracle.com> From: Spencer Dawkins at IETF Date: Tue, 8 Aug 2017 14:34:02 -0500 Message-ID: To: Sowmini Varadhan Cc: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a114fa266b297490556430b5c" Archived-At: Subject: Re: [tsvwg] comments about draft-ietf-tsvwg-aqm-dualq-coupled-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 19:34:08 -0000 --001a114fa266b297490556430b5c Content-Type: text/plain; charset="UTF-8" Speaking as an individual, but as an individual who needs to understand what's going on at PubReq time :-) ... On Mon, Aug 7, 2017 at 9:31 AM, Sowmini Varadhan < sowmini.varadhan@oracle.com> wrote: > I had some questions as I was going over this document and > Bob Briscoe suggested that this might be a useful discussion to > share with a list, so here's a current summary, including > clarifications that Bob provided for me offline > > In general, I liked the fact that the Appendix starts off by first > discussing core concepts and then gets into the more complex overload > case- this makes it easy to understand how the various blocks build on > each other. > > In keeping with that same core -> complex flow, it might be easier to > refactor Appendix A.1 a bit, so that it first goes over the enque/dequeue > logic and then gets into the more complex PI-update Pseudo-code. > > I realize the document *is* trying to do that, but it took > me some time to figure out the semantics of alpha/beta/alpha_U/beta_U > (these get defined in Figure 1, but a detailed description > is only available at the bottom Page 17..) > > What eventally helped me put things in place was the brief background > that Bob offered (in the offline thread) > > Bob> A Proportional Integral (PI) algorithm changes the controlled > variable (the > Bob> loss probability p) dependent on how fast the queue is increasing > (which is > Bob> Proportional to excess load) and how far any standing queue is > Bob> from its target (which represents the Integral of load). Two "gain > Bob> factors", beta and alpha, respectively weight how strongly each of > Bob> these elements alters p. > > Bob> The stability analysis in [PI216] recommends the values of alpha > Bob> and beta (in the header file in Fig 1) on the basis that these > Bob> cause the AQM to change p (loss prob) as fast as poss in response > Bob> to changes in load without over-compensating and therefore causing > Bob> oscillations in the queue. > > Bob> The recommended values of alpha and beta determine how much p ought > Bob> to change if it was updated every second. It is best to update p > Bob> as frequently as possible, but the actual update interval (Tupdate) > Bob> is constrained by hardware performance. For link rates from 4 - > Bob> 200 Mb/s, we found Tupdate=16ms is sufficient. Whatever value of > Bob> Tupdate is chosen, p should change by the same amount per second, > Bob> but in more smaller steps. So the gain factors used need to > Bob> be scaled by (Tupdate/1s). This is why alpha_U and beta_U are > Bob> used for updating p in Fig 4, where alpha_U= alpha*Tupdate and > Bob> beta_U=beta*Tupdate. > > Some/all of this information would be useful to have in the doc, since > it provides the needed brief background for dualpi2_update, within > the draft itself. > I found Bob's note to be very helpful to me. It might be helpful to include something like that text in the document itself. Do the right thing, of course. Spencer > One follow-up question (I've not read all of [PI216] yet, it's on my > reading list) - what is the general trend of Tupdate for faster > link-rates? E.g., what is the expected Tupdate at 1Gb/s? > > It would also be helpful to define the high-level semantics > of cq.time(), cq.len(), lq.len() etc. E.g. the description that Bob > offered in the offline mail (below) could be added in the preamble > to enque/dequeue, to improve readability (and also help an implementor > quickly see what the function indirections are supposed to do). > > Bob> cq.time() is a function that returns the time that the head packet > Bob> has been in the classic queue (cq), which is called the "service > Bob> time" of the queue, or sometimes the "sojourn time". > > Bob> Similarly for lq.time(), cq.len() and lq.len(), where lq is the > Bob> L4S queue and len() is the length in bytes. > > I'm still working through the doc, will get back here with additional > questions/comments. > > Thanks > --Sowmini > > --001a114fa266b297490556430b5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as an individual, but as an individual who needs = to understand what's going on at PubReq time :-) ...

On Mon, Aug 7, 2017 at 9:31 AM, Sowm= ini Varadhan <sowmini.varadhan@oracle.com> wrote:<= br>
I had some questions as I was going over = this document and
Bob Briscoe suggested that this might be a useful discussion to
share with a list, so here's a current summary, including
clarifications that Bob provided for me offline

In general, I liked the fact that the Appendix starts off by first
discussing core concepts and then gets into the more complex overload
case- this makes it easy to understand how the various blocks build on
each other.

In keeping with that same core -> complex flow, it might be easier to refactor Appendix A.1 a bit, so that it first goes over the enque/dequeue logic and then gets into the more complex PI-update Pseudo-code.

I realize the document *is* trying to do that, but it took
me some time to figure out the semantics of alpha/beta/alpha_U/beta_U
(these get defined in Figure 1, but a detailed description
is only available at the bottom Page 17..)

What eventally helped me put things in place was the brief background
that Bob offered (in the offline thread)

Bob> A Proportional Integral (PI) algorithm changes the controlled varia= ble (the
Bob> loss probability p) dependent on how fast the queue is increasing (= which is
Bob> Proportional to excess load) and how far any standing queue is
Bob> from its target (which represents the Integral of load). Two "= gain
Bob> factors", beta and alpha, respectively weight how strongly eac= h of
Bob> these elements alters p.

Bob> The stability analysis in [PI216] recommends the values of alpha Bob> and beta (in the header file in Fig 1) on the basis that these
Bob> cause the AQM to change p (loss prob) as fast as poss in response Bob> to changes in load without over-compensating and therefore causing<= br> Bob> oscillations in the queue.

Bob> The recommended values of alpha and beta determine how much p ought=
Bob> to change if it was updated every second. It is best to update p Bob> as frequently as possible, but the actual update interval (Tupdate)=
Bob> is constrained by hardware performance. For link rates from 4 -
Bob> 200 Mb/s, we found Tupdate=3D16ms is sufficient. Whatever value of<= br> Bob> Tupdate is chosen, p should change by the same amount per second, Bob> but in more smaller steps. So the gain factors used need to
Bob> be scaled by (Tupdate/1s). This is why alpha_U and beta_U are
Bob> used for updating p in Fig 4, where alpha_U=3D alpha*Tupdate and Bob> beta_U=3Dbeta*Tupdate.

Some/all of this information would be useful to have in the doc, since
it provides the needed brief background for dualpi2_update, within
the draft itself.

I found Bob's not= e to be very helpful to me. It might be helpful to include something like t= hat text in the document itself.

Do the right thin= g, of course.

Spencer
=C2=A0
One follow-up question (I've not read all of [= PI216] yet, it's on my
reading list) - what is the general trend of Tupdate for faster
link-rates? E.g., what is the expected Tupdate at 1Gb/s?

It would also be helpful to define the high-level semantics
of cq.time(), cq.len(), lq.len() etc. E.g. the description that Bob
offered in the offline mail (below) could be added in the preamble
to enque/dequeue, to improve readability (and also help an implementor
quickly see what the function indirections are supposed to do).

Bob> cq.time() is a function that returns the time that the head packet<= br> Bob> has been in the classic queue (cq), which is called the "servi= ce
Bob> time" of the queue, or sometimes the "sojourn time".=

Bob> Similarly for lq.time(), cq.len() and lq.len(), where lq is the
Bob> L4S queue and len() is the length in bytes.

I'm still working through the doc, will get back here with additional questions/comments.

Thanks
--Sowmini


--001a114fa266b297490556430b5c-- From nobody Wed Aug 9 03:31:53 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765B21320BB for ; Wed, 9 Aug 2017 03:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 O25ejBSurkmk for ; Wed, 9 Aug 2017 03:31:49 -0700 (PDT) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (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 CA0BF1243F3 for ; Wed, 9 Aug 2017 03:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1502274709; x=1533810709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PIQ74l/ku+XEfN1YcVP968+ETkbG/d4D+WABMXYmxQk=; b=mDxCgoN36443xFJdwKYt96KszLV9c9AQdbZAigmIjQ5y+2BzMOqgYsms Q5ihuUn11bTWKJAG9+sP3qSo4hlsbJczSapBhFQfSM0FzTWuuUjcfkOJ9 Yf/Vwe1ag8Age1ee4r8saPTzJw+ScLz16rkgiZazv56WhE/kDWvKNspqi mfReC4hdmi/kpL6RC/Ell/pjIPF1IzKyjUCmtiIDopV8iDjgEB3YINmrH N1lol7tOPNOhwOrGw+1Zq3CdEH5Grs4fZ7ywGMfsiGvslz8nP0aoe78NU wfzHf+gz4pbExa7FvcDYfb3Q6u17Tu4JSTO+42lddgE7NTqhEsaKmqt1Z A==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2017 12:31:45 +0200 X-IronPort-AV: E=Sophos;i="5.41,347,1498514400"; d="scan'208";a="643405751" Received: from he105654.emea1.cds.t-internal.com ([10.169.118.86]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 09 Aug 2017 12:31:45 +0200 Received: from HE105654.EMEA1.cds.t-internal.com (10.169.118.86) by HE105654.emea1.cds.t-internal.com (10.169.118.86) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 9 Aug 2017 12:31:44 +0200 Received: from HE105654.EMEA1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6]) by HE105654.emea1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6%26]) with mapi id 15.00.1263.000; Wed, 9 Aug 2017 12:31:44 +0200 From: To: CC: , Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? Thread-Index: AQHS9w2o4prCs8a2Uk2hjK9vt7Sn6aJIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQgAAbQwCAADlBgIAAr3OAgAAl4JD///thAIAAI+UQ///74YCAAWiAMIALOTZQ Date: Wed, 9 Aug 2017 10:31:44 +0000 Message-ID: References: <595F4D19.9030502@erg.abdn.ac.uk> <595F6F4F.20005@erg.abdn.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <59633402.9020907@erg.abdn.ac.uk> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> <59805BFB.8080201@erg.abdn.ac.uk> <59d67d4a2f6546d1b8d8cb154ba25e66@HE105654.emea1.cds.t-internal.com> In-Reply-To: <59d67d4a2f6546d1b8d8cb154ba25e66@HE105654.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.172.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 10:31:51 -0000 R29ycnksIGFsbCwNCg0KbGV0IG1lIHN1bSB1cCB3aGF0IEkgdGhpbmsgd2UndmUgZGlzY3Vzc2Vk LiBJIHRoaW5rIHRoZXJlIHdhcyBzb21lIHN1cHBvcnQsIGJ1dCBubyBjb25zZW5zdXMgZm9yIGIp IC4gYykgb25seSBzYXcgbWUgc3BlYWtpbmcgdXAgZm9yIGl0IGV4cGxpY2l0ZWx5LCBidXQgaXQg bWlnaHQgYmUgYSBwcmFnbWF0aWMgd2F5IG91dCAoSSBjYW4ndCBqdWRnZSBob3cgbXVjaCBlZmZv cnQgdGhlIElFVEYgcG9vbCBkaXNjdXNzaW9uIHdpbGwgdGFrZSwgaG93ZXZlcikuIFRoZSB0cm91 YmxlIGlzIGNhdXNlZCBieSBiaXQgbWFzayBiYXNlZCBEU0NQIHJlLW1hcmtpbmcuIEkgZG9uJ3Qg ZXhwZWN0IGJpdC1tYXNrIGJhc2VkIERTQ1AgY2xhc3NpZmljYXRpb24gYW5kIHJlLW1hcmtpbmcg dG8gZGlzYXBwZWFyLCBhcyBpdCBhbGxvd3MgZm9yIHRyYW5zcG9ydCBvZiBtdWx0aXBsZSAocmUt bWFya2VkKSBEU0NQIGJ5IGEgc2ltcGxlIGNvbmZpZ3VyYXRpb24uDQoNClRoZXJlJ3MgY29uc2Vu c3VzIHRoYXQgYSBEU0NQIDAwMCB4eXogaXMgYSBnb29kIGNob2ljZSBmb3IgYSBMRSBQSEIsIEkg dGhpbmsuIA0KDQpJbiBnZW5lcmFsLCBhbnkgY29uZmlndXJhdGlvbiBzaG91bGQgYmUgc2ltcGxl LCBoZW5jZSBJIGV4cGVjdCBhIERpZmZzZXJ2IGRvbWFpbjoNCi0gdG8gY2xhc3NpZnkgYW5kIHJl LW1hcmsgRFNDUHMgYmFzZWQgb24gYml0LW1hc2tzIChhIGNvbW1vZGl0eSBhdCBsZWFzdCBpbiBz b21lIHJvdXRlcnMpLg0KLSB0byBjbGFzc2lmeSBEU0NQcyBieSBhIGJpdC1tYXNrIGFuZCByZS1t YXJrIHRvIGEgc2luZ2xlIERTQ1AgKEknZCBsaWtlIHRvIHVuZGVyc3RhbmQgd2hldGhlciB0aGF0 IGlzIGRlc2lyYWJsZSkuDQotIEkgZGlkbid0IGNoZWNrIHdoZXRoZXIgdGhlcmUncyBhIGZlYXR1 cmUgbGlrZSAicmUtbWFyayBBRnggdG8gQUZ5IiAoSSBjYW4ndCByZWNhbGwgdG8gaGF2ZSBoZWFy ZCBvZiB0aGF0KS4NCg0KUmVsYXRlZCB0byBhbiBMRSBQSEIsIGEgc2VuZGluZyBkb21haW4gbWln aHQgYmUgc2VuZGluZyBhbnkgc3RhbmRhcmQvbm9uLSBzdGFuZGFyZCBEU0NQIGFjcm9zcyBhbiBp bnRlcmNvbm5lY3Rpb24gd2l0aG91dCBhbiBTTEEuIFRoaXMgdHJhZmZpYyBtYXkgZXhwZXJpZW5j ZSAoYml0LW1hc2sgYmFzZWQpIERTQ1AgcmUtbWFya2luZyBieSB0aGUgcmVjZWl2aW5nIGRvbWFp bi4gU2hvdWxkIHRoYXQgaGFwcGVuOg0KDQphKSBpZiBhbGwgdW5rbm93biBEU0NQcyBhcmUgcmUt bWFya2VkIHRvIGRlZmF1bHQgRFNDUCwgdGhhdCdzIG5vdCBhbiBpc3N1ZS4NCg0KYikgdGhlIHJl Y2VpdmVyIG1pZ2h0IHJlLW1hcmsgYmFzZWQgb24gYml0LW1hc2tzLiBUaGVuDQogIEFueSBBRnYg RFNDUCBtaWdodCBjb250aW51ZSBhcyAwMDB4eTAgYWZ0ZXIgYSBiaXQtbWFzayBiYXNlZCByZS1t YXJrLiBJZiB6ID0gMCBmb3IgdGhlIExFIERTQ1AsIGluIA0KICB0aGUgY2FzZSBvZiBjb25nZXN0 aW9uLCB0aGlzIG1heSBjYXVzZSBhIGZsb3cgdG8gYmUgcmUtb3JkZXJlZC4gRGVwZW5kaW5nIG9u IHRoZSBjaG9pY2Ugb2YgTEUgRFNDUCwgDQogIHRoZSBkcm9wIHJhdGUgb2YgYSByZS1tYXJrZWQg QUZ2MSBvciBBRnYyIG1heSBiZSBoaWdoZXIgdGhhbiB0aGF0IG9mIEFGdjIgb3IgQUZ2My4NCg0K YykgaWYgdGhlIExFIERTQ1AgaXMgMDAweHkxLCBiaXQtbWFzayBiYXNlZCByZS1tYXJraW5nIGlz IGxlc3MgaGFybWZ1bC4gVGhlIHByb3Bvc2VkIERTQ1AgaXMgZnJvbSBhIA0KICAgICByZXNlcnZl ZCBwb29sIGFuZCB0aGlzIG5lZWRzIHRvIHNldHRsZWQgd2l0aGluIElFVEYuIA0KDQpSZWdhcmRz LA0KDQpSdWVkaWdlcg0KDQoNCg0KDQo= From nobody Wed Aug 9 05:35:23 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DF91323A4; Wed, 9 Aug 2017 05:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 DHAweOF40fOA; Wed, 9 Aug 2017 05:35:18 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4BF13239D; Wed, 9 Aug 2017 05:35:17 -0700 (PDT) Received: from [IPv6:2003:cd:6bdb:ec00:a51f:7e41:2a8f:d1e9] (p200300CD6BDBEC00A51F7E412A8FD1E9.dip0.t-ipconnect.de [IPv6:2003:cd:6bdb:ec00:a51f:7e41:2a8f:d1e9]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id F420872106C12; Wed, 9 Aug 2017 14:35:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen In-Reply-To: Date: Wed, 9 Aug 2017 14:35:13 +0200 Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] AD Evaluation: draft-ietf-tsvwg-sctp-ndata-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 12:35:22 -0000 > On 18. Jul 2017, at 20:26, Spencer Dawkins at IETF = wrote: >=20 > Sorry for not finishing this last week. >=20 > I really like this mechanism and the document describing it was mostly = clear to me. I did have some questions, but most are simple requests for = more clarity. >=20 > I suspect this will require a revised ID, so I'll mark it that way in = the Datatracker, but if I'm completely wrong, don't submit one just to = make me happy. >=20 > Michael and I talked briefly at the beginning of TSVWG this afternoon, = and as I told him, "I'm here all week", if chatting is faster than = typing. Hi Spencer, thanks you very much for the review. See my comments in-line. The = changes are in the GitRepo at https://github.com/sctplab/sctp-idata so submitting an updated version is pretty easy. Let me know if I addressed you issues. Best regards Michael >=20 > I'm a bit curious about this text, >=20 > This document also defines several stream schedulers for general = SCTP > associations. They can be used with and without user message > interleaving being negotiated and possibly behave differently. > =20 > because I'm wondering, "possibly behave differently than what?" Could = you say a sentence or two more about what you mean here? The text in = Section 3 says=20 >=20 > This section defines several stream schedulers. The stream > schedulers may behave differently depending on whether user message > interleaving has been negotiated for the association or not.=20 > =20 > and that's clearer to me, if I'm understanding correctly. The point is that you can use one scheduler not matter if user message = interleaving has been negotiated or not. But this scheduler can behave different in = the following two cases: 1. User message interleaving has been negotiated. 2. User message interleaving has not been negotiated. I'll use the second text also in the first place. An example is given in = the paragraph following the above sentence. >=20 > I need a bit more help on this text, >=20 > Please note that the use of such a scheduler implies late > TSN assignment but it can be used with an [RFC4960] compliant > implementation that does not support user message interleaving. > =20 > I'm not quite sure what you mean by "can be used with/does not support = user message interleaving". I'm guessing that your point was, this is a = new sender-side behavior, so SCTPs that implement this specification = know what I-DATA is, and when they negotiate support for I-DATA, they = will reassemble fragments correctly, whether they would interleave user = messages that they send or not, but I'm guessing. This document specifies two things: 1. Stream Schedulers (like the round robin one used in the example), = which require late TSN assignments. 2. User message interleaving requiring the I-DATA chunk (and = I-FORWARD-TSN). You can implement Schedulers with implementing user message = interleaving. FreeBSD had several schedulers way before implementing user message interleaving. = You just need to do late TSN assignments. So an RFC 4960 based implementation can = implement these schedulers as long as they use late TSN assignment. >=20 > Also, could you provide a reference for "late TSN assignment"? This is = the first usage in the document. Hmm. Not sure it is specified anywhere. It is a term we use. It = describes when you assign the TSN to chunks. Conceptually you could do that as soon as the user provides a = message. Split it up in chunks, assign TSNs and process them. That would be early assignment. Or = you wait with splitting up as long as possible, just before you need to send the chunk. That is = late assignment. I can add the following sentence to explain "late TSN assignment": Late TSN assignment means that the sender generates chunks from user = messages and assigns the TSN as late as possible in the process of sending the user messages. >=20 > You might consider putting this text >=20 > The interleaving of user messages is required for WebRTC = Datachannels > as specified in [I-D.ietf-rtcweb-data-channel]. >=20 > earlier in the document - perhaps in the Introduction? I wish I = thought it belonged in the Abstract, too, but I'm less sure about = suggesting that. I have added The interleaving of user messages is required for WebRTC Datachannels. at the end of the first paragraph of the abstract to avoid using = references in the abstract. >=20 > You might consider adding explanatory text to=20 >=20 > If an SCTP implementation > supports user message interleaving and the extension described in > [RFC3758] or [RFC6525], it is REQUIRED to implement the = corresponding > changes specified in Section 2.3. > =20 > so,=20 >=20 > If an SCTP implementation > supports user message interleaving and the partial reliability = extension=20 > described in [RFC3758] or the stream reconfigurtion extension = described in=20 > RFC6525], it is REQUIRED to implement the corresponding > changes specified in Section 2.3. > =20 > for those of us who don't remember the RFC numbers of extensions off = the tops of our heads. Fixed with using Partial Reliability extension and Stream = Reconfiguration extension. >=20 > I think I know what=20 >=20 > A message is considered in flight, if at least > on of its I-DATA chunks is not acknowledged in a non-renegable > way. >=20 > means, but is "non-renegable" a term of art in the SCTP community? I = had the same question about PPID, but I'm sure you would have the same = answer ... TSN's which have not been acked via the cumack, but only via gap acks = can be revoked or reneged by the the receiver. The term "reneged" is used in RFC 4960. I'm using this wording to cover the RFC 4960 case and also a potential = extension = https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14#section-4= which is implemented in FreeBSD and also the userland stack used in web = browsers. But I can add (i. e. acknowledged by the cummulative TSN ACK) at the end = of the above sentence. The PPID is also well known, since the Payload Protocol Identifier is = defined for DATA chunks in RFC 4960. >=20 > This is a nit, but=20 >=20 > The sender MUST NOT be fragmenting more than one user message in = any > given stream at any time. =20 > =20 > would probably be clearer if it said "must not fragment". Fixed. >=20 > This is a nit, but >=20 > A message (either ordered or unordered) may be identified as > being fragmented whose 'E' and 'B' bits are not set both. > =20 > should probably be be "not both set". Fixed. >=20 > So, dumb question, but how close is the last sentence in >=20 > If I-DATA support has been negotiated for an association, the > reception of a DATA chunk is a violation of the above rules and > therefore the receiver of the DATA chunk MUST abort the association > by sending an ABORT chunk. The ABORT chunk MAY include the = 'Protocol > Violation' error cause. The same applies if I-DATA support has not > be negotiated for an association and an I-DATA chunk is received. > =20 > to what an SCTP that doesn't support this extension would do, if it = received an I-DATA chunk? I was guessing that the last sentence isn't = new behavior, but wanted to ask because it's being specified here. = Whether or not it's different, it might be useful to tell the reader = that. The suggested type is 64, which has the binary representation 01000000. According to https://tools.ietf.org/html/rfc4960#section-3.2 the = required behaviour is: Stop processing of the packet, discard the chunk, report the chunk in an = 'Unrecognized Chunk Type' error cause contained in an ERROR chunk. This is the handling of an unknown chunk having a type with upper bits = 01 required by RFC 4960. We are sending the ABORT, since the peer sends an I-DATA chunk and = support for it=20 has not been negotiated. That is a bug on the peer side. So we send an = ABORT indicating a protocol violation. >=20 > I had the same question about the last sentence in section 2.3.1, = "SCTP Partial Reliability Extension", but I'm sure you would have the = same answer. The I-FORWARD-TSN chunk has 194 as a suggested type, which has the = binary representation 11000010. According to https://tools.ietf.org/html/rfc4960#section-3.2 the = required behaviour is: Continue processing of the packet, discard the chunk, report the chunk = in an 'Unrecognized Chunk Type' error cause contained in an ERROR chunk. This is the handling of an unknown chunk having a type with upper bits = 11 required by RFC 4960. We are sending the ABORT, since the peer sends an I-FORWARD-TSN chunk = and support fir it=20 has not been negotiated. That is a bug on the peer side. So we send an = ABORT indicating a protocol violation. >=20 > In this text,=20 >=20 > 3.4. Priority Based Scheduler (SCTP_SS_PRIO) >=20 > Scheduling of user messages with strict priorities is used. The > priority is configurable per outgoing SCTP stream. Streams having = a > higher priority will be scheduled first and when multiple streams > have the same priority, the scheduling between them is = implementation > dependent. When using user message interleaving, the sending of > lower priority user messages will not block the sending of higher > priority user messages. > =20 > I'm not sure I understand "will not block". If I'm in the process of = sending a lower priority user message and a higher priority user message = is being scheduled, wouldn't the higher priority user message have to = wait? I'm probably not understanding this. The point is that without the possibility of interleaving user messages, = you have to finish the sending of the lower priority message before you can start = sending higher priority message. If you can interleave messages, you don't have = to finish the sending of the lower priority one. I think the following describes it better: When using user message interleaving, the sending of large lower = priority user messages will not delay the sending of higher priority user messages. From nobody Wed Aug 9 15:07:29 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE213226B; Wed, 9 Aug 2017 15:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlb83sHd9S8F; Wed, 9 Aug 2017 15:07:24 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8A2132195; Wed, 9 Aug 2017 15:07:24 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id l82so48302087ywc.2; Wed, 09 Aug 2017 15:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dm3GwwCOjzU5JAQSM7k54afHaRpoV82C0sjzUZm+9fw=; b=OQhP606XpieWOq1kHluI7cHn8ZIfmR8y5rwyV9036xYRhwbYTI3u4TOfS0IVck/ELK V6aUOkxwUgu2eczA5Ervqt+gCUEwKc4odAXfyoxS3fIBPwn9M0lAyzw49g7JFpmo8TvC 51mLvSAc5WouduFS17ZjLa+J4T5RrROtsrdZplt3lkAa+8Hwks8HQGRoRgtiSsRNEUwC XWg+oz4mlOxqmR7U09+BHP7N0Xn9eQo1YFeIZbFFWOISY/kLJDOig2k/a3iAiC7hQKSX yfgzYxeDHF4ILkvD7y9NIrrQDg6RbpcwOTqhS2TJNS0Ia2GTcs+MpP1xwUk5RvqKePGI PiKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dm3GwwCOjzU5JAQSM7k54afHaRpoV82C0sjzUZm+9fw=; b=cR/t+OprLwgw3XAo0r53yItUZi8iSh/pAB2zZovKNPf46B9VbzCTr1+pPx2NVVwQr0 vmcI0nR5jMC1WlIbtB3lDaY3IdNdaEpJshDRblxmuw9WxJX4qiLP5LIhlMhZ1Ckel+qu WWEftJNIVxwkdp7Cb4xCnBNXNzv9gglVZaIxXeXLGJmtp3u6cEanI/9cL+6oeN0qCKwp aQHY8lheSSdGn4/4/SqbW4KQjIZ2C5ZJTuJTrih6SqD2LkX58ZXdtAyM2Bhaes/Hflh5 qne+N1ZSzg7EiwfGSpQUljCCqRQ0i+e5gN/rJ5yzi7wgmAGK+4xv6TZhXcJDOIjRuYb0 yh5Q== X-Gm-Message-State: AHYfb5gbZILtc6R2gf9Od7axOZLTtKco8npg7P79dQppzUDnRTJN17eQ 1yms10xehTJk/ZiY5XyLV7p6NqeVGA== X-Received: by 10.37.36.14 with SMTP id k14mr7433644ybk.211.1502316443630; Wed, 09 Aug 2017 15:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 15:07:23 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Wed, 9 Aug 2017 17:07:23 -0500 Message-ID: To: Michael Tuexen Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a113d4580f6c60d0556594da3" Archived-At: Subject: Re: [tsvwg] AD Evaluation: draft-ietf-tsvwg-sctp-ndata-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 22:07:29 -0000 --001a113d4580f6c60d0556594da3 Content-Type: text/plain; charset="UTF-8" Hi, Michael, This all looks lovely. I had one question (below), but I'll request Last Call anytime you submit an update. And thanks for your help. Spencer On Wed, Aug 9, 2017 at 7:35 AM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > > On 18. Jul 2017, at 20:26, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Sorry for not finishing this last week. > > > > I really like this mechanism and the document describing it was mostly > clear to me. I did have some questions, but most are simple requests for > more clarity. > > > > I suspect this will require a revised ID, so I'll mark it that way in > the Datatracker, but if I'm completely wrong, don't submit one just to make > me happy. > > > > Michael and I talked briefly at the beginning of TSVWG this afternoon, > and as I told him, "I'm here all week", if chatting is faster than typing. > Hi Spencer, > > thanks you very much for the review. See my comments in-line. The changes > are in the GitRepo at > https://github.com/sctplab/sctp-idata > so submitting an updated version is pretty easy. > > Let me know if I addressed you issues. > > Best regards > Michael > > > > I'm a bit curious about this text, > > > > This document also defines several stream schedulers for general SCTP > > associations. They can be used with and without user message > > interleaving being negotiated and possibly behave differently. > > > > because I'm wondering, "possibly behave differently than what?" Could > you say a sentence or two more about what you mean here? The text in > Section 3 says > > > > This section defines several stream schedulers. The stream > > schedulers may behave differently depending on whether user message > > interleaving has been negotiated for the association or not. > > > > and that's clearer to me, if I'm understanding correctly. > The point is that you can use one scheduler not matter if user message > interleaving > has been negotiated or not. But this scheduler can behave different in the > following > two cases: > 1. User message interleaving has been negotiated. > 2. User message interleaving has not been negotiated. > > I'll use the second text also in the first place. An example is given in > the paragraph following > the above sentence. > > > > I need a bit more help on this text, > > > > Please note that the use of such a scheduler implies late > > TSN assignment but it can be used with an [RFC4960] compliant > > implementation that does not support user message interleaving. > > > > I'm not quite sure what you mean by "can be used with/does not support > user message interleaving". I'm guessing that your point was, this is a new > sender-side behavior, so SCTPs that implement this specification know what > I-DATA is, and when they negotiate support for I-DATA, they will reassemble > fragments correctly, whether they would interleave user messages that they > send or not, but I'm guessing. > This document specifies two things: > 1. Stream Schedulers (like the round robin one used in the example), which > require late TSN > assignments. > 2. User message interleaving requiring the I-DATA chunk (and > I-FORWARD-TSN). > > You can implement Schedulers with implementing user message interleaving. > FreeBSD had > several schedulers way before implementing user message interleaving. You > just need to > do late TSN assignments. So an RFC 4960 based implementation can implement > these schedulers > as long as they use late TSN assignment. > > > > Also, could you provide a reference for "late TSN assignment"? This is > the first usage in the document. > Hmm. Not sure it is specified anywhere. It is a term we use. It describes > when you assign the TSN > to chunks. Conceptually you could do that as soon as the user provides a > message. Split it up in > chunks, assign TSNs and process them. That would be early assignment. Or > you wait with splitting up > as long as possible, just before you need to send the chunk. That is late > assignment. > > I can add the following sentence to explain "late TSN assignment": > > Late TSN assignment means that the sender generates chunks from user > messages and assigns > the TSN as late as possible in the process of sending the user messages. > > > > > You might consider putting this text > > > > The interleaving of user messages is required for WebRTC Datachannels > > as specified in [I-D.ietf-rtcweb-data-channel]. > > > > earlier in the document - perhaps in the Introduction? I wish I thought > it belonged in the Abstract, too, but I'm less sure about suggesting that. > I have added > The interleaving of user messages is required for WebRTC Datachannels. > at the end of the first paragraph of the abstract to avoid using references > in the abstract. > > > > You might consider adding explanatory text to > > > > If an SCTP implementation > > supports user message interleaving and the extension described in > > [RFC3758] or [RFC6525], it is REQUIRED to implement the corresponding > > changes specified in Section 2.3. > > > > so, > > > > If an SCTP implementation > > supports user message interleaving and the partial reliability > extension > > described in [RFC3758] or the stream reconfigurtion extension > described in > > RFC6525], it is REQUIRED to implement the corresponding > > changes specified in Section 2.3. > > > > for those of us who don't remember the RFC numbers of extensions off the > tops of our heads. > Fixed with using Partial Reliability extension and Stream Reconfiguration > extension. > > > > I think I know what > > > > A message is considered in flight, if at least > > on of its I-DATA chunks is not acknowledged in a non-renegable > > way. > > > > means, but is "non-renegable" a term of art in the SCTP community? I had > the same question about PPID, but I'm sure you would have the same answer > ... > TSN's which have not been acked via the cumack, but only via gap acks can > be revoked or reneged > by the the receiver. The term "reneged" is used in RFC 4960. > > I'm using this wording to cover the RFC 4960 case and also a potential > extension > https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14#section-4 > which is implemented in FreeBSD and also the userland stack used in web > browsers. > > But I can add (i. e. acknowledged by the cummulative TSN ACK) at the end > of the > above sentence. > > The PPID is also well known, since the Payload Protocol Identifier is > defined for > DATA chunks in RFC 4960. > I didn't see this change in Github. If you were offering to make the change if I thought it was helpful, I think it's helpful :-) > > > > This is a nit, but > > > > The sender MUST NOT be fragmenting more than one user message in any > > given stream at any time. > > > > would probably be clearer if it said "must not fragment". > Fixed. > > > > This is a nit, but > > > > A message (either ordered or unordered) may be identified as > > being fragmented whose 'E' and 'B' bits are not set both. > > > > should probably be be "not both set". > Fixed. > > > > So, dumb question, but how close is the last sentence in > > > > If I-DATA support has been negotiated for an association, the > > reception of a DATA chunk is a violation of the above rules and > > therefore the receiver of the DATA chunk MUST abort the association > > by sending an ABORT chunk. The ABORT chunk MAY include the 'Protocol > > Violation' error cause. The same applies if I-DATA support has not > > be negotiated for an association and an I-DATA chunk is received. > > > > to what an SCTP that doesn't support this extension would do, if it > received an I-DATA chunk? I was guessing that the last sentence isn't new > behavior, but wanted to ask because it's being specified here. Whether or > not it's different, it might be useful to tell the reader that. > The suggested type is 64, which has the binary representation 01000000. > According to https://tools.ietf.org/html/rfc4960#section-3.2 the required > behaviour is: > Stop processing of the packet, discard the chunk, report the chunk in an > 'Unrecognized Chunk Type' > error cause contained in an ERROR chunk. > This is the handling of an unknown chunk having a type with upper bits 01 > required by RFC 4960. > > We are sending the ABORT, since the peer sends an I-DATA chunk and support > for it > has not been negotiated. That is a bug on the peer side. So we send an > ABORT > indicating a protocol violation. > > > > I had the same question about the last sentence in section 2.3.1, "SCTP > Partial Reliability Extension", but I'm sure you would have the same answer. > The I-FORWARD-TSN chunk has 194 as a suggested type, which has the binary > representation 11000010. > According to https://tools.ietf.org/html/rfc4960#section-3.2 the required > behaviour is: > Continue processing of the packet, discard the chunk, report the chunk in > an 'Unrecognized Chunk Type' > error cause contained in an ERROR chunk. > This is the handling of an unknown chunk having a type with upper bits 11 > required by RFC 4960. > > We are sending the ABORT, since the peer sends an I-FORWARD-TSN chunk and > support fir it > has not been negotiated. That is a bug on the peer side. So we send an > ABORT > indicating a protocol violation. > > > > In this text, > > > > 3.4. Priority Based Scheduler (SCTP_SS_PRIO) > > > > Scheduling of user messages with strict priorities is used. The > > priority is configurable per outgoing SCTP stream. Streams having a > > higher priority will be scheduled first and when multiple streams > > have the same priority, the scheduling between them is implementation > > dependent. When using user message interleaving, the sending of > > lower priority user messages will not block the sending of higher > > priority user messages. > > > > I'm not sure I understand "will not block". If I'm in the process of > sending a lower priority user message and a higher priority user message is > being scheduled, wouldn't the higher priority user message have to wait? > I'm probably not understanding this. > The point is that without the possibility of interleaving user messages, > you have > to finish the sending of the lower priority message before you can start > sending > higher priority message. If you can interleave messages, you don't have to > finish > the sending of the lower priority one. > > I think the following describes it better: > > When using user message interleaving, the sending of large lower priority > user > messages will not delay the sending of higher priority user messages. > > > --001a113d4580f6c60d0556594da3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

This all looks lovely. I h= ad one question (below), but I'll request Last Call anytime you submit = an update.

And thanks for your help.
Spencer

On Wed, Aug 9, 2017 at 7:35 AM, Michael Tuexen <= Micha= el.Tuexen@lurchi.franken.de> wrote:
> On 18. Jul 2017, at 20:26, Spencer Dawkins a= t IETF <spencerdawkins.= ietf@gmail.com> wrote:
>
> Sorry for not finishing this last week.
>
> I really like this mechanism and the document describing it was mostly= clear to me. I did have some questions, but most are simple requests for m= ore clarity.
>
> I suspect this will require a revised ID, so I'll mark it that way= in the Datatracker, but if I'm completely wrong, don't submit one = just to make me happy.
>
> Michael and I talked briefly at the beginning of TSVWG this afternoon,= and as I told him, "I'm here all week", if chatting is faste= r than typing.
Hi Spencer,

thanks you very much for the review. See my comments in-line. The changes a= re in the GitRepo at
https://github.com/sctplab/sctp-idata
so submitting an updated version is pretty easy.

Let me know if I addressed you issues.

Best regards
Michael
>
> I'm a bit curious about this text,
>
>=C2=A0 =C2=A0 This document also defines several stream schedulers for = general SCTP
>=C2=A0 =C2=A0 associations.=C2=A0 They can be used with and without use= r message
>=C2=A0 =C2=A0 interleaving being negotiated and possibly behave differe= ntly.
>
> because I'm wondering, "possibly behave differently than what= ?" Could you say a sentence or two more about what you mean here? The = text in Section 3 says
>
>=C2=A0 =C2=A0 This section defines several stream schedulers.=C2=A0 The= stream
>=C2=A0 =C2=A0 schedulers may behave differently depending on whether us= er message
>=C2=A0 =C2=A0 interleaving has been negotiated for the association or n= ot.
>
> and that's clearer to me, if I'm understanding correctly.
The point is that you can use one scheduler not matter if user messa= ge interleaving
has been negotiated or not. But this scheduler can behave different in the = following
two cases:
1. User message interleaving has been negotiated.
2. User message interleaving has not been negotiated.

I'll use the second text also in the first place. An example is given i= n the paragraph following
the above sentence.
>
> I need a bit more help on this text,
>
>=C2=A0 =C2=A0 Please note that the use of such a scheduler implies late=
>=C2=A0 =C2=A0 TSN assignment but it can be used with an [RFC4960] compl= iant
>=C2=A0 =C2=A0 implementation that does not support user message interle= aving.
>
> I'm not quite sure what you mean by "can be used with/does no= t support user message interleaving". I'm guessing that your point= was, this is a new sender-side behavior, so SCTPs that implement this spec= ification know what I-DATA is, and when they negotiate support for I-DATA, = they will reassemble fragments correctly, whether they would interleave use= r messages that they send or not, but I'm guessing.
This document specifies two things:
1. Stream Schedulers (like the round robin one used in the example), which = require late TSN
=C2=A0 =C2=A0assignments.
2. User message interleaving requiring the I-DATA chunk (and I-FORWARD-TSN)= .

You can implement Schedulers with implementing user message interleaving. F= reeBSD had
several schedulers way before implementing user message interleaving. You j= ust need to
do late TSN assignments. So an RFC 4960 based implementation can implement = these schedulers
as long as they use late TSN assignment.
>
> Also, could you provide a reference for "late TSN assignment"= ;? This is the first usage in the document.
Hmm. Not sure it is specified anywhere. It is a term we use. It desc= ribes when you assign the TSN
to chunks. Conceptually you could do that as soon as the user provides a me= ssage. Split it up in
chunks, assign TSNs and process them. That would be early assignment. Or yo= u wait with splitting up
as long as possible, just before you need to send the chunk. That is late a= ssignment.

I can add the following sentence to explain "late TSN assignment"= :

Late TSN assignment means that the sender generates chunks from user messag= es and assigns
the TSN as late as possible in the process of sending the user messages.
>
> You might consider putting this text
>
>=C2=A0 =C2=A0 The interleaving of user messages is required for WebRTC = Datachannels
>=C2=A0 =C2=A0 as specified in [I-D.ietf-rtcweb-data-channel].
>
> earlier in the document - perhaps in the Introduction? I wish I though= t it belonged in the Abstract, too, but I'm less sure about suggesting = that.
I have added
The interleaving of user messages is required for WebRTC Datachannels.
at the end of the first paragraph of the abstract to avoid using references=
in the abstract.
>
> You might consider adding explanatory text to
>
>=C2=A0 =C2=A0 If an SCTP implementation
>=C2=A0 =C2=A0 supports user message interleaving and the extension desc= ribed in
>=C2=A0 =C2=A0 [RFC3758] or [RFC6525], it is REQUIRED to implement the c= orresponding
>=C2=A0 =C2=A0 changes specified in Section 2.3.
>
> so,
>
>=C2=A0 =C2=A0 If an SCTP implementation
>=C2=A0 =C2=A0 supports user message interleaving and the partial reliab= ility extension
>=C2=A0 =C2=A0 described in [RFC3758] or the stream reconfigurtion exten= sion described in
>=C2=A0 =C2=A0 RFC6525], it is REQUIRED to implement the corresponding >=C2=A0 =C2=A0 changes specified in Section 2.3.
>
> for those of us who don't remember the RFC numbers of extensions o= ff the tops of our heads.
Fixed with using Partial Reliability extension and Stream Reconfigur= ation extension.
>
> I think I know what
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0A message is considered in flight, if at lea= st
>=C2=A0 =C2=A0 =C2=A0 =C2=A0on of its I-DATA chunks is not acknowledged = in a non-renegable
>=C2=A0 =C2=A0 =C2=A0 =C2=A0way.
>
> means, but is "non-renegable" a term of art in the SCTP comm= unity? I had the same question about PPID, but I'm sure you would have = the same answer ...
TSN's which have not been acked via the cumack, but only via gap= acks can be revoked or reneged
by the the receiver. The term "reneged" is used in RFC 4960.

I'm using this wording to cover the RFC 4960 case and also a potential = extension
https://tools.ietf.org/htm= l/draft-tuexen-tsvwg-sctp-multipath-14#section-4
which is implemented in FreeBSD and also the userland stack used in web bro= wsers.

But I can add (i. e. acknowledged by the cummulative TSN ACK) at the end of= the
above sentence.

The PPID is also well known, since the Payload Protocol Identifier is defin= ed for
DATA chunks in RFC 4960.

I didn't s= ee this change in Github. If you were offering to make the change if I thou= ght it was helpful, I think it's helpful :-)

= =C2=A0
>
> This is a nit, but
>
>=C2=A0 =C2=A0 The sender MUST NOT be fragmenting more than one user mes= sage in any
>=C2=A0 =C2=A0 given stream at any time.
>
> would probably be clearer if it said "must not fragment". Fixed.
>
> This is a nit, but
>
>=C2=A0 =C2=A0 A message (either ordered or unordered) may be identified= as
>=C2=A0 =C2=A0 being fragmented whose 'E' and 'B' bits a= re not set both.
>
> should probably be be "not both set".
Fixed.
>
> So, dumb question, but how close is the last sentence in
>
>=C2=A0 =C2=A0 If I-DATA support has been negotiated for an association,= the
>=C2=A0 =C2=A0 reception of a DATA chunk is a violation of the above rul= es and
>=C2=A0 =C2=A0 therefore the receiver of the DATA chunk MUST abort the a= ssociation
>=C2=A0 =C2=A0 by sending an ABORT chunk.=C2=A0 The ABORT chunk MAY incl= ude the 'Protocol
>=C2=A0 =C2=A0 Violation' error cause.=C2=A0 The same applies if I-D= ATA support has not
>=C2=A0 =C2=A0 be negotiated for an association and an I-DATA chunk is r= eceived.
>
> to what an SCTP that doesn't support this extension would do, if i= t received an I-DATA chunk? I was guessing that the last sentence isn't= new behavior, but wanted to ask because it's being specified here. Whe= ther or not it's different, it might be useful to tell the reader that.=
The suggested type is 64, which has the binary representation 010000= 00.
According to https://tools.ietf.org/html/rfc4960= #section-3.2 the required behaviour is:
Stop processing of the packet, discard the chunk, report the chunk in an &#= 39;Unrecognized Chunk Type'
error cause contained in an ERROR chunk.
This is the handling of an unknown chunk having a type with upper bits 01 r= equired by RFC 4960.

We are sending the ABORT, since the peer sends an I-DATA chunk and support = for it
has not been negotiated. That is a bug on the peer side. So we send an ABOR= T
indicating a protocol violation.
>
> I had the same question about the last sentence in section 2.3.1, &quo= t;SCTP Partial Reliability Extension", but I'm sure you would have= the same answer.
The I-FORWARD-TSN chunk has 194 as a suggested type, which has the b= inary representation 11000010.
According to https://tools.ietf.org/html/rfc4960= #section-3.2 the required behaviour is:
Continue processing of the packet, discard the chunk, report the chunk in a= n 'Unrecognized Chunk Type'
error cause contained in an ERROR chunk.
This is the handling of an unknown chunk having a type with upper bits 11 r= equired by RFC 4960.

We are sending the ABORT, since the peer sends an I-FORWARD-TSN chunk and s= upport fir it
has not been negotiated. That is a bug on the peer side. So we send an ABOR= T
indicating a protocol violation.
>
> In this text,
>
> 3.4.=C2=A0 Priority Based Scheduler (SCTP_SS_PRIO)
>
>=C2=A0 =C2=A0 Scheduling of user messages with strict priorities is use= d.=C2=A0 The
>=C2=A0 =C2=A0 priority is configurable per outgoing SCTP stream.=C2=A0 = Streams having a
>=C2=A0 =C2=A0 higher priority will be scheduled first and when multiple= streams
>=C2=A0 =C2=A0 have the same priority, the scheduling between them is im= plementation
>=C2=A0 =C2=A0 dependent.=C2=A0 When using user message interleaving, th= e sending of
>=C2=A0 =C2=A0 lower priority user messages will not block the sending o= f higher
>=C2=A0 =C2=A0 priority user messages.
>
> I'm not sure I understand "will not block". If I'm i= n the process of sending a lower priority user message and a higher priorit= y user message is being scheduled, wouldn't the higher priority user me= ssage have to wait? I'm probably not understanding this.
The point is that without the possibility of interleaving user messa= ges, you have
to finish the sending of the lower priority message before you can start se= nding
higher priority message. If you can interleave messages, you don't have= to finish
the sending of the lower priority one.

I think the following describes it better:

When using user message interleaving, the sending of large lower priority u= ser
messages will not delay the sending of higher priority user messages.



--001a113d4580f6c60d0556594da3-- From nobody Wed Aug 9 15:17:54 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6D3132195; Wed, 9 Aug 2017 15:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 AJcBcBn56Rp4; Wed, 9 Aug 2017 15:17:50 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE3413226B; Wed, 9 Aug 2017 15:17:50 -0700 (PDT) Received: from [192.168.1.204] (p57BB4E04.dip0.t-ipconnect.de [87.187.78.4]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 3A384721E282E; Thu, 10 Aug 2017 00:17:47 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen In-Reply-To: Date: Thu, 10 Aug 2017 00:17:47 +0200 Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1011B856-E6D0-4B06-845D-EB8FB6A33A5E@lurchi.franken.de> References: To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] AD Evaluation: draft-ietf-tsvwg-sctp-ndata-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 22:17:53 -0000 > On 10. Aug 2017, at 00:07, Spencer Dawkins at IETF = wrote: >=20 > Hi, Michael, >=20 > This all looks lovely. I had one question (below), but I'll request = Last Call anytime you submit an update. >=20 > And thanks for your help. >=20 > Spencer >=20 > On Wed, Aug 9, 2017 at 7:35 AM, Michael Tuexen = wrote: > > On 18. Jul 2017, at 20:26, Spencer Dawkins at IETF = wrote: > > > > Sorry for not finishing this last week. > > > > I really like this mechanism and the document describing it was = mostly clear to me. I did have some questions, but most are simple = requests for more clarity. > > > > I suspect this will require a revised ID, so I'll mark it that way = in the Datatracker, but if I'm completely wrong, don't submit one just = to make me happy. > > > > Michael and I talked briefly at the beginning of TSVWG this = afternoon, and as I told him, "I'm here all week", if chatting is faster = than typing. > Hi Spencer, >=20 > thanks you very much for the review. See my comments in-line. The = changes are in the GitRepo at > https://github.com/sctplab/sctp-idata > so submitting an updated version is pretty easy. >=20 > Let me know if I addressed you issues. >=20 > Best regards > Michael > > > > I'm a bit curious about this text, > > > > This document also defines several stream schedulers for general = SCTP > > associations. They can be used with and without user message > > interleaving being negotiated and possibly behave differently. > > > > because I'm wondering, "possibly behave differently than what?" = Could you say a sentence or two more about what you mean here? The text = in Section 3 says > > > > This section defines several stream schedulers. The stream > > schedulers may behave differently depending on whether user = message > > interleaving has been negotiated for the association or not. > > > > and that's clearer to me, if I'm understanding correctly. > The point is that you can use one scheduler not matter if user message = interleaving > has been negotiated or not. But this scheduler can behave different in = the following > two cases: > 1. User message interleaving has been negotiated. > 2. User message interleaving has not been negotiated. >=20 > I'll use the second text also in the first place. An example is given = in the paragraph following > the above sentence. > > > > I need a bit more help on this text, > > > > Please note that the use of such a scheduler implies late > > TSN assignment but it can be used with an [RFC4960] compliant > > implementation that does not support user message interleaving. > > > > I'm not quite sure what you mean by "can be used with/does not = support user message interleaving". I'm guessing that your point was, = this is a new sender-side behavior, so SCTPs that implement this = specification know what I-DATA is, and when they negotiate support for = I-DATA, they will reassemble fragments correctly, whether they would = interleave user messages that they send or not, but I'm guessing. > This document specifies two things: > 1. Stream Schedulers (like the round robin one used in the example), = which require late TSN > assignments. > 2. User message interleaving requiring the I-DATA chunk (and = I-FORWARD-TSN). >=20 > You can implement Schedulers with implementing user message = interleaving. FreeBSD had > several schedulers way before implementing user message interleaving. = You just need to > do late TSN assignments. So an RFC 4960 based implementation can = implement these schedulers > as long as they use late TSN assignment. > > > > Also, could you provide a reference for "late TSN assignment"? This = is the first usage in the document. > Hmm. Not sure it is specified anywhere. It is a term we use. It = describes when you assign the TSN > to chunks. Conceptually you could do that as soon as the user provides = a message. Split it up in > chunks, assign TSNs and process them. That would be early assignment. = Or you wait with splitting up > as long as possible, just before you need to send the chunk. That is = late assignment. >=20 > I can add the following sentence to explain "late TSN assignment": >=20 > Late TSN assignment means that the sender generates chunks from user = messages and assigns > the TSN as late as possible in the process of sending the user = messages. >=20 > > > > You might consider putting this text > > > > The interleaving of user messages is required for WebRTC = Datachannels > > as specified in [I-D.ietf-rtcweb-data-channel]. > > > > earlier in the document - perhaps in the Introduction? I wish I = thought it belonged in the Abstract, too, but I'm less sure about = suggesting that. > I have added > The interleaving of user messages is required for WebRTC Datachannels. > at the end of the first paragraph of the abstract to avoid using = references > in the abstract. > > > > You might consider adding explanatory text to > > > > If an SCTP implementation > > supports user message interleaving and the extension described in > > [RFC3758] or [RFC6525], it is REQUIRED to implement the = corresponding > > changes specified in Section 2.3. > > > > so, > > > > If an SCTP implementation > > supports user message interleaving and the partial reliability = extension > > described in [RFC3758] or the stream reconfigurtion extension = described in > > RFC6525], it is REQUIRED to implement the corresponding > > changes specified in Section 2.3. > > > > for those of us who don't remember the RFC numbers of extensions off = the tops of our heads. > Fixed with using Partial Reliability extension and Stream = Reconfiguration extension. > > > > I think I know what > > > > A message is considered in flight, if at least > > on of its I-DATA chunks is not acknowledged in a non-renegable > > way. > > > > means, but is "non-renegable" a term of art in the SCTP community? I = had the same question about PPID, but I'm sure you would have the same = answer ... > TSN's which have not been acked via the cumack, but only via gap acks = can be revoked or reneged > by the the receiver. The term "reneged" is used in RFC 4960. >=20 > I'm using this wording to cover the RFC 4960 case and also a potential = extension > = https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14#section-4= > which is implemented in FreeBSD and also the userland stack used in = web browsers. >=20 > But I can add (i. e. acknowledged by the cummulative TSN ACK) at the = end of the > above sentence. >=20 > The PPID is also well known, since the Payload Protocol Identifier is = defined for > DATA chunks in RFC 4960. >=20 > I didn't see this change in Github. If you were offering to make the = change if I thought it was helpful, I think it's helpful :-) I guess I wasn't clear enough in my e-mail: I only added "(i. e. acknowledged by the cummulative TSN ACK)" at the = end of the sentences. I have not changed anything related to the PPID. I thought that was = clear enough. But if you think some clarification might help, what about changing: The Payload Protocol Identifier (PPID) and the FSN are stored at the same location of the packet using the B bit to determine which value is stored at the location. to The Payload Protocol Identifier (PPID) already defined for DATA chunks in and the new FSN are stored at the same location of the packet using the B bit to determine which value is stored at the location. Best regards Michael >=20 > =20 > > > > This is a nit, but > > > > The sender MUST NOT be fragmenting more than one user message in = any > > given stream at any time. > > > > would probably be clearer if it said "must not fragment". > Fixed. > > > > This is a nit, but > > > > A message (either ordered or unordered) may be identified as > > being fragmented whose 'E' and 'B' bits are not set both. > > > > should probably be be "not both set". > Fixed. > > > > So, dumb question, but how close is the last sentence in > > > > If I-DATA support has been negotiated for an association, the > > reception of a DATA chunk is a violation of the above rules and > > therefore the receiver of the DATA chunk MUST abort the = association > > by sending an ABORT chunk. The ABORT chunk MAY include the = 'Protocol > > Violation' error cause. The same applies if I-DATA support has = not > > be negotiated for an association and an I-DATA chunk is received. > > > > to what an SCTP that doesn't support this extension would do, if it = received an I-DATA chunk? I was guessing that the last sentence isn't = new behavior, but wanted to ask because it's being specified here. = Whether or not it's different, it might be useful to tell the reader = that. > The suggested type is 64, which has the binary representation = 01000000. > According to https://tools.ietf.org/html/rfc4960#section-3.2 the = required behaviour is: > Stop processing of the packet, discard the chunk, report the chunk in = an 'Unrecognized Chunk Type' > error cause contained in an ERROR chunk. > This is the handling of an unknown chunk having a type with upper bits = 01 required by RFC 4960. >=20 > We are sending the ABORT, since the peer sends an I-DATA chunk and = support for it > has not been negotiated. That is a bug on the peer side. So we send an = ABORT > indicating a protocol violation. > > > > I had the same question about the last sentence in section 2.3.1, = "SCTP Partial Reliability Extension", but I'm sure you would have the = same answer. > The I-FORWARD-TSN chunk has 194 as a suggested type, which has the = binary representation 11000010. > According to https://tools.ietf.org/html/rfc4960#section-3.2 the = required behaviour is: > Continue processing of the packet, discard the chunk, report the chunk = in an 'Unrecognized Chunk Type' > error cause contained in an ERROR chunk. > This is the handling of an unknown chunk having a type with upper bits = 11 required by RFC 4960. >=20 > We are sending the ABORT, since the peer sends an I-FORWARD-TSN chunk = and support fir it > has not been negotiated. That is a bug on the peer side. So we send an = ABORT > indicating a protocol violation. > > > > In this text, > > > > 3.4. Priority Based Scheduler (SCTP_SS_PRIO) > > > > Scheduling of user messages with strict priorities is used. The > > priority is configurable per outgoing SCTP stream. Streams = having a > > higher priority will be scheduled first and when multiple streams > > have the same priority, the scheduling between them is = implementation > > dependent. When using user message interleaving, the sending of > > lower priority user messages will not block the sending of higher > > priority user messages. > > > > I'm not sure I understand "will not block". If I'm in the process of = sending a lower priority user message and a higher priority user message = is being scheduled, wouldn't the higher priority user message have to = wait? I'm probably not understanding this. > The point is that without the possibility of interleaving user = messages, you have > to finish the sending of the lower priority message before you can = start sending > higher priority message. If you can interleave messages, you don't = have to finish > the sending of the lower priority one. >=20 > I think the following describes it better: >=20 > When using user message interleaving, the sending of large lower = priority user > messages will not delay the sending of higher priority user messages. >=20 >=20 >=20 From nobody Wed Aug 9 15:35:12 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4213239B; Wed, 9 Aug 2017 15:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BdAf7CcwcUl; Wed, 9 Aug 2017 15:35:06 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7542132380; Wed, 9 Aug 2017 15:35:05 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l82so48604755ywc.2; Wed, 09 Aug 2017 15:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QQzgVHSXjiAg7gHFKurnZi7MWm4+UecGBMGAX37pujs=; b=NTrArJ7zm1tIDlFLDjjFqdxHyhXVr3kATGtKeS1Kwv6Pt7vzFQUSMOggilyYr6T0JT 0uTXDY4hOqHHrSwpLvfMVaco8ocNe7o5Z2sY6dY53AX7e+wq0CH+tgCFOhshxaYOMuNs 0W6pptFgnEFwx0qs+iCjjA3fIg/nBes6oZ2/GQJ8+vVkKs7rW3+398j+BheHGWFWyWLZ 6hxxBR8zlmvUEed6JucbBlBTdHevq8jZEzy6OTfD1S58APz/+KrWoVEKVFGAe+1c5Dp3 7sSVyVeiLGjLkgRFNyH9Vhq3vYnN2mDbvBEy43Z64DdGj1GfMh+WuGsz42XcBAJgW0rr qNlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QQzgVHSXjiAg7gHFKurnZi7MWm4+UecGBMGAX37pujs=; b=LkSr/+qJNeHyXywIHT/S5glM+WzdsD5vvYi5ni7oyhs4vi/IzUoDP/+eavBtAiSjnn f3fDCKbGuDTU1i6TH4vzNhzp1O39YeqRRR/Be937o9jX8NnfNaZzNlTWL6j+iTl2r8IW VawnjQ88Hqo4Gg0dDHqsTd5LdFHNavbt8WzTWkpEoDBTB+RYM+mCA4Sxn7wc5UiOamsl XyvhEfA2s+z/xvaBi179rsuvDejIlSiRW8xOGjcl+6mtQ5qB4OXujXecKgp/RvqPgKAC YQnmbClPhUpdQ19w710gqQV/CKZfDHfM+qzhn7aeTBc6AcLr6eY0ChDTp+R+SRTFoVmQ J9YA== X-Gm-Message-State: AHYfb5iDgvU+pQgvqYA/wWSRfwB/Qxpa+X8giRVfi/bpByzvvj/UEX5S INf68KOoUY9vyTyZ5or8ajQd+X0g0A== X-Received: by 10.129.141.9 with SMTP id d9mr3875352ywg.339.1502318105021; Wed, 09 Aug 2017 15:35:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 15:35:04 -0700 (PDT) In-Reply-To: <1011B856-E6D0-4B06-845D-EB8FB6A33A5E@lurchi.franken.de> References: <1011B856-E6D0-4B06-845D-EB8FB6A33A5E@lurchi.franken.de> From: Spencer Dawkins at IETF Date: Wed, 9 Aug 2017 17:35:04 -0500 Message-ID: To: Michael Tuexen Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="f403045e6012fd57eb055659b052" Archived-At: Subject: Re: [tsvwg] AD Evaluation: draft-ietf-tsvwg-sctp-ndata-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 22:35:11 -0000 --f403045e6012fd57eb055659b052 Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Wed, Aug 9, 2017 at 5:17 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > > > On 10. Aug 2017, at 00:07, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Hi, Michael, > > > > This all looks lovely. I had one question (below), but I'll request Last > Call anytime you submit an update. > > > > And thanks for your help. > > > > Spencer > > > > On Wed, Aug 9, 2017 at 7:35 AM, Michael Tuexen franken.de> wrote: > > > On 18. Jul 2017, at 20:26, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > > > Sorry for not finishing this last week. > > > > > > I really like this mechanism and the document describing it was mostly > clear to me. I did have some questions, but most are simple requests for > more clarity. > > > > > > I suspect this will require a revised ID, so I'll mark it that way in > the Datatracker, but if I'm completely wrong, don't submit one just to make > me happy. > > > > > > Michael and I talked briefly at the beginning of TSVWG this afternoon, > and as I told him, "I'm here all week", if chatting is faster than typing. > > Hi Spencer, > > > > thanks you very much for the review. See my comments in-line. The > changes are in the GitRepo at > > https://github.com/sctplab/sctp-idata > > so submitting an updated version is pretty easy. > > > > Let me know if I addressed you issues. > > > > Best regards > > Michael > > > > > > I'm a bit curious about this text, > > > > > > This document also defines several stream schedulers for general > SCTP > > > associations. They can be used with and without user message > > > interleaving being negotiated and possibly behave differently. > > > > > > because I'm wondering, "possibly behave differently than what?" Could > you say a sentence or two more about what you mean here? The text in > Section 3 says > > > > > > This section defines several stream schedulers. The stream > > > schedulers may behave differently depending on whether user message > > > interleaving has been negotiated for the association or not. > > > > > > and that's clearer to me, if I'm understanding correctly. > > The point is that you can use one scheduler not matter if user message > interleaving > > has been negotiated or not. But this scheduler can behave different in > the following > > two cases: > > 1. User message interleaving has been negotiated. > > 2. User message interleaving has not been negotiated. > > > > I'll use the second text also in the first place. An example is given in > the paragraph following > > the above sentence. > > > > > > I need a bit more help on this text, > > > > > > Please note that the use of such a scheduler implies late > > > TSN assignment but it can be used with an [RFC4960] compliant > > > implementation that does not support user message interleaving. > > > > > > I'm not quite sure what you mean by "can be used with/does not support > user message interleaving". I'm guessing that your point was, this is a new > sender-side behavior, so SCTPs that implement this specification know what > I-DATA is, and when they negotiate support for I-DATA, they will reassemble > fragments correctly, whether they would interleave user messages that they > send or not, but I'm guessing. > > This document specifies two things: > > 1. Stream Schedulers (like the round robin one used in the example), > which require late TSN > > assignments. > > 2. User message interleaving requiring the I-DATA chunk (and > I-FORWARD-TSN). > > > > You can implement Schedulers with implementing user message > interleaving. FreeBSD had > > several schedulers way before implementing user message interleaving. > You just need to > > do late TSN assignments. So an RFC 4960 based implementation can > implement these schedulers > > as long as they use late TSN assignment. > > > > > > Also, could you provide a reference for "late TSN assignment"? This is > the first usage in the document. > > Hmm. Not sure it is specified anywhere. It is a term we use. It > describes when you assign the TSN > > to chunks. Conceptually you could do that as soon as the user provides a > message. Split it up in > > chunks, assign TSNs and process them. That would be early assignment. Or > you wait with splitting up > > as long as possible, just before you need to send the chunk. That is > late assignment. > > > > I can add the following sentence to explain "late TSN assignment": > > > > Late TSN assignment means that the sender generates chunks from user > messages and assigns > > the TSN as late as possible in the process of sending the user messages. > > > > > > > > You might consider putting this text > > > > > > The interleaving of user messages is required for WebRTC > Datachannels > > > as specified in [I-D.ietf-rtcweb-data-channel]. > > > > > > earlier in the document - perhaps in the Introduction? I wish I > thought it belonged in the Abstract, too, but I'm less sure about > suggesting that. > > I have added > > The interleaving of user messages is required for WebRTC Datachannels. > > at the end of the first paragraph of the abstract to avoid using > references > > in the abstract. > > > > > > You might consider adding explanatory text to > > > > > > If an SCTP implementation > > > supports user message interleaving and the extension described in > > > [RFC3758] or [RFC6525], it is REQUIRED to implement the > corresponding > > > changes specified in Section 2.3. > > > > > > so, > > > > > > If an SCTP implementation > > > supports user message interleaving and the partial reliability > extension > > > described in [RFC3758] or the stream reconfigurtion extension > described in > > > RFC6525], it is REQUIRED to implement the corresponding > > > changes specified in Section 2.3. > > > > > > for those of us who don't remember the RFC numbers of extensions off > the tops of our heads. > > Fixed with using Partial Reliability extension and Stream > Reconfiguration extension. > > > > > > I think I know what > > > > > > A message is considered in flight, if at least > > > on of its I-DATA chunks is not acknowledged in a non-renegable > > > way. > > > > > > means, but is "non-renegable" a term of art in the SCTP community? I > had the same question about PPID, but I'm sure you would have the same > answer ... > > TSN's which have not been acked via the cumack, but only via gap acks > can be revoked or reneged > > by the the receiver. The term "reneged" is used in RFC 4960. > > > > I'm using this wording to cover the RFC 4960 case and also a potential > extension > > https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp- > multipath-14#section-4 > > which is implemented in FreeBSD and also the userland stack used in web > browsers. > > > > But I can add (i. e. acknowledged by the cummulative TSN ACK) at the end > of the > > above sentence. > > > > The PPID is also well known, since the Payload Protocol Identifier is > defined for > > DATA chunks in RFC 4960. > > > > I didn't see this change in Github. If you were offering to make the > change if I thought it was helpful, I think it's helpful :-) > I guess I wasn't clear enough in my e-mail: > > I only added "(i. e. acknowledged by the cummulative TSN ACK)" at the end > of > the sentences. > > I have not changed anything related to the PPID. I thought that was clear > enough. > > But if you think some clarification might help, what about changing: > > The Payload Protocol Identifier (PPID) and the FSN are stored at the > same location of the packet using the B bit to determine which value is > stored at the location. > > to > > The Payload Protocol Identifier (PPID) already defined for DATA chunks > in and the new FSN are stored at the > same location of the packet using the B bit to determine which value is > stored at the location. > Upon reflection, you're right, of course. That should be clear enough. Please feel free to submit an update that I can process. And thanks for the quick response. Spencer > Best regards > Michael > > > > > > > > > > This is a nit, but > > > > > > The sender MUST NOT be fragmenting more than one user message in any > > > given stream at any time. > > > > > > would probably be clearer if it said "must not fragment". > > Fixed. > > > > > > This is a nit, but > > > > > > A message (either ordered or unordered) may be identified as > > > being fragmented whose 'E' and 'B' bits are not set both. > > > > > > should probably be be "not both set". > > Fixed. > > > > > > So, dumb question, but how close is the last sentence in > > > > > > If I-DATA support has been negotiated for an association, the > > > reception of a DATA chunk is a violation of the above rules and > > > therefore the receiver of the DATA chunk MUST abort the association > > > by sending an ABORT chunk. The ABORT chunk MAY include the > 'Protocol > > > Violation' error cause. The same applies if I-DATA support has not > > > be negotiated for an association and an I-DATA chunk is received. > > > > > > to what an SCTP that doesn't support this extension would do, if it > received an I-DATA chunk? I was guessing that the last sentence isn't new > behavior, but wanted to ask because it's being specified here. Whether or > not it's different, it might be useful to tell the reader that. > > The suggested type is 64, which has the binary representation 01000000. > > According to https://tools.ietf.org/html/rfc4960#section-3.2 the > required behaviour is: > > Stop processing of the packet, discard the chunk, report the chunk in an > 'Unrecognized Chunk Type' > > error cause contained in an ERROR chunk. > > This is the handling of an unknown chunk having a type with upper bits > 01 required by RFC 4960. > > > > We are sending the ABORT, since the peer sends an I-DATA chunk and > support for it > > has not been negotiated. That is a bug on the peer side. So we send an > ABORT > > indicating a protocol violation. > > > > > > I had the same question about the last sentence in section 2.3.1, > "SCTP Partial Reliability Extension", but I'm sure you would have the same > answer. > > The I-FORWARD-TSN chunk has 194 as a suggested type, which has the > binary representation 11000010. > > According to https://tools.ietf.org/html/rfc4960#section-3.2 the > required behaviour is: > > Continue processing of the packet, discard the chunk, report the chunk > in an 'Unrecognized Chunk Type' > > error cause contained in an ERROR chunk. > > This is the handling of an unknown chunk having a type with upper bits > 11 required by RFC 4960. > > > > We are sending the ABORT, since the peer sends an I-FORWARD-TSN chunk > and support fir it > > has not been negotiated. That is a bug on the peer side. So we send an > ABORT > > indicating a protocol violation. > > > > > > In this text, > > > > > > 3.4. Priority Based Scheduler (SCTP_SS_PRIO) > > > > > > Scheduling of user messages with strict priorities is used. The > > > priority is configurable per outgoing SCTP stream. Streams having a > > > higher priority will be scheduled first and when multiple streams > > > have the same priority, the scheduling between them is > implementation > > > dependent. When using user message interleaving, the sending of > > > lower priority user messages will not block the sending of higher > > > priority user messages. > > > > > > I'm not sure I understand "will not block". If I'm in the process of > sending a lower priority user message and a higher priority user message is > being scheduled, wouldn't the higher priority user message have to wait? > I'm probably not understanding this. > > The point is that without the possibility of interleaving user messages, > you have > > to finish the sending of the lower priority message before you can start > sending > > higher priority message. If you can interleave messages, you don't have > to finish > > the sending of the lower priority one. > > > > I think the following describes it better: > > > > When using user message interleaving, the sending of large lower > priority user > > messages will not delay the sending of higher priority user messages. > > > > > > > > --f403045e6012fd57eb055659b052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

On Wed, Aug 9, 2017 at 5:17 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

> On 10. Aug 2017, at 00:07, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>= ; wrote:
>
> Hi, Michael,
>
> This all looks lovely. I had one question (below), but I'll reques= t Last Call anytime you submit an update.
>
> And thanks for your help.
>
> Spencer
>
> On Wed, Aug 9, 2017 at 7:35 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de&= gt; wrote:
> > On 18. Jul 2017, at 20:26, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> >
> > Sorry for not finishing this last week.
> >
> > I really like this mechanism and the document describing it was m= ostly clear to me. I did have some questions, but most are simple requests = for more clarity.
> >
> > I suspect this will require a revised ID, so I'll mark it tha= t way in the Datatracker, but if I'm completely wrong, don't submit= one just to make me happy.
> >
> > Michael and I talked briefly at the beginning of TSVWG this after= noon, and as I told him, "I'm here all week", if chatting is = faster than typing.
> Hi Spencer,
>
> thanks you very much for the review. See my comments in-line. The chan= ges are in the GitRepo at
> https://github.com/sctplab/sctp-idata
> so submitting an updated version is pretty easy.
>
> Let me know if I addressed you issues.
>
> Best regards
> Michael
> >
> > I'm a bit curious about this text,
> >
> >=C2=A0 =C2=A0 This document also defines several stream schedulers= for general SCTP
> >=C2=A0 =C2=A0 associations.=C2=A0 They can be used with and withou= t user message
> >=C2=A0 =C2=A0 interleaving being negotiated and possibly behave di= fferently.
> >
> > because I'm wondering, "possibly behave differently than= what?" Could you say a sentence or two more about what you mean here?= The text in Section 3 says
> >
> >=C2=A0 =C2=A0 This section defines several stream schedulers.=C2= =A0 The stream
> >=C2=A0 =C2=A0 schedulers may behave differently depending on wheth= er user message
> >=C2=A0 =C2=A0 interleaving has been negotiated for the association= or not.
> >
> > and that's clearer to me, if I'm understanding correctly.=
> The point is that you can use one scheduler not matter if user message= interleaving
> has been negotiated or not. But this scheduler can behave different in= the following
> two cases:
> 1. User message interleaving has been negotiated.
> 2. User message interleaving has not been negotiated.
>
> I'll use the second text also in the first place. An example is gi= ven in the paragraph following
> the above sentence.
> >
> > I need a bit more help on this text,
> >
> >=C2=A0 =C2=A0 Please note that the use of such a scheduler implies= late
> >=C2=A0 =C2=A0 TSN assignment but it can be used with an [RFC4960] = compliant
> >=C2=A0 =C2=A0 implementation that does not support user message in= terleaving.
> >
> > I'm not quite sure what you mean by "can be used with/do= es not support user message interleaving". I'm guessing that your = point was, this is a new sender-side behavior, so SCTPs that implement this= specification know what I-DATA is, and when they negotiate support for I-D= ATA, they will reassemble fragments correctly, whether they would interleav= e user messages that they send or not, but I'm guessing.
> This document specifies two things:
> 1. Stream Schedulers (like the round robin one used in the example), w= hich require late TSN
>=C2=A0 =C2=A0 assignments.
> 2. User message interleaving requiring the I-DATA chunk (and I-FORWARD= -TSN).
>
> You can implement Schedulers with implementing user message interleavi= ng. FreeBSD had
> several schedulers way before implementing user message interleaving. = You just need to
> do late TSN assignments. So an RFC 4960 based implementation can imple= ment these schedulers
> as long as they use late TSN assignment.
> >
> > Also, could you provide a reference for "late TSN assignment= "? This is the first usage in the document.
> Hmm. Not sure it is specified anywhere. It is a term we use. It descri= bes when you assign the TSN
> to chunks. Conceptually you could do that as soon as the user provides= a message. Split it up in
> chunks, assign TSNs and process them. That would be early assignment. = Or you wait with splitting up
> as long as possible, just before you need to send the chunk. That is l= ate assignment.
>
> I can add the following sentence to explain "late TSN assignment&= quot;:
>
> Late TSN assignment means that the sender generates chunks from user m= essages and assigns
> the TSN as late as possible in the process of sending the user message= s.
>
> >
> > You might consider putting this text
> >
> >=C2=A0 =C2=A0 The interleaving of user messages is required for We= bRTC Datachannels
> >=C2=A0 =C2=A0 as specified in [I-D.ietf-rtcweb-data-channel].=
> >
> > earlier in the document - perhaps in the Introduction? I wish I t= hought it belonged in the Abstract, too, but I'm less sure about sugges= ting that.
> I have added
> The interleaving of user messages is required for WebRTC Datachannels.=
> at the end of the first paragraph of the abstract to avoid using refer= ences
> in the abstract.
> >
> > You might consider adding explanatory text to
> >
> >=C2=A0 =C2=A0 If an SCTP implementation
> >=C2=A0 =C2=A0 supports user message interleaving and the extension= described in
> >=C2=A0 =C2=A0 [RFC3758] or [RFC6525], it is REQUIRED to implement = the corresponding
> >=C2=A0 =C2=A0 changes specified in Section 2.3.
> >
> > so,
> >
> >=C2=A0 =C2=A0 If an SCTP implementation
> >=C2=A0 =C2=A0 supports user message interleaving and the partial r= eliability extension
> >=C2=A0 =C2=A0 described in [RFC3758] or the stream reconfigurtion = extension described in
> >=C2=A0 =C2=A0 RFC6525], it is REQUIRED to implement the correspond= ing
> >=C2=A0 =C2=A0 changes specified in Section 2.3.
> >
> > for those of us who don't remember the RFC numbers of extensi= ons off the tops of our heads.
> Fixed with using Partial Reliability extension and Stream Reconfigurat= ion extension.
> >
> > I think I know what
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0A message is considered in flight, if a= t least
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0on of its I-DATA chunks is not acknowle= dged in a non-renegable
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0way.
> >
> > means, but is "non-renegable" a term of art in the SCTP= community? I had the same question about PPID, but I'm sure you would = have the same answer ...
> TSN's which have not been acked via the cumack, but only via gap a= cks can be revoked or reneged
> by the the receiver. The term "reneged" is used in RFC 4960.=
>
> I'm using this wording to cover the RFC 4960 case and also a poten= tial extension
> https://tools.ietf.or= g/html/draft-tuexen-tsvwg-sctp-multipath-14#section-4
> which is implemented in FreeBSD and also the userland stack used in we= b browsers.
>
> But I can add (i. e. acknowledged by the cummulative TSN ACK) at the e= nd of the
> above sentence.
>
> The PPID is also well known, since the Payload Protocol Identifier is = defined for
> DATA chunks in RFC 4960.
>
> I didn't see this change in Github. If you were offering to make t= he change if I thought it was helpful, I think it's helpful :-)
I guess I wasn't clear enough in my e-mail:

I only added "(i. e. acknowledged by the cummulative TSN ACK)" at= the end of
the sentences.

I have not changed anything related to the PPID. I thought that was clear e= nough.

But if you think some clarification might help, what about changing:

The Payload Protocol Identifier (PPID) and the FSN are stored at the
same location of the packet using the B bit to determine which value is
stored at the location.

to

The Payload Protocol Identifier (PPID) already defined for DATA chunks
in <xref target=3D'RFC4960'/> and the new FSN are stored at t= he
same location of the packet using the B bit to determine which value is
stored at the location.

Upon reflection= , you're right, of course. That should be clear enough.

<= /div>
Please feel free to submit an update that I can process.

And thanks for the quick response.

Spencer
=C2=A0
Best regards=
Michael
>
>
> >
> > This is a nit, but
> >
> >=C2=A0 =C2=A0 The sender MUST NOT be fragmenting more than one use= r message in any
> >=C2=A0 =C2=A0 given stream at any time.
> >
> > would probably be clearer if it said "must not fragment"= ;.
> Fixed.
> >
> > This is a nit, but
> >
> >=C2=A0 =C2=A0 A message (either ordered or unordered) may be ident= ified as
> >=C2=A0 =C2=A0 being fragmented whose 'E' and 'B' b= its are not set both.
> >
> > should probably be be "not both set".
> Fixed.
> >
> > So, dumb question, but how close is the last sentence in
> >
> >=C2=A0 =C2=A0 If I-DATA support has been negotiated for an associa= tion, the
> >=C2=A0 =C2=A0 reception of a DATA chunk is a violation of the abov= e rules and
> >=C2=A0 =C2=A0 therefore the receiver of the DATA chunk MUST abort = the association
> >=C2=A0 =C2=A0 by sending an ABORT chunk.=C2=A0 The ABORT chunk MAY= include the 'Protocol
> >=C2=A0 =C2=A0 Violation' error cause.=C2=A0 The same applies i= f I-DATA support has not
> >=C2=A0 =C2=A0 be negotiated for an association and an I-DATA chunk= is received.
> >
> > to what an SCTP that doesn't support this extension would do,= if it received an I-DATA chunk? I was guessing that the last sentence isn&= #39;t new behavior, but wanted to ask because it's being specified here= . Whether or not it's different, it might be useful to tell the reader = that.
> The suggested type is 64, which has the binary representation 01000000= .
> According to https://tools.ietf.org/html/rf= c4960#section-3.2 the required behaviour is:
> Stop processing of the packet, discard the chunk, report the chunk in = an 'Unrecognized Chunk Type'
> error cause contained in an ERROR chunk.
> This is the handling of an unknown chunk having a type with upper bits= 01 required by RFC 4960.
>
> We are sending the ABORT, since the peer sends an I-DATA chunk and sup= port for it
> has not been negotiated. That is a bug on the peer side. So we send an= ABORT
> indicating a protocol violation.
> >
> > I had the same question about the last sentence in section 2.3.1,= "SCTP Partial Reliability Extension", but I'm sure you would= have the same answer.
> The I-FORWARD-TSN chunk has 194 as a suggested type, which has the bin= ary representation 11000010.
> According to https://tools.ietf.org/html/rf= c4960#section-3.2 the required behaviour is:
> Continue processing of the packet, discard the chunk, report the chunk= in an 'Unrecognized Chunk Type'
> error cause contained in an ERROR chunk.
> This is the handling of an unknown chunk having a type with upper bits= 11 required by RFC 4960.
>
> We are sending the ABORT, since the peer sends an I-FORWARD-TSN chunk = and support fir it
> has not been negotiated. That is a bug on the peer side. So we send an= ABORT
> indicating a protocol violation.
> >
> > In this text,
> >
> > 3.4.=C2=A0 Priority Based Scheduler (SCTP_SS_PRIO)
> >
> >=C2=A0 =C2=A0 Scheduling of user messages with strict priorities i= s used.=C2=A0 The
> >=C2=A0 =C2=A0 priority is configurable per outgoing SCTP stream.= =C2=A0 Streams having a
> >=C2=A0 =C2=A0 higher priority will be scheduled first and when mul= tiple streams
> >=C2=A0 =C2=A0 have the same priority, the scheduling between them = is implementation
> >=C2=A0 =C2=A0 dependent.=C2=A0 When using user message interleavin= g, the sending of
> >=C2=A0 =C2=A0 lower priority user messages will not block the send= ing of higher
> >=C2=A0 =C2=A0 priority user messages.
> >
> > I'm not sure I understand "will not block". If I= 9;m in the process of sending a lower priority user message and a higher pr= iority user message is being scheduled, wouldn't the higher priority us= er message have to wait? I'm probably not understanding this.
> The point is that without the possibility of interleaving user message= s, you have
> to finish the sending of the lower priority message before you can sta= rt sending
> higher priority message. If you can interleave messages, you don't= have to finish
> the sending of the lower priority one.
>
> I think the following describes it better:
>
> When using user message interleaving, the sending of large lower prior= ity user
> messages will not delay the sending of higher priority user messages.<= br> >
>
>


--f403045e6012fd57eb055659b052-- From nobody Wed Aug 9 17:39:06 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 159A21324CF; Wed, 9 Aug 2017 17:39:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150232554403.11875.18212689783722165612@ietfa.amsl.com> Date: Wed, 09 Aug 2017 17:39:04 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-12.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 00:39:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol Authors : Randall R. Stewart Michael Tuexen Salvatore Loreto Robin Seggelmann Filename : draft-ietf-tsvwg-sctp-ndata-12.txt Pages : 21 Date : 2017-08-09 Abstract: The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender. The interleaving of user messages is required for WebRTC Datachannels. Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined. A stream scheduler can choose to either implement, or not implement, user message interleaving. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-12 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-sctp-ndata-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-12 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/ From nobody Wed Aug 9 17:40:42 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B4D131CB2; Wed, 9 Aug 2017 17:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 46evdG91e5Kz; Wed, 9 Aug 2017 17:40:37 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB990129D9D; Wed, 9 Aug 2017 17:40:36 -0700 (PDT) Received: from [192.168.1.204] (p57BB4E04.dip0.t-ipconnect.de [87.187.78.4]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 83A54721E282E; Thu, 10 Aug 2017 02:40:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen In-Reply-To: Date: Thu, 10 Aug 2017 02:40:34 +0200 Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0552C7E8-CBD5-4CC1-AB97-DA4BD59C0BBE@lurchi.franken.de> References: <1011B856-E6D0-4B06-845D-EB8FB6A33A5E@lurchi.franken.de> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] AD Evaluation: draft-ietf-tsvwg-sctp-ndata-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 00:40:40 -0000 > On 10. Aug 2017, at 00:35, Spencer Dawkins at IETF = wrote: >=20 > Hi, Michael, >=20 > On Wed, Aug 9, 2017 at 5:17 PM, Michael Tuexen = wrote: >=20 > > On 10. Aug 2017, at 00:07, Spencer Dawkins at IETF = wrote: > > > > Hi, Michael, > > > > This all looks lovely. I had one question (below), but I'll request = Last Call anytime you submit an update. > > > > And thanks for your help. > > > > Spencer > > > > On Wed, Aug 9, 2017 at 7:35 AM, Michael Tuexen = wrote: > > > On 18. Jul 2017, at 20:26, Spencer Dawkins at IETF = wrote: > > > > > > Sorry for not finishing this last week. > > > > > > I really like this mechanism and the document describing it was = mostly clear to me. I did have some questions, but most are simple = requests for more clarity. > > > > > > I suspect this will require a revised ID, so I'll mark it that way = in the Datatracker, but if I'm completely wrong, don't submit one just = to make me happy. > > > > > > Michael and I talked briefly at the beginning of TSVWG this = afternoon, and as I told him, "I'm here all week", if chatting is faster = than typing. > > Hi Spencer, > > > > thanks you very much for the review. See my comments in-line. The = changes are in the GitRepo at > > https://github.com/sctplab/sctp-idata > > so submitting an updated version is pretty easy. > > > > Let me know if I addressed you issues. > > > > Best regards > > Michael > > > > > > I'm a bit curious about this text, > > > > > > This document also defines several stream schedulers for = general SCTP > > > associations. They can be used with and without user message > > > interleaving being negotiated and possibly behave differently. > > > > > > because I'm wondering, "possibly behave differently than what?" = Could you say a sentence or two more about what you mean here? The text = in Section 3 says > > > > > > This section defines several stream schedulers. The stream > > > schedulers may behave differently depending on whether user = message > > > interleaving has been negotiated for the association or not. > > > > > > and that's clearer to me, if I'm understanding correctly. > > The point is that you can use one scheduler not matter if user = message interleaving > > has been negotiated or not. But this scheduler can behave different = in the following > > two cases: > > 1. User message interleaving has been negotiated. > > 2. User message interleaving has not been negotiated. > > > > I'll use the second text also in the first place. An example is = given in the paragraph following > > the above sentence. > > > > > > I need a bit more help on this text, > > > > > > Please note that the use of such a scheduler implies late > > > TSN assignment but it can be used with an [RFC4960] compliant > > > implementation that does not support user message interleaving. > > > > > > I'm not quite sure what you mean by "can be used with/does not = support user message interleaving". I'm guessing that your point was, = this is a new sender-side behavior, so SCTPs that implement this = specification know what I-DATA is, and when they negotiate support for = I-DATA, they will reassemble fragments correctly, whether they would = interleave user messages that they send or not, but I'm guessing. > > This document specifies two things: > > 1. Stream Schedulers (like the round robin one used in the example), = which require late TSN > > assignments. > > 2. User message interleaving requiring the I-DATA chunk (and = I-FORWARD-TSN). > > > > You can implement Schedulers with implementing user message = interleaving. FreeBSD had > > several schedulers way before implementing user message = interleaving. You just need to > > do late TSN assignments. So an RFC 4960 based implementation can = implement these schedulers > > as long as they use late TSN assignment. > > > > > > Also, could you provide a reference for "late TSN assignment"? = This is the first usage in the document. > > Hmm. Not sure it is specified anywhere. It is a term we use. It = describes when you assign the TSN > > to chunks. Conceptually you could do that as soon as the user = provides a message. Split it up in > > chunks, assign TSNs and process them. That would be early = assignment. Or you wait with splitting up > > as long as possible, just before you need to send the chunk. That is = late assignment. > > > > I can add the following sentence to explain "late TSN assignment": > > > > Late TSN assignment means that the sender generates chunks from user = messages and assigns > > the TSN as late as possible in the process of sending the user = messages. > > > > > > > > You might consider putting this text > > > > > > The interleaving of user messages is required for WebRTC = Datachannels > > > as specified in [I-D.ietf-rtcweb-data-channel]. > > > > > > earlier in the document - perhaps in the Introduction? I wish I = thought it belonged in the Abstract, too, but I'm less sure about = suggesting that. > > I have added > > The interleaving of user messages is required for WebRTC = Datachannels. > > at the end of the first paragraph of the abstract to avoid using = references > > in the abstract. > > > > > > You might consider adding explanatory text to > > > > > > If an SCTP implementation > > > supports user message interleaving and the extension described = in > > > [RFC3758] or [RFC6525], it is REQUIRED to implement the = corresponding > > > changes specified in Section 2.3. > > > > > > so, > > > > > > If an SCTP implementation > > > supports user message interleaving and the partial reliability = extension > > > described in [RFC3758] or the stream reconfigurtion extension = described in > > > RFC6525], it is REQUIRED to implement the corresponding > > > changes specified in Section 2.3. > > > > > > for those of us who don't remember the RFC numbers of extensions = off the tops of our heads. > > Fixed with using Partial Reliability extension and Stream = Reconfiguration extension. > > > > > > I think I know what > > > > > > A message is considered in flight, if at least > > > on of its I-DATA chunks is not acknowledged in a = non-renegable > > > way. > > > > > > means, but is "non-renegable" a term of art in the SCTP community? = I had the same question about PPID, but I'm sure you would have the same = answer ... > > TSN's which have not been acked via the cumack, but only via gap = acks can be revoked or reneged > > by the the receiver. The term "reneged" is used in RFC 4960. > > > > I'm using this wording to cover the RFC 4960 case and also a = potential extension > > = https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-14#section-4= > > which is implemented in FreeBSD and also the userland stack used in = web browsers. > > > > But I can add (i. e. acknowledged by the cummulative TSN ACK) at the = end of the > > above sentence. > > > > The PPID is also well known, since the Payload Protocol Identifier = is defined for > > DATA chunks in RFC 4960. > > > > I didn't see this change in Github. If you were offering to make the = change if I thought it was helpful, I think it's helpful :-) > I guess I wasn't clear enough in my e-mail: >=20 > I only added "(i. e. acknowledged by the cummulative TSN ACK)" at the = end of > the sentences. >=20 > I have not changed anything related to the PPID. I thought that was = clear enough. >=20 > But if you think some clarification might help, what about changing: >=20 > The Payload Protocol Identifier (PPID) and the FSN are stored at the > same location of the packet using the B bit to determine which value = is > stored at the location. >=20 > to >=20 > The Payload Protocol Identifier (PPID) already defined for DATA chunks > in and the new FSN are stored at the > same location of the packet using the B bit to determine which value = is > stored at the location. >=20 > Upon reflection, you're right, of course. That should be clear enough. >=20 > Please feel free to submit an update that I can process. Submitted. >=20 > And thanks for the quick response. Thanks for your help! Best regards Michael >=20 > Spencer > =20 > Best regards > Michael > > > > > > > > > > This is a nit, but > > > > > > The sender MUST NOT be fragmenting more than one user message = in any > > > given stream at any time. > > > > > > would probably be clearer if it said "must not fragment". > > Fixed. > > > > > > This is a nit, but > > > > > > A message (either ordered or unordered) may be identified as > > > being fragmented whose 'E' and 'B' bits are not set both. > > > > > > should probably be be "not both set". > > Fixed. > > > > > > So, dumb question, but how close is the last sentence in > > > > > > If I-DATA support has been negotiated for an association, the > > > reception of a DATA chunk is a violation of the above rules and > > > therefore the receiver of the DATA chunk MUST abort the = association > > > by sending an ABORT chunk. The ABORT chunk MAY include the = 'Protocol > > > Violation' error cause. The same applies if I-DATA support has = not > > > be negotiated for an association and an I-DATA chunk is = received. > > > > > > to what an SCTP that doesn't support this extension would do, if = it received an I-DATA chunk? I was guessing that the last sentence isn't = new behavior, but wanted to ask because it's being specified here. = Whether or not it's different, it might be useful to tell the reader = that. > > The suggested type is 64, which has the binary representation = 01000000. > > According to https://tools.ietf.org/html/rfc4960#section-3.2 the = required behaviour is: > > Stop processing of the packet, discard the chunk, report the chunk = in an 'Unrecognized Chunk Type' > > error cause contained in an ERROR chunk. > > This is the handling of an unknown chunk having a type with upper = bits 01 required by RFC 4960. > > > > We are sending the ABORT, since the peer sends an I-DATA chunk and = support for it > > has not been negotiated. That is a bug on the peer side. So we send = an ABORT > > indicating a protocol violation. > > > > > > I had the same question about the last sentence in section 2.3.1, = "SCTP Partial Reliability Extension", but I'm sure you would have the = same answer. > > The I-FORWARD-TSN chunk has 194 as a suggested type, which has the = binary representation 11000010. > > According to https://tools.ietf.org/html/rfc4960#section-3.2 the = required behaviour is: > > Continue processing of the packet, discard the chunk, report the = chunk in an 'Unrecognized Chunk Type' > > error cause contained in an ERROR chunk. > > This is the handling of an unknown chunk having a type with upper = bits 11 required by RFC 4960. > > > > We are sending the ABORT, since the peer sends an I-FORWARD-TSN = chunk and support fir it > > has not been negotiated. That is a bug on the peer side. So we send = an ABORT > > indicating a protocol violation. > > > > > > In this text, > > > > > > 3.4. Priority Based Scheduler (SCTP_SS_PRIO) > > > > > > Scheduling of user messages with strict priorities is used. = The > > > priority is configurable per outgoing SCTP stream. Streams = having a > > > higher priority will be scheduled first and when multiple = streams > > > have the same priority, the scheduling between them is = implementation > > > dependent. When using user message interleaving, the sending = of > > > lower priority user messages will not block the sending of = higher > > > priority user messages. > > > > > > I'm not sure I understand "will not block". If I'm in the process = of sending a lower priority user message and a higher priority user = message is being scheduled, wouldn't the higher priority user message = have to wait? I'm probably not understanding this. > > The point is that without the possibility of interleaving user = messages, you have > > to finish the sending of the lower priority message before you can = start sending > > higher priority message. If you can interleave messages, you don't = have to finish > > the sending of the lower priority one. > > > > I think the following describes it better: > > > > When using user message interleaving, the sending of large lower = priority user > > messages will not delay the sending of higher priority user = messages. > > > > > > >=20 >=20 From nobody Thu Aug 10 06:34:14 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0964B132153; Thu, 10 Aug 2017 06:34:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk CC: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, spencerdawkins.ietf@gmail.com, Gorry Fairhurst , draft-ietf-tsvwg-sctp-ndata@ietf.org, tsvwg-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150237204602.11847.9380206064199336776.idtracker@ietfa.amsl.com> Date: Thu, 10 Aug 2017 06:34:06 -0700 Archived-At: Subject: [tsvwg] Last Call: (Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 13:34:06 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-08-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender. The interleaving of user messages is required for WebRTC Datachannels. Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined. A stream scheduler can choose to either implement, or not implement, user message interleaving. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Aug 13 06:27:35 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FD5132436 for ; Sun, 13 Aug 2017 06:27:33 -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 6HWnbvK2R4Jc for ; Sun, 13 Aug 2017 06:27:31 -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 8014E1327EC for ; Sun, 13 Aug 2017 06:27:30 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-ab-599053bf4f46 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.67.21299.FB350995; Sun, 13 Aug 2017 15:27:28 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sun, 13 Aug 2017 15:27:27 +0200 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=NdbByYKcVbtzQjx1nox3nkxLGcsEpOHI9cdSIpBtLq0=; b=Npe+g0bxOV0h6uq2Nw2mla1EPbwr0Lk+kEL7WhFik9Y6gu2z8RzYQjXPxEIVocCdLaZ2vfE/hc8DnbtAMYgOT6vC11L0DfvQbvJpgVru20lS26o4SE+Pb2A4rn1a7HI6DEftm9+yslZQXTiqo2/BQ4+VhHYtWkfyJIxcN227xKM= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB299.eurprd07.prod.outlook.com (10.141.234.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Sun, 13 Aug 2017 13:27:26 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::c0f3:b085:e762:6381]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::c0f3:b085:e762:6381%13]) with mapi id 15.01.1341.020; Sun, 13 Aug 2017 13:27:26 +0000 From: Ingemar Johansson S To: tsvwg IETF list Thread-Topic: ECN documents in 3GPP RAN2 Thread-Index: AdMUN07uRR4xEc3kSxiqXedlV7jFeQ== Date: Sun, 13 Aug 2017 13:27:25 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.113.27.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB299; 6:ZflVKshqsXr3JNkrEsMvgGpfQw42HE7ILMxvIWfXZJas9jShu85A22S/TNDEDOeKW3SpuJIYcWnC9jeJpeXmgVi+CbuxvEkaf+gU2kkkpwjw8D7bzTpYUa4JJxxDprfUtsPeC9dZPTH4UJI2hHNtoUh8+52SQiR9aO5grjElUY1Qh9Kql8OZQ6mWhWoOyodH27c3QuKyxNFuaKLLIzLs+GDogT54/KZFspqFieM0w2BhpLQO/CPoMIXfIoDxS6EBK7ooLvLKEvqgoNaJGpTK/u/BtFZtVdsAtCnfCzHhWBxrJDZ11FlQJBITDvt/s2IPjNwVxIecKVxEsHDqgqImtA==; 5:30WCiG7g2s6fANWe+5LB7Vl+M1ltqMzaJ7Xfw+tqFsOTbOPwp+ctlt8s/SJUzvybZBBMnEGo0H96Cg1KC7h/qYR53BwTot887dUdtrctR45+cDisJwFcSJMJ7qiUsNfsJ4V/UuKXCxYJhAhxVAQA6w==; 24:cc2ylJUaCIWs9fwk/q89RkgubXkS7rUp8CGsAkDWzfdiBrMyxNw8J8lpmycxZ5pMxsDYhAZPJcgNbDg6Y56RUSmbz9InhmUYfTfXY9F+exg=; 7:S2q0qhb2MvGa3vPPsA+2ey9BIyTY8UMjiuNPvfRgiwO6uA0khiflMKI2zlWSV8/qaoH+RTNU1QAUh81xYHdgaN4ciu121FwI4fqpNtVo/q/QsiVrqCyfnK0ssrEwA6ZuF+ycS/lLyIZ8dAmPy1Sm4lHk4nViglFGi23Nu/L0P4ndVjKaqh1QkLa57OyTOVN5J8NtifsUmm08bWWAcFKjUsxiowVhKd7wSLBRGRvw7RM= x-ms-office365-filtering-correlation-id: c92f3b2e-01ec-44ec-abf4-08d4e24f09db x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603124)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB299; x-ms-traffictypediagnostic: DB4PR07MB299: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB299; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB299; x-forefront-prvs: 03982FDC1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(74316002)(55016002)(8936002)(99286003)(3660700001)(101416001)(7736002)(3846002)(6306002)(54896002)(50986999)(2900100001)(6436002)(5250100002)(7696004)(9686003)(8558605004)(81166006)(106356001)(236005)(81156014)(33656002)(6916009)(54356999)(8676002)(606006)(2906002)(105586002)(14454004)(25786009)(97736004)(53936002)(86362001)(3280700002)(6506006)(9326002)(66066001)(68736007)(110136004)(478600001)(790700001)(6116002)(102836003)(966005)(5660300001)(19609705001)(189998001)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB299; H:DB4PR07MB348.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348D4E5B4E6F4FDD0129814C28F0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2017 13:27:25.9111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB299 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHObv3btfh6DQ1f/joMTNW5rKHYWCSgRSBIegfalROvehIN9ld plIwU5NmhqKOFHwyK80yxbLIxE0zjTK1p5mPmdQkwxRDQpC2HQP/+5zv55wfv9+Pw1LSGsaL Val1nFatTJMJxXRlbCcE9kSXxAWZXolC+ucnhMfQSZPpryAKxYtDk7k0VSan3ReWIE4duivP qDmaVblcKNIjQ4gBubCAD8F4rZ4yIDErxX0IevVFNDkMIDCX5zkNjYspmO7qZogxCuB34SJy vJdiK4KG6UwHC3EoNFlWnLk73gnLTQaRg92wH9S132RILofKZ69FhBXwYLZR4GAa+0N+TZ3z rQTHw/fWq84cYV+YWpmkHUxhT/gyWysgfWMwdb2lCHvA3Lc1e33Wzjugr/wSiX1htLYIOXoG XCCChhuNiIhIeDEwIyLCKoCe3OH1QrthoblTSPgMlPcb1lkFM21565VGGJgqXaCJ8AGTYZkh opWB/LZxhqyFgzv3CxAZIQmWxooZsgovmHh/HRH2AdvX50wJkldtmK7KPgWFNbA4F1PlXMZm GKycpckVBXyuKBcSDoDb9T8pwoFwa81Cb8zrkKgZefAcn5iecuCggtOqknheo1aoOV07sv8a c8eq/xP0bj7cgjCLZK4SeXhJnJRRZvLZ6RYELCVzl0ScsEeSZGV2DqfVnNdeTON4C/JmaZmn JLx7OFaKU5Q67gLHZXDa/1bAunjpUaTFak5MjaCfPvTcZTt8NserQh1m1LrEIFfNlrLRzTPR OttYsM11+w9NhCHh1+Nc6rSx/d4g96kl5c1QvdAPlYV4bxsZGP4YcK2xukMWW21Mr+17WcQe CX40oRPzUuvU6tKmKOPxvdNVp86NpXzY6hZk6r38p9CcxZa2BE1eSZLRfKpy/x5Kyyv/AWFn qCUxAwAA Archived-At: Subject: [tsvwg] ECN documents in 3GPP RAN2 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 13:27:33 -0000 --_000_DB4PR07MB348D4E5B4E6F4FDD0129814C28F0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi To whom it may concern. The following ECN related documents have been uploaded to 3GPP and are subj= ect to discussion on Aug 21-25 Stage 3 details on how to implement ECN support on the RLC layer http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_99/Docs/R2-1708179.zip Motivation to improved ECN handling in NR http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_99/Docs/R2-1709469.zip /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_DB4PR07MB348D4E5B4E6F4FDD0129814C28F0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

To whom it may concern.

The following ECN related documents have been upload= ed to 3GPP and are subject to discussion on Aug 21-25

 

Stage 3 details on how to implement ECN support on t= he RLC layer

http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_= 99/Docs/R2-1708179.zip

 

Motivation to improved ECN handling in NR=

http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_9= 9/Docs/R2-1709469.zip

 

/Ingemar

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB348D4E5B4E6F4FDD0129814C28F0DB4PR07MB348eurprd_-- From nobody Mon Aug 14 13:02:35 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3598313240F; Mon, 14 Aug 2017 13:02:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: Cc: tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150274094205.10409.17989486864216331116@ietfa.amsl.com> Date: Mon, 14 Aug 2017 13:02:22 -0700 Archived-At: Subject: [tsvwg] Genart last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:02:22 -0000 Reviewer: Stewart Bryant Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tsvwg-sctp-ndata-12 Reviewer: Stewart Bryant Review Date: 2017-08-14 IETF LC End Date: 2017-08-25 IESG Telechat date: Not scheduled for a telechat Summary: This is a well written draft and is ready for publication. Major issues: None Minor issues: None Nits/editorial comments: You repeat the text: "A message is considered in flight, if at least on of its I-DATA chunks is not acknowledged in a non-renegable way" in two consecutive sections, maybe a common definition could be used. From nobody Wed Aug 16 02:24:42 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F22132025; Wed, 16 Aug 2017 02:24:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Winter To: Cc: tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150287547583.12471.9085655210334710687@ietfa.amsl.com> Date: Wed, 16 Aug 2017 02:24:35 -0700 Archived-At: Subject: [tsvwg] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 09:24:36 -0000 Reviewer: Stefan Winter Review result: Has Issues One issue: The chapter IANA considerations mentions four bits to be registered: E,B,U,I. In the main body, only three of those are actually defined and used (End of fragmented message, Beginning of fragmented message, Unordered/Ordered message). Please add a definition of the I bit or remove the IANA registration request for that bit. And the rest are only musings not needing any action if the authors don't want to action on them: The introduction presents a good use case, quoting: "e.g., when the transmission of an urgent message is blocked from transmission because the sender has started the transmission of another, possibly large, message". The later queueing example in figure 1 has three SIDs being queued simultanseously. It is not clear which of those "has already started" and which are the important ones being delayed. For a better understanding of the reader, it might be useful to revise the figure so that the head-of-line blocking happens for SID 1 because transmission of 0 and 2 has already started (and declare SID 1 to be the "important" message). The ASCII art would just have to indent SID 1 content a bit (placing 0 and 2 earlier in time), and the resulting serialisation would then put all the SID 1 messages at the very end, when 0 and 2 have been completely submitted (right?). In 2.2.3, is there any particular reason why the "protocol violation" error cause is only a MAY? As it enables debugging on the remote end, a SHOULD seems useful. From nobody Wed Aug 16 11:16:23 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A841200F3; Wed, 16 Aug 2017 11:16:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150290738178.15052.11420132809128204914@ietfa.amsl.com> Date: Wed, 16 Aug 2017 11:16:21 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:16:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Diffserv to IEEE 802.11 Mapping Authors : Tim Szigeti Jerome Henry Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-06.txt Pages : 35 Date : 2017-08-16 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-06 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/ From nobody Wed Aug 16 11:17:34 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D86132382 for ; Wed, 16 Aug 2017 11:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2-_uB4p9m2Du for ; Wed, 16 Aug 2017 11:17:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEDD13237B for ; Wed, 16 Aug 2017 11:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14442; q=dns/txt; s=iport; t=1502907449; x=1504117049; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=08xJ5o46xcGGdB8GuV5kMaGF8g8ULUkU+436WJzUwaM=; b=kRB1tpJzi4J/ejSbImzqYTvjZ84V8wdg6U95BtY5fNVZRvJUpF6rBMWL 0+njuJQ4kEMH5nhsch1HRfa5fGRlqXmF+qngHhRg/E0CPWsTkr7yBqvkj RDqj/1uXLSWivphmNwBBeetXD7bvI71NKYdH2BMt0YVFPRTBYPJPrFHhb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAADvipRZ/4YNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEVB44LkBCBbog3jWIOggQshRsChEY/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAw4ZEysUDAQCAQgRBAEBAR4JByERFAkIAQEEAQ0FCIoQAxUQrF86h?= =?us-ascii?q?zkNhBYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMkBIICgy4BgyeCV4FoAQESAUW?= =?us-ascii?q?FTgWXZogjPAKHUoMMhGyEbYIZhWCKbIw2hSSEQAEfOH8LdxUfKoUSBRwZgQ8/d?= =?us-ascii?q?ocwgSOBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,383,1498521600"; d="scan'208";a="472439354" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Aug 2017 18:17:28 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7GIHSmr020388 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Aug 2017 18:17:28 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Aug 2017 13:17:27 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Wed, 16 Aug 2017 13:17:27 -0500 From: "Tim Szigeti (szigeti)" To: "Black, David" , G Fairhurst , tsvwg WG CC: "Jerome Henry (jerhenry)" , Fred Baker Thread-Topic: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments Thread-Index: AdL9iKwSAOxDD+ndQlSPMOl+i2FRxAJn8UbwAi2HR9ABt1YHQA== Date: Wed, 16 Aug 2017 18:17:27 +0000 Message-ID: <9907583a83dd46ffa05409471a256e5e@XCH-RCD-010.cisco.com> References: <9603e1facabb48ec865439a997392120@XCH-RCD-010.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.132.12.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:17:33 -0000 Thank you David for catching even these subtle points. I've made the changes exactly as you've recommended below and have uploaded= a new draft. Please confirm if this allows us to proceed to the next step. TIA. -tim > -----Original Message----- > From: Black, David [mailto:David.Black@dell.com] > Sent: Monday, August 07, 2017 6:24 PM > To: Tim Szigeti (szigeti); G Fairhurst; tsvwg WG > Cc: Jerome Henry (jerhenry); Fred Baker > Subject: RE: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg- > ieee-802-11 - David Black's comments >=20 > Hi Tim, >=20 > Many thanks for your continued efforts on this draft, and sorry for the > delayed response. The changes generally look good - there were two area= s > where I wanted to re-check the revised text: >=20 > A) On Section 5.3, I wrote: >=20 > > > I don't understand what a "trust function" is, so this looks like a > > > circular statement. Once "trust function" is clarified, change > > > "RECOMMENDED to trust DSCP" to "RECOMMENDED to pass through > DSCP" > > > ... but the details of this clarification are crucial as this text > > > is a potentially serious security hole > as currently written. >=20 > The revised text removes the use of the term "trust function" and is much > clearer as a result. >=20 > B) >=20 > > > Finally, Gorry noted: > > > > > > (4) I suspect the security section may benefit from a better defin= ition > > > of the case where the 802.11 network forms the edge of a DS domain= . I > > > suspect other people will suggest text on this. > > > > > > I suspect that some of the changes suggested in this review towards > > > less use of the word "trust" will help with this concern, so I sugges= t that > Gorry and I > > > both take a look at the resulting text to see whether it suffices. = That > said, it > > > would help to add a reference from the security considerations text > > > on CS6 and CS7 back to section 5.4, which discusses this "edge of a D= S > domain" case. > > > >=20 > Beyond removal of most uses of the word "trust," the security > considerations text on CS6 and CS7 was expanded, which obviates the need > for a backpointer, however .... this text in Section 5.4 is now subtly > inconsistent with at least the security considerations text: >=20 > When business requirements and/or technical constraints and/or > administrative policies require QoS markings to be passed through at > the wireless edge, then it is RECOMMENDED to pass through Layer 3 > DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the > upstream direction, for the following reasons: >=20 > CS6 and CS7 are exceptions to this "RECOMMENDED" requirement for the > security reasons discussed in section 8, and because they should not be > generated by hosts for the reasons discussed in section 5.1. I have a c= ouple > of suggested changes. >=20 > 1) Insert "with the exception of CS6 and CS7" after "in the upstream > direction" in the above text. >=20 > 2) Add a paragraph after the itemized list to explain (mostly by citing t= he two > relevant sections): >=20 > CS6 and CS7 are exceptions to this pass through recommendation because > wireless hosts SHOULD NOT use them (see Section 5.1) and traffic with > those two markings poses a threat to operation of the wired network (s= ee > Section 8.2). CS6 and CS7 SHOULD NOT be passed through to the wired > network in the upstream direction unless the access point has been > specifically configured to do that by a network administrator or opera= tor. >=20 > Does that sound reasonable? >=20 > Thanks, --David >=20 > > -----Original Message----- > > From: Tim Szigeti (szigeti) [mailto:szigeti@cisco.com] > > Sent: Thursday, July 27, 2017 6:35 PM > > To: Black, David ; G Fairhurst > > ; tsvwg WG > > Cc: Jerome Henry (jerhenry) ; Fred Baker > > > > Subject: RE: TSVWG Working Group Last Call (WGLC) on > > draft-ietf-tsvwg-ieee- > > 802-11 - David Black's comments > > > > Hi David, > > > > Thank you again for taking the time to do another round of review. > > > > All changes you've suggested below have been made to the latest > > version of the draft. > > > > Thank you again for helping us find the right balance on security vs. > > functionality. > > > > -tim > > > > > -----Original Message----- > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, > > > David > > > Sent: Saturday, July 15, 2017 9:40 AM > > > To: G Fairhurst; tsvwg WG > > > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on > > > draft-ietf-tsvwg- > > > ieee-802-11 - David Black's comments > > > > > > In general, the -04 draft is much improved from the -01 draft. All > > > of my remaining major concerns involve uses of the word "trust" that > > > > > > -- Major > > > > > > Section 3: > > > > > > This document assumes and RECOMMENDS that all wireless access > points > > > (as the bridges between wired-and-wireless networks) support the > > > ability to: > > > > > > [... snip ...] > > > > > > o trust DSCP markings set by wireless endpoint devices > > > > > > This instance of "trust" appears to have been overlooked. I suggest > > > changing "trust" to "process." > > > > > > Section 5: > > > > > > o DSCP-Trust at the wireless access point (effectively a 1:1 DSCP= - > > > to-DSCP mapping) > > > > > > Aha, the dreaded T-word again. Suggest: DSCP-Trust -> DSCP- > Passthrough, > > > as that not only removes the T-word, but is also more descriptive. = This > also > > > affects Section 5.3 ... > > > > > > Section 5.3: > > > > > > Change DSCP-Trust -> DSCP-Passthrough in section title. > > > > > > It is generally NOT RECOMMENDED to trust DSCP markings from > > > unauthenticated and unauthorized devices, as these are typically > > > considered untrusted sources. > > > > > > to trust DSCP markings -> to pass through DSCP markings > > > > > > When business requirements and/or technical constraints and/or > > > administrative policies require a trust function at the wireless > > > edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016= ] > > > UP markings) markings in the upstream direction, for the following > > > reasons: > > > > > > I don't understand what a "trust function" is, so this looks like a > > > circular statement. Once "trust function" is clarified, change > > > "RECOMMENDED to trust DSCP" to "RECOMMENDED to pass through > DSCP" > > > ... but the details of this clarification are crucial as this text > > > is a potentially serious security hole > > as > > > currently written. > > > > > > A related minor issue turns up in Section 8.1 - see below. > > > > > > Finally, Gorry noted: > > > > > > (4) I suspect the security section may benefit from a better defin= ition > > > of the case where the 802.11 network forms the edge of a DS domain= . I > > > suspect other people will suggest text on this. > > > > > > I suspect that some of the changes suggested in this review towards > > > less use of the word "trust" will help with this concern, so I sugges= t that > Gorry and I > > > both take a look at the resulting text to see whether it suffices. = That > said, it > > > would help to add a reference from the security considerations text > > > on CS6 and CS7 back to section 5.4, which discusses this "edge of a D= S > domain" > > case. > > > > > > -- Minor > > > > > > Section 2.1: > > > > > > Thus the QoS treatment of packets at the access point will depend = on > > > the position of the AP in the network infrastructure and on the WL= AN > > > deployment model. > > > > > > Needs specific examples and/or forward references to what changes > > > with AP position. > > > > > > Sections 5.2, 5.3 and 5.4: > > > > > > These sections are effectively discussing alternatives for access > > > point > > Diffserv > > > functionality. That structure (do one of these three) is not clear i= n the > draft. > > > > > > Section 8.1: > > > > > > Additionally, Section 5.3 made it clear > > > that it is generally NOT RECOMMENDED to trust DSCP markings fro= m > > > unauthorized and/or unauthenticated devices, as these are > > > typically considered untrusted sources. This is especially > > > relevant for IoT deployments, where tens-of-billions of devices > > > are being connected to IP networks, many of which have little o= r > > > no security. > > > > > > In the first sentence: "trust" -> "pass through" > > > > > > In the second sentence as written, "many of which" refers to "IP > > > networks" - I suspect that was not intended, e.g., "tens-of-billions > > > of devices that may have little or no security are being connected > > > to IP networks" may be closer to what was intended. > > > > > > Setting a trust boundary reflective of business objectives and > > > policy, such that traffic from authorized users and/or > > > applications and/or endpoints will be accepted by the network; > > > otherwise packet markings will be "bleached" (i.e. remarked to > > > DSCP DF and/or UP 0). > > > > > > I have some idea of what a "trust boundary" is, but suspect that > > > "traffic conditioning policy" may be clearer and closer to what was > intended. > > > > > > Section 8.2: > > > > > > Every paragraph in this section is bidirectional in scope, applying > > > to both > > > wired->wireless and wireless-> wired traffic, except for this paragra= ph: > > > > > > If such marking/mapping were not controlled, then, for example, a > > > malicious user could cause WLAN DoS by flooding traffic marked CS7 > > > DSCP downstream. This codepoint would map by default to UP 7 and > > > would be assigned to the Voice Access Category (AC_VO). Such a fl= ood > > > could cause Denial-of-Service to not only wireless voice > > > applications, but also to all other traffic classes. > > > > > > I suggest making this paragraph bidirectional by providing the > > > example in both directions and then making it clear that the followin= g > paragraph: > > > > > > Therefore, to mitigate such an attack, it is RECOMMENDED that all > > > packets marked to Diffserv Codepoints not in use over the wireless > > > network be mapped to UP 0. > > > > > > applies to both access points and wireless device operating systems. > > > > > > > > > -- Editorial > > > > > > Section 1.1: > > > > > > Note: [RFC4594] is intended to be viewed as a set of "project plan= s" > > > for building all the (diffserv) furniture that one might want. Th= us, > > > it describes different types of traffic expected in IP networks an= d > > > provides guidance as to what DSCP marking(s) should be associated > > > with each traffic type. As such, this document draws heavily on > > > [RFC4594], [RFC5127], and [RFC8100]. > > > > > > The first sentence seems a bit too informal, suggest: > > > > > > OLD > > > Note: [RFC4594] is intended to be viewed as a set of "project plan= s" > > > for building all the (diffserv) furniture that one might want. > > > NEW > > > Note: [RFC4594] is intended to be viewed as a framework and > guidelines > > > for supporting Diffserv in any network, including wireless network= s. > > > > > > Section 2.1: > > > > > > It is important to recognize that the wired-to-wireless edge may o= r > > > may not equate to the edge of the Diffserv domain. > > > > > > equate to the edge of the Diffserv domain -> function as an edge of > > > a Diffserv domain or a domain boundary. > > > > > > Section 8: > > > > > > Initial paragraph seems overly defensive, suggest: > > > > > > OLD > > > The recommendations put forward in this document do not present an= y > > > additional security concerns that do not already exist in wired an= d > > > wireless devices. In fact, several of the recommendations made in > > > this document serve to mitigate and protect wired and wireless > > > networks from potential abuse arising from existing vulnerabilitie= s. > > > NEW > > > The recommendations in this document concern existing wired and > > > wireless > > > network functionality, and for that reason do not add significant = security > > > concerns. Some of the recommendations help protect wired and > wireless > > > networks from potential abuse, e.g., as discussed further in this = section. > > > > > > Section 8.2: > > > > > > It should be strongly noted that in the wireless deployment model > > > > > > I suggest deleting "It should be strongly noted that" > > > > > > Thanks, --David > > > > > > > > > > -----Original Message----- > > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of G > > > > Fairhurst > > > > Sent: Thursday, July 6, 2017 3:11 AM > > > > To: tsvwg WG > > > > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on > > > > draft-ietf-tsvwg- > > > > ieee-802-11-01 to conclude 10th Jul 2017 > > > > > > > > This email announces a second TSVWG Working Group Last Call (WGLC) > > on: > > > > > > > > DiffServ to IEEE 802.11 Mapping > > > > draft-ietf-tsvwg-ieee-802-11-01 > > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01 > > > > > > > > This WGLC will last for about 2 weeks weeks. The purpose of this > > > > call is to provide further feedback (if required) on changes made > > > > since the first WGLC concluded. > > > > > > > > Comments should be sent to thetsvwg@ietf.org > > > > list, although purely editorial comments > > > > may be sent directly to the authors. Please cc: the WG chairs > > > > attsvwg-chairs@ietf.org if you > > > > would like the chairs to track such editorial comments as part of > > > > the WGLC process. > > > > > > > > No IPR disclosures have been submitted directly on > > > > draft-ietf-tsvwg-ieee-802-11-01 > > > > > > > > Thanks, > > > > Gorry > > > > (TSVWG Co-Chair) From nobody Sun Aug 20 23:50:24 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9FB126B71; Sun, 20 Aug 2017 23:50:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: gorry@erg.abdn.ac.uk, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150329821874.6559.3845932090802569070.idtracker@ietfa.amsl.com> Date: Sun, 20 Aug 2017 23:50:18 -0700 Archived-At: Subject: [tsvwg] tsvwg - New Meeting Session Request for IETF 100 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 06:50:19 -0000 A new meeting session request has just been submitted by Gorry Fairhurst, a Chair of the tsvwg working group. --------------------------------------------------------- Working Group Name: Transport Area Working Group Area Name: Transport Area Session Requester: Gorry Fairhurst Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: intarea tsvarea iccrg aqm rmcat tcpm mptcp taps ippm quic tcpinc rtgwg opsarea Second Priority: dtn rtcweb v6ops tram dispatch Third Priority: artarea ccamp People who must be present: David L. Black Gorry Fairhurst Spencer Dawkins Wesley Eddy Mirja Kuehlewind Resources Requested: Special Requests: [If rtcweb has 2 sessions, 1 should not conflict] [Must not conflict with Transport Area BoFs] --------------------------------------------------------- From nobody Wed Aug 23 07:02:01 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7C1132C26 for ; Wed, 23 Aug 2017 07:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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=dell.com header.b=YCL3BXzH; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Wcwk57KL 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 gARCsewT-zcq for ; Wed, 23 Aug 2017 07:01:57 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 00011132C25 for ; Wed, 23 Aug 2017 07:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1503496916; x=1535032916; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SJ2Cjaac19oNyb/zMRO2Kdc8WeLV9S0hQbG7Wjshluc=; b=YCL3BXzHti5q+PMUzILW1+f6u9sb+dZulpVp5mzZmDIQsWtPnXK1vPDA APQf7G6kk1+/U2g6oQe8Ol7qYU9Vfx5CtwJL5g+Co9EjwhMvYcls2wMFp u+YxsIs9SQ3LbGV4RXRXCtj8uNtmOfYIyUGmjgWbW9eF5TgQyiYg6J2+T c=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2017 09:01:56 -0500 From: "Black, David" Cc: "Jerome Henry (jerhenry)" , Fred Baker , "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2017 19:52:06 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7NE1n28016060 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Aug 2017 10:01:53 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v7NE1n28016060 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1503496914; bh=mIefFO9QoiUlliV6YM0gxNcq6Qs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Wcwk57KLr7iohj2Ei+gpyR5iCjsLODCF+V+KnaFKZx6vHPTzgZ5MKeYWQLThi7tyh WDIgAEoTV35GRQ0aNmA9eumz/elv2AKOcA4FUZyZobrNMd33LaxI88jKagFCCxHvVY /0LtWid5AkbW0rntVav7hZ+mkIOWfb9q4l0m9530= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v7NE1n28016060 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 23 Aug 2017 10:01:01 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7NE1Pm4007659 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 23 Aug 2017 10:01:25 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0352.000; Wed, 23 Aug 2017 10:01:24 -0400 To: "Tim Szigeti (szigeti)" , G Fairhurst , tsvwg WG Thread-Topic: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments Thread-Index: AdL9iKwSAOxDD+ndQlSPMOl+i2FRxAJn8UbwAi2HR9ABt1YHQAE2cG+w Date: Wed, 23 Aug 2017 14:01:24 +0000 Message-ID: References: <9603e1facabb48ec865439a997392120@XCH-RCD-010.cisco.com> <9907583a83dd46ffa05409471a256e5e@XCH-RCD-010.cisco.com> In-Reply-To: <9907583a83dd46ffa05409471a256e5e@XCH-RCD-010.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-ieee-802-11 - David Black's comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 14:02:00 -0000 Tim and authors, This does suffice, as indicated by the change in WG draft state to WG Conse= nsus: Waiting for Write-Up that I just made. The next step is for me to produce a shepherd write-up for this draft, whic= h should happen next week, as I'm traveling this week. Thanks, --David > -----Original Message----- > From: Tim Szigeti (szigeti) [mailto:szigeti@cisco.com] > Sent: Wednesday, August 16, 2017 2:17 PM > To: Black, David ; G Fairhurst > ; tsvwg WG > Cc: Jerome Henry (jerhenry) ; Fred Baker > > Subject: RE: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg-iee= e- > 802-11 - David Black's comments >=20 > Thank you David for catching even these subtle points. >=20 > I've made the changes exactly as you've recommended below and have > uploaded a new draft. >=20 > Please confirm if this allows us to proceed to the next step. >=20 > TIA. >=20 > -tim >=20 > > -----Original Message----- > > From: Black, David [mailto:David.Black@dell.com] > > Sent: Monday, August 07, 2017 6:24 PM > > To: Tim Szigeti (szigeti); G Fairhurst; tsvwg WG > > Cc: Jerome Henry (jerhenry); Fred Baker > > Subject: RE: TSVWG Working Group Last Call (WGLC) on draft-ietf-tsvwg- > > ieee-802-11 - David Black's comments > > > > Hi Tim, > > > > Many thanks for your continued efforts on this draft, and sorry for the > > delayed response. The changes generally look good - there were two ar= eas > > where I wanted to re-check the revised text: > > > > A) On Section 5.3, I wrote: > > > > > > I don't understand what a "trust function" is, so this looks like a > > > > circular statement. Once "trust function" is clarified, change > > > > "RECOMMENDED to trust DSCP" to "RECOMMENDED to pass through > > DSCP" > > > > ... but the details of this clarification are crucial as this text > > > > is a potentially serious security hole > as currently written. > > > > The revised text removes the use of the term "trust function" and is mu= ch > > clearer as a result. > > > > B) > > > > > > Finally, Gorry noted: > > > > > > > > (4) I suspect the security section may benefit from a better def= inition > > > > of the case where the 802.11 network forms the edge of a DS doma= in. I > > > > suspect other people will suggest text on this. > > > > > > > > I suspect that some of the changes suggested in this review towards > > > > less use of the word "trust" will help with this concern, so I sugg= est that > > Gorry and I > > > > both take a look at the resulting text to see whether it suffices. = That > > said, it > > > > would help to add a reference from the security considerations text > > > > on CS6 and CS7 back to section 5.4, which discusses this "edge of a= DS > > domain" case. > > > > > > > > Beyond removal of most uses of the word "trust," the security > > considerations text on CS6 and CS7 was expanded, which obviates the nee= d > > for a backpointer, however .... this text in Section 5.4 is now subtly > > inconsistent with at least the security considerations text: > > > > When business requirements and/or technical constraints and/or > > administrative policies require QoS markings to be passed through at > > the wireless edge, then it is RECOMMENDED to pass through Layer 3 > > DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the > > upstream direction, for the following reasons: > > > > CS6 and CS7 are exceptions to this "RECOMMENDED" requirement for the > > security reasons discussed in section 8, and because they should not be > > generated by hosts for the reasons discussed in section 5.1. I have a= couple > > of suggested changes. > > > > 1) Insert "with the exception of CS6 and CS7" after "in the upstream > > direction" in the above text. > > > > 2) Add a paragraph after the itemized list to explain (mostly by citing= the two > > relevant sections): > > > > CS6 and CS7 are exceptions to this pass through recommendation becau= se > > wireless hosts SHOULD NOT use them (see Section 5.1) and traffic wit= h > > those two markings poses a threat to operation of the wired network = (see > > Section 8.2). CS6 and CS7 SHOULD NOT be passed through to the wired > > network in the upstream direction unless the access point has been > > specifically configured to do that by a network administrator or ope= rator. > > > > Does that sound reasonable? > > > > Thanks, --David > > > > > -----Original Message----- > > > From: Tim Szigeti (szigeti) [mailto:szigeti@cisco.com] > > > Sent: Thursday, July 27, 2017 6:35 PM > > > To: Black, David ; G Fairhurst > > > ; tsvwg WG > > > Cc: Jerome Henry (jerhenry) ; Fred Baker > > > > > > Subject: RE: TSVWG Working Group Last Call (WGLC) on > > > draft-ietf-tsvwg-ieee- > > > 802-11 - David Black's comments > > > > > > Hi David, > > > > > > Thank you again for taking the time to do another round of review. > > > > > > All changes you've suggested below have been made to the latest > > > version of the draft. > > > > > > Thank you again for helping us find the right balance on security vs. > > > functionality. > > > > > > -tim > > > > > > > -----Original Message----- > > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, > > > > David > > > > Sent: Saturday, July 15, 2017 9:40 AM > > > > To: G Fairhurst; tsvwg WG > > > > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on > > > > draft-ietf-tsvwg- > > > > ieee-802-11 - David Black's comments > > > > > > > > In general, the -04 draft is much improved from the -01 draft. All > > > > of my remaining major concerns involve uses of the word "trust" tha= t > > > > > > > > -- Major > > > > > > > > Section 3: > > > > > > > > This document assumes and RECOMMENDS that all wireless access > > points > > > > (as the bridges between wired-and-wireless networks) support the > > > > ability to: > > > > > > > > [... snip ...] > > > > > > > > o trust DSCP markings set by wireless endpoint devices > > > > > > > > This instance of "trust" appears to have been overlooked. I sugge= st > > > > changing "trust" to "process." > > > > > > > > Section 5: > > > > > > > > o DSCP-Trust at the wireless access point (effectively a 1:1 DS= CP- > > > > to-DSCP mapping) > > > > > > > > Aha, the dreaded T-word again. Suggest: DSCP-Trust -> DSCP- > > Passthrough, > > > > as that not only removes the T-word, but is also more descriptive. = This > > also > > > > affects Section 5.3 ... > > > > > > > > Section 5.3: > > > > > > > > Change DSCP-Trust -> DSCP-Passthrough in section title. > > > > > > > > It is generally NOT RECOMMENDED to trust DSCP markings from > > > > unauthenticated and unauthorized devices, as these are typically > > > > considered untrusted sources. > > > > > > > > to trust DSCP markings -> to pass through DSCP markings > > > > > > > > When business requirements and/or technical constraints and/or > > > > administrative policies require a trust function at the wireless > > > > edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-20= 16] > > > > UP markings) markings in the upstream direction, for the followi= ng > > > > reasons: > > > > > > > > I don't understand what a "trust function" is, so this looks like a > > > > circular statement. Once "trust function" is clarified, change > > > > "RECOMMENDED to trust DSCP" to "RECOMMENDED to pass through > > DSCP" > > > > ... but the details of this clarification are crucial as this text > > > > is a potentially serious security hole > > > as > > > > currently written. > > > > > > > > A related minor issue turns up in Section 8.1 - see below. > > > > > > > > Finally, Gorry noted: > > > > > > > > (4) I suspect the security section may benefit from a better def= inition > > > > of the case where the 802.11 network forms the edge of a DS doma= in. I > > > > suspect other people will suggest text on this. > > > > > > > > I suspect that some of the changes suggested in this review towards > > > > less use of the word "trust" will help with this concern, so I sugg= est that > > Gorry and I > > > > both take a look at the resulting text to see whether it suffices. = That > > said, it > > > > would help to add a reference from the security considerations text > > > > on CS6 and CS7 back to section 5.4, which discusses this "edge of a= DS > > domain" > > > case. > > > > > > > > -- Minor > > > > > > > > Section 2.1: > > > > > > > > Thus the QoS treatment of packets at the access point will depen= d on > > > > the position of the AP in the network infrastructure and on the = WLAN > > > > deployment model. > > > > > > > > Needs specific examples and/or forward references to what changes > > > > with AP position. > > > > > > > > Sections 5.2, 5.3 and 5.4: > > > > > > > > These sections are effectively discussing alternatives for access > > > > point > > > Diffserv > > > > functionality. That structure (do one of these three) is not clear= in the > > draft. > > > > > > > > Section 8.1: > > > > > > > > Additionally, Section 5.3 made it clear > > > > that it is generally NOT RECOMMENDED to trust DSCP markings f= rom > > > > unauthorized and/or unauthenticated devices, as these are > > > > typically considered untrusted sources. This is especially > > > > relevant for IoT deployments, where tens-of-billions of devic= es > > > > are being connected to IP networks, many of which have little= or > > > > no security. > > > > > > > > In the first sentence: "trust" -> "pass through" > > > > > > > > In the second sentence as written, "many of which" refers to "IP > > > > networks" - I suspect that was not intended, e.g., "tens-of-billion= s > > > > of devices that may have little or no security are being connected > > > > to IP networks" may be closer to what was intended. > > > > > > > > Setting a trust boundary reflective of business objectives an= d > > > > policy, such that traffic from authorized users and/or > > > > applications and/or endpoints will be accepted by the network= ; > > > > otherwise packet markings will be "bleached" (i.e. remarked t= o > > > > DSCP DF and/or UP 0). > > > > > > > > I have some idea of what a "trust boundary" is, but suspect that > > > > "traffic conditioning policy" may be clearer and closer to what was > > intended. > > > > > > > > Section 8.2: > > > > > > > > Every paragraph in this section is bidirectional in scope, applying > > > > to both > > > > wired->wireless and wireless-> wired traffic, except for this parag= raph: > > > > > > > > If such marking/mapping were not controlled, then, for example, = a > > > > malicious user could cause WLAN DoS by flooding traffic marked C= S7 > > > > DSCP downstream. This codepoint would map by default to UP 7 an= d > > > > would be assigned to the Voice Access Category (AC_VO). Such a = flood > > > > could cause Denial-of-Service to not only wireless voice > > > > applications, but also to all other traffic classes. > > > > > > > > I suggest making this paragraph bidirectional by providing the > > > > example in both directions and then making it clear that the follow= ing > > paragraph: > > > > > > > > Therefore, to mitigate such an attack, it is RECOMMENDED that al= l > > > > packets marked to Diffserv Codepoints not in use over the wirele= ss > > > > network be mapped to UP 0. > > > > > > > > applies to both access points and wireless device operating systems= . > > > > > > > > > > > > -- Editorial > > > > > > > > Section 1.1: > > > > > > > > Note: [RFC4594] is intended to be viewed as a set of "project pl= ans" > > > > for building all the (diffserv) furniture that one might want. = Thus, > > > > it describes different types of traffic expected in IP networks = and > > > > provides guidance as to what DSCP marking(s) should be associate= d > > > > with each traffic type. As such, this document draws heavily on > > > > [RFC4594], [RFC5127], and [RFC8100]. > > > > > > > > The first sentence seems a bit too informal, suggest: > > > > > > > > OLD > > > > Note: [RFC4594] is intended to be viewed as a set of "project pl= ans" > > > > for building all the (diffserv) furniture that one might want. > > > > NEW > > > > Note: [RFC4594] is intended to be viewed as a framework and > > guidelines > > > > for supporting Diffserv in any network, including wireless netwo= rks. > > > > > > > > Section 2.1: > > > > > > > > It is important to recognize that the wired-to-wireless edge may= or > > > > may not equate to the edge of the Diffserv domain. > > > > > > > > equate to the edge of the Diffserv domain -> function as an edge of > > > > a Diffserv domain or a domain boundary. > > > > > > > > Section 8: > > > > > > > > Initial paragraph seems overly defensive, suggest: > > > > > > > > OLD > > > > The recommendations put forward in this document do not present > any > > > > additional security concerns that do not already exist in wired = and > > > > wireless devices. In fact, several of the recommendations made = in > > > > this document serve to mitigate and protect wired and wireless > > > > networks from potential abuse arising from existing vulnerabilit= ies. > > > > NEW > > > > The recommendations in this document concern existing wired and > > > > wireless > > > > network functionality, and for that reason do not add significan= t > security > > > > concerns. Some of the recommendations help protect wired and > > wireless > > > > networks from potential abuse, e.g., as discussed further in thi= s > section. > > > > > > > > Section 8.2: > > > > > > > > It should be strongly noted that in the wireless deployment mode= l > > > > > > > > I suggest deleting "It should be strongly noted that" > > > > > > > > Thanks, --David > > > > > > > > > > > > > -----Original Message----- > > > > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of G > > > > > Fairhurst > > > > > Sent: Thursday, July 6, 2017 3:11 AM > > > > > To: tsvwg WG > > > > > Subject: [tsvwg] TSVWG Working Group Last Call (WGLC) on > > > > > draft-ietf-tsvwg- > > > > > ieee-802-11-01 to conclude 10th Jul 2017 > > > > > > > > > > This email announces a second TSVWG Working Group Last Call > (WGLC) > > > on: > > > > > > > > > > DiffServ to IEEE 802.11 Mapping > > > > > draft-ietf-tsvwg-ieee-802-11-01 > > > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01 > > > > > > > > > > This WGLC will last for about 2 weeks weeks. The purpose of this > > > > > call is to provide further feedback (if required) on changes made > > > > > since the first WGLC concluded. > > > > > > > > > > Comments should be sent to thetsvwg@ietf.org > > > > > list, although purely editorial comments > > > > > may be sent directly to the authors. Please cc: the WG chairs > > > > > attsvwg-chairs@ietf.org if you > > > > > would like the chairs to track such editorial comments as part of > > > > > the WGLC process. > > > > > > > > > > No IPR disclosures have been submitted directly on > > > > > draft-ietf-tsvwg-ieee-802-11-01 > > > > > > > > > > Thanks, > > > > > Gorry > > > > > (TSVWG Co-Chair) From nobody Fri Aug 25 03:54:13 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18B013291F; Fri, 25 Aug 2017 03:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 MQ80H4hBWlpN; Fri, 25 Aug 2017 03:53:57 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7623B132BC2; Fri, 25 Aug 2017 03:53:57 -0700 (PDT) Received: from [192.168.1.204] (p57BB53DA.dip0.t-ipconnect.de [87.187.83.218]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 10711721E281A; Fri, 25 Aug 2017 12:53:53 +0200 (CEST) From: Michael Tuexen Message-Id: <2B0B5E2A-0B15-4B86-9226-3129A101EE24@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_A9D8225C-80BA-41CE-A1C7-811AF7BC68CA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 25 Aug 2017 12:53:52 +0200 In-Reply-To: <150274094205.10409.17989486864216331116@ietfa.amsl.com> Cc: gen-art@ietf.org, tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org To: Stewart Bryant References: <150274094205.10409.17989486864216331116@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 10:54:00 -0000 --Apple-Mail=_A9D8225C-80BA-41CE-A1C7-811AF7BC68CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14. Aug 2017, at 22:02, Stewart Bryant = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready >=20 Hi Stewart, thanks for your review. See my comment in-line. Best regards Michael > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-tsvwg-sctp-ndata-12 > Reviewer: Stewart Bryant > Review Date: 2017-08-14 > IETF LC End Date: 2017-08-25 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This is a well written draft and is ready for publication. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: >=20 > You repeat the text: >=20 > "A message is considered in flight, if at least on of its I-DATA = chunks is not > acknowledged in a non-renegable way" in two consecutive sections, = maybe a > common definition could be used. The first text covers "Message in flight", the second covers "Fragment = in flight". What is duplicated is the text (i.e. acknowledged by the cumulative TSN = Ack) for explaining "acknowledged in a non-renegable way". Giving the explanation = only once improves readability, I guess. Best regards Michael >=20 --Apple-Mail=_A9D8225C-80BA-41CE-A1C7-811AF7BC68CA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjUxMDUzNTNaMCMGCSqGSIb3DQEJBDEWBBSTAd8v90Povog1uT5r /4uPRN7nKDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQCPaDD6Mo/lCEk82iMc4gPjDuGX2WcJFGMt F70w9revy0GejckcrjRgQEbcTMdvvBStNz4qOGAdzmnv0NeLkmKLRomJ4Gj9PWRTaeaXQnkV3Q5x W/ODLFCf6sBusPI5pcW5syQPrCQTPloSF72jyB94cPz4+IfKN2ht3Q6O1E/ErSpRnpPus59QyVxC o6MfxM3RGEX1GqWvnKc7X4zS9DE5pyCsUUvkfrY6XIkdIAyXioUFMp1Gnjpx9QR3UBEnSHPOg7iO sit5hIKLwkU7wNFP1JQYWsyRDDPvGnXqXomjOJ1Wx2xWlNQVshxpzRuQFAcpO4/9c8MZEZetmxOg sbLvAAAAAAAA --Apple-Mail=_A9D8225C-80BA-41CE-A1C7-811AF7BC68CA-- From nobody Fri Aug 25 04:28:46 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174F81321A1; Fri, 25 Aug 2017 04:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er3Dz8qP_1Uf; Fri, 25 Aug 2017 04:28:29 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 743D9132B9F; Fri, 25 Aug 2017 04:28:28 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id a47so6451027wra.4; Fri, 25 Aug 2017 04:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=YHyGruDpP2hv76A84vBLPrM5pzmvi07akeqBeS0aBJA=; b=Fs2dwCoc9DkufOZgYbYUBVQK4G8qxdJTI8ElvsT9dRVnTtEVC/8fpoKss9HIOBs42J xxsMkXcvy0SMEnWrLeK8bg4ysb5BgoiVmtRr0kaKWQXQecO2SLZZNq4UXfXVhxcYbaiK d+XSZxTd6Nm127Gi8bjdeSgfzLX+04vZsiTHHfAnFwk4BNE4PjJedy/AuDOhUZsI2Nd3 3vrSGBmmni4Fk2Rl18k/PUYarxTcaWsT6yRECGAvE05Qv0QvZ8AI3/D1GUxJrlHIefUm QmfA1yvc4Qy3OXoItRSxOQWoMrzFnjon62H6YvXNs8V3N0F+nOs4o4F7i3fJ9YisgR4G u+bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=YHyGruDpP2hv76A84vBLPrM5pzmvi07akeqBeS0aBJA=; b=dnZeXjvgpq/6Mba9jetLBlLWMmbu1LfETN999K2Fox8ZmO70Odwvqw7TOtJIP8YYTi BbBWsCD9IRaEKataHut+wNp8EJGZIXgP7iv0ySLQRbhCuWQJmBNMJ11o11IhYxBBlQ6b wW5qpquw8zpqBLoeJzbeI6a7JZ2eBajVhq0JWM7ZoyWpWeoJWU0xoI7eD/3LIi1xLIM6 AEkKRuraryTTr9aTQrT7JqsBsnQSrNp4YpZjq6PC8ERpj6BEoyXTbDgKicgWGZ5YA3H3 7kx9xfylapMY/8YnGHz+dhI/5sKAJBe1LgC4SKJ6m4syEPRcbpQ59pKS0NLX67Ao2uGx Z7Hw== X-Gm-Message-State: AHYfb5hHrrP0NaEZQjaVctbpj1hs8u92Dj7w7gW8Yq1Jk+l9Rfdo7tMC zFU4c97KLNYFw31PfiU= X-Received: by 10.223.167.138 with SMTP id j10mr5081636wrc.97.1503660506634; Fri, 25 Aug 2017 04:28:26 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id u83sm999934wmu.40.2017.08.25.04.28.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 04:28:26 -0700 (PDT) To: Michael Tuexen Cc: gen-art@ietf.org, tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org References: <150274094205.10409.17989486864216331116@ietfa.amsl.com> <2B0B5E2A-0B15-4B86-9226-3129A101EE24@fh-muenster.de> From: Stewart Bryant Message-ID: <3c58ac17-179c-6e2a-2ba6-589e83cb6dd1@gmail.com> Date: Fri, 25 Aug 2017 12:28:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2B0B5E2A-0B15-4B86-9226-3129A101EE24@fh-muenster.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 11:28:32 -0000 Hi Michael Sorry I misread the text. The text is fine as it is, and I leave it to you to see if there is an improvement with a common definition. I am correcting the review. - Stewart On 25/08/2017 11:53, Michael Tuexen wrote: >> On 14. Aug 2017, at 22:02, Stewart Bryant wrote: >> >> Reviewer: Stewart Bryant >> Review result: Ready >> > Hi Stewart, > > thanks for your review. See my comment in-line. > > Best regards > Michael >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-tsvwg-sctp-ndata-12 >> Reviewer: Stewart Bryant >> Review Date: 2017-08-14 >> IETF LC End Date: 2017-08-25 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: This is a well written draft and is ready for publication. >> >> Major issues: None >> >> Minor issues: None >> >> Nits/editorial comments: >> >> You repeat the text: >> >> "A message is considered in flight, if at least on of its I-DATA chunks is not >> acknowledged in a non-renegable way" in two consecutive sections, maybe a >> common definition could be used. > The first text covers "Message in flight", the second covers "Fragment in flight". > What is duplicated is the text (i.e. acknowledged by the cumulative TSN Ack) for > explaining "acknowledged in a non-renegable way". Giving the explanation only once > improves readability, I guess. > > Best regards > Michael From nobody Fri Aug 25 04:50:39 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3C11243F6; Fri, 25 Aug 2017 04:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 AeTgZ9qyj0E1; Fri, 25 Aug 2017 04:50:36 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F5613292C; Fri, 25 Aug 2017 04:50:36 -0700 (PDT) Received: from [192.168.1.204] (p57BB53DA.dip0.t-ipconnect.de [87.187.83.218]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 1D803721E281A; Fri, 25 Aug 2017 13:50:33 +0200 (CEST) From: Michael Tuexen Message-Id: <0D2E38FA-03E3-4C0F-A1DF-08C4F20F50D4@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_FB0AC65D-AEDB-4EC8-A28F-9817F50F682E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 25 Aug 2017 13:50:31 +0200 In-Reply-To: <3c58ac17-179c-6e2a-2ba6-589e83cb6dd1@gmail.com> Cc: gen-art@ietf.org, tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org To: Stewart Bryant References: <150274094205.10409.17989486864216331116@ietfa.amsl.com> <2B0B5E2A-0B15-4B86-9226-3129A101EE24@fh-muenster.de> <3c58ac17-179c-6e2a-2ba6-589e83cb6dd1@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 11:50:38 -0000 --Apple-Mail=_FB0AC65D-AEDB-4EC8-A28F-9817F50F682E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25. Aug 2017, at 13:28, Stewart Bryant = wrote: >=20 > Hi Michael >=20 > Sorry I misread the text. >=20 > The text is fine as it is, and I leave it to you to see if there is an = improvement with a common definition. I think the change = https://github.com/sctplab/sctp-idata/commit/768dac9acbeff654ecea782bf6823= 92fad4d4709 makes the text more readable. >=20 > I am correcting the review. Thanks for the quick feedback! Best regards Michael >=20 > - Stewart >=20 >=20 > On 25/08/2017 11:53, Michael Tuexen wrote: >>> On 14. Aug 2017, at 22:02, Stewart Bryant = wrote: >>>=20 >>> Reviewer: Stewart Bryant >>> Review result: Ready >>>=20 >> Hi Stewart, >>=20 >> thanks for your review. See my comment in-line. >>=20 >> Best regards >> Michael >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> . >>>=20 >>> Document: draft-ietf-tsvwg-sctp-ndata-12 >>> Reviewer: Stewart Bryant >>> Review Date: 2017-08-14 >>> IETF LC End Date: 2017-08-25 >>> IESG Telechat date: Not scheduled for a telechat >>>=20 >>> Summary: This is a well written draft and is ready for publication. >>>=20 >>> Major issues: None >>>=20 >>> Minor issues: None >>>=20 >>> Nits/editorial comments: >>>=20 >>> You repeat the text: >>>=20 >>> "A message is considered in flight, if at least on of its I-DATA = chunks is not >>> acknowledged in a non-renegable way" in two consecutive sections, = maybe a >>> common definition could be used. >> The first text covers "Message in flight", the second covers = "Fragment in flight". >> What is duplicated is the text (i.e. acknowledged by the cumulative = TSN Ack) for >> explaining "acknowledged in a non-renegable way". Giving the = explanation only once >> improves readability, I guess. >>=20 >> Best regards >> Michael >=20 --Apple-Mail=_FB0AC65D-AEDB-4EC8-A28F-9817F50F682E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjUxMTUwMzJaMCMGCSqGSIb3DQEJBDEWBBTxsbtGH9BB+gS3DQJE bOerEzMphDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQApoJ6L1yt1mr6ekfHM7S/XG/Ju2hJ91g9I l+ONJjO8livJKoLi7IwdMlKfhqQAfpfiqsTEHf/FPj6YIhDPuU4DVg1dubC4SKeRqCycRsYexCu4 T7UQaCRY0WWhQ8VCakSCrPMS50Vlc7utx6cLz1NItO2jdEYKinF6cnYfnM762ow3+L/1rmSen/C5 c7ZApNWCwT/26w0PQEL3c3HnIHBe2uspQybF1Ht47qZEz2ZT79kbYxuC7fQMfKMWtOmwalYwFfSe lC4KBJgDofzgD9CJD3hP6A75M4TJ/kJyWRqAIqUXahZfI3R4g2wmvtJfqDaayXVuTRb7pw7mmGRd fnlDAAAAAAAA --Apple-Mail=_FB0AC65D-AEDB-4EC8-A28F-9817F50F682E-- From nobody Fri Aug 25 07:32:40 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C34132BF1; Fri, 25 Aug 2017 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ZRq1XaSpudv8; Fri, 25 Aug 2017 07:32:37 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69D4132944; Fri, 25 Aug 2017 07:32:36 -0700 (PDT) Received: from [192.168.1.204] (p57BB598B.dip0.t-ipconnect.de [87.187.89.139]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 4C21D721E2822; Fri, 25 Aug 2017 16:32:33 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A9615269-0F8E-4323-B807-63A8FB6EE3D6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 25 Aug 2017 16:32:31 +0200 In-Reply-To: <150287547583.12471.9085655210334710687@ietfa.amsl.com> Cc: ops-dir@ietf.org, tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org To: Stefan Winter References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 14:32:39 -0000 --Apple-Mail=_A9615269-0F8E-4323-B807-63A8FB6EE3D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 16. Aug 2017, at 11:24, Stefan Winter = wrote: >=20 > Reviewer: Stefan Winter > Review result: Has Issues >=20 Hi Stefan, thanks for your review. See my comments in-line. Best regards Michael > One issue: >=20 > The chapter IANA considerations mentions four bits to be registered: = E,B,U,I. > In the main body, only three of those are actually defined and used = (End of > fragmented message, Beginning of fragmented message, Unordered/Ordered > message). Please add a definition of the I bit or remove the IANA = registration > request for that bit. The I bit is defined in RFC 7053 and that is the reason why we state "DATA chunk defined in [RFC4960]and [RFC7053]". In addition to that it = is not mentioned (in contrast to the U, B and E bit), since the delaying of = the SACK is not specific to the I-DATA chunk. I have added the following text to the body of Section 2.2: The handling of the I bit for the I-DATA chunk corresponds to the = handling of the I bit for the DATA chunk described in . to improve the description of the I bit. See = https://github.com/sctplab/sctp-idata/commit/f16308ffe0e67ce5deb957bd40c25= c5a0e691b82 Does that address your issue? >=20 > And the rest are only musings not needing any action if the authors = don't want > to action on them: >=20 > The introduction presents a good use case, quoting: "e.g., when the > transmission of an urgent > message is blocked from transmission because the sender has started > the transmission of another, possibly large, message". >=20 > The later queueing example in figure 1 has three SIDs being queued > simultanseously. It is not clear which of those "has already started" = and which There is actually one message queued for stream 0, three messages for = stream 1, and one message for stream 2. > are the important ones being delayed. For a better understanding of = the reader, The figure is about in which sequence they are put on the wire. So no transmission has startet. This examples also does not deal with the case of one stream having a higher priority than another. That would be an example using a priority scheduler. This examples illustrates the round robin scheduler. The point here is that a single scheduler (the round robin scheduler, = for example) behaves differently when user message interleaving is used or = not. That is an important point: You can even use the schedulers with regular DATA chunk, i.e. with user message interleaving being negotiated. > it might be useful to revise the figure so that the head-of-line = blocking > happens for SID 1 because transmission of 0 and 2 has already started = (and > declare SID 1 to be the "important" message). The ASCII art would just = have to > indent SID 1 content a bit (placing 0 and 2 earlier in time), and the = resulting > serialisation would then put all the SID 1 messages at the very end, = when 0 and > 2 have been completely submitted (right?). One could think about adding another example based on the priority = scheduler and giving stream 1 a higher priority. But for illustrating the point of schedulers behaving differently depending on the negotiation of user = message interleaving this seems not necessary. >=20 > In 2.2.3, is there any particular reason why the "protocol violation" = error > cause is only a MAY? As it enables debugging on the remote end, a = SHOULD seems > useful. This is for consistency with other SCTP specifications. There is always = the balance between providing more information to help diagnosing the problem and = providing more information to an attacker. This allows implementers to do what they = prefer. For interoperability it is not important if the error cause is included = or not. >=20 --Apple-Mail=_A9615269-0F8E-4323-B807-63A8FB6EE3D6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjUxNDMyMzJaMCMGCSqGSIb3DQEJBDEWBBQtxLPq0Yqy8f5dn3vr sFA/0vJNtTCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQAM5IlD09mTsIoNg4tynHJbbnsIHx+lDPsw Lidj+w5usOved0RUkub6qdZifNQXZ9J8ndG5IME9O4oUFy1VZdFP4wc7sIyue+i5GFTxEwGmvrIR DCMqIxmeG2nOI+vVaN57P5xgcSiAcfRgkrv/3ch3Ht36J12HLRdBXZyINoICkFpI+ISYwT6xrN9K C3v/oXwMgSdfbgi3ka07V1/X0ifqiRpeP7xZGgkSEgjZXuq+mRp8HDH9XH8iKb4MK6akSkpPzLhB qKQ9p0iGTQVHticX41gOJGzBicOjhNE+mx9Dfjz4nmzEx9W6eU82/rF4I8se+XfejVGPEQqsBw1M RFpdAAAAAAAA --Apple-Mail=_A9615269-0F8E-4323-B807-63A8FB6EE3D6-- From nobody Sat Aug 26 12:21:04 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F8E132256; Sat, 26 Aug 2017 12:21:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> Date: Sat, 26 Aug 2017 12:21:03 -0700 Archived-At: Subject: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 19:21:03 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-tsvwg-sctp-ndata-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- TECHNICAL I'm not sure I am following the rules about interleaving multiple messages in the same flight. The sender MUST NOT fragment more than one user message in any given stream at any time. At any time, a sender MAY fragment multiple user messages, each of them on different streams. So, say I have one stream and the application sends M1 and M2 and both need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this mean that I can't send M2a until M1{a,b} has been acknowledged? If so what's the need for that requirement? It seems like you could use MID to reassemble correctly. And given this requirement, why do you need MID? Because fragementation is indicated by index, not range, what happens if you have to reduce MTU? So, say I have a message of size 2K which I fragment into 1K/1K and then I have to decrease my MTU to 512 bytes? EDITORIAL I think it would be helpful to indicate that B has to be set for the first chunk in S 2.1. Or perhaps move the overview of how the sender behaves in S 2.2.2 up in the document? From nobody Mon Aug 28 06:45:08 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9D3132936; Mon, 28 Aug 2017 06:44:54 -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 2aNZ_kyOitPD; Mon, 28 Aug 2017 06:44:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03B713292B; Mon, 28 Aug 2017 06:44:46 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-73-59a41e4c21e5 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 81.9F.20899.C4E14A95; Mon, 28 Aug 2017 15:44:44 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 28 Aug 2017 15:44:43 +0200 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=KXxxXt0zw5cZbXqsAtX4WAHDOzXCoOSn2u3FU+OOANk=; b=JdSXr+D4oHVNMkVHOyha3T3raP9CTRewbgSBATlKxoWkylpgjPmfSHCZtGEgVlE336E3gZ8Z4Ue8o1K9DW5Ln9lVWeda/2flZwZCRdsHkTQ4z4aV2fvKAVkWTuyVj0dp93x+nXfhqEMMLoMczkr0Hbf4T3uCI+9XG8BxsCYRmy4= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB110.eurprd07.prod.outlook.com (10.242.138.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Mon, 28 Aug 2017 13:44:43 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::787a:c6a2:f24c:1326]) by DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::787a:c6a2:f24c:1326%16]) with mapi id 15.20.0013.008; Mon, 28 Aug 2017 13:44:43 +0000 From: Ingemar Johansson S To: "rmcat WG (rmcat@ietf.org)" , tsvwg IETF list CC: QUIC IETF mailing list Thread-Topic: SCReAM congestion control with ECN support Thread-Index: AdMgA7+OopcqECc5TgW2pH9Wr69HXQ== Date: Mon, 28 Aug 2017 13:44:42 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DBXPR07MB110; 6:+O3UZqBG7H1LqKDsJCsa9EKkrmrywTAnF+V7LhQL7VOIh/NY+UTYqV4LUybEkkpjjtke/LVKjsnsiK54QgXCI68iDyqh+iBhhbAaLhQ9CGNV5CJwP0hvw8W+YnQ5FoPVZT6G1K90Z3uzApvKrcYBjSByYANdxbV6zeN0yZPcPugp7Jt+soSQiV9QSe25QiQ6HBTYZsol7px1bA3pq3tPkFaIWLIev9Brtu54DhB5bebL7izI4VyxBcC1/GghzhQmMoMuqBPLayVkiWdQ7+ycZ+pTFx5srKN88CZLDxZyzN4oy1gY9EQnHfa7VfDkkaWIlTN9tZerTOwJBrnO0dJFSw==; 5:hbx0hIQT8tRh8f93SWh8yLZDj2x8YxB0XUNUGJ9rfAdYBPniXgZw4BoHCj5xgs3DVfwuqj7CwoYc9t/Ka60liAusammIcuuM9d+uAaG4pOOCNLcz+KI6PXqSrdbkHsNf1Y3VC6wcJVRWO+n88cewiw==; 24:qAD+Rz8DxjSWTNBW/6T/A15XxOs1ujAWmTXuHl+mLwt9k2auqJtx8aBreBM4Im0LUYfDvhcWkzYyO1+r6Y1h9LoGpyLz2LkXZifYEiUKzZ8=; 7:Jp8zt2jkIcvDCklxpT9bcuH07aLB4C8rJK9FazuDXIIMCzSPn6hVAbcKjOr1j8RgHveu0Xp7uczJo5P6quWsNpzi+FdF9GaWZFZdHms+41/iGa/fiKWQliE+eYIgq+axANnXE0kmWtjOlrHisia1fl0qy5USU0/5s0V+6gj0uZsK89O9xD4HTD+J93PfCjByjK2hiaZQvza62asmWWD6PnINM88Qofsi73zOpTtoJR4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f893e510-ac98-4a85-5228-08d4ee1af015 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DBXPR07MB110; x-ms-traffictypediagnostic: DBXPR07MB110: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(202460600054446)(21748063052155)(192278398808882); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DBXPR07MB110; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DBXPR07MB110; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(189002)(199003)(606006)(6506006)(101416001)(99286003)(66066001)(55016002)(236005)(74316002)(54896002)(6306002)(9686003)(7696004)(33656002)(5660300001)(14454004)(8676002)(966005)(450100002)(68736007)(50986999)(81166006)(81156014)(6436002)(5250100002)(189998001)(54356999)(790700001)(6116002)(4326008)(102836003)(3846002)(25786009)(2900100001)(3660700001)(3280700002)(97736004)(86362001)(9326002)(2906002)(19609705001)(478600001)(7736002)(53936002)(106356001)(105586002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB110; H:DBXPR07MB351.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB351EFC36B64990A8FE5A860C29E0DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 13:44:42.9165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB110 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUYRSG++YuXicHrpPLadKoAaHGZiyNEhMzCvKHkWSECqKD3lRya65Z GpIpGk7uKKb9UHHQtCzMpUky9eZStDhJmUpZrkMuaJqISZozn4H/nvO+53AWDkNIqykZExWb wGli1dFyWkyWBjxTKn336gIPT40ed8+u2On+cGiBdu+Z/UZ7Ez463arIDwWJPcO56KhETuPi FSqOzDKmxE+cuDGRVkqnIv0xLbJkgD0Kk39GSRNL2S4Et5citUi8ya8RGHJbCFNAsjkELBnb aOwUiWAqp4fEwSiCupI2ZKqnWU+oFVbMbMNehPaVdEqLGIZgFZBXy5vkXawb/P7USuMUd1ib HbfArILut43mUpJ1gqbCO2ZdwgZBR9uUeTzEOsL3lREzE6w9DE+Ui/AKLOhe9BGYbeHn+Lq5 LbD7QPd3N5Ydob/8LjKNDGyGBWyUtyBsqKC5YG6Lz0H+aj+Bk0ZFkL+wTGHjIDzuyNtqlgLd T2ZJzFHwq8FA4oKPFNQWZ9G4swO8T4vAehUFmfMNCB+Yg5r6DIS3CYPFoRwqHynKti2EOQ4M fSNUmfkA1vCmdILEugoGi4tozM5QXTlDYFbCvXWB3K5XIIs6ZMtzPB8T4eqq4jRRYTwfF6uK 5RKeos3v6Wxa89CjTuMpAbEMkltJJqeqAqWUOpFPihEQMITcRjLsoAuUSsLVScmcJi5Ecy2a 4wW0hyHl9hLvl4YAKRuhTuCucFw8p/nvihhLWSo6EzLQ5xN8aEOqr//iZNjhnD6QXNjTa938 uetDgN43+Ourm71XBZmiwFkz3VzUHv1u+oKQfSk+l7D1ryxRaJWPLKYn7dIrZ4xzpzNrMhKX 57MOuDwYPp+wPGZoPNlaRY15CNcX7Z+nBBp+yNr23zobLnjajRUOull5+bv4NVwOvS8n+Uj1 EQWh4dX/AGGbLa45AwAA Archived-At: Subject: [tsvwg] SCReAM congestion control with ECN support X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 13:44:55 -0000 --_000_DBXPR07MB351EFC36B64990A8FE5A860C29E0DBXPR07MB351eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Just in case that there are still people around who question the benefits w= ith ECN. The SCReAM congestion control code has now been updated to support ECN. You= can find more info + some rudimentary videos from a real test at https://github.com/EricssonResearch/scream#ecn-explicit-congestion-notifica= tion Something QUIC related. Implementing ECN support in Linux is very straightf= orward. Look for instance in https://gist.github.com/jirihnidek/95c369996a8= 1be1b854e for the details. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_DBXPR07MB351EFC36B64990A8FE5A860C29E0DBXPR07MB351eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Just in case that there are still people around who = question the benefits with ECN.

 

The SCReAM congestion control code has now been upda= ted to support ECN. You can find more info + some rudimentary videos fr= om a real test at

https://github.com/EricssonResearch= /scream#ecn-explicit-congestion-notification

 

Something QUIC related. Implementing ECN support in = Linux is very straightforward. Look for instance in https:/= /gist.github.com/jirihnidek/95c369996a81be1b854e for the details.

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DBXPR07MB351EFC36B64990A8FE5A860C29E0DBXPR07MB351eurprd_-- From nobody Mon Aug 28 08:07:17 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF3D132FB5; Mon, 28 Aug 2017 08:07:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150393282505.9896.5564464062210222338.idtracker@ietfa.amsl.com> Date: Mon, 28 Aug 2017 08:07:05 -0700 Archived-At: Subject: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tsvw?= =?utf-8?q?g-sctp-ndata-12=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 15:07:05 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tsvwg-sctp-ndata-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Mostly editorial comments: 1) Why, after all, is SSN renamed to MID? I understand that the MID was extended to 32 bit and that the name might be more appropriate but I still find it confusing given both fields have the same semantics. Maybe it would help to point this out more explicitly in the document. 2) It could be helpful for the reader to also name the I and the U bits in section 2.1; especially the U bit could be referenced when MID is explained. 3) Should there maybe be a recommendation that re-assotiating without interleaving support could be tried if a ABORT message is received. I guess that failure case could occur if the negation was altered in the network and one end thinks it support interleaving but the other not...? 4) Related to my first point: I guess you only need a new I-FORWARD-TSN chunk because you use MID instead of SSN. This seem to me that you just took the opportunity to make this change with this extension but then it should maybe be the spell out as a 'separate' change/improvement in the intro. 5) Really a nit but hard to read otherwise; you really need to use a comma here (sec 1.1): OLD "If I-DATA support has been negotiated for an association I-DATA chunks are used for all user-messages." NEW "If I-DATA support has been negotiated for an association, I-DATA chunks are used for all user-messages.“ From nobody Mon Aug 28 13:42:26 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE239132650; Mon, 28 Aug 2017 13:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 WUQdnGxB6CQd; Mon, 28 Aug 2017 13:42:17 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0769126BF0; Mon, 28 Aug 2017 13:42:16 -0700 (PDT) Received: from [192.168.1.204] (p57BB4218.dip0.t-ipconnect.de [87.187.66.24]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 4528E72106C12; Mon, 28 Aug 2017 22:42:02 +0200 (CEST) From: Michael Tuexen Message-Id: <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_2013AE25-F88C-457A-919B-38CDB787BEFC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 28 Aug 2017 22:42:00 +0200 In-Reply-To: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Eric Rescorla References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 20:42:20 -0000 --Apple-Mail=_2013AE25-F88C-457A-919B-38CDB787BEFC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Hi Eric, thanks for the review. See my responses in-line. Best regards Michael > TECHNICAL > I'm not sure I am following the rules about interleaving multiple > messages in the same flight. > > The sender MUST NOT fragment more than one user message in any given > stream at any time. At any time, a sender MAY fragment multiple user > messages, each of them on different streams. > > So, say I have one stream and the application sends M1 and M2 and both > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this > mean that I can't send M2a until M1{a,b} has been acknowledged? No, that is not what is meant. Assume M1 is sent before M2 and you end up in M1a (first fragment), M1b (second fragment), M2a (first fragment) and M2b (second fragment). You would assign the TSNs in a way that they are increasing for M1a, M1b, M2a, and M2b. So you are not interleaving messages on the same stream. That is the point. So you would not send them as M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming that M2 doesn't need to be fragmented). I agree, the above text is not as clear as possible. So what about stating it as: The sender MUST NOT assign TSNs to more than one user message in any given stream at any time. At any time, a sender MAY assign TSNs to multiple user messages, each of them on different streams. > If so what's the need for that requirement? It seems like you could The reason for this limitation is: * It is enough to make streams independent of each other as for example required for WebRTC * If you would allow interleaving of messages on the same stream you would also need to allow this in the upper layer API of SCTP. We did not want to make this API more complex for the user as it is already specified in RFC 6458. When keeping the API as specified in RFC 6458 but allowing the interleaving of user messages within a stream you are allowing deadlocks. During the work on the extension we considered removing this restriction, but decided it is not worth it. We even considered to allow the interleaving of an ordered and unordered message. However, that you have required to add a new interleaving level in https://tools.ietf.org/html/rfc6458#section-8.1.20 and we decided that it is simpler and cleaner to stick to the interleaving of messages from different streams. I just double checked the document and the is a left over in the security considerations: When doing so, an application has to provide up to two reassembly buffers (one for ordered messages, one for unordered messages) for each incoming stream. this needs to be changed to: When doing so, an application has to provide a reassembly buffer for each incoming stream. > use MID to reassemble correctly. And given this requirement, why do > you need MID? You need some id to know which fragments belong to the same user message. You can't derive that from the TSN. > > > Because fragementation is indicated by index, not range, > what happens if you have to reduce MTU? So, say I have a message of > size 2K which I fragment into 1K/1K and then I have to decrease > my MTU to 512 bytes? SCTP can't adopt, so IP fragmentation will be used. The reason is that once you sent a DATA chunk or an I-DATA chunk you assigned a TSN will is used for reliable transfer. So you have to retransmit it and you can't change the user data contained in it. This has not changed from the base spec. Changing the information from index to range for handling reassembly would not really help, since you still do reliable transfer by using the TSN assigned to the DATA or I-DATA chunk and you need to retransmit it. > > > EDITORIAL > I think it would be helpful to indicate that B has to be > set for the first chunk in S 2.1. Or perhaps move the overview of > how the sender behaves in S 2.2.2 up in the document? Considering this comment and the ones I got from other people it seems like referring to RFC 4960 and RFC 7053 for the fields which haven't changed and only describing the new fields doesn't seem to work well. I'll add text describing the "old fields". > > --Apple-Mail=_2013AE25-F88C-457A-919B-38CDB787BEFC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjgyMDQyMDBaMCMGCSqGSIb3DQEJBDEWBBTvpydmKPVCVeQaK79Q GcSXBNXk4DCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQACt/Jz9MZ+erBtvPoSk0dMHUU0+63HpwJT OugdYwWsoGdVIVSSZ3hOK18a8eK7BlzrXQer2vgA1/OxAG6r0PWzWCCtX9R662lN9BOBa4YnCwNo OxHP/v4rWXFzsH5PSIbjQzxU/+oiBw1MUFOc7V7/WbQHBvM8D0Ws63A9dxA+D+JgYQgWNQ7Hu6uN IqWA0t96A3VfO+MarniAp4rtNNLuWHcMq5aRHXKqN5UFO25RS9N64VYwK+5v8SQd9AQoLwohr49J xv9q/7aaxUO5yX4ER0/wOC1ClV/Iv08+CX6pMzIvt6LBJv9bRS03lgtvN/H4X7kPzNrJ9C53BT8w vNUkAAAAAAAA --Apple-Mail=_2013AE25-F88C-457A-919B-38CDB787BEFC-- From nobody Mon Aug 28 13:56:59 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1A01329A8 for ; Mon, 28 Aug 2017 13:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5Q3prkp7K1x for ; Mon, 28 Aug 2017 13:56:54 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F65132974 for ; Mon, 28 Aug 2017 13:56:53 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id s187so8377496ywf.2 for ; Mon, 28 Aug 2017 13:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r1IP6StRi88C+8fbi4ZWCQLyX5T3fwpjJ5hLS/7uKB4=; b=Vowvfo+eNxmK0i6WiolFwjXXvqNmoG80PAr90OZOYch7HNMvqWDIFayrae0cVZ9NeA hyt227lvPUlBso8nLxmhsfqg3OuNI/poCH4OakCmM08nKCI7JdD2YZZwebp4fRMazRDO bczHivGo2bjhOOlrHXyQ1sTlPWVO9CppsSWJxiLAyNwX0ltGIr0ntiO3+ZTubgZ+q1Au TSKVpGmcIjushYROqT86+oVpF4orGjzCDYdq3/SVGBCjqEvIgWGlfRfBb2ECdMy/PEol Pn+HujwW5ppvi1Havm7/rFuJZXVoPOxk+ySKoprgF1/IW7RlhHaxzmVlv4YvuSzK5wFi eLDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r1IP6StRi88C+8fbi4ZWCQLyX5T3fwpjJ5hLS/7uKB4=; b=IlBUzIMVOEtozqYfsUrKCmfXXK+zeWLmEWwr2ryJvQ3z4yqNY7HbOQTFuf4IIfPI7a yjgg9E6IeX7Ag6GeME5xIKWRZayhFxW2vuFdK3gsAf5BrM5nWTWRI4SAygQDmsRUsGwF JzTtcxoqMJ7a+JNGsqx5tLWoX8AC53NWw/wydldP4/docC9yoLEylsZan4phhtJ/hbre zGwjUApc4x7NzHo0vWWH18CiLTyl5yhlHX/DC5Q+JiZWMYy4dcJEt/yZc6e5nQXg3HtP h38PDKWWa+2HpEoucZQ2YfMcRm8BkiotyM6cRYXxih6b7TQplhsBB1llqxPWoBQWESnM HQxA== X-Gm-Message-State: AHYfb5gceExV6YwXQ+ThzyimNCh5KBE632W6vQcbPmDX0Ve5lLW6P9jD lRg3P8/4aGYjnckDp2BuC800LAvu5ByM X-Received: by 10.129.87.79 with SMTP id l76mr1756497ywb.222.1503953813069; Mon, 28 Aug 2017 13:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Mon, 28 Aug 2017 13:56:12 -0700 (PDT) In-Reply-To: <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> From: Eric Rescorla Date: Mon, 28 Aug 2017 13:56:12 -0700 Message-ID: To: Michael Tuexen Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a1149d326c97a1c0557d68869" Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 20:56:57 -0000 --001a1149d326c97a1c0557d68869 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen wrote: > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > Hi Eric, > > thanks for the review. See my responses in-line. > > Best regards > Michael > > TECHNICAL > > I'm not sure I am following the rules about interleaving multiple > > messages in the same flight. > > > > The sender MUST NOT fragment more than one user message in any given > > stream at any time. At any time, a sender MAY fragment multiple user > > messages, each of them on different streams. > > > > So, say I have one stream and the application sends M1 and M2 and both > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this > > mean that I can't send M2a until M1{a,b} has been acknowledged? > No, that is not what is meant. > > Assume M1 is sent before M2 and you end up in M1a (first fragment), > M1b (second fragment), M2a (first fragment) and M2b (second fragment). > You would assign the TSNs in a way that they are increasing for > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > the same stream. That is the point. So you would not send them as > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming > that M2 doesn't need to be fragmented). > > I agree, the above text is not as clear as possible. So what about stating > it as: > > The sender MUST NOT assign TSNs to more than one user message in any > given > stream at any time. At any time, a sender MAY assign TSNs to multiple > user > messages, each of them on different streams. > Perhaps you might instead say: The user messages within a given stream must have strictly increasing TSNs > use MID to reassemble correctly. And given this requirement, why do > > you need MID? > You need some id to know which fragments belong to the same > user message. You can't derive that from the TSN. > Yeah, I thought you could but after some thought I see you cannot. -Ekr > Because fragementation is indicated by index, not range, > > what happens if you have to reduce MTU? So, say I have a message of > > size 2K which I fragment into 1K/1K and then I have to decrease > > my MTU to 512 bytes? > SCTP can't adopt, so IP fragmentation will be used. > > The reason is that once you sent a DATA chunk or an I-DATA chunk > you assigned a TSN will is used for reliable transfer. So you > have to retransmit it and you can't change the user data contained > in it. This has not changed from the base spec. > > Changing the information from index to range for handling reassembly > would not really help, since you still do reliable transfer by using the > TSN assigned to the DATA or I-DATA chunk and you need to retransmit it. > > > > > > EDITORIAL > > I think it would be helpful to indicate that B has to be > > set for the first chunk in S 2.1. Or perhaps move the overview of > > how the sender behaves in S 2.2.2 up in the document? > Considering this comment and the ones I got from other people > it seems like referring to RFC 4960 and RFC 7053 for the fields > which haven't changed and only describing the new fields doesn't > seem to work well. > > I'll add text describing the "old fields". > > > > > > --001a1149d326c97a1c0557d68869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen <<= a href=3D"mailto:tuexen@fh-muenster.de" target=3D"_blank">tuexen@fh-muenste= r.de> wrote:
> On 26. Aug 2017, at 21:21, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tsvwg-sctp-ndata-12: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/= doc/draft-ietf-tsvwg-sctp-ndata/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
Hi Eric,

thanks for the review. See my responses in-line.

Best regards
Michael
> TECHNICAL
> I'm not sure I am following the rules about interleaving multiple<= br> > messages in the same flight.
>
>=C2=A0 =C2=A0The sender MUST NOT fragment more than one user message in= any given
>=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender MAY fragme= nt multiple user
>=C2=A0 =C2=A0messages, each of them on different streams.
>
> So, say I have one stream and the application sends M1 and M2 and both=
> need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this > mean that I can't send M2a until M1{a,b} has been acknowledged? No, that is not what is meant.

Assume M1 is sent before M2 and you end up in M1a (first fragment),
M1b (second fragment), M2a (first fragment) and M2b (second fragment).
You would assign the TSNs in a way that they are increasing for
M1a, M1b, M2a, and M2b. So you are not interleaving messages on
the same stream. That is the point. So you would not send them as
M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming
that M2 doesn't need to be fragmented).

I agree, the above text is not as clear as possible. So what about stating<= br> it as:

=C2=A0 The sender MUST NOT assign TSNs to more than one user message in any= given
=C2=A0 stream at any time.=C2=A0 At any time, a sender MAY assign TSNs to m= ultiple user
=C2=A0 messages, each of them on different streams.

Perhaps you might instead say:

The user messages within a given stream must have strictl= y increasing TSNs



> use MID to reassemble correctly. And given this requirement, why do > you need MID?
You need some id to know which fragments belong to the same
user message. You can't derive that from the TSN.
=
Yeah, I thought you could but after some thought I see you c= annot.

=C2=A0
-Ekr

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> > Because fragementation is indicated by index, not range,
> what happens if you have to reduce MTU? So, say I have a message of > size 2K which I fragment into 1K/1K and then I have to decrease
> my MTU to 512 bytes?
SCTP can't adopt, so IP fragmentation will be used.

The reason is that once you sent a DATA chunk or an I-DATA chunk
you assigned a TSN will is used for reliable transfer. So you
have to retransmit it and you can't change the user data contained
in it. This has not changed from the base spec.

Changing the information from index to range for handling reassembly
would not really help, since you still do reliable transfer by using the TSN assigned to the DATA or I-DATA chunk and you need to retransmit it.
>
>
> EDITORIAL
> I think it would be helpful to indicate that B has to be
> set for the first chunk in S 2.1. Or perhaps move the overview of
> how the sender behaves in S 2.2.2 up in the document?
Considering this comment and the ones I got from other people
it seems like referring to RFC 4960 and RFC 7053 for the fields
which haven't changed and only describing the new fields doesn't seem to work well.

I'll add text describing the "old fields".
>
>


--001a1149d326c97a1c0557d68869-- From nobody Mon Aug 28 15:40:00 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A244A13213D; Mon, 28 Aug 2017 15:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 UXIg7xqnysUJ; Mon, 28 Aug 2017 15:39:56 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EF51320CF; Mon, 28 Aug 2017 15:39:55 -0700 (PDT) Received: from [192.168.1.204] (p57BB4D21.dip0.t-ipconnect.de [87.187.77.33]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 0BBF372106C12; Tue, 29 Aug 2017 00:39:40 +0200 (CEST) From: Michael Tuexen Message-Id: <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_62AE38DC-0487-4CB1-8DFC-48D252F45CDA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 00:39:40 +0200 In-Reply-To: Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, "tsvwg@ietf.org" To: Eric Rescorla References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 22:39:58 -0000 --Apple-Mail=_62AE38DC-0487-4CB1-8DFC-48D252F45CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 28. Aug 2017, at 22:56, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen = wrote: > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > Hi Eric, >=20 > thanks for the review. See my responses in-line. >=20 > Best regards > Michael > > TECHNICAL > > I'm not sure I am following the rules about interleaving multiple > > messages in the same flight. > > > > The sender MUST NOT fragment more than one user message in any = given > > stream at any time. At any time, a sender MAY fragment multiple = user > > messages, each of them on different streams. > > > > So, say I have one stream and the application sends M1 and M2 and = both > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this > > mean that I can't send M2a until M1{a,b} has been acknowledged? > No, that is not what is meant. >=20 > Assume M1 is sent before M2 and you end up in M1a (first fragment), > M1b (second fragment), M2a (first fragment) and M2b (second fragment). > You would assign the TSNs in a way that they are increasing for > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > the same stream. That is the point. So you would not send them as > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming > that M2 doesn't need to be fragmented). >=20 > I agree, the above text is not as clear as possible. So what about = stating > it as: >=20 > The sender MUST NOT assign TSNs to more than one user message in any = given > stream at any time. At any time, a sender MAY assign TSNs to = multiple user > messages, each of them on different streams. >=20 > Perhaps you might instead say: >=20 > The user messages within a given stream must have strictly increasing = TSNs Not sure what you are suggesting, since TSN are assigned to chunks, not user messages. Just considering the simple case of non-fragmented user messages, you can't guarantee that user messages of a particular stream have increasing TSNs, since there can be wrap arounds due to chunks belonging to other streams. The TSN are 32-bit numbers with serial = arithmetic... Best regards Michael >=20 >=20 >=20 > > use MID to reassemble correctly. And given this requirement, why do > > you need MID? > You need some id to know which fragments belong to the same > user message. You can't derive that from the TSN. >=20 > Yeah, I thought you could but after some thought I see you cannot. >=20 > =20 > -Ekr >=20 > > Because fragementation is indicated by index, not range, > > what happens if you have to reduce MTU? So, say I have a message of > > size 2K which I fragment into 1K/1K and then I have to decrease > > my MTU to 512 bytes? > SCTP can't adopt, so IP fragmentation will be used. >=20 > The reason is that once you sent a DATA chunk or an I-DATA chunk > you assigned a TSN will is used for reliable transfer. So you > have to retransmit it and you can't change the user data contained > in it. This has not changed from the base spec. >=20 > Changing the information from index to range for handling reassembly > would not really help, since you still do reliable transfer by using = the > TSN assigned to the DATA or I-DATA chunk and you need to retransmit = it. > > > > > > EDITORIAL > > I think it would be helpful to indicate that B has to be > > set for the first chunk in S 2.1. Or perhaps move the overview of > > how the sender behaves in S 2.2.2 up in the document? > Considering this comment and the ones I got from other people > it seems like referring to RFC 4960 and RFC 7053 for the fields > which haven't changed and only describing the new fields doesn't > seem to work well. >=20 > I'll add text describing the "old fields". > > > > >=20 >=20 --Apple-Mail=_62AE38DC-0487-4CB1-8DFC-48D252F45CDA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjgyMjM5NDFaMCMGCSqGSIb3DQEJBDEWBBR2KJHN5VwQ5848LrQd j8Q3JrmUjDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQAwoDxZPdiGts9TwVb0hBpn10/inXXgTNLC egsL/h3O1to9H0uivc178sAEhp53lrt3Iz/DA6UP9l1HCChzthr8i7NHzGXKpE658XYvqjAhbQBA srM2aD71M6GG4WN9DE+x+oazrR1eSQFJO814qDlQdyQ/upcE1iLx0zitHLAmzuvT28mXk02ZO7qJ n70GDpHZePEmTdEwcgJ0yqnd07Q8vgtoizenQlRcxFy8CKlywWTK3cMaGhpK92MnHSpJqMorea9o pL8Y6lQAL+kpNRgstzN8nj1to2TSS/OsTGID9/d3jp9We3ZIEn2swAgT4Glf1M/DZMUo6OK2lqO6 +7yiAAAAAAAA --Apple-Mail=_62AE38DC-0487-4CB1-8DFC-48D252F45CDA-- From nobody Mon Aug 28 16:04:47 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4445132961 for ; Mon, 28 Aug 2017 16:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upv1uBjkWDdl for ; Mon, 28 Aug 2017 16:04:43 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8983713219F for ; Mon, 28 Aug 2017 16:04:43 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id s187so9543638ywf.2 for ; Mon, 28 Aug 2017 16:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eKn14+AqqOwHBIhcuzMCDyfjwmN7Z5ZCJlrNfKOVlBQ=; b=E2mF/ZjdUl2VMAO21HRE2hMecNYrfwB64IWKxiRlMTUOUDJQ89xxFuUnpLzSqxzmfI LciCEJYl4xyJJ+Z+x1DpdVwkdcJqMW22eL+mE97hs8GwMorIhVqjtq+AkMXGInTjsdnh cPcINSYRUpBsPVu5jh3IB0f/SHXgUmNQwRyEQKpn+itNBmaFOqQk6oGk7VLdfZwwJHqB VOFN410W88Nq5X3GEcA56VbkVM9kgm8TyAvryOD14Sof+K+uiqlNj4k1+J03PeB9WsLD Xls2EJ6xTid6XbVJE1ufcCtbAlmrSZ9dFiJ4i29u1Rm74UloJy3cXmPJfVLDdObiBzKy tAFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eKn14+AqqOwHBIhcuzMCDyfjwmN7Z5ZCJlrNfKOVlBQ=; b=B0uyNbMDKZogBjDKRqOr6dld+oDNfGlvrf5BvGZzOuJcbicRULbTdqxrMjjdsMbF8F rvhvOMS9GEzI/KuyiB86twoYYwzkr/iytlD+Iq8AvoJLFtVtUwjHEQgahChBahI3x0Jy Btw1m1G4kMK8YIhJuSuLH5MQKsralQHkeTSEJzIY8gE44UwW7epJ+BnU6MtHhdfxLtcT 7caY2ZwmM0q4hOFNg69KBPQWWdrvnvVPJFZ5RilIxFI+Ubg3/ns6E9FWgM/tDEm8AHSI q/F2r+SCa2Cl2NM82b0zRSLTMLkZb0+4rIYESuJKd1UOYWqUdTPDwXWycNi8vQhOdP7x I0Qg== X-Gm-Message-State: AHYfb5jrgAgRxyn1A/P7xChnmUeKyQjYMcTnhFnjJs+fkHeQXIGLqem/ h/tnY61EmbnVemld0x3VWioEwgQa6b0k X-Received: by 10.129.87.79 with SMTP id l76mr2027265ywb.222.1503961482803; Mon, 28 Aug 2017 16:04:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Mon, 28 Aug 2017 16:04:02 -0700 (PDT) In-Reply-To: <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> From: Eric Rescorla Date: Mon, 28 Aug 2017 16:04:02 -0700 Message-ID: To: Michael Tuexen Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a1149d326f055e70557d851c6" Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 23:04:46 -0000 --001a1149d326f055e70557d851c6 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen wrote: > > On 28. Aug 2017, at 22:56, Eric Rescorla wrote: > > > > > > > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen > wrote: > > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > > > > > Eric Rescorla has entered the following ballot position for > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > Hi Eric, > > > > thanks for the review. See my responses in-line. > > > > Best regards > > Michael > > > TECHNICAL > > > I'm not sure I am following the rules about interleaving multiple > > > messages in the same flight. > > > > > > The sender MUST NOT fragment more than one user message in any given > > > stream at any time. At any time, a sender MAY fragment multiple user > > > messages, each of them on different streams. > > > > > > So, say I have one stream and the application sends M1 and M2 and both > > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this > > > mean that I can't send M2a until M1{a,b} has been acknowledged? > > No, that is not what is meant. > > > > Assume M1 is sent before M2 and you end up in M1a (first fragment), > > M1b (second fragment), M2a (first fragment) and M2b (second fragment). > > You would assign the TSNs in a way that they are increasing for > > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > > the same stream. That is the point. So you would not send them as > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming > > that M2 doesn't need to be fragmented). > > > > I agree, the above text is not as clear as possible. So what about > stating > > it as: > > > > The sender MUST NOT assign TSNs to more than one user message in any > given > > stream at any time. At any time, a sender MAY assign TSNs to multiple > user > > messages, each of them on different streams. > > > > Perhaps you might instead say: > > > > The user messages within a given stream must have strictly increasing > TSNs > Not sure what you are suggesting, since TSN are assigned to chunks, not > user messages. The problem here is that your text focuses on TSN *assignment* which is not really the relevant property (it's an implementation artifact) rather what appears on the wire is. So, the requirement here seems to be that you allocate TSNs to fragments of user messages in order. Just considering the simple case of non-fragmented user > messages, you can't guarantee that user messages of a particular stream > have increasing TSNs, since there can be wrap arounds due to chunks > belonging to other streams. The TSN are 32-bit numbers with serial > arithmetic... > Hmm... You don't think of these as being infinite precision but taken mod 2^32? -Ekr > Best regards > Michael > > > > > > > > > use MID to reassemble correctly. And given this requirement, why do > > > you need MID? > > You need some id to know which fragments belong to the same > > user message. You can't derive that from the TSN. > > > > Yeah, I thought you could but after some thought I see you cannot. > > > > > > -Ekr > > > > > Because fragementation is indicated by index, not range, > > > what happens if you have to reduce MTU? So, say I have a message of > > > size 2K which I fragment into 1K/1K and then I have to decrease > > > my MTU to 512 bytes? > > SCTP can't adopt, so IP fragmentation will be used. > > > > The reason is that once you sent a DATA chunk or an I-DATA chunk > > you assigned a TSN will is used for reliable transfer. So you > > have to retransmit it and you can't change the user data contained > > in it. This has not changed from the base spec. > > > > Changing the information from index to range for handling reassembly > > would not really help, since you still do reliable transfer by using the > > TSN assigned to the DATA or I-DATA chunk and you need to retransmit it. > > > > > > > > > EDITORIAL > > > I think it would be helpful to indicate that B has to be > > > set for the first chunk in S 2.1. Or perhaps move the overview of > > > how the sender behaves in S 2.2.2 up in the document? > > Considering this comment and the ones I got from other people > > it seems like referring to RFC 4960 and RFC 7053 for the fields > > which haven't changed and only describing the new fields doesn't > > seem to work well. > > > > I'll add text describing the "old fields". > > > > > > > > > > > > --001a1149d326f055e70557d851c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen <<= a href=3D"mailto:tuexen@fh-muenster.de" target=3D"_blank">tuexen@fh-muenste= r.de> wrote:
> On 28. Aug 2017, at 22:56, Eric Rescorla <= ;ekr@rtfm.com> wrote:
>
>
>
> On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > On 26. Aug 2017, at 21:21, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-tsvwg-sctp-ndata-12: No Objection
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/= doc/draft-ietf-tsvwg-sctp-ndata/
> >
> >
> >
> > ------------------------------------------------------------= ----------
> > COMMENT:
> > ------------------------------------------------------------= ----------
> >
> Hi Eric,
>
> thanks for the review. See my responses in-line.
>
> Best regards
> Michael
> > TECHNICAL
> > I'm not sure I am following the rules about interleaving mult= iple
> > messages in the same flight.
> >
> >=C2=A0 =C2=A0The sender MUST NOT fragment more than one user messa= ge in any given
> >=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender MAY f= ragment multiple user
> >=C2=A0 =C2=A0messages, each of them on different streams.
> >
> > So, say I have one stream and the application sends M1 and M2 and= both
> > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does t= his
> > mean that I can't send M2a until M1{a,b} has been acknowledge= d?
> No, that is not what is meant.
>
> Assume M1 is sent before M2 and you end up in M1a (first fragment), > M1b (second fragment), M2a (first fragment) and M2b (second fragment).=
> You would assign the TSNs in a way that they are increasing for
> M1a, M1b, M2a, and M2b. So you are not interleaving messages on
> the same stream. That is the point. So you would not send them as
> M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming > that M2 doesn't need to be fragmented).
>
> I agree, the above text is not as clear as possible. So what about sta= ting
> it as:
>
>=C2=A0 =C2=A0The sender MUST NOT assign TSNs to more than one user mess= age in any given
>=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender MAY assign= TSNs to multiple user
>=C2=A0 =C2=A0messages, each of them on different streams.
>
> Perhaps you might instead say:
>
> The user messages within a given stream must have strictly increasing = TSNs
Not sure what you are suggesting, since TSN are assigned to chu= nks, not
user messages.

The problem here is that =C2= =A0your text focuses on TSN *assignment* which is not
really the = relevant property (it's an implementation artifact) rather what appears=
on the wire is. So, the requirement here seems to be that you al= locate TSNs
to fragments of user messages in order.

Just considering the = simple case of non-fragmented user
messages, you can't guarantee that user messages of a particular stream=
have increasing TSNs, since there can be wrap arounds due to chunks
belonging to other streams. The TSN are 32-bit numbers with serial arithmet= ic...

Hmm... You don't think of the= se as being infinite precision but taken mod 2^32?

-Ekr




Best regards
Michael
>
>
>
> > use MID to reassemble correctly. And given this requirement, why = do
> > you need MID?
> You need some id to know which fragments belong to the same
> user message. You can't derive that from the TSN.
>
> Yeah, I thought you could but after some thought I see you cannot.
>
>
> -Ekr
>
> > Because fragementation is indicated by index, not range,
> > what happens if you have to reduce MTU? So, say I have a message = of
> > size 2K which I fragment into 1K/1K and then I have to decrease > > my MTU to 512 bytes?
> SCTP can't adopt, so IP fragmentation will be used.
>
> The reason is that once you sent a DATA chunk or an I-DATA chunk
> you assigned a TSN will is used for reliable transfer. So you
> have to retransmit it and you can't change the user data contained=
> in it. This has not changed from the base spec.
>
> Changing the information from index to range for handling reassembly > would not really help, since you still do reliable transfer by using t= he
> TSN assigned to the DATA or I-DATA chunk and you need to retransmit it= .
> >
> >
> > EDITORIAL
> > I think it would be helpful to indicate that B has to be
> > set for the first chunk in S 2.1. Or perhaps move the overview of=
> > how the sender behaves in S 2.2.2 up in the document?
> Considering this comment and the ones I got from other people
> it seems like referring to RFC 4960 and RFC 7053 for the fields
> which haven't changed and only describing the new fields doesn'= ;t
> seem to work well.
>
> I'll add text describing the "old fields".
> >
> >
>
>


--001a1149d326f055e70557d851c6-- From nobody Tue Aug 29 00:10:49 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196CB132D19; Tue, 29 Aug 2017 00:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 bcQOsuZqmKmX; Tue, 29 Aug 2017 00:10:39 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34504132D16; Tue, 29 Aug 2017 00:10:37 -0700 (PDT) Received: from [192.168.1.204] (p57BB4D21.dip0.t-ipconnect.de [87.187.77.33]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id E7CDE70F8F89B; Tue, 29 Aug 2017 09:10:23 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4B8FB271-C01F-49CB-B610-C4192F8B06B7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 09:10:22 +0200 In-Reply-To: <150393282505.9896.5564464062210222338.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: =?utf-8?Q?Mirja_K=C3=BChlewind?= References: <150393282505.9896.5564464062210222338.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-tsv?= =?utf-8?q?wg-sctp-ndata-12=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 07:10:42 -0000 --Apple-Mail=_4B8FB271-C01F-49CB-B610-C4192F8B06B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28. Aug 2017, at 17:07, Mirja K=C3=BChlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-tsvwg-sctp-ndata-12: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Mostly editorial comments: Hi Mirja, thanks you your comments. See my replies in-line. Best regards Michael > 1) Why, after all, is SSN renamed to MID? I understand that the MID = was > extended to 32 bit and that the name might be more appropriate but I = still find > it confusing given both fields have the same semantics. Maybe it would = help to > point this out more explicitly in the document. They only have the same semantics for ordered user messages. For = unordered user messages, the SSN is not defined. So it has a different semantics and = using the name "Stream Sequence Number" for unordered user messages does not = make sense. So the name was changed. This is stated in the description of the MID: The MID is the same for all fragments of a user message, it is used to determine which fragments (enumerated by the FSN) belong to the same user message. For ordered user messages, the MID is also used by the SCTP receiver to deliver the user messages in the correct order to the upper layer (similar to the SSN of the DATA chunk defined in [RFC4960]).=20 The change of the size was done to overcome the limitations of only having about 2**15 outstanding user messages per stream when not using = the TSN anymore. >=20 > 2) It could be helpful for the reader to also name the I and the U = bits in > section 2.1; especially the U bit could be referenced when MID is = explained. Since Eric brought up a similar comment, I have added text to 2.1 also = describing the "old" fields explicitly and only by referring to RFC 4960 and RFC = 7053. >=20 > 3) Should there maybe be a recommendation that re-assotiating without > interleaving support could be tried if a ABORT message is received. I = guess > that failure case could occur if the negation was altered in the = network and > one end thinks it support interleaving but the other not...? Hmm. You mean middleboxes changing parameters of INIT- and INIT-ACK = chunks in an inconsistent way... I haven't seen such boxes up to now and we = haven't put in protocol mechanisms in the negotiation of extensions to deal with this. Not sure why we should start doing this with this extension. In the case of WebRTC, SCTP is running on top of DTLS and there should = really be no changes to SCTP packets made by middleboxes. >=20 > 4) Related to my first point: I guess you only need a new = I-FORWARD-TSN chunk > because you use MID instead of SSN. This seem to me that you just took = the > opportunity to make this change with this extension but then it should = maybe be > the spell out as a 'separate' change/improvement in the intro. I'm not sure I understand what you are wanting to say. The FORWARD-TSN = chunk contains the SSN, which is gone from the I-DATA chunk, we had to change = it. >=20 > 5) Really a nit but hard to read otherwise; you really need to use a = comma here > (sec 1.1): OLD "If I-DATA support has been negotiated for an = association > I-DATA chunks are used for all user-messages." > NEW > "If I-DATA support has been negotiated for an association, > I-DATA chunks are used for all user-messages.=E2=80=9C Fixed. >=20 >=20 --Apple-Mail=_4B8FB271-C01F-49CB-B610-C4192F8B06B7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjkwNzEwMjJaMCMGCSqGSIb3DQEJBDEWBBQu6vi5i7MLIwyeQRnk RCvvXrqUnjCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQCpP9384y0QxfzvYp/IP+CSvHpqFDAr4UKd H+IHgFRRl/PjIYIb4xirRiV+RdxzzOb88LveSkrCj5PIOIunN9wTzhG1DOqRylsdldTAfWktlrnq dLARwIx4BodkH+rYhgbuhlq16t+VcAVTLKaKpf7akn2+W4Bt9+Y6DEGKXOknL61Fy9E6QK96aSgy ZXMKW2n7Wqwf6rLfDxBZA/0qGIfllB5wwODJUDh8isyL3SGJXrjlsgKK/YjENzgmcWvXz2L8tX34 6AkxI2O5wKanT472sQ5YqDhja+G1pCW1JuoR5XCL4N6USr0681wcL+uhAkGQFwg5QCZddHA6uDWC veGNAAAAAAAA --Apple-Mail=_4B8FB271-C01F-49CB-B610-C4192F8B06B7-- From nobody Tue Aug 29 00:24:47 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E24132D41; Tue, 29 Aug 2017 00:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 P6wrRz9fltMm; Tue, 29 Aug 2017 00:24:31 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6C1132D18; Tue, 29 Aug 2017 00:24:29 -0700 (PDT) Received: from [192.168.1.204] (p57BB4D21.dip0.t-ipconnect.de [87.187.77.33]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 903FF70F8F88D; Tue, 29 Aug 2017 09:24:15 +0200 (CEST) From: Michael Tuexen Message-Id: <68C4E71D-B044-4DC3-B570-97C0AD0578F6@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_F2CD61B6-CED1-4A09-828F-2EDD4140C7B1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 09:24:13 +0200 In-Reply-To: Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, "tsvwg@ietf.org" To: Eric Rescorla References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 07:24:45 -0000 --Apple-Mail=_F2CD61B6-CED1-4A09-828F-2EDD4140C7B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 29. Aug 2017, at 01:04, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen = wrote: > > On 28. Aug 2017, at 22:56, Eric Rescorla wrote: > > > > > > > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen = wrote: > > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > > > > > Eric Rescorla has entered the following ballot position for > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > > > > > When responding, please keep the subject line intact and reply to = all > > > email addresses included in the To and CC lines. (Feel free to cut = this > > > introductory paragraph, however.) > > > > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > > > > > > > > > = ---------------------------------------------------------------------- > > > COMMENT: > > > = ---------------------------------------------------------------------- > > > > > Hi Eric, > > > > thanks for the review. See my responses in-line. > > > > Best regards > > Michael > > > TECHNICAL > > > I'm not sure I am following the rules about interleaving multiple > > > messages in the same flight. > > > > > > The sender MUST NOT fragment more than one user message in any = given > > > stream at any time. At any time, a sender MAY fragment multiple = user > > > messages, each of them on different streams. > > > > > > So, say I have one stream and the application sends M1 and M2 and = both > > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does = this > > > mean that I can't send M2a until M1{a,b} has been acknowledged? > > No, that is not what is meant. > > > > Assume M1 is sent before M2 and you end up in M1a (first fragment), > > M1b (second fragment), M2a (first fragment) and M2b (second = fragment). > > You would assign the TSNs in a way that they are increasing for > > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > > the same stream. That is the point. So you would not send them as > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming > > that M2 doesn't need to be fragmented). > > > > I agree, the above text is not as clear as possible. So what about = stating > > it as: > > > > The sender MUST NOT assign TSNs to more than one user message in = any given > > stream at any time. At any time, a sender MAY assign TSNs to = multiple user > > messages, each of them on different streams. > > > > Perhaps you might instead say: > > > > The user messages within a given stream must have strictly = increasing TSNs > Not sure what you are suggesting, since TSN are assigned to chunks, = not > user messages. >=20 > The problem here is that your text focuses on TSN *assignment* which = is not > really the relevant property (it's an implementation artifact) rather = what appears > on the wire is. So, the requirement here seems to be that you allocate = TSNs > to fragments of user messages in order. The next sentence in the document states: The sender MUST assign TSNs in a way that the receiver can make = progress. One way to achieve this is to assign a higher TSN to the later fragments = of a user message and send out the TSNs in sequence. The reason not to mandate this is that you might you more complex = schemes in case of load-sharing between multiple paths. >=20 >=20 > Just considering the simple case of non-fragmented user > messages, you can't guarantee that user messages of a particular = stream > have increasing TSNs, since there can be wrap arounds due to chunks > belonging to other streams. The TSN are 32-bit numbers with serial = arithmetic... >=20 > Hmm... You don't think of these as being infinite precision but taken = mod 2^32? In most cases, yes. But I need to take into account that the numbers can = wrap and how this is handled by receivers. That is why the document states = some limitations you the number of outstanding MIDs and FSNs. Best regards Michael >=20 > -Ekr >=20 >=20 >=20 >=20 > Best regards > Michael > > > > > > > > > use MID to reassemble correctly. And given this requirement, why = do > > > you need MID? > > You need some id to know which fragments belong to the same > > user message. You can't derive that from the TSN. > > > > Yeah, I thought you could but after some thought I see you cannot. > > > > > > -Ekr > > > > > Because fragementation is indicated by index, not range, > > > what happens if you have to reduce MTU? So, say I have a message = of > > > size 2K which I fragment into 1K/1K and then I have to decrease > > > my MTU to 512 bytes? > > SCTP can't adopt, so IP fragmentation will be used. > > > > The reason is that once you sent a DATA chunk or an I-DATA chunk > > you assigned a TSN will is used for reliable transfer. So you > > have to retransmit it and you can't change the user data contained > > in it. This has not changed from the base spec. > > > > Changing the information from index to range for handling reassembly > > would not really help, since you still do reliable transfer by using = the > > TSN assigned to the DATA or I-DATA chunk and you need to retransmit = it. > > > > > > > > > EDITORIAL > > > I think it would be helpful to indicate that B has to be > > > set for the first chunk in S 2.1. Or perhaps move the overview of > > > how the sender behaves in S 2.2.2 up in the document? > > Considering this comment and the ones I got from other people > > it seems like referring to RFC 4960 and RFC 7053 for the fields > > which haven't changed and only describing the new fields doesn't > > seem to work well. > > > > I'll add text describing the "old fields". > > > > > > > > > > >=20 >=20 --Apple-Mail=_F2CD61B6-CED1-4A09-828F-2EDD4140C7B1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjkwNzI0MTRaMCMGCSqGSIb3DQEJBDEWBBQ7dgeRFQ2zJugDJkA0 oJDnMEg7EDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQBEom7SUH6A7IlwwWoZIdhyG4vwcAr85FQB BK6GZSjaJ6RA/ZHjPiPV3lTVhYv9aeTVijyCdTdmQSost1QFv7dRS4owrvDga4lgA+g4mAafDeEh SmXO140opxTzkYe/3oeYJEoBxS8Redq4hqxyLdi8iEal9BVOS+o20HQEJgFAxPZddR6pmq4ncmtl cj70VFJj7MhND5Ygogj40BstkY2bhm6wZhexsuxlHKI7hV1utQVdNowragXRK8UOl3eWqGx0a6E/ uvw7go3YequWPiYHPEVKaeAHXyXR5M55/P5zcaIyDqhqOYMTlLYUn2IstWOrjlrK60z5O5TJwlHd 6QXTAAAAAAAA --Apple-Mail=_F2CD61B6-CED1-4A09-828F-2EDD4140C7B1-- From nobody Tue Aug 29 06:09:53 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9E113217D for ; Tue, 29 Aug 2017 06:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHTf0nYgdttj for ; Tue, 29 Aug 2017 06:09:42 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 AF42F1200F3 for ; Tue, 29 Aug 2017 06:09:42 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id s143so16594588ywg.0 for ; Tue, 29 Aug 2017 06:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QbGQenB1ZPijplFP84NibWZQGU7X/ZJrBpj4gZvtvdI=; b=MUNnIuohccyuIM0rilkyFajYRFaEeO80CupGDvp/s6CgYkkFEqUu7dI1o1axjwOAm6 m9AcCOUG/8L53bUVH1hktdQ2EYk3L2cl9Yg3lEGYkwraGpgZXN9rfFUIkkRU2blxddmP Gw+9dvbe5xpTSX7jAx1/WCSDQPAKNFej6JT6BdWKw1XyLj9oGM6eezLJXjqZZBvJIxOD 6Fo5f3Q594x0qfr/P4yMtONLJcVWJyt/0RO+r/L/gSUzqO7zY+AEWIZuDPSNWqGkRLZW 2XWIAeG03OeQ5hav5P3/7hc+WFP8eD1q5RW5DpJbZeAOjVUWcgdOv1d9njQ3DxhyEV2k pDFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QbGQenB1ZPijplFP84NibWZQGU7X/ZJrBpj4gZvtvdI=; b=opyE4hGYFDpQPSNadDFjydpO+TCGft3+rFY6LJf4SttDLDq5aS0Zy9VXuT2sfq1FC4 CUT43A+eRs+hkHYJKdw0q/7p/FG4v7y90G7lRUNiWdv1p98EtnFuzcL3hot9jAzSsnA6 HEBF8aTWkmIMT+XrinyZGbAPxuqx0xqlCPNycDc2ssRc108sHA7mVW7XtTRKfI8Q9TYE q9hWb4adSTNJ9JeDu4ONLnVjDF5YMi40stnMKAz98BGB/s9n0oTCrYGiGEa4+YxqsfbO TkhTintp9ODABuMNPhZcb82IaQOaUL9Qi9QIFWKgc3M8NJTJl0fNI/pyEcek8b0t/o5y eLvA== X-Gm-Message-State: AHYfb5irGjUjtjNG3KUMdy1Vob+Xuf9z/5tavCapjTUh787+TsHtfRZE L9RJaRQ1iap1pw4dMROz9tzgvEKWZlGx X-Received: by 10.129.75.139 with SMTP id y133mr260980ywa.270.1504012181897; Tue, 29 Aug 2017 06:09:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Tue, 29 Aug 2017 06:09:01 -0700 (PDT) In-Reply-To: <68C4E71D-B044-4DC3-B570-97C0AD0578F6@fh-muenster.de> References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> <68C4E71D-B044-4DC3-B570-97C0AD0578F6@fh-muenster.de> From: Eric Rescorla Date: Tue, 29 Aug 2017 06:09:01 -0700 Message-ID: To: Michael Tuexen Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a113f1efcd71c3d0557e41fca" Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 13:09:46 -0000 --001a113f1efcd71c3d0557e41fca Content-Type: text/plain; charset="UTF-8" On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen wrote: > > On 29. Aug 2017, at 01:04, Eric Rescorla wrote: > > > > > > > > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen > wrote: > > > On 28. Aug 2017, at 22:56, Eric Rescorla wrote: > > > > > > > > > > > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen > wrote: > > > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > > > > > > > Eric Rescorla has entered the following ballot position for > > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > email addresses included in the To and CC lines. (Feel free to cut > this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to https://www.ietf.org/iesg/ > statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > > > > > > > > > > > > > ------------------------------------------------------------ > ---------- > > > > COMMENT: > > > > ------------------------------------------------------------ > ---------- > > > > > > > Hi Eric, > > > > > > thanks for the review. See my responses in-line. > > > > > > Best regards > > > Michael > > > > TECHNICAL > > > > I'm not sure I am following the rules about interleaving multiple > > > > messages in the same flight. > > > > > > > > The sender MUST NOT fragment more than one user message in any > given > > > > stream at any time. At any time, a sender MAY fragment multiple > user > > > > messages, each of them on different streams. > > > > > > > > So, say I have one stream and the application sends M1 and M2 and > both > > > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does this > > > > mean that I can't send M2a until M1{a,b} has been acknowledged? > > > No, that is not what is meant. > > > > > > Assume M1 is sent before M2 and you end up in M1a (first fragment), > > > M1b (second fragment), M2a (first fragment) and M2b (second fragment). > > > You would assign the TSNs in a way that they are increasing for > > > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > > > the same stream. That is the point. So you would not send them as > > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming > > > that M2 doesn't need to be fragmented). > > > > > > I agree, the above text is not as clear as possible. So what about > stating > > > it as: > > > > > > The sender MUST NOT assign TSNs to more than one user message in any > given > > > stream at any time. At any time, a sender MAY assign TSNs to > multiple user > > > messages, each of them on different streams. > > > > > > Perhaps you might instead say: > > > > > > The user messages within a given stream must have strictly increasing > TSNs > > Not sure what you are suggesting, since TSN are assigned to chunks, not > > user messages. > > > > The problem here is that your text focuses on TSN *assignment* which is > not > > really the relevant property (it's an implementation artifact) rather > what appears > > on the wire is. So, the requirement here seems to be that you allocate > TSNs > > to fragments of user messages in order. > The next sentence in the document states: > > The sender MUST assign TSNs in a way that the receiver can make progress. > One way to achieve this is to assign a higher TSN to the later fragments of > a user message and send out the TSNs in sequence. > > The reason not to mandate this is that you might you more complex schemes > in case of load-sharing between multiple paths. > That's fine, but I don't find the current text clear and this doesn't help. Why don't you try listing the requirements on what appears on the wire from the receiver's perspective in response to this message, and then we can discuss how to write it in the doc. -Ekr > > > > > Just considering the simple case of non-fragmented user > > messages, you can't guarantee that user messages of a particular stream > > have increasing TSNs, since there can be wrap arounds due to chunks > > belonging to other streams. The TSN are 32-bit numbers with serial > arithmetic... > > > > Hmm... You don't think of these as being infinite precision but taken > mod 2^32? > In most cases, yes. But I need to take into account that the numbers can > wrap > and how this is handled by receivers. That is why the document states some > limitations you the number of outstanding MIDs and FSNs. > > Best regards > Michael > > > > -Ekr > > > > > > > > > > Best regards > > Michael > > > > > > > > > > > > > use MID to reassemble correctly. And given this requirement, why do > > > > you need MID? > > > You need some id to know which fragments belong to the same > > > user message. You can't derive that from the TSN. > > > > > > Yeah, I thought you could but after some thought I see you cannot. > > > > > > > > > -Ekr > > > > > > > Because fragementation is indicated by index, not range, > > > > what happens if you have to reduce MTU? So, say I have a message of > > > > size 2K which I fragment into 1K/1K and then I have to decrease > > > > my MTU to 512 bytes? > > > SCTP can't adopt, so IP fragmentation will be used. > > > > > > The reason is that once you sent a DATA chunk or an I-DATA chunk > > > you assigned a TSN will is used for reliable transfer. So you > > > have to retransmit it and you can't change the user data contained > > > in it. This has not changed from the base spec. > > > > > > Changing the information from index to range for handling reassembly > > > would not really help, since you still do reliable transfer by using > the > > > TSN assigned to the DATA or I-DATA chunk and you need to retransmit it. > > > > > > > > > > > > EDITORIAL > > > > I think it would be helpful to indicate that B has to be > > > > set for the first chunk in S 2.1. Or perhaps move the overview of > > > > how the sender behaves in S 2.2.2 up in the document? > > > Considering this comment and the ones I got from other people > > > it seems like referring to RFC 4960 and RFC 7053 for the fields > > > which haven't changed and only describing the new fields doesn't > > > seem to work well. > > > > > > I'll add text describing the "old fields". > > > > > > > > > > > > > > > > > > > > --001a113f1efcd71c3d0557e41fca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen <= tuexen@fh-muenst= er.de> wrote:
> On 29. Aug 2017, at 01:04, Eric Rescorla &l= t;ekr@rtfm.com> wrote:
>
>
>
> On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > On 28. Aug 2017, at 22:56, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > > On 26. Aug 2017, at 21:21, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > Eric Rescorla has entered the following ballot position for<= br> > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection
> > >
> > > When responding, please keep the subject line intact and rep= ly to all
> > > email addresses included in the To and CC lines. (Feel free = to cut this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to https://www.= ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT position= s.
> > >
> > >
> > > The document, along with other ballot positions, can be foun= d here:
> > > https://datatracker.ietf= .org/doc/draft-ietf-tsvwg-sctp-ndata/
> > >
> > >
> > >
> > > -------------------------------------------------------= ---------------
> > > COMMENT:
> > > -------------------------------------------------------= ---------------
> > >
> > Hi Eric,
> >
> > thanks for the review. See my responses in-line.
> >
> > Best regards
> > Michael
> > > TECHNICAL
> > > I'm not sure I am following the rules about interleaving= multiple
> > > messages in the same flight.
> > >
> > >=C2=A0 =C2=A0The sender MUST NOT fragment more than one user = message in any given
> > >=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender = MAY fragment multiple user
> > >=C2=A0 =C2=A0messages, each of them on different streams.
> > >
> > > So, say I have one stream and the application sends M1 and M= 2 and both
> > > need to be fragmented, so I have M1a, M1b and M2a and M2b. D= oes this
> > > mean that I can't send M2a until M1{a,b} has been acknow= ledged?
> > No, that is not what is meant.
> >
> > Assume M1 is sent before M2 and you end up in M1a (first fragment= ),
> > M1b (second fragment), M2a (first fragment) and M2b (second fragm= ent).
> > You would assign the TSNs in a way that they are increasing for > > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > > the same stream. That is the point. So you would not send them as=
> > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assumi= ng
> > that M2 doesn't need to be fragmented).
> >
> > I agree, the above text is not as clear as possible. So what abou= t stating
> > it as:
> >
> >=C2=A0 =C2=A0The sender MUST NOT assign TSNs to more than one user= message in any given
> >=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender MAY a= ssign TSNs to multiple user
> >=C2=A0 =C2=A0messages, each of them on different streams.
> >
> > Perhaps you might instead say:
> >
> > The user messages within a given stream must have strictly increa= sing TSNs
> Not sure what you are suggesting, since TSN are assigned to chunks, no= t
> user messages.
>
> The problem here is that=C2=A0 your text focuses on TSN *assignment* w= hich is not
> really the relevant property (it's an implementation artifact) rat= her what appears
> on the wire is. So, the requirement here seems to be that you allocate= TSNs
> to fragments of user messages in order.
The next sentence in the document states:

The sender MUST assign TSNs in a way that the receiver can make progress. One way to achieve this is to assign a higher TSN to the later fragments of=
a user message and send out the TSNs in sequence.

The reason not to mandate this is that you might you more complex schemes in case of load-sharing between multiple paths.

That's fine, but I don't find the current text clear and t= his doesn't help. Why don't
you try listing the requireme= nts on what appears on the wire from the receiver's
perspecti= ve in response to this message, and then we can discuss how to
wr= ite it in the doc.

-Ekr

>
>
> Just considering the simple case of non-fragmented user
> messages, you can't guarantee that user messages of a particular s= tream
> have increasing TSNs, since there can be wrap arounds due to chunks > belonging to other streams. The TSN are 32-bit numbers with serial ari= thmetic...
>
> Hmm... You don't think of these as being infinite precision but ta= ken mod 2^32?
In most cases, yes. But I need to take into account that the numbers= can wrap
and how this is handled by receivers. That is why the document states some<= br> limitations you the number of outstanding MIDs and FSNs.

Best regards
Michael
>
> -Ekr
>
>
>
>
> Best regards
> Michael
> >
> >
> >
> > > use MID to reassemble correctly. And given this requirement,= why do
> > > you need MID?
> > You need some id to know which fragments belong to the same
> > user message. You can't derive that from the TSN.
> >
> > Yeah, I thought you could but after some thought I see you cannot= .
> >
> >
> > -Ekr
> >
> > > Because fragementation is indicated by index, not range,
> > > what happens if you have to reduce MTU? So, say I have a mes= sage of
> > > size 2K which I fragment into 1K/1K and then I have to decre= ase
> > > my MTU to 512 bytes?
> > SCTP can't adopt, so IP fragmentation will be used.
> >
> > The reason is that once you sent a DATA chunk or an I-DATA chunk<= br> > > you assigned a TSN will is used for reliable transfer. So you
> > have to retransmit it and you can't change the user data cont= ained
> > in it. This has not changed from the base spec.
> >
> > Changing the information from index to range for handling reassem= bly
> > would not really help, since you still do reliable transfer by us= ing the
> > TSN assigned to the DATA or I-DATA chunk and you need to retransm= it it.
> > >
> > >
> > > EDITORIAL
> > > I think it would be helpful to indicate that B has to be
> > > set for the first chunk in S 2.1. Or perhaps move the overvi= ew of
> > > how the sender behaves in S 2.2.2 up in the document?
> > Considering this comment and the ones I got from other people
> > it seems like referring to RFC 4960 and RFC 7053 for the fields > > which haven't changed and only describing the new fields does= n't
> > seem to work well.
> >
> > I'll add text describing the "old fields".
> > >
> > >
> >
> >
>
>


--001a113f1efcd71c3d0557e41fca-- From nobody Tue Aug 29 07:52:15 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B163132D00; Tue, 29 Aug 2017 07:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5kicQaUS-BCQ; Tue, 29 Aug 2017 07:52:11 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B76132AA5; Tue, 29 Aug 2017 07:52:10 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:855c:fc83:a144:ed84] (p200300CD6BCC5600855CFC83A144ED84.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:855c:fc83:a144:ed84]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id B664C70F8FC0B; Tue, 29 Aug 2017 16:51:57 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9B9B0155-1256-4475-B5BE-18D5D9DA52E1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 16:51:57 +0200 In-Reply-To: Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, "tsvwg@ietf.org" To: Eric Rescorla References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> <68C4E71D-B044-4DC3-B570-97C0AD0578F6@fh-muenster.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 14:52:14 -0000 --Apple-Mail=_9B9B0155-1256-4475-B5BE-18D5D9DA52E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 29. Aug 2017, at 15:09, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen = wrote: > > On 29. Aug 2017, at 01:04, Eric Rescorla wrote: > > > > > > > > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen = wrote: > > > On 28. Aug 2017, at 22:56, Eric Rescorla wrote: > > > > > > > > > > > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen = wrote: > > > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > > > > > > > Eric Rescorla has entered the following ballot position for > > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > > > > > > > When responding, please keep the subject line intact and reply = to all > > > > email addresses included in the To and CC lines. (Feel free to = cut this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > > > > > > > > > > > > > = ---------------------------------------------------------------------- > > > > COMMENT: > > > > = ---------------------------------------------------------------------- > > > > > > > Hi Eric, > > > > > > thanks for the review. See my responses in-line. > > > > > > Best regards > > > Michael > > > > TECHNICAL > > > > I'm not sure I am following the rules about interleaving = multiple > > > > messages in the same flight. > > > > > > > > The sender MUST NOT fragment more than one user message in any = given > > > > stream at any time. At any time, a sender MAY fragment = multiple user > > > > messages, each of them on different streams. > > > > > > > > So, say I have one stream and the application sends M1 and M2 = and both > > > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does = this > > > > mean that I can't send M2a until M1{a,b} has been acknowledged? > > > No, that is not what is meant. > > > > > > Assume M1 is sent before M2 and you end up in M1a (first = fragment), > > > M1b (second fragment), M2a (first fragment) and M2b (second = fragment). > > > You would assign the TSNs in a way that they are increasing for > > > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > > > the same stream. That is the point. So you would not send them as > > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b = (assuming > > > that M2 doesn't need to be fragmented). > > > > > > I agree, the above text is not as clear as possible. So what about = stating > > > it as: > > > > > > The sender MUST NOT assign TSNs to more than one user message in = any given > > > stream at any time. At any time, a sender MAY assign TSNs to = multiple user > > > messages, each of them on different streams. > > > > > > Perhaps you might instead say: > > > > > > The user messages within a given stream must have strictly = increasing TSNs > > Not sure what you are suggesting, since TSN are assigned to chunks, = not > > user messages. > > > > The problem here is that your text focuses on TSN *assignment* = which is not > > really the relevant property (it's an implementation artifact) = rather what appears > > on the wire is. So, the requirement here seems to be that you = allocate TSNs > > to fragments of user messages in order. > The next sentence in the document states: >=20 > The sender MUST assign TSNs in a way that the receiver can make = progress. > One way to achieve this is to assign a higher TSN to the later = fragments of > a user message and send out the TSNs in sequence. >=20 > The reason not to mandate this is that you might you more complex = schemes > in case of load-sharing between multiple paths. >=20 > That's fine, but I don't find the current text clear and this doesn't = help. Why don't > you try listing the requirements on what appears on the wire from the = receiver's > perspective in response to this message, and then we can discuss how = to > write it in the doc. Sure. The point is that there should not occur a deadlock when the = sender and the receiver follow the rules. Receiver constraint: * The receiver can not interleave user messages from the same stream = when delivering data to the user. However, it can do partial delivery. This means the receiver can start delivering the user data, delivering the = bytes in the correct sequence, but not delivering it completely. Sender contraint: * When chunks are lost, they are retransmitted giving smaller TSNs = priority. This is the normal error recovery behaviour, which we don't want to = change. Example of deadlock to avoid: The sender sends on stream 0 the first n fragments of a big user = message, which are all received by the receiver. Since the buffer space needs to = be freed on the receiver side, it start partial delivery of the message and delivers the data corresponding to the first n fragments. Now the sender starts sending the first fragments of another message on stream 0. These will be received by the receiver, will be buffered, but can't be delivered, since this would require interleaving two = messages at the receiver side when passing the user data up to the user. Or, alternatively, the sender starts sending a number of user messages = on stream 0. These also can't be delivered. That is why the function (the stream scheduler) selecting from which = stream queue data is taken to be filled in a chunk and assigning the TSN should only select a stream and not a message on that stream. Once you started = to take data from a message in a stream queue, you have to finishing = processing it before you can move on to another message from that stream queue. Any idea how to write a better text? Best regards Michael =20 >=20 > -Ekr >=20 > > > > > > Just considering the simple case of non-fragmented user > > messages, you can't guarantee that user messages of a particular = stream > > have increasing TSNs, since there can be wrap arounds due to chunks > > belonging to other streams. The TSN are 32-bit numbers with serial = arithmetic... > > > > Hmm... You don't think of these as being infinite precision but = taken mod 2^32? > In most cases, yes. But I need to take into account that the numbers = can wrap > and how this is handled by receivers. That is why the document states = some > limitations you the number of outstanding MIDs and FSNs. >=20 > Best regards > Michael > > > > -Ekr > > > > > > > > > > Best regards > > Michael > > > > > > > > > > > > > use MID to reassemble correctly. And given this requirement, why = do > > > > you need MID? > > > You need some id to know which fragments belong to the same > > > user message. You can't derive that from the TSN. > > > > > > Yeah, I thought you could but after some thought I see you cannot. > > > > > > > > > -Ekr > > > > > > > Because fragementation is indicated by index, not range, > > > > what happens if you have to reduce MTU? So, say I have a message = of > > > > size 2K which I fragment into 1K/1K and then I have to decrease > > > > my MTU to 512 bytes? > > > SCTP can't adopt, so IP fragmentation will be used. > > > > > > The reason is that once you sent a DATA chunk or an I-DATA chunk > > > you assigned a TSN will is used for reliable transfer. So you > > > have to retransmit it and you can't change the user data contained > > > in it. This has not changed from the base spec. > > > > > > Changing the information from index to range for handling = reassembly > > > would not really help, since you still do reliable transfer by = using the > > > TSN assigned to the DATA or I-DATA chunk and you need to = retransmit it. > > > > > > > > > > > > EDITORIAL > > > > I think it would be helpful to indicate that B has to be > > > > set for the first chunk in S 2.1. Or perhaps move the overview = of > > > > how the sender behaves in S 2.2.2 up in the document? > > > Considering this comment and the ones I got from other people > > > it seems like referring to RFC 4960 and RFC 7053 for the fields > > > which haven't changed and only describing the new fields doesn't > > > seem to work well. > > > > > > I'll add text describing the "old fields". > > > > > > > > > > > > > > > > > > >=20 >=20 --Apple-Mail=_9B9B0155-1256-4475-B5BE-18D5D9DA52E1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjkxNDUxNTdaMCMGCSqGSIb3DQEJBDEWBBTt6qSpuKuncVTvAbAA 11t3I2jnbzCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQCiQ5rlAGSuS4XdotJWT+k2xDgjAhIY084t kSt3oVHC2CAgcJMJD6l/DO3tn537aiNbktvwB6u1dc5F8N5lKCY1ccoQePhVuQDAtNX2tHuqOIk4 QJkmm/6PkxrsbRG8TYrTG63K/dTGUxmPPZxFlHOVEGGpNYpXwHqQ5YkM9WJ2q/9mWu9lfuTgyUHh K8YO2p4QBuaSeYWjN4mpbkn4FFexIJhCEfCgdcnOoXgM3SMKhSTDYui36W+KDhcjg2UUZ3X08QBo fgcjz7k1CRdL7MKwQgG85KgnJN9/tOJOnTEU5Hp3/HoRrtBdYKh/NJfPsCwzei7egj/v61v3x8oJ Q64EAAAAAAAA --Apple-Mail=_9B9B0155-1256-4475-B5BE-18D5D9DA52E1-- From nobody Tue Aug 29 15:33:04 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7D71321B9; Tue, 29 Aug 2017 15:33:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150404598289.21566.8138949859492184191.idtracker@ietfa.amsl.com> Date: Tue, 29 Aug 2017 15:33:02 -0700 Archived-At: Subject: [tsvwg] Ben Campbell's Yes on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 22:33:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tsvwg-sctp-ndata-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I wish this had been around back when we were figuring out how to share connections in MSRP. Otherwise, just a couple of editorial comments: - Abstract: "Multiple ways for performing this selection, called stream schedulers, are defined. " I assume you mean that they are defined in this document rather than in previously existing documents, but it seems ambiguous. - 2.1: "The sender uses two counters for each outgoing stream, one for ordered messages, one for unordered messages. All counters are independent and initially 0." s/ all / both ; unless this rule is intended to apply to more counters than the ones mentioned in the previous sentence. From nobody Wed Aug 30 02:03:00 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17ED1326FE; Wed, 30 Aug 2017 02:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 zM8ij6Reo0rL; Wed, 30 Aug 2017 02:02:57 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69991321C4; Wed, 30 Aug 2017 02:02:56 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:855c:fc83:a144:ed84] (p200300CD6BCC5600855CFC83A144ED84.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:855c:fc83:a144:ed84]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 13F3571E3F8C4; Wed, 30 Aug 2017 11:02:52 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C81C5BD9-0098-4162-98B5-F10C0A55900C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 30 Aug 2017 11:02:50 +0200 In-Reply-To: <150404598289.21566.8138949859492184191.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Ben Campbell References: <150404598289.21566.8138949859492184191.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Ben Campbell's Yes on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:03:00 -0000 --Apple-Mail=_C81C5BD9-0098-4162-98B5-F10C0A55900C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30. Aug 2017, at 00:33, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-tsvwg-sctp-ndata-12: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 Hi Ben, thanks for your review. Comments in-line. Best regards Michael > I wish this had been around back when we were figuring out how to = share > connections in MSRP. >=20 > Otherwise, just a couple of editorial comments: >=20 > - Abstract: "Multiple ways for performing > this selection, called stream schedulers, are defined. " > I assume you mean that they are defined in this document rather than = in > previously existing documents, but it seems ambiguous. Changed to Multiple ways for performing this selection, called stream schedulers, = are defined in this document. >=20 > - 2.1: "The sender uses two counters for > each outgoing stream, one for ordered messages, one for unordered > messages. All counters are independent and initially 0." >=20 > s/ all / both ; unless this rule is intended to apply to more = counters than > the ones mentioned in the previous sentence. >=20 >=20 With "all counters" I'm referring to two counters for each outgoing = stream. But there might be more than one outgoing stream. So if there are n outgoing = streams, I'm referring to 2 * n counters. And these 2 * n counters are mentioned = in the previous sentence.= --Apple-Mail=_C81C5BD9-0098-4162-98B5-F10C0A55900C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzAwOTAyNTFaMCMGCSqGSIb3DQEJBDEWBBQUiT3BUFeYVZfqUKUv EctHOTX1mzCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQC5z6z17st1fig1KnPOQNVnctuGiejUoiR+ EkTzrvIZbsLPyvH4jSBUiCej+teQphFwxqr/oSDn2pFE4+D+N3biMgtuGrcb7IuIuJ4/FidvyM+j l+C6xboIxA6rcV6r8DCVTtMUKlXaAZdCI67ZCoU1FPwdC52N1xvxGGa0y0gQV5AOPEk4nnerZ8Ar TZ6Yw/K7zyUqDFPHtcvgT5YnwEys22IZ8IL2F7OmS7qdrvz4a39d+r5d9hJbLVpflEJt46JNnsd0 UOxj0XSHKgUCSvP9M0PWVfaiezbxGmCYH3C3OznMB85/QlpX+pRflqv7Yj9q1yo838Uifw5jfjx1 1d1OAAAAAAAA --Apple-Mail=_C81C5BD9-0098-4162-98B5-F10C0A55900C-- From nobody Wed Aug 30 03:55:34 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57E4132E9E; Wed, 30 Aug 2017 03:55:32 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, WEIRD_PORT=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 noWp-QSbVAuO; Wed, 30 Aug 2017 03:55:29 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 4F770132E97; Wed, 30 Aug 2017 03:55:29 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id B706643AF0; Wed, 30 Aug 2017 12:55:27 +0200 (CEST) To: Michael Tuexen Cc: ops-dir@ietf.org, tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> Date: Wed, 30 Aug 2017 12:55:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UkpaJf7op9RwpXffTxWmLDPqCwTptcxOI" Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 10:55:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UkpaJf7op9RwpXffTxWmLDPqCwTptcxOI Content-Type: multipart/mixed; boundary="kdH3TJxgFep85VqxqtldwGOxUxWSjr95F"; protected-headers="v1" From: Stefan Winter To: Michael Tuexen Cc: ops-dir@ietf.org, tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org Message-ID: <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> Subject: Re: [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> In-Reply-To: --kdH3TJxgFep85VqxqtldwGOxUxWSjr95F Content-Type: multipart/mixed; boundary="------------130DEFEAF385F9D2F7754364" Content-Language: lb-LU This is a multi-part message in MIME format. --------------130DEFEAF385F9D2F7754364 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >> The chapter IANA considerations mentions four bits to be registered: E= ,B,U,I. >> In the main body, only three of those are actually defined and used (E= nd of >> fragmented message, Beginning of fragmented message, Unordered/Ordered= >> message). Please add a definition of the I bit or remove the IANA regi= stration >> request for that bit. > The I bit is defined in RFC 7053 and that is the reason why we state > "DATA chunk defined in [RFC4960]and [RFC7053]". In addition to that it = is > not mentioned (in contrast to the U, B and E bit), since the delaying o= f the > SACK is not specific to the I-DATA chunk. > > I have added the following text to the body of Section 2.2: > > The handling of the I bit for the I-DATA chunk corresponds to the ha= ndling > of the I bit for the DATA chunk described in = =2E > > to improve the description of the I bit. See > https://github.com/sctplab/sctp-idata/commit/f16308ffe0e67ce5deb957bd40= c25c5a0e691b82 > Does that address your issue? Yes, thank you. >> And the rest are only musings not needing any action if the authors do= n't want >> to action on them: >> >> The introduction presents a good use case, quoting: "e.g., when the >> transmission of an urgent >> message is blocked from transmission because the sender has started >> the transmission of another, possibly large, message". >> >> The later queueing example in figure 1 has three SIDs being queued >> simultanseously. It is not clear which of those "has already started" = and which > There is actually one message queued for stream 0, three messages for s= tream 1, > and one message for stream 2. >> are the important ones being delayed. For a better understanding of th= e reader, > The figure is about in which sequence they are put on the wire. So no > transmission has startet. This examples also does not deal with the cas= e > of one stream having a higher priority than another. That would be an > example using a priority scheduler. This examples illustrates the round= > robin scheduler. > The point here is that a single scheduler (the round robin scheduler, f= or > example) behaves differently when user message interleaving is used or = not. > That is an important point: You can even use the schedulers with regula= r > DATA chunk, i.e. with user message interleaving being negotiated. >> it might be useful to revise the figure so that the head-of-line block= ing >> happens for SID 1 because transmission of 0 and 2 has already started= (and >> declare SID 1 to be the "important" message). The ASCII art would just= have to >> indent SID 1 content a bit (placing 0 and 2 earlier in time), and the = resulting >> serialisation would then put all the SID 1 messages at the very end, w= hen 0 and >> 2 have been completely submitted (right?). > One could think about adding another example based on the priority sche= duler > and giving stream 1 a higher priority. But for illustrating the point o= f > schedulers behaving differently depending on the negotiation of user me= ssage > interleaving this seems not necessary. That second example might indeed be useful. It's simply a bit strange that in the introduction you speak about an "urgent" message (something deserving a higher-priority sending) and that another transmission has already started - but then the example has none of those two. In fact I wonder why you speak about urgent things in the introduction at all. Neither the scheduler nor the interleaving are designed to help urgent things to be sent earlier. All they do is make the transmission fairer so that *all* chunks get a more even serialised distribution on the wire. So, rather than saying that the spec helps urgent things to be sent earlier, it should maybe rather state that the spec helps every message getting an equal, and equally distributed, share of the medium. >> In 2.2.3, is there any particular reason why the "protocol violation" = error >> cause is only a MAY? As it enables debugging on the remote end, a SHOU= LD seems >> useful. > This is for consistency with other SCTP specifications. There is always= the balance > between providing more information to help diagnosing the problem and p= roviding more > information to an attacker. This allows implementers to do what they pr= efer. > For interoperability it is not important if the error cause is included= or not. That's fine, thanks. Greetings, Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------130DEFEAF385F9D2F7754364 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------130DEFEAF385F9D2F7754364-- --kdH3TJxgFep85VqxqtldwGOxUxWSjr95F-- --UkpaJf7op9RwpXffTxWmLDPqCwTptcxOI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJZppmfAAoJEMDeajWKOdxmrk8P/1+CRYxZ3QZN8Mm1KDB/e8qx DjTBDoJnVIQSNk8wKUQrt4MabAMNUBG6hBuL+VcDbQ7K19bPDz08rKUDhiDwFHAW L5nSv0EOQfT/r4up1lY3wkzUUJRZLj14YVk/DgZltgHxrz63VLnHy6V0Vm4tCPQ1 1b9aJY67/8PJ9zRYKoTriOq8reeebEeqTCz5tDS8nlIxahstPMMoWCrt7L20OSrn tQdTn97pZIzdiR6ULWUBENdzW+5EKWeNUlc1OcxCMqCyCclctCXU6WTGi+upfthk B9xPyb5vzpMiUqyoTD6CwNSn4+UrtdjL7qZoAJW1zjcczgFlefJo2G/BYT/cgK8A 4SmZMn/gQ2oaVcFlUuqDZf82wGDvqaWvNLLjC7ctaGMc+mRBmOr8cFJoAhCO3EMO nDj3Sx1jacVwh5HTuW0rkXlJEcT5Qf2AMU8dKqOYpiLJ/cP9NieC2y//PfPcXkID MsMCm8vCZ9As+phq/BDBy/K2+brtD/IJN4J9JaO1czH8O/RX1U6PLX8adADJWvDI GL/51//2YciKz6iT5qCgBy/nzuN9ZkNwsY8NHxgYf0eRRa9wmVvIDIOFAbilsgVF IPIndvakwxpflUWJ93SEMEXG1cm3wraIWkxvgx2HP33zQARwCynPOpvB3hWs2yUY qzZpMw0gKoTaBBppvw2A =Jsov -----END PGP SIGNATURE----- --UkpaJf7op9RwpXffTxWmLDPqCwTptcxOI-- From nobody Wed Aug 30 04:45:17 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1230913301D; Wed, 30 Aug 2017 04:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, WEIRD_PORT=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 yhSC_DY9RqIz; Wed, 30 Aug 2017 04:45:07 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D044132E94; Wed, 30 Aug 2017 04:45:07 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:855c:fc83:a144:ed84] (p200300CD6BCC5600855CFC83A144ED84.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:855c:fc83:a144:ed84]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 09004721BBD31; Wed, 30 Aug 2017 13:45:02 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FF631798-8A71-4239-A470-995FA44C095B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 30 Aug 2017 13:45:01 +0200 In-Reply-To: <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> Cc: ops-dir@ietf.org, tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org To: Stefan Winter References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 11:45:10 -0000 --Apple-Mail=_FF631798-8A71-4239-A470-995FA44C095B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 30. Aug 2017, at 12:55, Stefan Winter = wrote: >=20 > Hi, >=20 >>> The chapter IANA considerations mentions four bits to be registered: = E,B,U,I. >>> In the main body, only three of those are actually defined and used = (End of >>> fragmented message, Beginning of fragmented message, = Unordered/Ordered >>> message). Please add a definition of the I bit or remove the IANA = registration >>> request for that bit. >> The I bit is defined in RFC 7053 and that is the reason why we state >> "DATA chunk defined in [RFC4960]and [RFC7053]". In addition to that = it is >> not mentioned (in contrast to the U, B and E bit), since the delaying = of the >> SACK is not specific to the I-DATA chunk. >>=20 >> I have added the following text to the body of Section 2.2: >>=20 >> The handling of the I bit for the I-DATA chunk corresponds to the = handling >> of the I bit for the DATA chunk described in . >>=20 >> to improve the description of the I bit. See >> = https://github.com/sctplab/sctp-idata/commit/f16308ffe0e67ce5deb957bd40c25= c5a0e691b82 >> Does that address your issue? >=20 > Yes, thank you. There has also been added a description of all fields, since this issue = came up multiple times. See = https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?input=3D&url=3Dhttps%3A= %2F%2Fraw.githubusercontent.com%2Fsctplab%2Fsctp-idata%2Fmaster%2Fdraft-ie= tf-tsvwg-sctp-ndata.xml&modeAsFormat=3Dhtml%2Fascii&type=3Dtowindow&Submit= =3DSubmit >=20 >=20 >>> And the rest are only musings not needing any action if the authors = don't want >>> to action on them: >>>=20 >>> The introduction presents a good use case, quoting: "e.g., when the >>> transmission of an urgent >>> message is blocked from transmission because the sender has started >>> the transmission of another, possibly large, message". >>>=20 >>> The later queueing example in figure 1 has three SIDs being queued >>> simultanseously. It is not clear which of those "has already = started" and which >> There is actually one message queued for stream 0, three messages for = stream 1, >> and one message for stream 2. >>> are the important ones being delayed. For a better understanding of = the reader, >> The figure is about in which sequence they are put on the wire. So no >> transmission has startet. This examples also does not deal with the = case >> of one stream having a higher priority than another. That would be an >> example using a priority scheduler. This examples illustrates the = round >> robin scheduler. >> The point here is that a single scheduler (the round robin scheduler, = for >> example) behaves differently when user message interleaving is used = or not. >> That is an important point: You can even use the schedulers with = regular >> DATA chunk, i.e. with user message interleaving being negotiated. >>> it might be useful to revise the figure so that the head-of-line = blocking >>> happens for SID 1 because transmission of 0 and 2 has already = started (and >>> declare SID 1 to be the "important" message). The ASCII art would = just have to >>> indent SID 1 content a bit (placing 0 and 2 earlier in time), and = the resulting >>> serialisation would then put all the SID 1 messages at the very end, = when 0 and >>> 2 have been completely submitted (right?). >> One could think about adding another example based on the priority = scheduler >> and giving stream 1 a higher priority. But for illustrating the point = of >> schedulers behaving differently depending on the negotiation of user = message >> interleaving this seems not necessary. >=20 > That second example might indeed be useful. >=20 > It's simply a bit strange that in the introduction you speak about an > "urgent" message (something deserving a higher-priority sending) and > that another transmission has already started - but then the example = has > none of those two. What about removing the word "urgent" from that sentence. >=20 > In fact I wonder why you speak about urgent things in the introduction > at all. Neither the scheduler nor the interleaving are designed to = help > urgent things to be sent earlier. >=20 > All they do is make the transmission fairer so that *all* chunks get a > more even serialised distribution on the wire. That is not true in general. If you use the priority scheduler, one stream gets preferred treatment. It also makes sure that the time of a message spent in the stream queue is shorter. So these messages get sent earlier. In the case of the round robin scheduler, you are right that this is about getting fairer treatment. If you take the WFQ scheduler, the streams don't get the same treatment, but it depends on the weight given to the stream. >=20 > So, rather than saying that the spec helps urgent things to be sent > earlier, it should maybe rather state that the spec helps every = message > getting an equal, and equally distributed, share of the medium. It is not meant that the spec does this. It was one example, what a particular stream scheduler does. But there are multiple schedulers defined in the document. The RR scheduler example is not intended to illustrate what you can do with all the schedulers, but that using message interleaving or not has an impact on the scheduler. That is meant by stating: This document also defines several stream schedulers for general SCTP = associations. The stream schedulers may behave differently depending on whether user = message interleaving has been negotiated for the association or not. This is followed by illustrating this using the RR scheduler. Best regards Michael >=20 >>> In 2.2.3, is there any particular reason why the "protocol = violation" error >>> cause is only a MAY? As it enables debugging on the remote end, a = SHOULD seems >>> useful. >> This is for consistency with other SCTP specifications. There is = always the balance >> between providing more information to help diagnosing the problem and = providing more >> information to an attacker. This allows implementers to do what they = prefer. >> For interoperability it is not important if the error cause is = included or not. >=20 > That's fine, thanks. >=20 > Greetings, >=20 > Stefan >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de = l'Education Nationale et de la Recherche > 2, avenue de l'Universit=C3=A9 > L-4365 Esch-sur-Alzette >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the = recipient's key is known to me >=20 > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66= >=20 > <0x8A39DC66.asc> --Apple-Mail=_FF631798-8A71-4239-A470-995FA44C095B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzAxMTQ1MDJaMCMGCSqGSIb3DQEJBDEWBBRkMHobf1qZykVt8aCe YzqYlK6B0zCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQDDqGNKrr1j9YYwYMsgmX0nYC+yhSSxEPLm 5YotD9ZztKAFEGOA/GUwhq2ZwFviBJczpdPgbpEHIbSJLTdBKeEnTQOPMzH/B/HmWMS9vpuimXwi HgLZiUItCjb38Bu58Gor1ssogXnoja5sDpPnJHgNrGp6xxvjhnchHpiUh61tP6XgjYVLYWwXn3Ga 63G7ateUCQ0MOKHqCvdQeNblBqNXAgKW8eOqeEpfyUN8sGt+lkNGGaIY+WWpd2+xgVRXKX95lGzI eZDkru8vBoCWdxhrSmOYRPrU2p+4GG4AzRlckDPG48b6AzhSswV+WUaibvvr1mNJ1gUb3aBDisi5 mmsKAAAAAAAA --Apple-Mail=_FF631798-8A71-4239-A470-995FA44C095B-- From nobody Wed Aug 30 06:11:51 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430C0133225; Wed, 30 Aug 2017 06:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 IcZINVD0x-ZZ; Wed, 30 Aug 2017 06:11:46 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707B2133222; Wed, 30 Aug 2017 06:11:46 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:855c:fc83:a144:ed84] (p200300CD6BCC5600855CFC83A144ED84.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:855c:fc83:a144:ed84]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id C282C721E280C; Wed, 30 Aug 2017 15:11:43 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A63B9402-5180-4FDC-BECB-386074004776"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 30 Aug 2017 15:11:42 +0200 In-Reply-To: Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, "tsvwg@ietf.org" To: Eric Rescorla References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> <68C4E71D-B044-4DC3-B570-97C0AD0578F6@fh-muenster.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 13:11:49 -0000 --Apple-Mail=_A63B9402-5180-4FDC-BECB-386074004776 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 29. Aug 2017, at 15:09, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen = wrote: > > On 29. Aug 2017, at 01:04, Eric Rescorla wrote: > > > > > > > > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen = wrote: > > > On 28. Aug 2017, at 22:56, Eric Rescorla wrote: > > > > > > > > > > > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen = wrote: > > > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > > > > > > > Eric Rescorla has entered the following ballot position for > > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > > > > > > > When responding, please keep the subject line intact and reply = to all > > > > email addresses included in the To and CC lines. (Feel free to = cut this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > > > > > > > > > > > > > = ---------------------------------------------------------------------- > > > > COMMENT: > > > > = ---------------------------------------------------------------------- > > > > > > > Hi Eric, > > > > > > thanks for the review. See my responses in-line. > > > > > > Best regards > > > Michael > > > > TECHNICAL > > > > I'm not sure I am following the rules about interleaving = multiple > > > > messages in the same flight. > > > > > > > > The sender MUST NOT fragment more than one user message in any = given > > > > stream at any time. At any time, a sender MAY fragment = multiple user > > > > messages, each of them on different streams. > > > > > > > > So, say I have one stream and the application sends M1 and M2 = and both > > > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does = this > > > > mean that I can't send M2a until M1{a,b} has been acknowledged? > > > No, that is not what is meant. > > > > > > Assume M1 is sent before M2 and you end up in M1a (first = fragment), > > > M1b (second fragment), M2a (first fragment) and M2b (second = fragment). > > > You would assign the TSNs in a way that they are increasing for > > > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > > > the same stream. That is the point. So you would not send them as > > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b = (assuming > > > that M2 doesn't need to be fragmented). > > > > > > I agree, the above text is not as clear as possible. So what about = stating > > > it as: > > > > > > The sender MUST NOT assign TSNs to more than one user message in = any given > > > stream at any time. At any time, a sender MAY assign TSNs to = multiple user > > > messages, each of them on different streams. > > > > > > Perhaps you might instead say: > > > > > > The user messages within a given stream must have strictly = increasing TSNs > > Not sure what you are suggesting, since TSN are assigned to chunks, = not > > user messages. > > > > The problem here is that your text focuses on TSN *assignment* = which is not > > really the relevant property (it's an implementation artifact) = rather what appears > > on the wire is. So, the requirement here seems to be that you = allocate TSNs > > to fragments of user messages in order. > The next sentence in the document states: >=20 > The sender MUST assign TSNs in a way that the receiver can make = progress. > One way to achieve this is to assign a higher TSN to the later = fragments of > a user message and send out the TSNs in sequence. >=20 > The reason not to mandate this is that you might you more complex = schemes > in case of load-sharing between multiple paths. >=20 > That's fine, but I don't find the current text clear and this doesn't = help. Why don't > you try listing the requirements on what appears on the wire from the = receiver's > perspective in response to this message, and then we can discuss how = to > write it in the doc. Let me make another suggestion: OLD TEXT: The sender MUST NOT fragment more than one user message in any given stream at any time. At any time, a sender MAY fragment multiple user messages, each of them on different streams. The sender MUST assign TSNs in a way that the receiver can make progress. One way to achieve this is to assign a higher TSN to the later fragments of a user message and send out the TSNs in sequence. NEW TEXT: The sender MUST NOT process (move user data into I-DATA chunks and = assign a TSN to it) for more than one user message in any given stream at = any time. At any time, a sender MAY process multiple user messages, each of = them on different streams. The sender MUST assign TSNs to I-DATA chunks in a way that the = receiver can make progress. One way to achieve this is to assign a higher TSN = to the later fragments of a user message and send out the I-DATA chunks such = that the TSNs are in sequence. Does that address your issue? Best regards Michael >=20 > -Ekr >=20 > > > > > > Just considering the simple case of non-fragmented user > > messages, you can't guarantee that user messages of a particular = stream > > have increasing TSNs, since there can be wrap arounds due to chunks > > belonging to other streams. The TSN are 32-bit numbers with serial = arithmetic... > > > > Hmm... You don't think of these as being infinite precision but = taken mod 2^32? > In most cases, yes. But I need to take into account that the numbers = can wrap > and how this is handled by receivers. That is why the document states = some > limitations you the number of outstanding MIDs and FSNs. >=20 > Best regards > Michael > > > > -Ekr > > > > > > > > > > Best regards > > Michael > > > > > > > > > > > > > use MID to reassemble correctly. And given this requirement, why = do > > > > you need MID? > > > You need some id to know which fragments belong to the same > > > user message. You can't derive that from the TSN. > > > > > > Yeah, I thought you could but after some thought I see you cannot. > > > > > > > > > -Ekr > > > > > > > Because fragementation is indicated by index, not range, > > > > what happens if you have to reduce MTU? So, say I have a message = of > > > > size 2K which I fragment into 1K/1K and then I have to decrease > > > > my MTU to 512 bytes? > > > SCTP can't adopt, so IP fragmentation will be used. > > > > > > The reason is that once you sent a DATA chunk or an I-DATA chunk > > > you assigned a TSN will is used for reliable transfer. So you > > > have to retransmit it and you can't change the user data contained > > > in it. This has not changed from the base spec. > > > > > > Changing the information from index to range for handling = reassembly > > > would not really help, since you still do reliable transfer by = using the > > > TSN assigned to the DATA or I-DATA chunk and you need to = retransmit it. > > > > > > > > > > > > EDITORIAL > > > > I think it would be helpful to indicate that B has to be > > > > set for the first chunk in S 2.1. Or perhaps move the overview = of > > > > how the sender behaves in S 2.2.2 up in the document? > > > Considering this comment and the ones I got from other people > > > it seems like referring to RFC 4960 and RFC 7053 for the fields > > > which haven't changed and only describing the new fields doesn't > > > seem to work well. > > > > > > I'll add text describing the "old fields". > > > > > > > > > > > > > > > > > > >=20 >=20 --Apple-Mail=_A63B9402-5180-4FDC-BECB-386074004776 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzAxMzExNDNaMCMGCSqGSIb3DQEJBDEWBBSAdizRTBQFiPqyOvxi yWgt0xsvqDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQBNrxUGrtsB+ck/4aT1v5V8GuToUijQigFQ FvtHEyLHu/ZCuhl/I3idlj4kD/D19+i04wpHfo7bjt0wOX6w7Intrdu904ON94IwioDXp+Stzpg8 3XGpoLsU4nV/6WX61JpOsmuU4+sMWk9roCL4hz+BRi1mMtULHvv1Y0PMZrAiq4mAvbXu3NrJA1e+ qi+2CLqCXe/ARm+uYolXguJy4i4GrZlqJF5Sd6LZJncQoX0g7kckEw6VUB/T3P5tqXDfquo5GxGI VO96a3mz3b6IomyiiP3/3DVEGSA9D9UUZnInzWWglDt2HgDdhfyo6Vo+nSRe18m+tOrFm/k3hVRi cBo8AAAAAAAA --Apple-Mail=_A63B9402-5180-4FDC-BECB-386074004776-- From nobody Wed Aug 30 08:13:43 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF1E1329C0; Wed, 30 Aug 2017 08:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO7jQaX2wVoO; Wed, 30 Aug 2017 08:13:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D64F126B71; Wed, 30 Aug 2017 08:13:33 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7UFCtKG020673 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Aug 2017 10:12:57 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 30 Aug 2017 10:12:55 -0500 Cc: Gorry Fairhurst , draft-ietf-tsvwg-sctp-ndata@ietf.org, The IESG , tsvwg@ietf.org, tsvwg-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7D1CD491-0991-4950-95CF-69BDEA3D33F9@nostrum.com> References: <150404598289.21566.8138949859492184191.idtracker@ietfa.amsl.com> To: Michael Tuexen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Ben Campbell's Yes on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:13:35 -0000 > On Aug 30, 2017, at 4:02 AM, Michael Tuexen = wrote: >=20 >> On 30. Aug 2017, at 00:33, Ben Campbell wrote: >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-tsvwg-sctp-ndata-12: Yes >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 > Hi Ben, >=20 > thanks for your review. Comments in-line. >=20 > Best regards > Michael >> I wish this had been around back when we were figuring out how to = share >> connections in MSRP. >>=20 >> Otherwise, just a couple of editorial comments: >>=20 >> - Abstract: "Multiple ways for performing >> this selection, called stream schedulers, are defined. " >> I assume you mean that they are defined in this document rather than = in >> previously existing documents, but it seems ambiguous. > Changed to >=20 > Multiple ways for performing this selection, called stream schedulers, = are > defined in this document. >=20 Works for me. >>=20 >> - 2.1: "The sender uses two counters for >> each outgoing stream, one for ordered messages, one for unordered >> messages. All counters are independent and initially 0." >>=20 >> s/ all / both ; unless this rule is intended to apply to more = counters than >> the ones mentioned in the previous sentence. >>=20 >>=20 > With "all counters" I'm referring to two counters for each outgoing = stream. But > there might be more than one outgoing stream. So if there are n = outgoing streams, > I'm referring to 2 * n counters. And these 2 * n counters are = mentioned in the > previous sentence. I read it in the context of the previous sentence, that is, both = counters in a given stream. But this is not a blocking comment; do what = you think is best. Thanks! Ben. From nobody Wed Aug 30 08:31:06 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251BA13202D for ; Wed, 30 Aug 2017 08:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=FZdAd3Fv; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=SiLyzLnk 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 eaANIeDng6vc for ; Wed, 30 Aug 2017 08:31:00 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 210501243F6 for ; Wed, 30 Aug 2017 08:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1504106637; x=1535642637; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SPdbonHyyfgLOXRnUJgWFPQ13/A1Py2Wk+62TdM29bQ=; b=FZdAd3FvPlX/u8nS+Wws/JBfqPTPApzk2yDbIDWg6UhtfFq7uscmmNHE O2nqOfRVJZrIGX01gRsXhWH1Md+ohwNbSnRX7/orn4b1p/568pemEOFgB yYjPe6iq9jDSCwcS4gB4tuy3WizT8e7mFzvtRwSQW/e0vBNZ3Tpx3nAk+ 0=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 10:23:57 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 21:28:07 +0600 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7UFUu32024542 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Aug 2017 11:30:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v7UFUu32024542 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1504107058; bh=oMbrHv8fqkH/blIJ5RmWshvulKc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=SiLyzLnk7oONnrD7DrTa5W/MxXRTCSRJMvD0ddT4t7rEMz3q/dqWPuy2qUmGBk0sg HYPbj9xN315+oosx9M0zJMyl/OeHq400yzqb3RSY1njhwLf7PTXlYr1a7X/m1IGTHH 0S3sFdxlAPoq0IENaLpPkN5IyoSLwln+asKyfC50= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v7UFUu32024542 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 30 Aug 2017 11:30:24 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7UFUfE2008071 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 30 Aug 2017 11:30:42 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 11:30:41 -0400 To: Spencer Dawkins at IETF CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt Thread-Index: AQHTD6wilfNp2RGXa0qgnZaxsTfJo6KdHsew Date: Wed, 30 Aug 2017 15:30:40 +0000 Message-ID: References: <150188933148.18701.4807220216565950086@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.2.174] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FC2A962MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:31:04 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FC2A962MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BlbmNlciwNCg0KUmVzdXJmYWNpbmcgZnJvbSB0cnlpbmcgdG8gdGFrZSB2YWNhdGlvbiBp biBBdWd1c3Qg4oCTIG1hbnkgdGhhbmtzIGZvciB0aGlzIGRldGFpbGVkIHJldmlldy4gIENvbW1l bnRzIGlubGluZS4NCg0KSSBoYXZlIGEgLTA1IHJlYWR5IHRvIGdvIGlmIHRoZXNlIGNoYW5nZXMg YXJlIG9rIHdpdGggeW91Lg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KRnJvbTogU3BlbmNlciBEYXdr aW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6 IE1vbmRheSwgQXVndXN0IDcsIDIwMTcgMjozNyBQTQ0KVG86IEJsYWNrLCBEYXZpZCA8ZGF2aWQu YmxhY2tAZW1jLmNvbT4NCkNjOiB0c3Z3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0c3Z3Z10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA0LnR4dA0K DQpIaSwgRGF2aWQsDQoNCk9uIEZyaSwgQXVnIDQsIDIwMTcgYXQgNjozMSBQTSwgQmxhY2ssIERh dmlkIDxEYXZpZC5CbGFja0BkZWxsLmNvbTxtYWlsdG86RGF2aWQuQmxhY2tAZGVsbC5jb20+PiB3 cm90ZToNCkFzIGRpc2N1c3NlZCBpbiBQcmFndWUsIHRoaXMgaXMgYSBzbWFsbCB1cGRhdGUgdG8g cmVxdWVzdCB0aGF0IElBTkEgcmVtb3ZlIHRoZSByZWdpc3RyYXRpb24gb2YgdGhlIFRDUCBoZWFk ZXIgZmxhZyB1c2VkIGJ5IFJGQyAzNTQwIChFQ04gTm9uY2UpLiAgIEFueSByZWFzc2lnbm1lbnQg b2YgdGhhdCBmbGFnIHdpbGwgYmUgaGFuZGxlZCBieSB0aGUgVENQTSBXRy4gIFRoaXMgdXBkYXRl IGFsc28gY2hhbmdlcyB0aGUgbmFtZSBvZiBvbmUgb2YgdGhlIGFyZWFzIG9mIEVDTiBleHBlcmlt ZW50YXRpb24gdG8gYmUgZGlmZmVyZW50IGZyb20gdGhlIG5hbWUgb2YgdGhlIGV4cGVyaW1lbnQg cHJvcG9zZWQgaW4gdGhhdCBhcmVhLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KSGksIERhdmlkLA0K DQpJIHJlYWxseSBsaWtlIHRoaXMgZHJhZnQuIFRoYW5rcyB0byB5b3UgYW5kIHlvdXIgQUNLIGxp c3QgZm9yIHlvdXIgZWZmb3J0cyAtIHRoZSByZXN1bHQgaXMgdmVyeSBjbGVhciBhbmQgY29tcGxl dGUuDQoNCkkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgYmVmb3JlIEkgcHVzaCB0aGUgYnV0dG9uIG9u IExhc3QgQ2FsbC4gVGhleSdyZSBtaW5vciBlbm91Z2ggdGhhdCBJIGRvbid0IHRoaW5rIHdlIG5l ZWQgdG8gd2FpdCBmb3IgR29ycnkgdG8gYmUgcHJlc2VudCBmb3IgdGhlIGRpc2N1c3Npb24gKG9m IGNvdXJzZSwgaWYgcGVvcGxlIGRpc2FncmVlLCBqdXN0IGxldCBtZSBrbm93KS4NCg0KSSB0cmll ZCB0byBvZmZlciB0ZXh0IGZvciBtb3N0IG9mIHRoZW0sIGJ1dCB5b3UgbWlnaHQgYWxzbyBhbnN3 ZXIgdGhlbSBieSBzYXlpbmcgdGhhdCBUU1ZXRyBuZWVkcyBhIG11Y2ggc21hcnRlciByZXNwb25z aWJsZSBBRCA7LSkgLi4uDQoNCkluIHRoaXMgdGV4dCwNCg0KICAgQW4gRXhwZXJpbWVudGFsIFJG QyBNVVNUIGJlIHB1Ymxpc2hlZCBmb3IgYW55IHByb3RvY29sDQogICBvciBtZWNoYW5pc20gdGhh dCB0YWtlcyBhZHZhbnRhZ2Ugb2YgYW55IG9mIHRoZXNlIGVuYWJsaW5nIHVwZGF0ZXMuDQoNCkkg dGhpbmsgSSBrbm93IHdoYXQgeW91J3JlIHNheWluZywgYnV0IHRoaXMgZm9ybXVsYXRpb24gY29u ZnVzZXMgbWUgYmVjYXVzZSBpdCdzIHBsYWNpbmcgYSBjb21taXRtZW50IG9uIHdoYXQgYSBmdXR1 cmUgd29ya2luZyBncm91cCBtdXN0IGRvIChsaWtlLCB3aGF0IGlmIHRoZSBkcmFmdCBkZXNjcmli aW5nIHRoZSBleHBlcmltZW50YWwgcHJvdG9jb2wgaXMgaW5jb2hlcmVudCAtIGNhbiB0aGUgd29y a2luZyBncm91cCBKdXN0IFNheSBObywgb3IgY2FuIHRoZSBhdXRob3JzIHNheSAiYnV0IHlvdSBo YXZlIHRvIHJlcXVlc3QgcHVibGljYXRpb24sIGJlY2F1c2UgIkFuIEV4cGVyaW1lbnRhbCBSRkMg TVVTVCBiZSBwdWJsaXNoZWQgLi4uIikuDQpbRGF2aWQ+XSBUaGUgd29ya2luZyBncm91cCBjYW4g SnVzdCBTYXkgTm8sIGFuZCB0aGF0IG91dGNvbWUgd291bGQgYmUgYSDigJxmZWF0dXJl4oCdIOKA kyBpZiB0aGUgZXhwZXJpbWVudGFsIHByb3RvY29sIGlzIHByb2JsZW1hdGljLCB0aGVuIHRoZSBl eHBlcmltZW50IHNob3VsZG7igJl0IGJlIHJ1biBhdCBzY2FsZSBpbiB0aGUgSW50ZXJuZXQsIGFu ZCB0aGUgV0cgd2lsbCBoYXZlIGRvbmUgdGhlIHJpZ2h0IHRoaW5nIGJ5IHNheWluZyBzby4NCg0K SXMgeW91ciBwb2ludCB0aGF0IGFueSBwcm90b2NvbCBvciBtZWNoYW5pc20gdGhhdCB0YWtlcyBh ZHZhbnRhZ2Ugb2YgdGhlc2UgZW5hYmxpbmcgdXBkYXRlcyBjYW4ndCBiZSBTdGFuZGFyZHMtVHJh Y2s/DQpbRGF2aWQ+XSBObyDigJMgYSBTdGFuZGFyZHMtVHJhY2sgcHJvdG9jb2wgUkZDIGNhbiBz aW1wbHkgdXBkYXRlIFJGQyAzMTY4IChhbmQgYW55IG90aGVyIFJGQ3MgdGhhdCBpdCBuZWVkcyB0 bykgZGlyZWN0bHksIGFuZCBkb2VzbuKAmXQgbmVlZCB0aGlzIGRyYWZ04oCZcyBwZXJtaXNzaW9u IHRvIGRvIHNvLCBhcyB0aGUgbmV4dCBzZW50ZW5jZSBzdGF0ZXMg4oCmDQoNCkluIHRoaXMgdGV4 dCwNCg0KICAgVGhlcmUgaXMgbm8gbmVlZCB0byBtYWtlIGNoYW5nZXMgZm9yIHByb3RvY29scyBh bmQgbWVjaGFuaXNtcyB0aGF0DQogICBhcmUgZG9jdW1lbnRlZCBpbiBTdGFuZGFyZHMgVHJhY2sg UkZDcywgYXMgYW55IFN0YW5kYXJkcyBUcmFjayBSRkMNCiAgIGNhbiB1cGRhdGUgUkZDIDMxNjgg d2l0aG91dCBuZWVkaW5nIGEgc3RhbmRhcmRzIHByb2Nlc3MgZXhjZXB0aW9uLg0KDQp3ZSd2ZSBi ZWVuIHRhbGtpbmcgdXNpbmcgdGhpcyB0ZXJtaW5vbG9neSBmb3IgYXQgbGVhc3QgYSB5ZWFyIHRo YXQgSSBjYW4gcmVtZW1iZXIsIGJ1dCBJJ20gbm90IHRvdGFsbHkgc3VyZSB0aGF0IGFuIGF2ZXJh Z2UgSUVTRyB3b3VsZCBldmVuIGFwcHJvdmUgYW4gRXhwZXJpbWVudGFsIGRyYWZ0IHRoYXQgdXBk YXRlZCBhIHN0YW5kYXJkcy10cmFjayBSRkMuIEhvdyBiYWRseSBkbyB5b3UgbmVlZCB0byBzYXkg dGhpcyBhdCBhbGwsIHNpbmNlIHlvdSdyZSBqdXN0IGNvbmZpcm1pbmcgYSB3ZWxsLXVuZGVyc3Rv b2QgZmFjdCB0aGF0IEkgdGhpbmsgd2UgYWxsIGFncmVlIG9uPw0KW0RhdmlkPl0gVGhpcyBoYXMg YmVlbiBicm91Z2h0IHVwIHRvbyBtYW55IHRpbWVzIGluIFdHIGRpc2N1c3Npb24gb2YgdGhpcyBk cmFmdCB0byBsZWF2ZSBvdXQsIElNSE8uDQoNCkluIHRoaXMgdGV4dCwNCg0KICAgQSBzdHVkeSBv ZiB0aGUgRUNOIGJlaGF2aW91ciBvZiB0aGUgQWxleGEgdG9wIDFNIHdlYg0KICAgc2VydmVycyB1 c2luZyAyMDE0IGRhdGEgW1RyYW1tZWxsMTVdDQoNCkknbSB3b25kZXJpbmcgd2hldGhlciBpdCdz IHVzZWZ1bCB0byBzYXkgIkFsZXhhIHRvcCAxTSB3ZWIgc2VydmVycyIgaW4gYW4gUkZDIHRoYXQg d2lsbCBwcm9iYWJseSBsYXN0IGxvbmdlciB0aGFuIEFsZXhhIGxhc3RzIC4uLg0KW0RhdmlkPl0g SSB2aWV3IHRoaXMgYXMgYSDigJxzaG93IHlvdXIgd29ya+KAnSBpdGVtIOKApiB0aGlzIGlzIHRo ZSBkYXRhIHRoYXQgd2FzIHVzZWQgYXQgdGhlIHRpbWUuDQoNCkluIHRoaXMgdGV4dCwNCg0KICAg U2lnbmlmaWNhbnRseSBtb3JlIGFnZ3Jlc3NpdmUgc2VuZGVyIHJlc3BvbnNlcyB0byBFQ04NCiAg IGFyZSByZXF1aXJlZCB0byBtYWtlIGVmZmVjdGl2ZSB1c2Ugb2Ygc3VjaCBzaGFsbG93IHF1ZXVl czsgRGF0YWNlbnRlcg0KICAgICAgIF5eXl5eXl5eDQogICBUQ1AgKERDVENQKSBbSS1ELmlldGYt dGNwbS1kY3RjcF0gcHJvdmlkZXMgYW4gZXhhbXBsZS4NCg0KSSdtIHRhbmdsZWQgdXAgaW4gcGFz c2l2ZSB0ZW5zZSAoIndobyBpcyByZXF1aXJlZCB0byBkbyB3aGF0PyIpLiBJcyBpdCBjb3JyZWN0 IHRvIHNheQ0KDQogICBTaWduaWZpY2FudGx5IG1vcmUgYWdncmVzc2l2ZSBzZW5kZXIgcmVzcG9u c2VzIHRvIEVDTg0KICAgYXJlIG5lZWRlZCBpbiBvcmRlciB0byBtYWtlIGVmZmVjdGl2ZSB1c2Ug b2Ygc3VjaCBzaGFsbG93IHF1ZXVlczsNCiAgIERhdGFjZW50ZXIgVENQIChEQ1RDUCkgW0ktRC5p ZXRmLXRjcG0tZGN0Y3BdIHByb3ZpZGVzIGFuIGV4YW1wbGUuDQoNCj8NCiAgIFtEYXZpZD5dIFll cywgY2hhbmdlIG1hZGUuDQoNCkkgc2VlIHRoYXQgdGhlIGRyYWZ0IHVzZXMgYm90aCB0aGUgdGVy bXMgInNoYWxsb3cgcXVldWVzIiBhbmQgIm5lYXJseSBlbXB0eSBxdWV1ZXMiLiBEbyB0aGVzZSB0 ZXJtcyBtZWFuIHRoZSBzYW1lIHRoaW5nPyBJZiBzbywgcGVyaGFwcyBpdCdzIHdvcnRoIGVpdGhl ciBwaWNraW5nIG9uZSB0ZXJtLCBvciBzYXlpbmcgdGhhdCB0aGV5IG1lYW4gdGhlIHNhbWUgdGhp bmcuIFJpZ2h0IG5vdywgSSdtIHRyeWluZyB0byBpbWFnaW5lIHdoYXQgdGhlIGRpZmZlcmVuY2Ug bWlnaHQgYmUsIHNpbmNlIGJvdGggcGhyYXNlcyBhcmUgdXNlZC4NCltEYXZpZD5dIEdvb2QgcG9p bnQsIGNoYW5nZWQgdG8gY29uc2lzdGVudGx5IHVzZSDigJx2ZXJ5IHNoYWxsb3figJ0gZXZlcnl3 aGVyZS4NCg0KWW91IGZvbGtzIGFyZSB0aGUgZXhwZXJ0cyBvbiB0aGlzIHN0dWZmLCBidXQgSSdt IGxvb2tpbmcgYXQgdGhpcyBxdW90ZWQgdGV4dCBmcm9tIFJGQyAzMTY4DQoNCiBSRkMgMzE2OCBw cm9oaWJpdHMgdXNlIG9mIEVDTiBmb3IgVENQIGNvbnRyb2wgcGFja2V0cyBhbmQNCiAgIHJldHJh bnNtaXR0ZWQgcGFja2V0cyBpbiBhIG51bWJlciBvZiBwbGFjZXM6DQoNCiAgIG8gICJUbyBlbnN1 cmUgdGhlIHJlbGlhYmxlIGRlbGl2ZXJ5IG9mIHRoZSBjb25nZXN0aW9uIGluZGljYXRpb24gb2YN CiAgICAgIHRoZSBDRSBjb2RlcG9pbnQsIGFuIEVDVCBjb2RlcG9pbnQgTVVTVCBOT1QgYmUgc2V0 IGluIGEgcGFja2V0DQogICAgICB1bmxlc3MgdGhlIGxvc3Mgb2YgdGhhdCBwYWNrZXQgaW4gdGhl IG5ldHdvcmsgd291bGQgYmUgZGV0ZWN0ZWQgYnkNCiAgICAgIHRoZSBlbmQgbm9kZXMgYW5kIGlu dGVycHJldGVkIGFzIGFuIGluZGljYXRpb24gb2YgY29uZ2VzdGlvbi4iDQogICAgICAoU2VjdGlv biA1LjIpDQoNCiAgIG8gICJBIGhvc3QgTVVTVCBOT1Qgc2V0IEVDVCBvbiBTWU4gb3IgU1lOLUFD SyBwYWNrZXRzLiINCiAgICAgIChTZWN0aW9uIDYuMS4xKQ0KDQogICBvICAicHVyZSBhY2tub3ds ZWRnZW1lbnQgcGFja2V0cyAoZS5nLiwgcGFja2V0cyB0aGF0IGRvIG5vdCBjb250YWluDQogICAg ICBhbnkgYWNjb21wYW55aW5nIGRhdGEpIE1VU1QgYmUgc2VudCB3aXRoIHRoZSBub3QtRUNUIGNv ZGVwb2ludC4iDQogICAgICAoU2VjdGlvbiA2LjEuNCkNCg0KICAgbyAgIlRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIEVDTi1jYXBhYmxlIFRDUCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBOT1QNCiAgICAg IHNldCBlaXRoZXIgRUNUIGNvZGVwb2ludCAoRUNUKDApIG9yIEVDVCgxKSkgaW4gdGhlIElQIGhl YWRlciBmb3INCiAgICAgIHJldHJhbnNtaXR0ZWQgZGF0YSBwYWNrZXRzLCBhbmQgdGhhdCB0aGUg VENQIGRhdGEgcmVjZWl2ZXIgU0hPVUxEDQogICAgICBpZ25vcmUgdGhlIEVDTiBmaWVsZCBvbiBh cnJpdmluZyBkYXRhIHBhY2tldHMgdGhhdCBhcmUgb3V0c2lkZSBvZg0KICAgICAgdGhlIHJlY2Vp dmVyJ3MgY3VycmVudCB3aW5kb3cuIiAgKFNlY3Rpb24gNi4xLjUpDQoNCiAgIG8gICJ0aGUgVENQ IGRhdGEgc2VuZGVyIE1VU1QgTk9UIHNldCBlaXRoZXIgYW4gRUNUIGNvZGVwb2ludCBvciB0aGUN CiAgICAgIENXUiBiaXQgb24gd2luZG93IHByb2JlIHBhY2tldHMuIiAgKFNlY3Rpb24gNi4xLjYp DQoNCmFuZCBub3RpY2luZyB0aGF0IG9ubHkgdGhlIHRleHQgaW4gNi4xLjUgZXhwbGljaXRseSBt ZW50aW9ucyB0aGUgVENQIGRhdGEgcmVjZWl2ZXIgaWdub3JpbmcgdGhlICJNVVNUIE5PVCBzZXQi IEVDTiBmaWVsZC4gSSB0b29rIGEgcXVpY2sgc3BpbiB0aHJvdWdoIFJGQyAzMTY4IHNlYXJjaGlu ZyBmb3IgImlnbm9yZSIsIGJ1dCBkaWRuJ3Qgc2VlIHNvbWV0aGluZyB0aGF0IGV4cGxpY2l0bHkg Y292ZXJlZCB0aGUgb3RoZXIgY2FzZXMuDQoNCkJlY2F1c2UgdGhlc2UgYXJlICJNVVNUIE5PVCBz ZXQiIGNvbnN0cmFpbnRzLCBJIGNvdWxkIGltYWdpbmUgaW1wbGVtZW50ZXJzIHdobyBuZXZlciBh bnRpY2lwYXRlZCB0aGF0IGFuIEVDTigwKSBvciBFQ04oMSkgd291bGQgYmUgc2V0LCBhbmQgZG9u J3QgbG9vayBhdCB0aGUgZmllbGQgKHByb2JhYmx5IGdvb2QpLCBidXQgSSBjYW4gYWxzbyBpbWFn aW5lIGltcGxlbWVudGVycyB2YWxpZGF0aW5nIHRoYXQgRUNOKDApIGFuZCBFQ04oMSkgYXJlIG5v dCBzZXQgKHByb2JhYmx5IGJhZCkuIERvIHBlb3BsZSBoYXZlIGFueSBjb25jZXJucyBhYm91dCBl bmNvdW50ZXJpbmcgIkVDVCB2YWx1ZXMgTVVTVCBiZSBjbGVhcmVkIiBpbXBsZW1lbnRhdGlvbnMg ZHVyaW5nIHRoaXMgZXhwZXJpbWVudD8NCg0KSSBzdXBwb3NlIGlmIHNvbWUgaW1wbGVtZW50YXRp b24gdGhhdCBkb2VzIHRoaXMgaXMgZGVwbG95ZWQgYW5kIHlvdSBmb2xrcyBydW4gdGhlIGV4cGVy aW1lbnQsIHRoZW4gd2UnbGwga25vdyA6RCAuLi4NCltEYXZpZD5dIEkgd291bGQgbGVhdmUgdGhp cyB0byB0aGUgZHJhZnRzL1JGQ1MgdGhhdCBkZXNjcmliZSB0aGUgZXhwZXJpbWVudHMsIGFzIEkg ZXhwZWN0IGltcGxlbWVudGVycyBvZiB0aGUgZXhwZXJpbWVudHMgdG8gbG9vayB0aGVyZSwgYW5k IG5vdCBhdCB0aGlzIHByb2Nlc3MgUkZDICh0byBiZSkuDQoNCkJ1dCBJIHdvbmRlciBpZiBpdCdz IHdvcnRoIG1ha2luZyB0aGF0IGNsZWFyIGZvciByZWNlaXZlcnMsIHNpbmNlIHlvdSdyZSB1cGRh dGluZyBSRkMgMzE2OCBhbnl3YXk/DQoNCkluIHRoaXMgdGV4dCwNCg0KICAgICAgUmFuZG9tIEVD VCB2YWx1ZXMgTVVTVCBOT1QgYmUgdXNlZCwgYXMgdGhhdCBtYXkgZXhwb3NlIFJUUCB0bw0KICAg ICAgZGlmZmVyZW5jZXMgaW4gbmV0d29yayB0cmVhdG1lbnQgb2YgdHJhZmZpYyBtYXJrZWQgd2l0 aCBFQ1QoMSkgYW5kDQogICAgICBFQ1QoMCkgYW5kIGRpZmZlcmVuY2VzIGluIGFzc29jaWF0ZWQg ZW5kcG9pbnQgY29uZ2VzdGlvbg0KICAgICAgcmVzcG9uc2VzLA0KDQppcyAiUmFuZG9tIEVDVCB2 YWx1ZXMiIHRoZSByaWdodCB3b3JkPyBJIGNvdWxkIGltYWdpbmUgdGhpcyBwcm9oaWJpdGluZyB1 c2luZyBFQ1QoMCkgYW5kIEVDVCgxKSBpbnRlcmNoYW5nZWFibHksIGJ1dCBpZiB0aGF0J3Mgd2hh dCdzIGludGVuZGVkLCBJIGNvdWxkIGFsc28gaW1hZ2luZSB0aGlzIHByb2hpYml0aW5nIHNpbXBs eSBub3QgZXhwbGljaXRseSBzZXR0aW5nIHRoZSBFQ1QgdmFsdWVzIGF0IGFsbCwgc28gbWlzc2lu ZyB5b3VyIHBvaW50Lg0KW0RhdmlkPl0gWWVzLCDigJxSYW5kb23igJ0gaXMgdGhlIHJpZ2h0IHdv cmQsIGFzIHRoZSB0ZXh0IHF1b3RlZCBmcm9tIFJGQyA2Njc5IHVzZXMgdGhlIHdvcmQg4oCccmFu ZG9t4oCdIHNvIHRoYXQgaXMgdGhlIGNvcnJlY3Qgd29yZCB0byB1c2UgaGVyZSwgYW5kIGZ1cnRo ZXIgZXhwbGFuYXRpb24gY2FuIGJlIGZvdW5kIGluIFJGQyA2Njc5Lg0KDQpJJ20gbG9va2luZyBh dCB0aGlzIHRleHQNCg0KICAgQXMgYSBwcm9jZXNzIG1lbW8gdGhhdCBtYWtlcyBubyBjaGFuZ2Vz IHRvIGV4aXN0aW5nIHByb3RvY29scywgdGhlcmUNCiAgIGFyZSBubyBwcm90b2NvbCBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucy4NCg0KYW5kIHdvbmRlcmluZyBpZiBpdCdzIGN1cnJlbnQgd2l0aCB0 aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQuIElzICJubyBjaGFuZ2VzIHRvIGV4aXN0aW5nIHByb3Rv Y29scyIgc3RpbGwgdGhlIHJpZ2h0IHdheSB0byBjaGFyYWN0ZXJpemUgdGhpcyBkcmFmdD8gSWYg eW91IHdhbnRlZCB0byBzYXkNCg0KICAgQXMgYSBwcm9jZXNzIG1lbW8gdGhhdCBvbmx5IGFkZHMg bGltaXRhdGlvbnMgdG8gZXhpc3RpbmcgcHJvdG9jb2xzLCB0aGVyZQ0KICAgYXJlIG5vIHByb3Rv Y29sIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0KDQpJJ2QgYmUgaGFwcHkgdG8gYmVsaWV2ZSB5 b3UgLi4uDQpbRGF2aWQ+XSBJIHNlZSB0aGUgY29uY2VybiwgYW5kIGVkaXRlZCB0aGUgdGV4dCBy b3VnaGx5IGFzIHN1Z2dlc3RlZCwgcGx1cyBtb3ZlZCBhIHN1cHBvcnRpbmcgc2VudGVuY2UgYWJv dXQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBleHBlcmltZW50cyB1cCB0byBqb2lu IHRoaXMgc2VudGVuY2UsIHNvIHRoZSBuZXcgcGFyYWdyYXBoIG5vdyByZWFkczoNCg0KQXMgYSBw cm9jZXNzIG1lbW8gdGhhdCBvbmx5IHJlbW92ZXMgbGltaXRhdGlvbnMgb24gcHJvcG9zZWQgZXhw ZXJpbWVudHMsDQp0aGVyZSBhcmUgbm8gcHJvdG9jb2wgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMu ICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhlDQpwcm9wb3NlZCBleHBlcmltZW50cyBh cmUgZGlzY3Vzc2VkIGluIHRoZSBJbnRlcm5ldC1EcmFmdHMgdGhhdCBwcm9wb3NlIHRoZW0uDQoN ClRoYW5rcywNCg0KU3BlbmNlcg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0c3Z3Zy1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIGludGVybmV0LQ0KPiBkcmFmdHNAaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0c0BpZXRmLm9yZz4NCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgNCwgMjAx NyA3OjI5IFBNDQo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5j ZUBpZXRmLm9yZz4NCj4gQ2M6IHRzdndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4N Cj4gU3ViamVjdDogW3RzdndnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRzdndnLWVjbi1leHBl cmltZW50YXRpb24tMDQudHh0DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVHJhbnNwb3J0IEFyZWEgV29ya2luZyBHcm91 cCBXRyBvZiB0aGUNCj4gSUVURi4NCj4NCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBFeHBs aWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBFeHBlcmltZW50YXRpb24NCj4gICAg ICAgICBBdXRob3IgICAgICAgICAgOiBEYXZpZCBCbGFjaw0KPiAgICAgICBGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDQudHh0DQo+ICAgICAg IFBhZ2VzICAgICAgICAgICA6IDE3DQo+ICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTctMDgt MDQNCj4NCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgbWVtbyB1cGRhdGVzIFJGQyAzMTY4LCB3aGlj aCBzcGVjaWZpZXMgRXhwbGljaXQgQ29uZ2VzdGlvbg0KPiAgICBOb3RpZmljYXRpb24gKEVDTikg YXMgYSByZXBsYWNlbWVudCBmb3IgcGFja2V0IGRyb3BzIGFzIGluZGljYXRvcnMgb2YNCj4gICAg bmV0d29yayBjb25nZXN0aW9uLiAgSXQgcmVsYXhlcyByZXN0cmljdGlvbnMgaW4gUkZDIDMxNjgg dGhhdCB3b3VsZA0KPiAgICBvdGhlcndpc2UgaGluZGVyIGV4cGVyaW1lbnRhdGlvbiB0b3dhcmRz IGJlbmVmaXRzIGJleW9uZCBqdXN0IHJlbW92YWwNCj4gICAgb2YgbG9zcy4gIFRoaXMgbWVtbyBz dW1tYXJpemVzIHRoZSBhbnRpY2lwYXRlZCBhcmVhcyBvZg0KPiAgICBleHBlcmltZW50YXRpb24g YW5kIHVwZGF0ZXMgUkZDIDMxNjggdG8gZW5hYmxlIGV4cGVyaW1lbnRhdGlvbiBpbg0KPiAgICB0 aGVzZSBhcmVhcy4gIEFuIEV4cGVyaW1lbnRhbCBSRkMgaXMgcmVxdWlyZWQgdG8gdGFrZSBhZHZh bnRhZ2Ugb2YNCj4gICAgYW55IG9mIHRoZXNlIGVuYWJsaW5nIHVwZGF0ZXMuICBJbiBhZGRpdGlv biwgdGhpcyBtZW1vIG1ha2VzIHJlbGF0ZWQNCj4gICAgdXBkYXRlcyB0byB0aGUgRUNOIHNwZWNp ZmljYXRpb25zIGZvciBSVFAgaW4gUkZDIDY2NzkgYW5kIGZvciBEQ0NQIGluDQo+ICAgIFJGQyA0 MzQxLCBSRkMgNDM0MiBhbmQgUkZDIDU2MjIuICBUaGlzIG1lbW8gYWxzbyByZWNvcmRzIHRoZQ0K PiAgICBjb25jbHVzaW9uIG9mIHRoZSBFQ04gTm9uY2UgZXhwZXJpbWVudCBpbiBSRkMgMzU0MCwg YW5kIHByb3ZpZGVzIHRoZQ0KPiAgICByYXRpb25hbGUgZm9yIHJlY2xhc3NpZmljYXRpb24gb2Yg UkZDIDM1NDAgYXMgSGlzdG9yaWM7IHRoaXMNCj4gICAgcmVjbGFzc2lmaWNhdGlvbiBlbmFibGVz IG5ldyBleHBlcmltZW50YWwgdXNlIG9mIHRoZSBFQ1QoMSkNCj4gICAgY29kZXBvaW50Lg0KPg0K Pg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1lY24t ZXhwZXJpbWVudGF0aW9uLw0KPg0KPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBh dmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRz dndnLWVjbi1leHBlcmltZW50YXRpb24tMDQNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWVjbi0NCj4gZXhwZXJpbWVudGF0aW9uLTA0DQo+ DQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHN2d2ctZWNuLWV4 cGVyaW1lbnRhdGlvbi0wNA0KPg0KPg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KDQo= --_000_CE03DB3D7B45C245BCA0D243277949362FC2A962MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SGkgU3BlbmNlciw8bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5SZXN1cmZhY2luZyBmcm9tIHRyeWluZyB0byB0YWtlIHZhY2F0aW9uIGluIEF1Z3VzdCDigJMg bWFueSB0aGFua3MgZm9yIHRoaXMgZGV0YWlsZWQgcmV2aWV3LiZuYnNwOyBDb21tZW50cyBpbmxp bmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGhhdmUgYSAt MDUgcmVhZHkgdG8gZ28gaWYgdGhlc2UgY2hhbmdlcyBhcmUgb2sgd2l0aCB5b3UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsIC0tRGF2aWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZA Z21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDcsIDIwMTcgMjoz NyBQTTxicj4NCjxiPlRvOjwvYj4gQmxhY2ssIERhdmlkICZsdDtkYXZpZC5ibGFja0BlbWMuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gdHN2d2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0 aW9uLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSwgRGF2aWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBBdWcgNCwgMjAxNyBhdCA2OjMxIFBNLCBCbGFjaywgRGF2aWQgJmx0OzxhIGhyZWY9 Im1haWx0bzpEYXZpZC5CbGFja0BkZWxsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkRhdmlkLkJsYWNr QGRlbGwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QXMgZGlzY3Vzc2VkIGluIFByYWd1ZSwgdGhpcyBpcyBhIHNtYWxs IHVwZGF0ZSB0byByZXF1ZXN0IHRoYXQgSUFOQSByZW1vdmUgdGhlIHJlZ2lzdHJhdGlvbiBvZiB0 aGUgVENQIGhlYWRlciBmbGFnIHVzZWQgYnkgUkZDIDM1NDAgKEVDTiBOb25jZSkuJm5ic3A7ICZu YnNwO0FueSByZWFzc2lnbm1lbnQgb2YgdGhhdCBmbGFnIHdpbGwgYmUgaGFuZGxlZCBieSB0aGUg VENQTSBXRy4mbmJzcDsgVGhpcyB1cGRhdGUgYWxzbyBjaGFuZ2VzIHRoZQ0KIG5hbWUgb2Ygb25l IG9mIHRoZSBhcmVhcyBvZiBFQ04gZXhwZXJpbWVudGF0aW9uIHRvIGJlIGRpZmZlcmVudCBmcm9t IHRoZSBuYW1lIG9mIHRoZSBleHBlcmltZW50IHByb3Bvc2VkIGluIHRoYXQgYXJlYS48YnI+DQo8 YnI+DQpUaGFua3MsIC0tRGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBEYXZpZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSByZWFsbHkgbGlrZSB0aGlzIGRyYWZ0 LiBUaGFua3MgdG8geW91IGFuZCB5b3VyIEFDSyBsaXN0IGZvciB5b3VyIGVmZm9ydHMgLSB0aGUg cmVzdWx0IGlzIHZlcnkgY2xlYXIgYW5kIGNvbXBsZXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYSBmZXcgcXVlc3Rpb25zIGJl Zm9yZSBJIHB1c2ggdGhlIGJ1dHRvbiBvbiBMYXN0IENhbGwuIFRoZXkncmUgbWlub3IgZW5vdWdo IHRoYXQgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIHdhaXQgZm9yIEdvcnJ5IHRvIGJlIHByZXNl bnQgZm9yIHRoZSBkaXNjdXNzaW9uIChvZiBjb3Vyc2UsIGlmIHBlb3BsZSBkaXNhZ3JlZSwganVz dCBsZXQgbWUga25vdykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdHJpZWQgdG8gb2ZmZXIgdGV4dCBmb3IgbW9zdCBvZiB0aGVtLCBidXQg eW91IG1pZ2h0IGFsc28gYW5zd2VyIHRoZW0gYnkgc2F5aW5nIHRoYXQgVFNWV0cgbmVlZHMgYSBt dWNoIHNtYXJ0ZXIgcmVzcG9uc2libGUgQUQgOy0pIC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGlzIHRleHQsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtB biBFeHBlcmltZW50YWwgUkZDIE1VU1QgYmUgcHVibGlzaGVkIGZvciBhbnkgcHJvdG9jb2w8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDtvciBtZWNoYW5pc20gdGhhdCB0YWtlcyBhZHZhbnRhZ2Ugb2YgYW55IG9mIHRoZXNlIGVu YWJsaW5nIHVwZGF0ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEkga25vdyB3aGF0IHlvdSdyZSBzYXlpbmcsIGJ1 dCB0aGlzIGZvcm11bGF0aW9uIGNvbmZ1c2VzIG1lIGJlY2F1c2UgaXQncyBwbGFjaW5nIGEgY29t bWl0bWVudCBvbiB3aGF0IGEgZnV0dXJlIHdvcmtpbmcgZ3JvdXAgbXVzdCBkbyAobGlrZSwgd2hh dCBpZiB0aGUgZHJhZnQgZGVzY3JpYmluZyB0aGUgZXhwZXJpbWVudGFsIHByb3RvY29sIGlzIGlu Y29oZXJlbnQgLSBjYW4gdGhlIHdvcmtpbmcgZ3JvdXANCiBKdXN0IFNheSBObywgb3IgY2FuIHRo ZSBhdXRob3JzIHNheSAmcXVvdDtidXQgeW91IGhhdmUgdG8gcmVxdWVzdCBwdWJsaWNhdGlvbiwg YmVjYXVzZSAmcXVvdDtBbiBFeHBlcmltZW50YWwgUkZDIE1VU1QgYmUgcHVibGlzaGVkIC4uLiZx dW90OykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0RhdmlkJmd0O10gVGhlIHdvcmtpbmcgZ3JvdXAgY2Fu IEp1c3QgU2F5IE5vLCBhbmQgdGhhdCBvdXRjb21lIHdvdWxkIGJlIGEg4oCcZmVhdHVyZeKAnSDi gJMgaWYgdGhlIGV4cGVyaW1lbnRhbCBwcm90b2NvbCBpcyBwcm9ibGVtYXRpYywgdGhlbiB0aGUg ZXhwZXJpbWVudCBzaG91bGRu4oCZdA0KIGJlIHJ1biBhdCBzY2FsZSBpbiB0aGUgSW50ZXJuZXQs IGFuZCB0aGUgV0cgd2lsbCBoYXZlIGRvbmUgdGhlIHJpZ2h0IHRoaW5nIGJ5IHNheWluZyBzby4N Cjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHlv dXIgcG9pbnQgdGhhdCBhbnkgcHJvdG9jb2wgb3IgbWVjaGFuaXNtIHRoYXQgdGFrZXMgYWR2YW50 YWdlIG9mIHRoZXNlIGVuYWJsaW5nIHVwZGF0ZXMgY2FuJ3QgYmUgU3RhbmRhcmRzLVRyYWNrPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPltEYXZpZCZndDtdIE5vIOKAkyBhIFN0YW5kYXJkcy1UcmFjayBwcm90 b2NvbCBSRkMgY2FuIHNpbXBseSB1cGRhdGUgUkZDIDMxNjggKGFuZCBhbnkgb3RoZXIgUkZDcyB0 aGF0IGl0IG5lZWRzIHRvKSBkaXJlY3RseSwgYW5kIGRvZXNu4oCZdCBuZWVkIHRoaXMgZHJhZnTi gJlzIHBlcm1pc3Npb24NCiB0byBkbyBzbywgYXMgdGhlIG5leHQgc2VudGVuY2Ugc3RhdGVzIOKA pjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRo aXMgdGV4dCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1RoZXJlIGlzIG5vIG5lZWQgdG8gbWFrZSBjaGFuZ2Vz IGZvciBwcm90b2NvbHMgYW5kIG1lY2hhbmlzbXMgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FyZSBkb2N1bWVudGVk IGluIFN0YW5kYXJkcyBUcmFjayBSRkNzLCBhcyBhbnkgU3RhbmRhcmRzIFRyYWNrIFJGQzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwO2NhbiB1cGRhdGUgUkZDIDMxNjggd2l0aG91dCBuZWVkaW5nIGEgc3RhbmRhcmRzIHByb2Nl c3MgZXhjZXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj53ZSd2ZSBiZWVuIHRhbGtpbmcgdXNpbmcgdGhpcyB0ZXJtaW5vbG9neSBmb3Ig YXQgbGVhc3QgYSB5ZWFyIHRoYXQgSSBjYW4gcmVtZW1iZXIsIGJ1dCBJJ20gbm90IHRvdGFsbHkg c3VyZSB0aGF0IGFuIGF2ZXJhZ2UgSUVTRyB3b3VsZCBldmVuIGFwcHJvdmUgYW4gRXhwZXJpbWVu dGFsIGRyYWZ0IHRoYXQgdXBkYXRlZCBhIHN0YW5kYXJkcy10cmFjayBSRkMuIEhvdyBiYWRseSBk byB5b3UgbmVlZCB0byBzYXkgdGhpcw0KIGF0IGFsbCwgc2luY2UgeW91J3JlIGp1c3QgY29uZmly bWluZyBhIHdlbGwtdW5kZXJzdG9vZCBmYWN0IHRoYXQgSSB0aGluayB3ZSBhbGwgYWdyZWUgb24/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+W0RhdmlkJmd0O10gVGhpcyBoYXMgYmVlbiBicm91Z2h0IHVwIHRv byBtYW55IHRpbWVzIGluIFdHIGRpc2N1c3Npb24gb2YgdGhpcyBkcmFmdCB0byBsZWF2ZSBvdXQs IElNSE8uPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gdGhpcyB0ZXh0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7QSBzdHVkeSBvZiB0aGUgRUNOIGJlaGF2aW91ciBvZiB0 aGUgQWxleGEgdG9wIDFNIHdlYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3NlcnZlcnMgdXNpbmcgMjAxNCBkYXRhIFtUcmFt bWVsbDE1XSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSdtIHdvbmRlcmluZyB3aGV0aGVyIGl0J3MgdXNlZnVsIHRvIHNh eSAmcXVvdDtBbGV4YSB0b3AgMU0gd2ViIHNlcnZlcnMmcXVvdDsgaW4gYW4gUkZDIHRoYXQgd2ls bCBwcm9iYWJseSBsYXN0IGxvbmdlciB0aGFuIEFsZXhhIGxhc3RzIC4uLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPltEYXZpZCZndDtdIEkgdmlldyB0aGlzIGFzIGEg4oCcc2hvdyB5b3VyIHdvcmvigJ0gaXRl bSDigKYgdGhpcyBpcyB0aGUgZGF0YSB0aGF0IHdhcyB1c2VkIGF0IHRoZSB0aW1lLg0KPC9zcGFu PjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhpcyB0ZXh0 LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7U2lnbmlmaWNhbnRseSBtb3JlIGFnZ3Jlc3NpdmUgc2VuZGVyIHJlc3BvbnNl cyB0byBFQ048bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDthcmUgcmVxdWlyZWQgdG8gbWFrZSBlZmZlY3RpdmUgdXNlIG9mIHN1 Y2ggc2hhbGxvdyBxdWV1ZXM7IERhdGFjZW50ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO15eXl5e Xl5ePG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7VENQIChEQ1RDUCkgW0ktRC5pZXRmLXRjcG0tZGN0Y3BdIHByb3ZpZGVzIGFu IGV4YW1wbGUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHRhbmdsZWQgdXAgaW4gcGFzc2l2ZSB0ZW5zZSAoJnF1 b3Q7d2hvIGlzIHJlcXVpcmVkIHRvIGRvIHdoYXQ/JnF1b3Q7KS4gSXMgaXQgY29ycmVjdCB0byBz YXkmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO1NpZ25pZmljYW50bHkgbW9yZSBhZ2dyZXNzaXZlIHNlbmRlciBy ZXNwb25zZXMgdG8gRUNOPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7YXJlIG5lZWRlZCBpbiBvcmRlciB0byBtYWtlIGVmZmVj dGl2ZSB1c2Ugb2Ygc3VjaCBzaGFsbG93IHF1ZXVlczsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtEYXRhY2VudGVy IFRDUCAoRENUQ1ApIFtJLUQuaWV0Zi10Y3BtLWRjdGNwXSBwcm92aWRlcyBhbiBleGFtcGxlLiAm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOzxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bRGF2aWQmZ3Q7 XSBZZXMsIGNoYW5nZSBtYWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBzZWUgdGhhdCB0aGUgZHJhZnQgdXNlcyBib3RoIHRoZSB0ZXJtcyAmcXVvdDtz aGFsbG93IHF1ZXVlcyZxdW90OyBhbmQgJnF1b3Q7bmVhcmx5IGVtcHR5IHF1ZXVlcyZxdW90Oy4g RG8gdGhlc2UgdGVybXMgbWVhbiB0aGUgc2FtZSB0aGluZz8gSWYgc28sIHBlcmhhcHMgaXQncyB3 b3J0aCBlaXRoZXIgcGlja2luZyBvbmUgdGVybSwgb3Igc2F5aW5nIHRoYXQgdGhleSBtZWFuIHRo ZSBzYW1lIHRoaW5nLiBSaWdodCBub3csIEknbSB0cnlpbmcgdG8NCiBpbWFnaW5lIHdoYXQgdGhl IGRpZmZlcmVuY2UgbWlnaHQgYmUsIHNpbmNlIGJvdGggcGhyYXNlcyBhcmUgdXNlZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5bRGF2aWQmZ3Q7XSBHb29kIHBvaW50LCBjaGFuZ2VkIHRvIGNvbnNpc3RlbnRs eSB1c2Ug4oCcdmVyeSBzaGFsbG934oCdIGV2ZXJ5d2hlcmUuPC9zcGFuPjwvaT48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGZvbGtzIGFyZSB0aGUgZXhwZXJ0cyBv biB0aGlzIHN0dWZmLCBidXQgSSdtIGxvb2tpbmcgYXQgdGhpcyBxdW90ZWQgdGV4dCBmcm9tIFJG QyAzMTY4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwO1JGQyAzMTY4IHByb2hpYml0cyB1c2Ugb2YgRUNOIGZvciBUQ1AgY29udHJvbCBw YWNrZXRzIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO3JldHJhbnNtaXR0ZWQgcGFja2V0cyBpbiBhIG51bWJlciBvZiBw bGFjZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDtvICZuYnNwOyZxdW90O1RvIGVuc3VyZSB0aGUgcmVsaWFibGUgZGVs aXZlcnkgb2YgdGhlIGNvbmdlc3Rpb24gaW5kaWNhdGlvbiBvZjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhl IENFIGNvZGVwb2ludCwgYW4gRUNUIGNvZGVwb2ludCBNVVNUIE5PVCBiZSBzZXQgaW4gYSBwYWNr ZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDsgJm5ic3A7IHVubGVzcyB0aGUgbG9zcyBvZiB0aGF0IHBhY2tldCBpbiB0aGUg bmV0d29yayB3b3VsZCBiZSBkZXRlY3RlZCBieTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIGVuZCBub2Rl cyBhbmQgaW50ZXJwcmV0ZWQgYXMgYW4gaW5kaWNhdGlvbiBvZiBjb25nZXN0aW9uLiZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgKFNlY3Rpb24gNS4yKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7byAmbmJzcDsmcXVvdDtBIGhv c3QgTVVTVCBOT1Qgc2V0IEVDVCBvbiBTWU4gb3IgU1lOLUFDSyBwYWNrZXRzLiZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgKFNlY3Rpb24gNi4xLjEpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtvICZuYnNwOyZxdW90O3B1cmUg YWNrbm93bGVkZ2VtZW50IHBhY2tldHMgKGUuZy4sIHBhY2tldHMgdGhhdCBkbyBub3QgY29udGFp bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgYW55IGFjY29tcGFueWluZyBkYXRhKSBNVVNUIGJlIHNlbnQgd2l0 aCB0aGUgbm90LUVDVCBjb2RlcG9pbnQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAoU2VjdGlvbiA2 LjEuNCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7JnF1b3Q7VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgRUNO LWNhcGFibGUgVENQIGltcGxlbWVudGF0aW9ucyBNVVNUIE5PVDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2V0 IGVpdGhlciBFQ1QgY29kZXBvaW50IChFQ1QoMCkgb3IgRUNUKDEpKSBpbiB0aGUgSVAgaGVhZGVy IGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcmV0cmFuc21pdHRlZCBkYXRhIHBhY2tldHMsIGFuZCB0aGF0 IHRoZSBUQ1AgZGF0YSByZWNlaXZlciBTSE9VTEQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlnbm9yZSB0aGUg RUNOIGZpZWxkIG9uIGFycml2aW5nIGRhdGEgcGFja2V0cyB0aGF0IGFyZSBvdXRzaWRlIG9mPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyB0aGUgcmVjZWl2ZXIncyBjdXJyZW50IHdpbmRvdy4mcXVvdDsgJm5ic3A7 KFNlY3Rpb24gNi4xLjUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtvICZuYnNwOyZxdW90O3RoZSBUQ1AgZGF0YSBzZW5k ZXIgTVVTVCBOT1Qgc2V0IGVpdGhlciBhbiBFQ1QgY29kZXBvaW50IG9yIHRoZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgQ1dSIGJpdCBvbiB3aW5kb3cgcHJvYmUgcGFja2V0cy4mcXVvdDsgJm5ic3A7KFNlY3Rp b24gNi4xLjYpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIG5vdGljaW5nIHRoYXQgb25seSB0aGUgdGV4 dCBpbiA2LjEuNSBleHBsaWNpdGx5IG1lbnRpb25zIHRoZSBUQ1AgZGF0YSByZWNlaXZlciBpZ25v cmluZyB0aGUgJnF1b3Q7TVVTVCBOT1Qgc2V0JnF1b3Q7IEVDTiBmaWVsZC4gSSB0b29rIGEgcXVp Y2sgc3BpbiB0aHJvdWdoIFJGQyAzMTY4IHNlYXJjaGluZyBmb3IgJnF1b3Q7aWdub3JlJnF1b3Q7 LCBidXQgZGlkbid0IHNlZSBzb21ldGhpbmcgdGhhdCBleHBsaWNpdGx5IGNvdmVyZWQgdGhlDQog b3RoZXIgY2FzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlY2F1c2UgdGhlc2UgYXJlICZxdW90O01VU1QgTk9UIHNldCZxdW90OyBjb25z dHJhaW50cywgSSBjb3VsZCBpbWFnaW5lIGltcGxlbWVudGVycyB3aG8gbmV2ZXIgYW50aWNpcGF0 ZWQgdGhhdCBhbiBFQ04oMCkgb3IgRUNOKDEpIHdvdWxkIGJlIHNldCwgYW5kIGRvbid0IGxvb2sg YXQgdGhlIGZpZWxkIChwcm9iYWJseSBnb29kKSwgYnV0IEkgY2FuIGFsc28gaW1hZ2luZSBpbXBs ZW1lbnRlcnMgdmFsaWRhdGluZyB0aGF0IEVDTigwKQ0KIGFuZCBFQ04oMSkgYXJlIG5vdCBzZXQg KHByb2JhYmx5IGJhZCkuIERvIHBlb3BsZSBoYXZlIGFueSBjb25jZXJucyBhYm91dCBlbmNvdW50 ZXJpbmcgJnF1b3Q7RUNUIHZhbHVlcyBNVVNUIGJlIGNsZWFyZWQmcXVvdDsgaW1wbGVtZW50YXRp b25zIGR1cmluZyB0aGlzIGV4cGVyaW1lbnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VwcG9zZSBpZiBzb21lIGltcGxlbWVudGF0aW9u IHRoYXQgZG9lcyB0aGlzIGlzIGRlcGxveWVkIGFuZCB5b3UgZm9sa3MgcnVuIHRoZSBleHBlcmlt ZW50LCB0aGVuIHdlJ2xsIGtub3cgOkQgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0RhdmlkJmd0O10g SSB3b3VsZCBsZWF2ZSB0aGlzIHRvIHRoZSBkcmFmdHMvUkZDUyB0aGF0IGRlc2NyaWJlIHRoZSBl eHBlcmltZW50cywgYXMgSSBleHBlY3QgaW1wbGVtZW50ZXJzIG9mIHRoZSBleHBlcmltZW50cyB0 byBsb29rIHRoZXJlLCBhbmQgbm90IGF0IHRoaXMNCiBwcm9jZXNzIFJGQyAodG8gYmUpLjwvc3Bh bj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBJIHdvbmRl ciBpZiBpdCdzIHdvcnRoIG1ha2luZyB0aGF0IGNsZWFyIGZvciByZWNlaXZlcnMsIHNpbmNlIHlv dSdyZSB1cGRhdGluZyBSRkMgMzE2OCBhbnl3YXk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoaXMgdGV4dCw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgUmFuZG9tIEVDVCB2YWx1ZXMgTVVTVCBOT1QgYmUgdXNlZCwgYXMgdGhhdCBtYXkgZXhwb3Nl IFJUUCB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZGlmZmVyZW5jZXMgaW4gbmV0d29yayB0cmVhdG1lbnQg b2YgdHJhZmZpYyBtYXJrZWQgd2l0aCBFQ1QoMSkgYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBFQ1QoMCkg YW5kIGRpZmZlcmVuY2VzIGluIGFzc29jaWF0ZWQgZW5kcG9pbnQgY29uZ2VzdGlvbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgcmVzcG9uc2VzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlzICZxdW90O1JhbmRvbSBFQ1Qg dmFsdWVzJnF1b3Q7IHRoZSByaWdodCB3b3JkPyBJIGNvdWxkIGltYWdpbmUgdGhpcyBwcm9oaWJp dGluZyB1c2luZyBFQ1QoMCkgYW5kIEVDVCgxKSBpbnRlcmNoYW5nZWFibHksIGJ1dCBpZiB0aGF0 J3Mgd2hhdCdzIGludGVuZGVkLCBJIGNvdWxkIGFsc28gaW1hZ2luZSB0aGlzIHByb2hpYml0aW5n IHNpbXBseSBub3QgZXhwbGljaXRseSBzZXR0aW5nIHRoZSBFQ1QgdmFsdWVzIGF0IGFsbCwgc28N CiBtaXNzaW5nIHlvdXIgcG9pbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0RhdmlkJmd0O10gWWVzLCDi gJxSYW5kb23igJ0gaXMgdGhlIHJpZ2h0IHdvcmQsIGFzIHRoZSB0ZXh0IHF1b3RlZCBmcm9tIFJG QyA2Njc5IHVzZXMgdGhlIHdvcmQg4oCccmFuZG9t4oCdIHNvIHRoYXQgaXMgdGhlIGNvcnJlY3Qg d29yZCB0byB1c2UgaGVyZSwgYW5kIGZ1cnRoZXIgZXhwbGFuYXRpb24NCiBjYW4gYmUgZm91bmQg aW4gUkZDIDY2NzkuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSdtIGxvb2tpbmcgYXQgdGhpcyB0ZXh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtBcyBhIHByb2Nlc3MgbWVt byB0aGF0IG1ha2VzIG5vIGNoYW5nZXMgdG8gZXhpc3RpbmcgcHJvdG9jb2xzLCB0aGVyZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwO2FyZSBubyBwcm90b2NvbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB3b25k ZXJpbmcgaWYgaXQncyBjdXJyZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBJcyAm cXVvdDtubyBjaGFuZ2VzIHRvIGV4aXN0aW5nIHByb3RvY29scyZxdW90OyBzdGlsbCB0aGUgcmln aHQgd2F5IHRvIGNoYXJhY3Rlcml6ZSB0aGlzIGRyYWZ0PyBJZiB5b3Ugd2FudGVkIHRvIHNheTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7QXMgYSBwcm9jZXNzIG1lbW8gdGhhdCBvbmx5IGFkZHMgbGltaXRhdGlvbnMgdG8g ZXhpc3RpbmcgcHJvdG9jb2xzLCB0aGVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FyZSBubyBwcm90b2NvbCBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknZCBiZSBoYXBweSB0byBiZWxpZXZlIHlvdSAuLi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5bRGF2aWQmZ3Q7XSBJIHNlZSB0aGUgY29uY2VybiwgYW5kIGVkaXRlZCB0 aGUgdGV4dCByb3VnaGx5IGFzIHN1Z2dlc3RlZCwgcGx1cyBtb3ZlZCBhIHN1cHBvcnRpbmcgc2Vu dGVuY2UgYWJvdXQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBleHBlcmltZW50cw0K IHVwIHRvIGpvaW4gdGhpcyBzZW50ZW5jZSwgc28gdGhlIG5ldyBwYXJhZ3JhcGggbm93IHJlYWRz OjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjMw Ljc1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBhIHByb2Nlc3MgbWVtbyB0 aGF0IG9ubHkgcmVtb3ZlcyBsaW1pdGF0aW9ucyBvbiBwcm9wb3NlZCBleHBlcmltZW50cyw8YnI+ DQp0aGVyZSBhcmUgbm8gcHJvdG9jb2wgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuJm5ic3A7IFNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB0aGU8YnI+DQpwcm9wb3NlZCBleHBlcmltZW50cyBh cmUgZGlzY3Vzc2VkIGluIHRoZSBJbnRlcm5ldC1EcmFmdHMgdGhhdCBwcm9wb3NlIHRoZW0uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNwZW5jZXImbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7 IEZyb206IHRzdndnIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5v cmciPnRzdndnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtPGJy Pg0KJmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnRzQGlldGYub3JnIj5kcmFmdHNAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyBTZW50OiBGcmlkYXksIEF1Z3VzdCA0LCAyMDE3IDc6MjkgUE08YnI+DQom Z3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYu b3JnIj50c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFt0c3Z3Z10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA0LnR4dDxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdy b3VwIFdHIG9mIHRoZTxicj4NCiZndDsgSUVURi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7OiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBF eHBlcmltZW50YXRpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0F1dGhvciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBEYXZpZCBCbGFjazxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0wNC50 eHQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGFnZXMmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMTc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7RGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogMjAxNy0wOC0wNDxicj4NCiZndDs8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsmbmJz cDsgJm5ic3A7IFRoaXMgbWVtbyB1cGRhdGVzIFJGQyAzMTY4LCB3aGljaCBzcGVjaWZpZXMgRXhw bGljaXQgQ29uZ2VzdGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IE5vdGlmaWNhdGlvbiAoRUNO KSBhcyBhIHJlcGxhY2VtZW50IGZvciBwYWNrZXQgZHJvcHMgYXMgaW5kaWNhdG9ycyBvZjxicj4N CiZndDsmbmJzcDsgJm5ic3A7IG5ldHdvcmsgY29uZ2VzdGlvbi4mbmJzcDsgSXQgcmVsYXhlcyBy ZXN0cmljdGlvbnMgaW4gUkZDIDMxNjggdGhhdCB3b3VsZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7 IG90aGVyd2lzZSBoaW5kZXIgZXhwZXJpbWVudGF0aW9uIHRvd2FyZHMgYmVuZWZpdHMgYmV5b25k IGp1c3QgcmVtb3ZhbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG9mIGxvc3MuJm5ic3A7IFRoaXMg bWVtbyBzdW1tYXJpemVzIHRoZSBhbnRpY2lwYXRlZCBhcmVhcyBvZjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IGV4cGVyaW1lbnRhdGlvbiBhbmQgdXBkYXRlcyBSRkMgMzE2OCB0byBlbmFibGUgZXhw ZXJpbWVudGF0aW9uIGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdGhlc2UgYXJlYXMuJm5ic3A7 IEFuIEV4cGVyaW1lbnRhbCBSRkMgaXMgcmVxdWlyZWQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2Y8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBhbnkgb2YgdGhlc2UgZW5hYmxpbmcgdXBkYXRlcy4mbmJzcDsg SW4gYWRkaXRpb24sIHRoaXMgbWVtbyBtYWtlcyByZWxhdGVkPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgdXBkYXRlcyB0byB0aGUgRUNOIHNwZWNpZmljYXRpb25zIGZvciBSVFAgaW4gUkZDIDY2Nzkg YW5kIGZvciBEQ0NQIGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgUkZDIDQzNDEsIFJGQyA0MzQy IGFuZCBSRkMgNTYyMi4mbmJzcDsgVGhpcyBtZW1vIGFsc28gcmVjb3JkcyB0aGU8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyBjb25jbHVzaW9uIG9mIHRoZSBFQ04gTm9uY2UgZXhwZXJpbWVudCBpbiBS RkMgMzU0MCwgYW5kIHByb3ZpZGVzIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHJhdGlvbmFs ZSBmb3IgcmVjbGFzc2lmaWNhdGlvbiBvZiBSRkMgMzU0MCBhcyBIaXN0b3JpYzsgdGhpczxicj4N CiZndDsmbmJzcDsgJm5ic3A7IHJlY2xhc3NpZmljYXRpb24gZW5hYmxlcyBuZXcgZXhwZXJpbWVu dGFsIHVzZSBvZiB0aGUgRUNUKDEpPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgY29kZXBvaW50Ljxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi8i IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsg VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNu LWV4cGVyaW1lbnRhdGlvbi0wNCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0wNDwvYT48YnI+ DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi10c3Z3Zy1lY24tIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLTwvYT48YnI+DQomZ3Q7IGV4 cGVyaW1lbnRhdGlvbi0wNDxicj4NCiZndDs8YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50 YXRpb24tMDQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDQ8L2E+PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQomZ3Q7IHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwv YT4uPGJyPg0KJmd0Ozxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE03DB3D7B45C245BCA0D243277949362FC2A962MX307CL04corpem_-- From nobody Wed Aug 30 08:57:29 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4C132025 for ; Wed, 30 Aug 2017 08:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22LmEGpqUWTy for ; Wed, 30 Aug 2017 08:57:25 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 6073B1201F8 for ; Wed, 30 Aug 2017 08:57:25 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id s187so33294934ywf.2 for ; Wed, 30 Aug 2017 08:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BKXuSwy9Tx7Pv4Y0A1zZ36KE6h+ZSXJNiX2UZYcsqZ8=; b=Mg5FbFm5Q+SSUoMITc0vLGFgOub+UW04wYc9vkUy2WeD3CjFrARvDwqRsN40OlWBB+ KtKPzQziCeCHoSM3SnBWPBQPd2llEN9YKsTOGe6hxl4ZYPMfTdInj9VdoaT9/NU6/0Uw /O4EGwJQ73/dhSWl5qjaBA68kU9y500U7orQxX6kzZyq91r/V+GAH+uifoG6YgBuF82n TDXgnD/Huwt6fa9NgjgiF9QlXd0wG2JyUM4BeYzimLCzE9O27a+o4tFI8E1AfSmR1gYz k+DBOTGCnihDId5lgmgXM08BsT6eDoQZJgUnAQPURpTw61ITzFTCxrhho+Rs0cr4gDuM No5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BKXuSwy9Tx7Pv4Y0A1zZ36KE6h+ZSXJNiX2UZYcsqZ8=; b=RAUpjMJPfi2rKKvy1zAViFSuzzKmQvr9lvr/CNXQorRI4qYgWhEj3mh634UcpLvnCj XHQ5QuERdpEmxiHeXBdHZMBC0TIW7EZinHmqiS3ADVRkJUemVyfkpF2Q9iWHFwadx7ci xb1m5P4ypFi2CrI+nuuVV5PgO2FsdZcdXjItBdUF3MFlKHXN1wwSh9B/A7Pot9x46+Gm gbh3AncOhRfayiL3wjleb69NwMlZXXQASkCfenCZ5f2nxrSPcaINQ2hRfLcNiD384TGs KomXprljb51myf4GOm0wqG19YMbVhP5cJSiHOmRYfK7mRxMDwjHg7mP/32CwTFmVt2fB 3nwQ== X-Gm-Message-State: AHYfb5g62XBk1CoXFJrQvHeFWoxAH3QpJ925G7iJc3iW6dbEsvdQG3V1 6Z3rJoFHbcCQGl6pgITa0IJyAb1MWg== X-Received: by 10.37.88.86 with SMTP id m83mr1702314ybb.170.1504108644213; Wed, 30 Aug 2017 08:57:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Wed, 30 Aug 2017 08:57:23 -0700 (PDT) In-Reply-To: References: <150188933148.18701.4807220216565950086@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 30 Aug 2017 10:57:23 -0500 Message-ID: To: "Black, David" Cc: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a114166d4712a7f0557fa95cb" Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:57:29 -0000 --001a114166d4712a7f0557fa95cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, David, Thanks, and welcome back :-) This mostly looks uber-reasonable, but I have one reply on Alexa below. On Wed, Aug 30, 2017 at 10:30 AM, Black, David wrote= : > Hi Spencer, > > > > Resurfacing from trying to take vacation in August =E2=80=93 many thanks = for this > detailed review. Comments inline. > > > > I have a -05 ready to go if these changes are ok with you. > > > > Thanks, --David > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* Monday, August 7, 2017 2:37 PM > *To:* Black, David > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn- > experimentation-04.txt > > > > Hi, David, > > > > On Fri, Aug 4, 2017 at 6:31 PM, Black, David wrote= : > > As discussed in Prague, this is a small update to request that IANA remov= e > the registration of the TCP header flag used by RFC 3540 (ECN Nonce). A= ny > reassignment of that flag will be handled by the TCPM WG. This update al= so > changes the name of one of the areas of ECN experimentation to be differe= nt > from the name of the experiment proposed in that area. > > Thanks, --David > > > > Hi, David, > > > > I really like this draft. Thanks to you and your ACK list for your effort= s > - the result is very clear and complete. > > > > I have a few questions before I push the button on Last Call. They're > minor enough that I don't think we need to wait for Gorry to be present f= or > the discussion (of course, if people disagree, just let me know). > > > > I tried to offer text for most of them, but you might also answer them by > saying that TSVWG needs a much smarter responsible AD ;-) ... > > > > In this text, > > > > An Experimental RFC MUST be published for any protocol > > or mechanism that takes advantage of any of these enabling updates. > > > > I think I know what you're saying, but this formulation confuses me > because it's placing a commitment on what a future working group must do > (like, what if the draft describing the experimental protocol is incohere= nt > - can the working group Just Say No, or can the authors say "but you have > to request publication, because "An Experimental RFC MUST be published > ..."). > > *[David>] The working group can Just Say No, and that outcome would be a > =E2=80=9Cfeature=E2=80=9D =E2=80=93 if the experimental protocol is probl= ematic, then the > experiment shouldn=E2=80=99t be run at scale in the Internet, and the WG = will have > done the right thing by saying so. * > > > > Is your point that any protocol or mechanism that takes advantage of thes= e > enabling updates can't be Standards-Track? > > *[David>] No =E2=80=93 a Standards-Track protocol RFC can simply update R= FC 3168 > (and any other RFCs that it needs to) directly, and doesn=E2=80=99t need = this > draft=E2=80=99s permission to do so, as the next sentence states =E2=80= =A6* > > > > In this text, > > > > There is no need to make changes for protocols and mechanisms that > > are documented in Standards Track RFCs, as any Standards Track RFC > > can update RFC 3168 without needing a standards process exception. > > > > we've been talking using this terminology for at least a year that I can > remember, but I'm not totally sure that an average IESG would even approv= e > an Experimental draft that updated a standards-track RFC. How badly do yo= u > need to say this at all, since you're just confirming a well-understood > fact that I think we all agree on? > > *[David>] This has been brought up too many times in WG discussion of thi= s > draft to leave out, IMHO.* > > > > In this text, > > > > A study of the ECN behaviour of the Alexa top 1M web > > servers using 2014 data [Trammell15] > > > > I'm wondering whether it's useful to say "Alexa top 1M web servers" in an > RFC that will probably last longer than Alexa lasts ... > > *[David>] I view this as a =E2=80=9Cshow your work=E2=80=9D item =E2=80= =A6 this is the data that > was used at the time.* > I'm sorry that my comment wasn't clear. What I was asking was if there was any more description of Alexa (or for extra credit, a URL) so that a reader in ten years can do more than google "Alexa top 1M web server" to figure out what this is. So I'm wondering if you need to qualify "top 1M web servers" as "Alexa top 1M web servers", because I'm thinking adding the adjective doesn't add as much as it takes away. It may be that the answer is "not really", and that would be A Fine Answer, but I wanted to make sure you understood what I was thinking, because it apparently wasn't what I was typing :-) Either way, I'm ready for you to send the updated version and have me initiate Last Call, and thanks for horsing this through. Spencer > In this text, > > > > Significantly more aggressive sender responses to ECN > > are required to make effective use of such shallow queues; Datacenter > > ^^^^^^^^ > > TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. > > > > I'm tangled up in passive tense ("who is required to do what?"). Is it > correct to say > > > > Significantly more aggressive sender responses to ECN > > are needed in order to make effective use of such shallow queues; > > Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. > > > > ? > > *[David>] Yes, change made.* > > > > I see that the draft uses both the terms "shallow queues" and "nearly > empty queues". Do these terms mean the same thing? If so, perhaps it's > worth either picking one term, or saying that they mean the same thing. > Right now, I'm trying to imagine what the difference might be, since both > phrases are used. > > *[David>] Good point, changed to consistently use =E2=80=9Cvery shallow= =E2=80=9D > everywhere.* > > > > You folks are the experts on this stuff, but I'm looking at this quoted > text from RFC 3168 > > > > RFC 3168 prohibits use of ECN for TCP control packets and > > retransmitted packets in a number of places: > > > > o "To ensure the reliable delivery of the congestion indication of > > the CE codepoint, an ECT codepoint MUST NOT be set in a packet > > unless the loss of that packet in the network would be detected by > > the end nodes and interpreted as an indication of congestion." > > (Section 5.2) > > > > o "A host MUST NOT set ECT on SYN or SYN-ACK packets." > > (Section 6.1.1) > > > > o "pure acknowledgement packets (e.g., packets that do not contain > > any accompanying data) MUST be sent with the not-ECT codepoint." > > (Section 6.1.4) > > > > o "This document specifies ECN-capable TCP implementations MUST NOT > > set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for > > retransmitted data packets, and that the TCP data receiver SHOULD > > ignore the ECN field on arriving data packets that are outside of > > the receiver's current window." (Section 6.1.5) > > > > o "the TCP data sender MUST NOT set either an ECT codepoint or the > > CWR bit on window probe packets." (Section 6.1.6) > > > > and noticing that only the text in 6.1.5 explicitly mentions the TCP data > receiver ignoring the "MUST NOT set" ECN field. I took a quick spin throu= gh > RFC 3168 searching for "ignore", but didn't see something that explicitly > covered the other cases. > > > > Because these are "MUST NOT set" constraints, I could imagine implementer= s > who never anticipated that an ECN(0) or ECN(1) would be set, and don't lo= ok > at the field (probably good), but I can also imagine implementers > validating that ECN(0) and ECN(1) are not set (probably bad). Do people > have any concerns about encountering "ECT values MUST be cleared" > implementations during this experiment? > > > > I suppose if some implementation that does this is deployed and you folks > run the experiment, then we'll know :D ... > > *[David>] I would leave this to the drafts/RFCS that describe the > experiments, as I expect implementers of the experiments to look there, a= nd > not at this process RFC (to be).* > > > > But I wonder if it's worth making that clear for receivers, since you're > updating RFC 3168 anyway? > > > > In this text, > > > > Random ECT values MUST NOT be used, as that may expose RTP to > > differences in network treatment of traffic marked with ECT(1) and > > ECT(0) and differences in associated endpoint congestion > > responses, > > > > is "Random ECT values" the right word? I could imagine this prohibiting > using ECT(0) and ECT(1) interchangeably, but if that's what's intended, I > could also imagine this prohibiting simply not explicitly setting the ECT > values at all, so missing your point. > > *[David>] Yes, =E2=80=9CRandom=E2=80=9D is the right word, as the text qu= oted from RFC > 6679 uses the word =E2=80=9Crandom=E2=80=9D so that is the correct word t= o use here, and > further explanation can be found in RFC 6679.* > > > > I'm looking at this text > > > > As a process memo that makes no changes to existing protocols, there > > are no protocol security considerations. > > > > and wondering if it's current with the rest of the document. Is "no > changes to existing protocols" still the right way to characterize this > draft? If you wanted to say > > > > As a process memo that only adds limitations to existing protocols, > there > > are no protocol security considerations. > > > > I'd be happy to believe you ... > > *[David>] I see the concern, and edited the text roughly as suggested, > plus moved a supporting sentence about security considerations for the > experiments up to join this sentence, so the new paragraph now reads:* > > > > As a process memo that only removes limitations on proposed experiments, > there are no protocol security considerations. Security considerations > for the > proposed experiments are discussed in the Internet-Drafts that propose > them. > > > > Thanks, > > > > Spencer > > > > > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Friday, August 4, 2017 7:29 PM > > To: i-d-announce@ietf.org > > Cc: tsvwg@ietf.org > > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.tx= t > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Area Working Group WG of the > > IETF. > > > > Title : Explicit Congestion Notification (ECN) > Experimentation > > Author : David Black > > Filename : draft-ietf-tsvwg-ecn-experimentation-04.txt > > Pages : 17 > > Date : 2017-08-04 > > > > Abstract: > > This memo updates RFC 3168, which specifies Explicit Congestion > > Notification (ECN) as a replacement for packet drops as indicators o= f > > network congestion. It relaxes restrictions in RFC 3168 that would > > otherwise hinder experimentation towards benefits beyond just remova= l > > of loss. This memo summarizes the anticipated areas of > > experimentation and updates RFC 3168 to enable experimentation in > > these areas. An Experimental RFC is required to take advantage of > > any of these enabling updates. In addition, this memo makes related > > updates to the ECN specifications for RTP in RFC 6679 and for DCCP i= n > > RFC 4341, RFC 4342 and RFC 5622. This memo also records the > > conclusion of the ECN Nonce experiment in RFC 3540, and provides the > > rationale for reclassification of RFC 3540 as Historic; this > > reclassification enables new experimental use of the ECT(1) > > codepoint. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn- > > experimentation-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-ecn- > experimentation-04 > > > > > > 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/ > > > --001a114166d4712a7f0557fa95cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,

Thanks, and welcome back :-)=

This mostly looks uber-reasonable, but I have one= reply on Alexa below.

On Wed, Aug 30, 2017 at 10:30 AM, Black, David &= lt;David.Black@de= ll.com> wrote:

Hi Spencer,

=C2=A0

Resurfacing from trying to take vacation in = August =E2=80=93 many thanks for this detailed review.=C2=A0 Comments inlin= e.

=C2=A0

I have a -05 ready to go if these changes ar= e ok with you.

=C2=A0

Thanks, --David

=C2=A0

From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com= ]
Sent: Monday, August 7, 2017 2:37 PM
To: Black, David <david.black@emc.com>
Cc: tsvwg@ietf.o= rg
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimen= tation-04.txt

=C2=A0

Hi, David,

=C2=A0

On Fri, Aug 4, 2017 at 6:31 PM, Black, David <David.Black@dell.com= > wrote:

As discussed in Prague, this is a small update to re= quest that IANA remove the registration of the TCP header flag used by RFC = 3540 (ECN Nonce).=C2=A0 =C2=A0Any reassignment of that flag will be handled= by the TCPM WG.=C2=A0 This update also changes the name of one of the areas of ECN experimentation to be different from the n= ame of the experiment proposed in that area.

Thanks, --David

=C2=A0

Hi, David,

=C2=A0

I really like this draft. Thanks to you and your ACK= list for your efforts - the result is very clear and complete.

=C2=A0

I have a few questions before I push the button on L= ast Call. They're minor enough that I don't think we need to wait f= or Gorry to be present for the discussion (of course, if people disagree, j= ust let me know).

=C2=A0

I tried to offer text for most of them, but you migh= t also answer them by saying that TSVWG needs a much smarter responsible AD= ;-) ...

=C2=A0

In this text,

=C2=A0

=C2=A0 =C2=A0An Experimental RFC MUST be published f= or any protocol

=C2=A0 =C2=A0or mechanism that takes advantage of an= y of these enabling updates.

=C2=A0 =C2=A0

I think I know what you're saying, but this form= ulation confuses me because it's placing a commitment on what a future = working group must do (like, what if the draft describing the experimental = protocol is incoherent - can the working group Just Say No, or can the authors say "but you have to request publicat= ion, because "An Experimental RFC MUST be published ...").=

[David>] The working group c= an Just Say No, and that outcome would be a =E2=80=9Cfeature=E2=80=9D =E2= =80=93 if the experimental protocol is problematic, then the experiment sho= uldn=E2=80=99t be run at scale in the Internet, and the WG will have done the right thing= by saying so.

=C2=A0

Is your point that any protocol or mechanism that ta= kes advantage of these enabling updates can't be Standards-Track?

[David>] No =E2=80=93 a Stan= dards-Track protocol RFC can simply update RFC 3168 (and any other RFCs tha= t it needs to) directly, and doesn=E2=80=99t need this draft=E2=80=99s perm= ission to do so, as the next sentence states =E2=80=A6=

=C2=A0

In this text,=C2=A0

=C2=A0

=C2=A0 =C2=A0There is no need to make changes for pr= otocols and mechanisms that

=C2=A0 =C2=A0are documented in Standards Track RFCs,= as any Standards Track RFC

=C2=A0 =C2=A0can update RFC 3168 without needing a s= tandards process exception.

=C2=A0

we've been talking using this terminology for at= least a year that I can remember, but I'm not totally sure that an ave= rage IESG would even approve an Experimental draft that updated a standards= -track RFC. How badly do you need to say this at all, since you're just confirming a well-understood fact that I thi= nk we all agree on?

[David>] This has been broug= ht up too many times in WG discussion of this draft to leave out, IMHO.

=C2=A0

In this text,

=C2=A0

=C2=A0 =C2=A0A study of the ECN behaviour of the Ale= xa top 1M web

=C2=A0 =C2=A0servers using 2014 data [Trammell15]=C2= =A0

=C2=A0 =C2=A0

I'm wondering whether it's useful to say &qu= ot;Alexa top 1M web servers" in an RFC that will probably last longer = than Alexa lasts ...

[David>] I view this as a = =E2=80=9Cshow your work=E2=80=9D item =E2=80=A6 this is the data that was u= sed at the time.


I'm sorry that my comment wasn't= clear. What I was asking was if there was any more description of Alexa (o= r for extra credit, a URL) so that a reader in ten years can do more than g= oogle "Alexa top 1M web server" to figure out what this is.
=

So I'm wondering if you need to qualify "top 1= M web servers" as "Alexa top 1M web servers", because I'= m thinking adding the adjective doesn't add as much as it takes away.= =C2=A0

It may be that the answer is "not = really", and that would be A Fine Answer, but I wanted to make sure yo= u understood what I was thinking, because it apparently wasn't what I w= as typing :-)

Either way, I'm ready for you to= send the updated version and have me initiate Last Call, and thanks for ho= rsing this through.

Spencer
=C2=A0
=

In this text,

=C2=A0

=C2=A0 =C2=A0Significantly more aggressive sender re= sponses to ECN

=C2=A0 =C2=A0are required to make effective use of s= uch shallow queues; Datacenter

=C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^

=C2=A0 =C2=A0TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provi= des an example. =C2=A0

=C2=A0 =C2=A0

I'm tangled up in passive tense ("who is re= quired to do what?"). Is it correct to say=C2=A0

=C2=A0

=C2=A0 =C2=A0Significantly more aggressive sender re= sponses to ECN

=C2=A0 =C2=A0are needed in order to make effective u= se of such shallow queues;=C2=A0

=C2=A0 =C2=A0Datacenter TCP (DCTCP) [I-D.ietf-tcpm-d= ctcp] provides an example. =C2=A0

=C2=A0

?

=C2=A0 =C2=A0[David>] Yes, change made.

= =C2=A0

I see that the draft uses both the terms "shall= ow queues" and "nearly empty queues". Do these terms mean th= e same thing? If so, perhaps it's worth either picking one term, or say= ing that they mean the same thing. Right now, I'm trying to imagine what the difference might be, since both phrases are used.<= u>

[David>] Good point, changed= to consistently use =E2=80=9Cvery shallow=E2=80=9D everywhere.<= /b>

=C2=A0

You folks are the experts on this stuff, but I'm= looking at this quoted text from RFC 3168

=C2=A0

=C2=A0RFC 3168 prohibits use of ECN for TCP control = packets and

=C2=A0 =C2=A0retransmitted packets in a number of pl= aces:

=C2=A0

=C2=A0 =C2=A0o =C2=A0"To ensure the reliable de= livery of the congestion indication of

=C2=A0 =C2=A0 =C2=A0 the CE codepoint, an ECT codepo= int MUST NOT be set in a packet

=C2=A0 =C2=A0 =C2=A0 unless the loss of that packet = in the network would be detected by

=C2=A0 =C2=A0 =C2=A0 the end nodes and interpreted a= s an indication of congestion."

=C2=A0 =C2=A0 =C2=A0 (Section 5.2)

=C2=A0

=C2=A0 =C2=A0o =C2=A0"A host MUST NOT set ECT o= n SYN or SYN-ACK packets."

=C2=A0 =C2=A0 =C2=A0 (Section 6.1.1)

=C2=A0

=C2=A0 =C2=A0o =C2=A0"pure acknowledgement pack= ets (e.g., packets that do not contain

=C2=A0 =C2=A0 =C2=A0 any accompanying data) MUST be = sent with the not-ECT codepoint."

=C2=A0 =C2=A0 =C2=A0 (Section 6.1.4)

=C2=A0

=C2=A0 =C2=A0o =C2=A0"This document specifies E= CN-capable TCP implementations MUST NOT

=C2=A0 =C2=A0 =C2=A0 set either ECT codepoint (ECT(0= ) or ECT(1)) in the IP header for

=C2=A0 =C2=A0 =C2=A0 retransmitted data packets, and= that the TCP data receiver SHOULD

=C2=A0 =C2=A0 =C2=A0 ignore the ECN field on arrivin= g data packets that are outside of

=C2=A0 =C2=A0 =C2=A0 the receiver's current wind= ow." =C2=A0(Section 6.1.5)

=C2=A0

=C2=A0 =C2=A0o =C2=A0"the TCP data sender MUST = NOT set either an ECT codepoint or the

=C2=A0 =C2=A0 =C2=A0 CWR bit on window probe packets= ." =C2=A0(Section 6.1.6)

=C2=A0 =C2=A0 =C2=A0=C2=A0

and noticing that only the text in 6.1.5 explicitly = mentions the TCP data receiver ignoring the "MUST NOT set" ECN fi= eld. I took a quick spin through RFC 3168 searching for "ignore",= but didn't see something that explicitly covered the other cases.

=C2=A0

Because these are "MUST NOT set" constrain= ts, I could imagine implementers who never anticipated that an ECN(0) or EC= N(1) would be set, and don't look at the field (probably good), but I c= an also imagine implementers validating that ECN(0) and ECN(1) are not set (probably bad). Do people have any concerns about e= ncountering "ECT values MUST be cleared" implementations during t= his experiment?

=C2=A0

I suppose if some implementation that does this is d= eployed and you folks run the experiment, then we'll know :D ...=

[David>] I would leave this = to the drafts/RFCS that describe the experiments, as I expect implementers = of the experiments to look there, and not at this process RFC (to be).

=C2=A0

But I wonder if it's worth making that clear for= receivers, since you're updating RFC 3168 anyway?

=C2=A0

In this text,

=C2=A0

=C2=A0 =C2=A0 =C2=A0 Random ECT values MUST NOT be u= sed, as that may expose RTP to

=C2=A0 =C2=A0 =C2=A0 differences in network treatmen= t of traffic marked with ECT(1) and

=C2=A0 =C2=A0 =C2=A0 ECT(0) and differences in assoc= iated endpoint congestion

=C2=A0 =C2=A0 =C2=A0 responses,

=C2=A0 =C2=A0 =C2=A0=C2=A0

is "Random ECT values" the right word? I c= ould imagine this prohibiting using ECT(0) and ECT(1) interchangeably, but = if that's what's intended, I could also imagine this prohibiting si= mply not explicitly setting the ECT values at all, so missing your point.

[David>] Yes, =E2=80=9CRando= m=E2=80=9D is the right word, as the text quoted from RFC 6679 uses the wor= d =E2=80=9Crandom=E2=80=9D so that is the correct word to use here, and fur= ther explanation can be found in RFC 6679.

=C2=A0

I'm looking at this text

=C2=A0

=C2=A0 =C2=A0As a process memo that makes no changes= to existing protocols, there

=C2=A0 =C2=A0are no protocol security considerations= .

=C2=A0 =C2=A0

and wondering if it's current with the rest of t= he document. Is "no changes to existing protocols" still the righ= t way to characterize this draft? If you wanted to say

=C2=A0

=C2=A0 =C2=A0As a process memo that only adds limita= tions to existing protocols, there

=C2=A0 =C2=A0are no protocol security considerations= .

=C2=A0 =C2=A0

I'd be happy to believe you ...

[David>] I see the concern, = and edited the text roughly as suggested, plus moved a supporting sentence = about security considerations for the experiments up to join this sentence, so the new paragraph now reads:

=C2=A0

As a process m= emo that only removes limitations on proposed experiments,
there are no protocol security considerations.=C2=A0 Security consideration= s for the
proposed experiments are discussed in the Internet-Drafts that propose them= .

=C2=A0

Thanks,

=C2=A0

Spencer=C2=A0

=C2=A0


> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Friday, August 4, 2017 7:29 PM
> To: i-d-ann= ounce@ietf.org
> Cc: tsvwg@ietf.org=
> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation= -04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Transport Area Working Group WG of th= e
> IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Explicit Congestion Notification (ECN) Experimentation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : David Black
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tsvwg-ecn-experimentation-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 17
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-08-04
>
> Abstract:
>=C2=A0 =C2=A0 This memo updates RFC 3168, which specifies Explicit Cong= estion
>=C2=A0 =C2=A0 Notification (ECN) as a replacement for packet drops as i= ndicators of
>=C2=A0 =C2=A0 network congestion.=C2=A0 It relaxes restrictions in RFC = 3168 that would
>=C2=A0 =C2=A0 otherwise hinder experimentation towards benefits beyond = just removal
>=C2=A0 =C2=A0 of loss.=C2=A0 This memo summarizes the anticipated areas= of
>=C2=A0 =C2=A0 experimentation and updates RFC 3168 to enable experiment= ation in
>=C2=A0 =C2=A0 these areas.=C2=A0 An Experimental RFC is required to tak= e advantage of
>=C2=A0 =C2=A0 any of these enabling updates.=C2=A0 In addition, this me= mo makes related
>=C2=A0 =C2=A0 updates to the ECN specifications for RTP in RFC 6679 and= for DCCP in
>=C2=A0 =C2=A0 RFC 4341, RFC 4342 and RFC 5622.=C2=A0 This memo also rec= ords the
>=C2=A0 =C2=A0 conclusion of the ECN Nonce experiment in RFC 3540, and p= rovides the
>=C2=A0 =C2=A0 rationale for reclassification of RFC 3540 as Historic; t= his
>=C2=A0 =C2=A0 reclassification enables new experimental use of the ECT(= 1)
>=C2=A0 =C2=A0 codepoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimenta= tion/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-= 04
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-
> experimentation-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-ecn-experime= ntation-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/

=C2=A0


--001a114166d4712a7f0557fa95cb-- From nobody Wed Aug 30 09:10:12 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB513213D for ; Wed, 30 Aug 2017 09:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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=dell.com header.b=lFLtx9xY; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=jBBan24e 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 2MhlQ_1hsQXZ for ; Wed, 30 Aug 2017 09:10:07 -0700 (PDT) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 7A214132055 for ; Wed, 30 Aug 2017 09:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1504109269; x=1535645269; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=s+l76YTMfr3piTomBSTb/EnL7UpNc1uvn32HIYpSirc=; b=lFLtx9xY7ydIYfi/WXztqBHvpqV3yahWh3hLcF7/sNmvewnFUtBlegld wRNEIh5qd7MQPFqQZVcbEmATsv0NZKTpRlZqchyEbmSMeOVctc9O5cZ78 HKrxuGCf91KftQ7GLIW6dVxhDboXtKjqhu47Qs02lcOhE3V+3xBqGCXW6 w=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 11:07:49 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 22:01:18 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7UG9s7s030856 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Aug 2017 12:10:04 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v7UG9s7s030856 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1504109404; bh=TbTSOEpL9Rk6p69oJuMQX0tEnmA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=jBBan24eGEuCaNZ+952ago7oARRCG/IXEZJqUxMKW/vNpBT+PS58+Lg420j3CKW/W oqed+LqCA+8F3lvvZ5cPvq2/5ZACe9JDnw8ot1dnISHZioQdUqAEhHE1vdJLyGXhNz uqUjxJzc1iTlX0zMPHahr0m7dNoTzSTuo2RfBSiM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v7UG9s7s030856 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd06.lss.emc.com (RSA Interceptor); Wed, 30 Aug 2017 12:09:01 -0400 Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7UG9jrG005385 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 30 Aug 2017 12:09:45 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 12:09:45 -0400 To: Spencer Dawkins at IETF CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt Thread-Index: AQHTD6wilfNp2RGXa0qgnZaxsTfJo6KdHsewgABWRID//8BR0A== Date: Wed, 30 Aug 2017 16:09:44 +0000 Message-ID: References: <150188933148.18701.4807220216565950086@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.2.174] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FC2AB02MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:10:11 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FC2AB02MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIEnigJlsbCBkcm9wIOKAnEFsZXhh4oCdIGFuZCB1cGxvYWQgdGhlIHJlc3VsdC4NCg0KVGhh bmtzLCAtLURhdmlkDQoNCkZyb206IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3Bl bmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMCwg MjAxNyAxMTo1NyBBTQ0KVG86IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4NCkNj OiB0c3Z3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA0LnR4dA0KDQpIaSwgRGF2aWQsDQoNClRo YW5rcywgYW5kIHdlbGNvbWUgYmFjayA6LSkNCg0KVGhpcyBtb3N0bHkgbG9va3MgdWJlci1yZWFz b25hYmxlLCBidXQgSSBoYXZlIG9uZSByZXBseSBvbiBBbGV4YSBiZWxvdy4NCg0KT24gV2VkLCBB dWcgMzAsIDIwMTcgYXQgMTA6MzAgQU0sIEJsYWNrLCBEYXZpZCA8RGF2aWQuQmxhY2tAZGVsbC5j b208bWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tPj4gd3JvdGU6DQpIaSBTcGVuY2VyLA0KDQpS ZXN1cmZhY2luZyBmcm9tIHRyeWluZyB0byB0YWtlIHZhY2F0aW9uIGluIEF1Z3VzdCDigJMgbWFu eSB0aGFua3MgZm9yIHRoaXMgZGV0YWlsZWQgcmV2aWV3LiAgQ29tbWVudHMgaW5saW5lLg0KDQpJ IGhhdmUgYSAtMDUgcmVhZHkgdG8gZ28gaWYgdGhlc2UgY2hhbmdlcyBhcmUgb2sgd2l0aCB5b3Uu DQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFp bHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1haWx0bzpzcGVuY2VyZGF3a2lucy5p ZXRmQGdtYWlsLmNvbT5dDQpTZW50OiBNb25kYXksIEF1Z3VzdCA3LCAyMDE3IDI6MzcgUE0NClRv OiBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb208bWFpbHRvOmRhdmlkLmJsYWNrQGVt Yy5jb20+Pg0KQ2M6IHRzdndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbdHN2d2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1l bnRhdGlvbi0wNC50eHQNCg0KSGksIERhdmlkLA0KDQpPbiBGcmksIEF1ZyA0LCAyMDE3IGF0IDY6 MzEgUE0sIEJsYWNrLCBEYXZpZCA8RGF2aWQuQmxhY2tAZGVsbC5jb208bWFpbHRvOkRhdmlkLkJs YWNrQGRlbGwuY29tPj4gd3JvdGU6DQpBcyBkaXNjdXNzZWQgaW4gUHJhZ3VlLCB0aGlzIGlzIGEg c21hbGwgdXBkYXRlIHRvIHJlcXVlc3QgdGhhdCBJQU5BIHJlbW92ZSB0aGUgcmVnaXN0cmF0aW9u IG9mIHRoZSBUQ1AgaGVhZGVyIGZsYWcgdXNlZCBieSBSRkMgMzU0MCAoRUNOIE5vbmNlKS4gICBB bnkgcmVhc3NpZ25tZW50IG9mIHRoYXQgZmxhZyB3aWxsIGJlIGhhbmRsZWQgYnkgdGhlIFRDUE0g V0cuICBUaGlzIHVwZGF0ZSBhbHNvIGNoYW5nZXMgdGhlIG5hbWUgb2Ygb25lIG9mIHRoZSBhcmVh cyBvZiBFQ04gZXhwZXJpbWVudGF0aW9uIHRvIGJlIGRpZmZlcmVudCBmcm9tIHRoZSBuYW1lIG9m IHRoZSBleHBlcmltZW50IHByb3Bvc2VkIGluIHRoYXQgYXJlYS4NCg0KVGhhbmtzLCAtLURhdmlk DQoNCkhpLCBEYXZpZCwNCg0KSSByZWFsbHkgbGlrZSB0aGlzIGRyYWZ0LiBUaGFua3MgdG8geW91 IGFuZCB5b3VyIEFDSyBsaXN0IGZvciB5b3VyIGVmZm9ydHMgLSB0aGUgcmVzdWx0IGlzIHZlcnkg Y2xlYXIgYW5kIGNvbXBsZXRlLg0KDQpJIGhhdmUgYSBmZXcgcXVlc3Rpb25zIGJlZm9yZSBJIHB1 c2ggdGhlIGJ1dHRvbiBvbiBMYXN0IENhbGwuIFRoZXkncmUgbWlub3IgZW5vdWdoIHRoYXQgSSBk b24ndCB0aGluayB3ZSBuZWVkIHRvIHdhaXQgZm9yIEdvcnJ5IHRvIGJlIHByZXNlbnQgZm9yIHRo ZSBkaXNjdXNzaW9uIChvZiBjb3Vyc2UsIGlmIHBlb3BsZSBkaXNhZ3JlZSwganVzdCBsZXQgbWUg a25vdykuDQoNCkkgdHJpZWQgdG8gb2ZmZXIgdGV4dCBmb3IgbW9zdCBvZiB0aGVtLCBidXQgeW91 IG1pZ2h0IGFsc28gYW5zd2VyIHRoZW0gYnkgc2F5aW5nIHRoYXQgVFNWV0cgbmVlZHMgYSBtdWNo IHNtYXJ0ZXIgcmVzcG9uc2libGUgQUQgOy0pIC4uLg0KDQpJbiB0aGlzIHRleHQsDQoNCiAgIEFu IEV4cGVyaW1lbnRhbCBSRkMgTVVTVCBiZSBwdWJsaXNoZWQgZm9yIGFueSBwcm90b2NvbA0KICAg b3IgbWVjaGFuaXNtIHRoYXQgdGFrZXMgYWR2YW50YWdlIG9mIGFueSBvZiB0aGVzZSBlbmFibGlu ZyB1cGRhdGVzLg0KDQpJIHRoaW5rIEkga25vdyB3aGF0IHlvdSdyZSBzYXlpbmcsIGJ1dCB0aGlz IGZvcm11bGF0aW9uIGNvbmZ1c2VzIG1lIGJlY2F1c2UgaXQncyBwbGFjaW5nIGEgY29tbWl0bWVu dCBvbiB3aGF0IGEgZnV0dXJlIHdvcmtpbmcgZ3JvdXAgbXVzdCBkbyAobGlrZSwgd2hhdCBpZiB0 aGUgZHJhZnQgZGVzY3JpYmluZyB0aGUgZXhwZXJpbWVudGFsIHByb3RvY29sIGlzIGluY29oZXJl bnQgLSBjYW4gdGhlIHdvcmtpbmcgZ3JvdXAgSnVzdCBTYXkgTm8sIG9yIGNhbiB0aGUgYXV0aG9y cyBzYXkgImJ1dCB5b3UgaGF2ZSB0byByZXF1ZXN0IHB1YmxpY2F0aW9uLCBiZWNhdXNlICJBbiBF eHBlcmltZW50YWwgUkZDIE1VU1QgYmUgcHVibGlzaGVkIC4uLiIpLg0KW0RhdmlkPl0gVGhlIHdv cmtpbmcgZ3JvdXAgY2FuIEp1c3QgU2F5IE5vLCBhbmQgdGhhdCBvdXRjb21lIHdvdWxkIGJlIGEg 4oCcZmVhdHVyZeKAnSDigJMgaWYgdGhlIGV4cGVyaW1lbnRhbCBwcm90b2NvbCBpcyBwcm9ibGVt YXRpYywgdGhlbiB0aGUgZXhwZXJpbWVudCBzaG91bGRu4oCZdCBiZSBydW4gYXQgc2NhbGUgaW4g dGhlIEludGVybmV0LCBhbmQgdGhlIFdHIHdpbGwgaGF2ZSBkb25lIHRoZSByaWdodCB0aGluZyBi eSBzYXlpbmcgc28uDQoNCklzIHlvdXIgcG9pbnQgdGhhdCBhbnkgcHJvdG9jb2wgb3IgbWVjaGFu aXNtIHRoYXQgdGFrZXMgYWR2YW50YWdlIG9mIHRoZXNlIGVuYWJsaW5nIHVwZGF0ZXMgY2FuJ3Qg YmUgU3RhbmRhcmRzLVRyYWNrPw0KW0RhdmlkPl0gTm8g4oCTIGEgU3RhbmRhcmRzLVRyYWNrIHBy b3RvY29sIFJGQyBjYW4gc2ltcGx5IHVwZGF0ZSBSRkMgMzE2OCAoYW5kIGFueSBvdGhlciBSRkNz IHRoYXQgaXQgbmVlZHMgdG8pIGRpcmVjdGx5LCBhbmQgZG9lc27igJl0IG5lZWQgdGhpcyBkcmFm dOKAmXMgcGVybWlzc2lvbiB0byBkbyBzbywgYXMgdGhlIG5leHQgc2VudGVuY2Ugc3RhdGVzIOKA pg0KDQpJbiB0aGlzIHRleHQsDQoNCiAgIFRoZXJlIGlzIG5vIG5lZWQgdG8gbWFrZSBjaGFuZ2Vz IGZvciBwcm90b2NvbHMgYW5kIG1lY2hhbmlzbXMgdGhhdA0KICAgYXJlIGRvY3VtZW50ZWQgaW4g U3RhbmRhcmRzIFRyYWNrIFJGQ3MsIGFzIGFueSBTdGFuZGFyZHMgVHJhY2sgUkZDDQogICBjYW4g dXBkYXRlIFJGQyAzMTY4IHdpdGhvdXQgbmVlZGluZyBhIHN0YW5kYXJkcyBwcm9jZXNzIGV4Y2Vw dGlvbi4NCg0Kd2UndmUgYmVlbiB0YWxraW5nIHVzaW5nIHRoaXMgdGVybWlub2xvZ3kgZm9yIGF0 IGxlYXN0IGEgeWVhciB0aGF0IEkgY2FuIHJlbWVtYmVyLCBidXQgSSdtIG5vdCB0b3RhbGx5IHN1 cmUgdGhhdCBhbiBhdmVyYWdlIElFU0cgd291bGQgZXZlbiBhcHByb3ZlIGFuIEV4cGVyaW1lbnRh bCBkcmFmdCB0aGF0IHVwZGF0ZWQgYSBzdGFuZGFyZHMtdHJhY2sgUkZDLiBIb3cgYmFkbHkgZG8g eW91IG5lZWQgdG8gc2F5IHRoaXMgYXQgYWxsLCBzaW5jZSB5b3UncmUganVzdCBjb25maXJtaW5n IGEgd2VsbC11bmRlcnN0b29kIGZhY3QgdGhhdCBJIHRoaW5rIHdlIGFsbCBhZ3JlZSBvbj8NCltE YXZpZD5dIFRoaXMgaGFzIGJlZW4gYnJvdWdodCB1cCB0b28gbWFueSB0aW1lcyBpbiBXRyBkaXNj dXNzaW9uIG9mIHRoaXMgZHJhZnQgdG8gbGVhdmUgb3V0LCBJTUhPLg0KDQpJbiB0aGlzIHRleHQs DQoNCiAgIEEgc3R1ZHkgb2YgdGhlIEVDTiBiZWhhdmlvdXIgb2YgdGhlIEFsZXhhIHRvcCAxTSB3 ZWINCiAgIHNlcnZlcnMgdXNpbmcgMjAxNCBkYXRhIFtUcmFtbWVsbDE1XQ0KDQpJJ20gd29uZGVy aW5nIHdoZXRoZXIgaXQncyB1c2VmdWwgdG8gc2F5ICJBbGV4YSB0b3AgMU0gd2ViIHNlcnZlcnMi IGluIGFuIFJGQyB0aGF0IHdpbGwgcHJvYmFibHkgbGFzdCBsb25nZXIgdGhhbiBBbGV4YSBsYXN0 cyAuLi4NCltEYXZpZD5dIEkgdmlldyB0aGlzIGFzIGEg4oCcc2hvdyB5b3VyIHdvcmvigJ0gaXRl bSDigKYgdGhpcyBpcyB0aGUgZGF0YSB0aGF0IHdhcyB1c2VkIGF0IHRoZSB0aW1lLg0KDQpJJ20g c29ycnkgdGhhdCBteSBjb21tZW50IHdhc24ndCBjbGVhci4gV2hhdCBJIHdhcyBhc2tpbmcgd2Fz IGlmIHRoZXJlIHdhcyBhbnkgbW9yZSBkZXNjcmlwdGlvbiBvZiBBbGV4YSAob3IgZm9yIGV4dHJh IGNyZWRpdCwgYSBVUkwpIHNvIHRoYXQgYSByZWFkZXIgaW4gdGVuIHllYXJzIGNhbiBkbyBtb3Jl IHRoYW4gZ29vZ2xlICJBbGV4YSB0b3AgMU0gd2ViIHNlcnZlciIgdG8gZmlndXJlIG91dCB3aGF0 IHRoaXMgaXMuDQoNClNvIEknbSB3b25kZXJpbmcgaWYgeW91IG5lZWQgdG8gcXVhbGlmeSAidG9w IDFNIHdlYiBzZXJ2ZXJzIiBhcyAiQWxleGEgdG9wIDFNIHdlYiBzZXJ2ZXJzIiwgYmVjYXVzZSBJ J20gdGhpbmtpbmcgYWRkaW5nIHRoZSBhZGplY3RpdmUgZG9lc24ndCBhZGQgYXMgbXVjaCBhcyBp dCB0YWtlcyBhd2F5Lg0KDQpJdCBtYXkgYmUgdGhhdCB0aGUgYW5zd2VyIGlzICJub3QgcmVhbGx5 IiwgYW5kIHRoYXQgd291bGQgYmUgQSBGaW5lIEFuc3dlciwgYnV0IEkgd2FudGVkIHRvIG1ha2Ug c3VyZSB5b3UgdW5kZXJzdG9vZCB3aGF0IEkgd2FzIHRoaW5raW5nLCBiZWNhdXNlIGl0IGFwcGFy ZW50bHkgd2Fzbid0IHdoYXQgSSB3YXMgdHlwaW5nIDotKQ0KDQpFaXRoZXIgd2F5LCBJJ20gcmVh ZHkgZm9yIHlvdSB0byBzZW5kIHRoZSB1cGRhdGVkIHZlcnNpb24gYW5kIGhhdmUgbWUgaW5pdGlh dGUgTGFzdCBDYWxsLCBhbmQgdGhhbmtzIGZvciBob3JzaW5nIHRoaXMgdGhyb3VnaC4NCg0KU3Bl bmNlcg0KDQpJbiB0aGlzIHRleHQsDQoNCiAgIFNpZ25pZmljYW50bHkgbW9yZSBhZ2dyZXNzaXZl IHNlbmRlciByZXNwb25zZXMgdG8gRUNODQogICBhcmUgcmVxdWlyZWQgdG8gbWFrZSBlZmZlY3Rp dmUgdXNlIG9mIHN1Y2ggc2hhbGxvdyBxdWV1ZXM7IERhdGFjZW50ZXINCiAgICAgICBeXl5eXl5e Xg0KICAgVENQIChEQ1RDUCkgW0ktRC5pZXRmLXRjcG0tZGN0Y3BdIHByb3ZpZGVzIGFuIGV4YW1w bGUuDQoNCkknbSB0YW5nbGVkIHVwIGluIHBhc3NpdmUgdGVuc2UgKCJ3aG8gaXMgcmVxdWlyZWQg dG8gZG8gd2hhdD8iKS4gSXMgaXQgY29ycmVjdCB0byBzYXkNCg0KICAgU2lnbmlmaWNhbnRseSBt b3JlIGFnZ3Jlc3NpdmUgc2VuZGVyIHJlc3BvbnNlcyB0byBFQ04NCiAgIGFyZSBuZWVkZWQgaW4g b3JkZXIgdG8gbWFrZSBlZmZlY3RpdmUgdXNlIG9mIHN1Y2ggc2hhbGxvdyBxdWV1ZXM7DQogICBE YXRhY2VudGVyIFRDUCAoRENUQ1ApIFtJLUQuaWV0Zi10Y3BtLWRjdGNwXSBwcm92aWRlcyBhbiBl eGFtcGxlLg0KDQo/DQogICBbRGF2aWQ+XSBZZXMsIGNoYW5nZSBtYWRlLg0KDQpJIHNlZSB0aGF0 IHRoZSBkcmFmdCB1c2VzIGJvdGggdGhlIHRlcm1zICJzaGFsbG93IHF1ZXVlcyIgYW5kICJuZWFy bHkgZW1wdHkgcXVldWVzIi4gRG8gdGhlc2UgdGVybXMgbWVhbiB0aGUgc2FtZSB0aGluZz8gSWYg c28sIHBlcmhhcHMgaXQncyB3b3J0aCBlaXRoZXIgcGlja2luZyBvbmUgdGVybSwgb3Igc2F5aW5n IHRoYXQgdGhleSBtZWFuIHRoZSBzYW1lIHRoaW5nLiBSaWdodCBub3csIEknbSB0cnlpbmcgdG8g aW1hZ2luZSB3aGF0IHRoZSBkaWZmZXJlbmNlIG1pZ2h0IGJlLCBzaW5jZSBib3RoIHBocmFzZXMg YXJlIHVzZWQuDQpbRGF2aWQ+XSBHb29kIHBvaW50LCBjaGFuZ2VkIHRvIGNvbnNpc3RlbnRseSB1 c2Ug4oCcdmVyeSBzaGFsbG934oCdIGV2ZXJ5d2hlcmUuDQoNCllvdSBmb2xrcyBhcmUgdGhlIGV4 cGVydHMgb24gdGhpcyBzdHVmZiwgYnV0IEknbSBsb29raW5nIGF0IHRoaXMgcXVvdGVkIHRleHQg ZnJvbSBSRkMgMzE2OA0KDQogUkZDIDMxNjggcHJvaGliaXRzIHVzZSBvZiBFQ04gZm9yIFRDUCBj b250cm9sIHBhY2tldHMgYW5kDQogICByZXRyYW5zbWl0dGVkIHBhY2tldHMgaW4gYSBudW1iZXIg b2YgcGxhY2VzOg0KDQogICBvICAiVG8gZW5zdXJlIHRoZSByZWxpYWJsZSBkZWxpdmVyeSBvZiB0 aGUgY29uZ2VzdGlvbiBpbmRpY2F0aW9uIG9mDQogICAgICB0aGUgQ0UgY29kZXBvaW50LCBhbiBF Q1QgY29kZXBvaW50IE1VU1QgTk9UIGJlIHNldCBpbiBhIHBhY2tldA0KICAgICAgdW5sZXNzIHRo ZSBsb3NzIG9mIHRoYXQgcGFja2V0IGluIHRoZSBuZXR3b3JrIHdvdWxkIGJlIGRldGVjdGVkIGJ5 DQogICAgICB0aGUgZW5kIG5vZGVzIGFuZCBpbnRlcnByZXRlZCBhcyBhbiBpbmRpY2F0aW9uIG9m IGNvbmdlc3Rpb24uIg0KICAgICAgKFNlY3Rpb24gNS4yKQ0KDQogICBvICAiQSBob3N0IE1VU1Qg Tk9UIHNldCBFQ1Qgb24gU1lOIG9yIFNZTi1BQ0sgcGFja2V0cy4iDQogICAgICAoU2VjdGlvbiA2 LjEuMSkNCg0KICAgbyAgInB1cmUgYWNrbm93bGVkZ2VtZW50IHBhY2tldHMgKGUuZy4sIHBhY2tl dHMgdGhhdCBkbyBub3QgY29udGFpbg0KICAgICAgYW55IGFjY29tcGFueWluZyBkYXRhKSBNVVNU IGJlIHNlbnQgd2l0aCB0aGUgbm90LUVDVCBjb2RlcG9pbnQuIg0KICAgICAgKFNlY3Rpb24gNi4x LjQpDQoNCiAgIG8gICJUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBFQ04tY2FwYWJsZSBUQ1AgaW1w bGVtZW50YXRpb25zIE1VU1QgTk9UDQogICAgICBzZXQgZWl0aGVyIEVDVCBjb2RlcG9pbnQgKEVD VCgwKSBvciBFQ1QoMSkpIGluIHRoZSBJUCBoZWFkZXIgZm9yDQogICAgICByZXRyYW5zbWl0dGVk IGRhdGEgcGFja2V0cywgYW5kIHRoYXQgdGhlIFRDUCBkYXRhIHJlY2VpdmVyIFNIT1VMRA0KICAg ICAgaWdub3JlIHRoZSBFQ04gZmllbGQgb24gYXJyaXZpbmcgZGF0YSBwYWNrZXRzIHRoYXQgYXJl IG91dHNpZGUgb2YNCiAgICAgIHRoZSByZWNlaXZlcidzIGN1cnJlbnQgd2luZG93LiIgIChTZWN0 aW9uIDYuMS41KQ0KDQogICBvICAidGhlIFRDUCBkYXRhIHNlbmRlciBNVVNUIE5PVCBzZXQgZWl0 aGVyIGFuIEVDVCBjb2RlcG9pbnQgb3IgdGhlDQogICAgICBDV1IgYml0IG9uIHdpbmRvdyBwcm9i ZSBwYWNrZXRzLiIgIChTZWN0aW9uIDYuMS42KQ0KDQphbmQgbm90aWNpbmcgdGhhdCBvbmx5IHRo ZSB0ZXh0IGluIDYuMS41IGV4cGxpY2l0bHkgbWVudGlvbnMgdGhlIFRDUCBkYXRhIHJlY2VpdmVy IGlnbm9yaW5nIHRoZSAiTVVTVCBOT1Qgc2V0IiBFQ04gZmllbGQuIEkgdG9vayBhIHF1aWNrIHNw aW4gdGhyb3VnaCBSRkMgMzE2OCBzZWFyY2hpbmcgZm9yICJpZ25vcmUiLCBidXQgZGlkbid0IHNl ZSBzb21ldGhpbmcgdGhhdCBleHBsaWNpdGx5IGNvdmVyZWQgdGhlIG90aGVyIGNhc2VzLg0KDQpC ZWNhdXNlIHRoZXNlIGFyZSAiTVVTVCBOT1Qgc2V0IiBjb25zdHJhaW50cywgSSBjb3VsZCBpbWFn aW5lIGltcGxlbWVudGVycyB3aG8gbmV2ZXIgYW50aWNpcGF0ZWQgdGhhdCBhbiBFQ04oMCkgb3Ig RUNOKDEpIHdvdWxkIGJlIHNldCwgYW5kIGRvbid0IGxvb2sgYXQgdGhlIGZpZWxkIChwcm9iYWJs eSBnb29kKSwgYnV0IEkgY2FuIGFsc28gaW1hZ2luZSBpbXBsZW1lbnRlcnMgdmFsaWRhdGluZyB0 aGF0IEVDTigwKSBhbmQgRUNOKDEpIGFyZSBub3Qgc2V0IChwcm9iYWJseSBiYWQpLiBEbyBwZW9w bGUgaGF2ZSBhbnkgY29uY2VybnMgYWJvdXQgZW5jb3VudGVyaW5nICJFQ1QgdmFsdWVzIE1VU1Qg YmUgY2xlYXJlZCIgaW1wbGVtZW50YXRpb25zIGR1cmluZyB0aGlzIGV4cGVyaW1lbnQ/DQoNCkkg c3VwcG9zZSBpZiBzb21lIGltcGxlbWVudGF0aW9uIHRoYXQgZG9lcyB0aGlzIGlzIGRlcGxveWVk IGFuZCB5b3UgZm9sa3MgcnVuIHRoZSBleHBlcmltZW50LCB0aGVuIHdlJ2xsIGtub3cgOkQgLi4u DQpbRGF2aWQ+XSBJIHdvdWxkIGxlYXZlIHRoaXMgdG8gdGhlIGRyYWZ0cy9SRkNTIHRoYXQgZGVz Y3JpYmUgdGhlIGV4cGVyaW1lbnRzLCBhcyBJIGV4cGVjdCBpbXBsZW1lbnRlcnMgb2YgdGhlIGV4 cGVyaW1lbnRzIHRvIGxvb2sgdGhlcmUsIGFuZCBub3QgYXQgdGhpcyBwcm9jZXNzIFJGQyAodG8g YmUpLg0KDQpCdXQgSSB3b25kZXIgaWYgaXQncyB3b3J0aCBtYWtpbmcgdGhhdCBjbGVhciBmb3Ig cmVjZWl2ZXJzLCBzaW5jZSB5b3UncmUgdXBkYXRpbmcgUkZDIDMxNjggYW55d2F5Pw0KDQpJbiB0 aGlzIHRleHQsDQoNCiAgICAgIFJhbmRvbSBFQ1QgdmFsdWVzIE1VU1QgTk9UIGJlIHVzZWQsIGFz IHRoYXQgbWF5IGV4cG9zZSBSVFAgdG8NCiAgICAgIGRpZmZlcmVuY2VzIGluIG5ldHdvcmsgdHJl YXRtZW50IG9mIHRyYWZmaWMgbWFya2VkIHdpdGggRUNUKDEpIGFuZA0KICAgICAgRUNUKDApIGFu ZCBkaWZmZXJlbmNlcyBpbiBhc3NvY2lhdGVkIGVuZHBvaW50IGNvbmdlc3Rpb24NCiAgICAgIHJl c3BvbnNlcywNCg0KaXMgIlJhbmRvbSBFQ1QgdmFsdWVzIiB0aGUgcmlnaHQgd29yZD8gSSBjb3Vs ZCBpbWFnaW5lIHRoaXMgcHJvaGliaXRpbmcgdXNpbmcgRUNUKDApIGFuZCBFQ1QoMSkgaW50ZXJj aGFuZ2VhYmx5LCBidXQgaWYgdGhhdCdzIHdoYXQncyBpbnRlbmRlZCwgSSBjb3VsZCBhbHNvIGlt YWdpbmUgdGhpcyBwcm9oaWJpdGluZyBzaW1wbHkgbm90IGV4cGxpY2l0bHkgc2V0dGluZyB0aGUg RUNUIHZhbHVlcyBhdCBhbGwsIHNvIG1pc3NpbmcgeW91ciBwb2ludC4NCltEYXZpZD5dIFllcywg 4oCcUmFuZG9t4oCdIGlzIHRoZSByaWdodCB3b3JkLCBhcyB0aGUgdGV4dCBxdW90ZWQgZnJvbSBS RkMgNjY3OSB1c2VzIHRoZSB3b3JkIOKAnHJhbmRvbeKAnSBzbyB0aGF0IGlzIHRoZSBjb3JyZWN0 IHdvcmQgdG8gdXNlIGhlcmUsIGFuZCBmdXJ0aGVyIGV4cGxhbmF0aW9uIGNhbiBiZSBmb3VuZCBp biBSRkMgNjY3OS4NCg0KSSdtIGxvb2tpbmcgYXQgdGhpcyB0ZXh0DQoNCiAgIEFzIGEgcHJvY2Vz cyBtZW1vIHRoYXQgbWFrZXMgbm8gY2hhbmdlcyB0byBleGlzdGluZyBwcm90b2NvbHMsIHRoZXJl DQogICBhcmUgbm8gcHJvdG9jb2wgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCmFuZCB3b25k ZXJpbmcgaWYgaXQncyBjdXJyZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBJcyAi bm8gY2hhbmdlcyB0byBleGlzdGluZyBwcm90b2NvbHMiIHN0aWxsIHRoZSByaWdodCB3YXkgdG8g Y2hhcmFjdGVyaXplIHRoaXMgZHJhZnQ/IElmIHlvdSB3YW50ZWQgdG8gc2F5DQoNCiAgIEFzIGEg cHJvY2VzcyBtZW1vIHRoYXQgb25seSBhZGRzIGxpbWl0YXRpb25zIHRvIGV4aXN0aW5nIHByb3Rv Y29scywgdGhlcmUNCiAgIGFyZSBubyBwcm90b2NvbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4N Cg0KSSdkIGJlIGhhcHB5IHRvIGJlbGlldmUgeW91IC4uLg0KW0RhdmlkPl0gSSBzZWUgdGhlIGNv bmNlcm4sIGFuZCBlZGl0ZWQgdGhlIHRleHQgcm91Z2hseSBhcyBzdWdnZXN0ZWQsIHBsdXMgbW92 ZWQgYSBzdXBwb3J0aW5nIHNlbnRlbmNlIGFib3V0IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZv ciB0aGUgZXhwZXJpbWVudHMgdXAgdG8gam9pbiB0aGlzIHNlbnRlbmNlLCBzbyB0aGUgbmV3IHBh cmFncmFwaCBub3cgcmVhZHM6DQoNCkFzIGEgcHJvY2VzcyBtZW1vIHRoYXQgb25seSByZW1vdmVz IGxpbWl0YXRpb25zIG9uIHByb3Bvc2VkIGV4cGVyaW1lbnRzLA0KdGhlcmUgYXJlIG5vIHByb3Rv Y29sIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9y IHRoZQ0KcHJvcG9zZWQgZXhwZXJpbWVudHMgYXJlIGRpc2N1c3NlZCBpbiB0aGUgSW50ZXJuZXQt RHJhZnRzIHRoYXQgcHJvcG9zZSB0aGVtLg0KDQpUaGFua3MsDQoNClNwZW5jZXINCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBpbnRlcm5ldC0NCj4gZHJhZnRzQGlldGYub3JnPG1haWx0bzpkcmFmdHNAaWV0Zi5vcmc+DQo+ IFNlbnQ6IEZyaWRheSwgQXVndXN0IDQsIDIwMTcgNzoyOSBQTQ0KPiBUbzogaS1kLWFubm91bmNl QGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+IENjOiB0c3Z3Z0BpZXRm Lm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFt0c3Z3Z10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA0LnR4dA0KPg0KPg0KPiBB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IFRyYW5zcG9ydCBBcmVhIFdvcmtpbmcgR3JvdXAgV0cgb2YgdGhlDQo+IElFVEYuDQo+DQo+ICAg ICAgICAgVGl0bGUgICAgICAgICAgIDogRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24g KEVDTikgRXhwZXJpbWVudGF0aW9uDQo+ICAgICAgICAgQXV0aG9yICAgICAgICAgIDogRGF2aWQg QmxhY2sNCj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhw ZXJpbWVudGF0aW9uLTA0LnR4dA0KPiAgICAgICBQYWdlcyAgICAgICAgICAgOiAxNw0KPiAgICAg ICBEYXRlICAgICAgICAgICAgOiAyMDE3LTA4LTA0DQo+DQo+IEFic3RyYWN0Og0KPiAgICBUaGlz IG1lbW8gdXBkYXRlcyBSRkMgMzE2OCwgd2hpY2ggc3BlY2lmaWVzIEV4cGxpY2l0IENvbmdlc3Rp b24NCj4gICAgTm90aWZpY2F0aW9uIChFQ04pIGFzIGEgcmVwbGFjZW1lbnQgZm9yIHBhY2tldCBk cm9wcyBhcyBpbmRpY2F0b3JzIG9mDQo+ICAgIG5ldHdvcmsgY29uZ2VzdGlvbi4gIEl0IHJlbGF4 ZXMgcmVzdHJpY3Rpb25zIGluIFJGQyAzMTY4IHRoYXQgd291bGQNCj4gICAgb3RoZXJ3aXNlIGhp bmRlciBleHBlcmltZW50YXRpb24gdG93YXJkcyBiZW5lZml0cyBiZXlvbmQganVzdCByZW1vdmFs DQo+ICAgIG9mIGxvc3MuICBUaGlzIG1lbW8gc3VtbWFyaXplcyB0aGUgYW50aWNpcGF0ZWQgYXJl YXMgb2YNCj4gICAgZXhwZXJpbWVudGF0aW9uIGFuZCB1cGRhdGVzIFJGQyAzMTY4IHRvIGVuYWJs ZSBleHBlcmltZW50YXRpb24gaW4NCj4gICAgdGhlc2UgYXJlYXMuICBBbiBFeHBlcmltZW50YWwg UkZDIGlzIHJlcXVpcmVkIHRvIHRha2UgYWR2YW50YWdlIG9mDQo+ICAgIGFueSBvZiB0aGVzZSBl bmFibGluZyB1cGRhdGVzLiAgSW4gYWRkaXRpb24sIHRoaXMgbWVtbyBtYWtlcyByZWxhdGVkDQo+ ICAgIHVwZGF0ZXMgdG8gdGhlIEVDTiBzcGVjaWZpY2F0aW9ucyBmb3IgUlRQIGluIFJGQyA2Njc5 IGFuZCBmb3IgRENDUCBpbg0KPiAgICBSRkMgNDM0MSwgUkZDIDQzNDIgYW5kIFJGQyA1NjIyLiAg VGhpcyBtZW1vIGFsc28gcmVjb3JkcyB0aGUNCj4gICAgY29uY2x1c2lvbiBvZiB0aGUgRUNOIE5v bmNlIGV4cGVyaW1lbnQgaW4gUkZDIDM1NDAsIGFuZCBwcm92aWRlcyB0aGUNCj4gICAgcmF0aW9u YWxlIGZvciByZWNsYXNzaWZpY2F0aW9uIG9mIFJGQyAzNTQwIGFzIEhpc3RvcmljOyB0aGlzDQo+ ICAgIHJlY2xhc3NpZmljYXRpb24gZW5hYmxlcyBuZXcgZXhwZXJpbWVudGFsIHVzZSBvZiB0aGUg RUNUKDEpDQo+ICAgIGNvZGVwb2ludC4NCj4NCj4NCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi8NCj4NCj4gVGhlcmUg YXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA0DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1l Y24tDQo+IGV4cGVyaW1lbnRhdGlvbi0wNA0KPg0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMg dmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDQNCj4NCj4NCj4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+ DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQo= --_000_CE03DB3D7B45C245BCA0D243277949362FC2AB02MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLQ0KCXttc28t c3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9rLCBJ4oCZbGwgZHJvcCDi gJxBbGV4YeKAnSBhbmQgdXBsb2FkIHRoZSByZXN1bHQuPG86cD48L286cD48L3NwYW4+PC9hPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCAtLURhdmlkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gU3BlbmNl ciBEYXdraW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAzMCwgMjAxNyAxMTo1NyBBTTxi cj4NCjxiPlRvOjwvYj4gQmxhY2ssIERhdmlkICZsdDtkYXZpZC5ibGFja0BlbWMuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gdHN2d2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0 c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA0 LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSwgRGF2aWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MsIGFuZCB3ZWxjb21lIGJhY2sgOi0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbW9zdGx5IGxvb2tzIHViZXItcmVhc29u YWJsZSwgYnV0IEkgaGF2ZSBvbmUgcmVwbHkgb24gQWxleGEgYmVsb3cuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgMzAsIDIwMTcgYXQgMTA6MzAgQU0s IEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+RGF2aWQuQmxhY2tAZGVsbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGEgbmFtZT0ibV81OTc3NDYwMjU0NjExNDQxMDk2X19NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFNwZW5jZXIsPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlc3VyZmFjaW5nIGZyb20gdHJ5aW5nIHRv IHRha2UgdmFjYXRpb24gaW4gQXVndXN0IOKAkyBtYW55IHRoYW5rcyBmb3IgdGhpcyBkZXRhaWxl ZCByZXZpZXcuJm5ic3A7IENvbW1lbnRzDQogaW5saW5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBhIC0wNSByZWFkeSB0byBnbyBpZiB0aGVz ZSBjaGFuZ2VzIGFyZSBvayB3aXRoIHlvdS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MsIC0tRGF2aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gU3BlbmNlciBE YXdraW5zIGF0IElFVEYgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0 ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgNywgMjAxNyAyOjM3IFBN PGJyPg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5i bGFja0BlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj48Yj5T dWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10c3Z3Zy1lY24t ZXhwZXJpbWVudGF0aW9uLTA0LnR4dDwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpLCBEYXZpZCw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBBdWcgNCwgMjAxNyBhdCA2OjMxIFBN LCBCbGFjaywgRGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0bzpEYXZpZC5CbGFja0BkZWxsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkRhdmlkLkJsYWNrQGRlbGwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgZGlzY3Vzc2VkIGluIFByYWd1ZSwgdGhpcyBp cyBhIHNtYWxsIHVwZGF0ZSB0byByZXF1ZXN0IHRoYXQgSUFOQSByZW1vdmUgdGhlIHJlZ2lzdHJh dGlvbiBvZiB0aGUgVENQIGhlYWRlciBmbGFnIHVzZWQgYnkgUkZDIDM1NDAgKEVDTiBOb25jZSku Jm5ic3A7ICZuYnNwO0FueSByZWFzc2lnbm1lbnQgb2YgdGhhdCBmbGFnDQogd2lsbCBiZSBoYW5k bGVkIGJ5IHRoZSBUQ1BNIFdHLiZuYnNwOyBUaGlzIHVwZGF0ZSBhbHNvIGNoYW5nZXMgdGhlIG5h bWUgb2Ygb25lIG9mIHRoZSBhcmVhcyBvZiBFQ04gZXhwZXJpbWVudGF0aW9uIHRvIGJlIGRpZmZl cmVudCBmcm9tIHRoZSBuYW1lIG9mIHRoZSBleHBlcmltZW50IHByb3Bvc2VkIGluIHRoYXQgYXJl YS48YnI+DQo8YnI+DQpUaGFua3MsIC0tRGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSwgRGF2aWQsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHJlYWxs eSBsaWtlIHRoaXMgZHJhZnQuIFRoYW5rcyB0byB5b3UgYW5kIHlvdXIgQUNLIGxpc3QgZm9yIHlv dXIgZWZmb3J0cyAtIHRoZSByZXN1bHQgaXMgdmVyeSBjbGVhciBhbmQgY29tcGxldGUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhh dmUgYSBmZXcgcXVlc3Rpb25zIGJlZm9yZSBJIHB1c2ggdGhlIGJ1dHRvbiBvbiBMYXN0IENhbGwu IFRoZXkncmUgbWlub3IgZW5vdWdoIHRoYXQgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIHdhaXQg Zm9yIEdvcnJ5IHRvIGJlIHByZXNlbnQgZm9yIHRoZSBkaXNjdXNzaW9uIChvZiBjb3Vyc2UsIGlm IHBlb3BsZQ0KIGRpc2FncmVlLCBqdXN0IGxldCBtZSBrbm93KS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdHJpZWQgdG8gb2ZmZXIg dGV4dCBmb3IgbW9zdCBvZiB0aGVtLCBidXQgeW91IG1pZ2h0IGFsc28gYW5zd2VyIHRoZW0gYnkg c2F5aW5nIHRoYXQgVFNWV0cgbmVlZHMgYSBtdWNoIHNtYXJ0ZXIgcmVzcG9uc2libGUgQUQgOy0p IC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SW4gdGhpcyB0ZXh0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO0FuIEV4cGVyaW1lbnRhbCBSRkMgTVVT VCBiZSBwdWJsaXNoZWQgZm9yIGFueSBwcm90b2NvbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7b3IgbWVjaGFuaXNtIHRo YXQgdGFrZXMgYWR2YW50YWdlIG9mIGFueSBvZiB0aGVzZSBlbmFibGluZyB1cGRhdGVzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkgdGhpbmsgSSBrbm93IHdoYXQgeW91J3JlIHNheWluZywgYnV0IHRoaXMgZm9ybXVsYXRp b24gY29uZnVzZXMgbWUgYmVjYXVzZSBpdCdzIHBsYWNpbmcgYSBjb21taXRtZW50IG9uIHdoYXQg YSBmdXR1cmUgd29ya2luZyBncm91cCBtdXN0IGRvIChsaWtlLCB3aGF0IGlmIHRoZSBkcmFmdCBk ZXNjcmliaW5nDQogdGhlIGV4cGVyaW1lbnRhbCBwcm90b2NvbCBpcyBpbmNvaGVyZW50IC0gY2Fu IHRoZSB3b3JraW5nIGdyb3VwIEp1c3QgU2F5IE5vLCBvciBjYW4gdGhlIGF1dGhvcnMgc2F5ICZx dW90O2J1dCB5b3UgaGF2ZSB0byByZXF1ZXN0IHB1YmxpY2F0aW9uLCBiZWNhdXNlICZxdW90O0Fu IEV4cGVyaW1lbnRhbCBSRkMgTVVTVCBiZSBwdWJsaXNoZWQgLi4uJnF1b3Q7KS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPltEYXZpZCZndDtdIFRoZSB3b3JraW5nIGdyb3VwIGNhbiBKdXN0IFNheSBObywg YW5kIHRoYXQgb3V0Y29tZSB3b3VsZCBiZSBhIOKAnGZlYXR1cmXigJ0g4oCTIGlmIHRoZSBleHBl cmltZW50YWwNCiBwcm90b2NvbCBpcyBwcm9ibGVtYXRpYywgdGhlbiB0aGUgZXhwZXJpbWVudCBz aG91bGRu4oCZdCBiZSBydW4gYXQgc2NhbGUgaW4gdGhlIEludGVybmV0LCBhbmQgdGhlIFdHIHdp bGwgaGF2ZSBkb25lIHRoZSByaWdodCB0aGluZyBieSBzYXlpbmcgc28uDQo8L3NwYW4+PC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPklzIHlvdXIgcG9pbnQgdGhhdCBhbnkgcHJvdG9jb2wgb3IgbWVjaGFuaXNtIHRoYXQgdGFr ZXMgYWR2YW50YWdlIG9mIHRoZXNlIGVuYWJsaW5nIHVwZGF0ZXMgY2FuJ3QgYmUgU3RhbmRhcmRz LVRyYWNrPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0RhdmlkJmd0O10gTm8g4oCTIGEgU3RhbmRhcmRz LVRyYWNrIHByb3RvY29sIFJGQyBjYW4gc2ltcGx5IHVwZGF0ZSBSRkMgMzE2OCAoYW5kIGFueSBv dGhlciBSRkNzIHRoYXQNCiBpdCBuZWVkcyB0bykgZGlyZWN0bHksIGFuZCBkb2VzbuKAmXQgbmVl ZCB0aGlzIGRyYWZ04oCZcyBwZXJtaXNzaW9uIHRvIGRvIHNvLCBhcyB0aGUgbmV4dCBzZW50ZW5j ZSBzdGF0ZXMg4oCmPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiB0aGlzIHRleHQsJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg Jm5ic3A7VGhlcmUgaXMgbm8gbmVlZCB0byBtYWtlIGNoYW5nZXMgZm9yIHByb3RvY29scyBhbmQg bWVjaGFuaXNtcyB0aGF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDthcmUgZG9jdW1lbnRlZCBpbiBTdGFuZGFyZHMgVHJh Y2sgUkZDcywgYXMgYW55IFN0YW5kYXJkcyBUcmFjayBSRkM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO2NhbiB1cGRhdGUg UkZDIDMxNjggd2l0aG91dCBuZWVkaW5nIGEgc3RhbmRhcmRzIHByb2Nlc3MgZXhjZXB0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ d2UndmUgYmVlbiB0YWxraW5nIHVzaW5nIHRoaXMgdGVybWlub2xvZ3kgZm9yIGF0IGxlYXN0IGEg eWVhciB0aGF0IEkgY2FuIHJlbWVtYmVyLCBidXQgSSdtIG5vdCB0b3RhbGx5IHN1cmUgdGhhdCBh biBhdmVyYWdlIElFU0cgd291bGQgZXZlbiBhcHByb3ZlIGFuIEV4cGVyaW1lbnRhbCBkcmFmdCB0 aGF0IHVwZGF0ZWQNCiBhIHN0YW5kYXJkcy10cmFjayBSRkMuIEhvdyBiYWRseSBkbyB5b3UgbmVl ZCB0byBzYXkgdGhpcyBhdCBhbGwsIHNpbmNlIHlvdSdyZSBqdXN0IGNvbmZpcm1pbmcgYSB3ZWxs LXVuZGVyc3Rvb2QgZmFjdCB0aGF0IEkgdGhpbmsgd2UgYWxsIGFncmVlIG9uPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+W0RhdmlkJmd0O10gVGhpcyBoYXMgYmVlbiBicm91Z2h0IHVwIHRvbyBtYW55IHRp bWVzIGluIFdHIGRpc2N1c3Npb24gb2YgdGhpcyBkcmFmdCB0byBsZWF2ZSBvdXQsDQogSU1ITy48 L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkluIHRoaXMgdGV4dCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtBIHN0dWR5IG9mIHRo ZSBFQ04gYmVoYXZpb3VyIG9mIHRoZSBBbGV4YSB0b3AgMU0gd2ViPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtzZXJ2ZXJz IHVzaW5nIDIwMTQgZGF0YSBbVHJhbW1lbGwxNV0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20gd29uZGVyaW5n IHdoZXRoZXIgaXQncyB1c2VmdWwgdG8gc2F5ICZxdW90O0FsZXhhIHRvcCAxTSB3ZWIgc2VydmVy cyZxdW90OyBpbiBhbiBSRkMgdGhhdCB3aWxsIHByb2JhYmx5IGxhc3QgbG9uZ2VyIHRoYW4gQWxl eGEgbGFzdHMgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bRGF2aWQmZ3Q7XSBJIHZpZXcgdGhpcyBh cyBhIOKAnHNob3cgeW91ciB3b3Jr4oCdIGl0ZW0g4oCmIHRoaXMgaXMgdGhlIGRhdGEgdGhhdCB3 YXMgdXNlZCBhdCB0aGUgdGltZS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHNvcnJ5IHRoYXQgbXkg Y29tbWVudCB3YXNuJ3QgY2xlYXIuIFdoYXQgSSB3YXMgYXNraW5nIHdhcyBpZiB0aGVyZSB3YXMg YW55IG1vcmUgZGVzY3JpcHRpb24gb2YgQWxleGEgKG9yIGZvciBleHRyYSBjcmVkaXQsIGEgVVJM KSBzbyB0aGF0IGEgcmVhZGVyIGluIHRlbiB5ZWFycyBjYW4gZG8gbW9yZSB0aGFuIGdvb2dsZSAm cXVvdDtBbGV4YSB0b3AgMU0gd2ViIHNlcnZlciZxdW90OyB0byBmaWd1cmUgb3V0IHdoYXQgdGhp cw0KIGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TbyBJJ20gd29uZGVyaW5nIGlmIHlvdSBuZWVkIHRvIHF1YWxpZnkgJnF1b3Q7dG9wIDFN IHdlYiBzZXJ2ZXJzJnF1b3Q7IGFzICZxdW90O0FsZXhhIHRvcCAxTSB3ZWIgc2VydmVycyZxdW90 OywgYmVjYXVzZSBJJ20gdGhpbmtpbmcgYWRkaW5nIHRoZSBhZGplY3RpdmUgZG9lc24ndCBhZGQg YXMgbXVjaCBhcyBpdCB0YWtlcyBhd2F5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBtYXkgYmUgdGhhdCB0aGUgYW5zd2VyIGlz ICZxdW90O25vdCByZWFsbHkmcXVvdDssIGFuZCB0aGF0IHdvdWxkIGJlIEEgRmluZSBBbnN3ZXIs IGJ1dCBJIHdhbnRlZCB0byBtYWtlIHN1cmUgeW91IHVuZGVyc3Rvb2Qgd2hhdCBJIHdhcyB0aGlu a2luZywgYmVjYXVzZSBpdCBhcHBhcmVudGx5IHdhc24ndCB3aGF0IEkgd2FzIHR5cGluZyA6LSk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWl0 aGVyIHdheSwgSSdtIHJlYWR5IGZvciB5b3UgdG8gc2VuZCB0aGUgdXBkYXRlZCB2ZXJzaW9uIGFu ZCBoYXZlIG1lIGluaXRpYXRlIExhc3QgQ2FsbCwgYW5kIHRoYW5rcyBmb3IgaG9yc2luZyB0aGlz IHRocm91Z2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNwZW5jZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoaXMgdGV4dCw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtT aWduaWZpY2FudGx5IG1vcmUgYWdncmVzc2l2ZSBzZW5kZXIgcmVzcG9uc2VzIHRvIEVDTjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg Jm5ic3A7YXJlIHJlcXVpcmVkIHRvIG1ha2UgZWZmZWN0aXZlIHVzZSBvZiBzdWNoIHNoYWxsb3cg cXVldWVzOyBEYXRhY2VudGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO15eXl5eXl5ePG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAm bmJzcDtUQ1AgKERDVENQKSBbSS1ELmlldGYtdGNwbS1kY3RjcF0gcHJvdmlkZXMgYW4gZXhhbXBs ZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSdtIHRhbmdsZWQgdXAgaW4gcGFzc2l2ZSB0ZW5zZSAoJnF1b3Q7 d2hvIGlzIHJlcXVpcmVkIHRvIGRvIHdoYXQ/JnF1b3Q7KS4gSXMgaXQgY29ycmVjdCB0byBzYXkm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAmbmJzcDtTaWduaWZpY2FudGx5IG1vcmUgYWdncmVzc2l2ZSBzZW5kZXIg cmVzcG9uc2VzIHRvIEVDTjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7YXJlIG5lZWRlZCBpbiBvcmRlciB0byBtYWtlIGVm ZmVjdGl2ZSB1c2Ugb2Ygc3VjaCBzaGFsbG93IHF1ZXVlczsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO0RhdGFj ZW50ZXIgVENQIChEQ1RDUCkgW0ktRC5pZXRmLXRjcG0tZGN0Y3BdIHByb3ZpZGVzIGFuIGV4YW1w bGUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PltEYXZpZCZndDtdIFllcywgY2hhbmdlIG1hZGUuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBzZWUgdGhhdCB0aGUgZHJhZnQgdXNlcyBib3RoIHRo ZSB0ZXJtcyAmcXVvdDtzaGFsbG93IHF1ZXVlcyZxdW90OyBhbmQgJnF1b3Q7bmVhcmx5IGVtcHR5 IHF1ZXVlcyZxdW90Oy4gRG8gdGhlc2UgdGVybXMgbWVhbiB0aGUgc2FtZSB0aGluZz8gSWYgc28s IHBlcmhhcHMgaXQncyB3b3J0aCBlaXRoZXIgcGlja2luZyBvbmUgdGVybSwgb3Igc2F5aW5nDQog dGhhdCB0aGV5IG1lYW4gdGhlIHNhbWUgdGhpbmcuIFJpZ2h0IG5vdywgSSdtIHRyeWluZyB0byBp bWFnaW5lIHdoYXQgdGhlIGRpZmZlcmVuY2UgbWlnaHQgYmUsIHNpbmNlIGJvdGggcGhyYXNlcyBh cmUgdXNlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltEYXZpZCZndDtdIEdvb2QgcG9pbnQsIGNoYW5n ZWQgdG8gY29uc2lzdGVudGx5IHVzZSDigJx2ZXJ5IHNoYWxsb3figJ0gZXZlcnl3aGVyZS48L3Nw YW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPllvdSBmb2xrcyBhcmUgdGhlIGV4cGVydHMgb24gdGhpcyBzdHVmZiwgYnV0 IEknbSBsb29raW5nIGF0IHRoaXMgcXVvdGVkIHRleHQgZnJvbSBSRkMgMzE2ODxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7UkZD IDMxNjggcHJvaGliaXRzIHVzZSBvZiBFQ04gZm9yIFRDUCBjb250cm9sIHBhY2tldHMgYW5kPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyAmbmJzcDtyZXRyYW5zbWl0dGVkIHBhY2tldHMgaW4gYSBudW1iZXIgb2YgcGxhY2VzOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7ICZuYnNwO28gJm5ic3A7JnF1b3Q7VG8gZW5zdXJlIHRoZSByZWxpYWJsZSBkZWxpdmVyeSBv ZiB0aGUgY29uZ2VzdGlvbiBpbmRpY2F0aW9uIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBDRSBj b2RlcG9pbnQsIGFuIEVDVCBjb2RlcG9pbnQgTVVTVCBOT1QgYmUgc2V0IGluIGEgcGFja2V0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyAmbmJzcDsgJm5ic3A7IHVubGVzcyB0aGUgbG9zcyBvZiB0aGF0IHBhY2tldCBpbiB0aGUgbmV0 d29yayB3b3VsZCBiZSBkZXRlY3RlZCBieTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgZW5kIG5vZGVz IGFuZCBpbnRlcnByZXRlZCBhcyBhbiBpbmRpY2F0aW9uIG9mIGNvbmdlc3Rpb24uJnF1b3Q7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyAmbmJzcDsgJm5ic3A7IChTZWN0aW9uIDUuMik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtvICZuYnNwOyZxdW90 O0EgaG9zdCBNVVNUIE5PVCBzZXQgRUNUIG9uIFNZTiBvciBTWU4tQUNLIHBhY2tldHMuJnF1b3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyAmbmJzcDsgJm5ic3A7IChTZWN0aW9uIDYuMS4xKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7 JnF1b3Q7cHVyZSBhY2tub3dsZWRnZW1lbnQgcGFja2V0cyAoZS5nLiwgcGFja2V0cyB0aGF0IGRv IG5vdCBjb250YWluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFueSBhY2NvbXBhbnlpbmcgZGF0YSkgTVVT VCBiZSBzZW50IHdpdGggdGhlIG5vdC1FQ1QgY29kZXBvaW50LiZxdW90OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAoU2VjdGlvbiA2LjEuNCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtvICZuYnNwOyZxdW90O1RoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIEVDTi1jYXBhYmxlIFRDUCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBOT1Q8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgc2V0IGVpdGhlciBFQ1QgY29kZXBvaW50IChFQ1QoMCkgb3IgRUNU KDEpKSBpbiB0aGUgSVAgaGVhZGVyIGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyByZXRyYW5zbWl0dGVk IGRhdGEgcGFja2V0cywgYW5kIHRoYXQgdGhlIFRDUCBkYXRhIHJlY2VpdmVyIFNIT1VMRDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyBpZ25vcmUgdGhlIEVDTiBmaWVsZCBvbiBhcnJpdmluZyBkYXRhIHBhY2tl dHMgdGhhdCBhcmUgb3V0c2lkZSBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgcmVjZWl2ZXIncyBj dXJyZW50IHdpbmRvdy4mcXVvdDsgJm5ic3A7KFNlY3Rpb24gNi4xLjUpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 byAmbmJzcDsmcXVvdDt0aGUgVENQIGRhdGEgc2VuZGVyIE1VU1QgTk9UIHNldCBlaXRoZXIgYW4g RUNUIGNvZGVwb2ludCBvciB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQ1dSIGJpdCBvbiB3aW5kb3cg cHJvYmUgcGFja2V0cy4mcXVvdDsgJm5ic3A7KFNlY3Rpb24gNi4xLjYpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5i c3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPmFuZCBub3RpY2luZyB0aGF0IG9ubHkgdGhlIHRleHQgaW4gNi4xLjUgZXhwbGljaXRs eSBtZW50aW9ucyB0aGUgVENQIGRhdGEgcmVjZWl2ZXIgaWdub3JpbmcgdGhlICZxdW90O01VU1Qg Tk9UIHNldCZxdW90OyBFQ04gZmllbGQuIEkgdG9vayBhIHF1aWNrIHNwaW4gdGhyb3VnaCBSRkMg MzE2OCBzZWFyY2hpbmcgZm9yICZxdW90O2lnbm9yZSZxdW90OywNCiBidXQgZGlkbid0IHNlZSBz b21ldGhpbmcgdGhhdCBleHBsaWNpdGx5IGNvdmVyZWQgdGhlIG90aGVyIGNhc2VzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVjYXVz ZSB0aGVzZSBhcmUgJnF1b3Q7TVVTVCBOT1Qgc2V0JnF1b3Q7IGNvbnN0cmFpbnRzLCBJIGNvdWxk IGltYWdpbmUgaW1wbGVtZW50ZXJzIHdobyBuZXZlciBhbnRpY2lwYXRlZCB0aGF0IGFuIEVDTigw KSBvciBFQ04oMSkgd291bGQgYmUgc2V0LCBhbmQgZG9uJ3QgbG9vayBhdCB0aGUgZmllbGQgKHBy b2JhYmx5IGdvb2QpLA0KIGJ1dCBJIGNhbiBhbHNvIGltYWdpbmUgaW1wbGVtZW50ZXJzIHZhbGlk YXRpbmcgdGhhdCBFQ04oMCkgYW5kIEVDTigxKSBhcmUgbm90IHNldCAocHJvYmFibHkgYmFkKS4g RG8gcGVvcGxlIGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IGVuY291bnRlcmluZyAmcXVvdDtFQ1Qg dmFsdWVzIE1VU1QgYmUgY2xlYXJlZCZxdW90OyBpbXBsZW1lbnRhdGlvbnMgZHVyaW5nIHRoaXMg ZXhwZXJpbWVudD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkkgc3VwcG9zZSBpZiBzb21lIGltcGxlbWVudGF0aW9uIHRoYXQgZG9lcyB0 aGlzIGlzIGRlcGxveWVkIGFuZCB5b3UgZm9sa3MgcnVuIHRoZSBleHBlcmltZW50LCB0aGVuIHdl J2xsIGtub3cgOkQgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bRGF2aWQmZ3Q7XSBJIHdvdWxkIGxl YXZlIHRoaXMgdG8gdGhlIGRyYWZ0cy9SRkNTIHRoYXQgZGVzY3JpYmUgdGhlIGV4cGVyaW1lbnRz LCBhcyBJIGV4cGVjdCBpbXBsZW1lbnRlcnMNCiBvZiB0aGUgZXhwZXJpbWVudHMgdG8gbG9vayB0 aGVyZSwgYW5kIG5vdCBhdCB0aGlzIHByb2Nlc3MgUkZDICh0byBiZSkuPC9zcGFuPjwvaT48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5CdXQgSSB3b25kZXIgaWYgaXQncyB3b3J0aCBtYWtpbmcgdGhhdCBjbGVhciBmb3IgcmVjZWl2 ZXJzLCBzaW5jZSB5b3UncmUgdXBkYXRpbmcgUkZDIDMxNjggYW55d2F5PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gdGhpcyB0ZXh0 LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUmFuZG9tIEVDVCB2YWx1ZXMgTVVTVCBOT1QgYmUgdXNl ZCwgYXMgdGhhdCBtYXkgZXhwb3NlIFJUUCB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBkaWZmZXJlbmNl cyBpbiBuZXR3b3JrIHRyZWF0bWVudCBvZiB0cmFmZmljIG1hcmtlZCB3aXRoIEVDVCgxKSBhbmQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgRUNUKDApIGFuZCBkaWZmZXJlbmNlcyBpbiBhc3NvY2lhdGVkIGVu ZHBvaW50IGNvbmdlc3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVzcG9uc2VzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5pcyAmcXVvdDtSYW5kb20gRUNUIHZhbHVlcyZxdW90OyB0aGUgcmlnaHQgd29y ZD8gSSBjb3VsZCBpbWFnaW5lIHRoaXMgcHJvaGliaXRpbmcgdXNpbmcgRUNUKDApIGFuZCBFQ1Qo MSkgaW50ZXJjaGFuZ2VhYmx5LCBidXQgaWYgdGhhdCdzIHdoYXQncyBpbnRlbmRlZCwgSSBjb3Vs ZCBhbHNvIGltYWdpbmUgdGhpcyBwcm9oaWJpdGluZw0KIHNpbXBseSBub3QgZXhwbGljaXRseSBz ZXR0aW5nIHRoZSBFQ1QgdmFsdWVzIGF0IGFsbCwgc28gbWlzc2luZyB5b3VyIHBvaW50LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+W0RhdmlkJmd0O10gWWVzLCDigJxSYW5kb23igJ0gaXMgdGhlIHJpZ2h0 IHdvcmQsIGFzIHRoZSB0ZXh0IHF1b3RlZCBmcm9tIFJGQyA2Njc5IHVzZXMgdGhlIHdvcmQg4oCc cmFuZG9t4oCdDQogc28gdGhhdCBpcyB0aGUgY29ycmVjdCB3b3JkIHRvIHVzZSBoZXJlLCBhbmQg ZnVydGhlciBleHBsYW5hdGlvbiBjYW4gYmUgZm91bmQgaW4gUkZDIDY2NzkuPC9zcGFuPjwvaT48 L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JJ20gbG9va2luZyBhdCB0aGlzIHRleHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtBcyBhIHByb2Nlc3Mg bWVtbyB0aGF0IG1ha2VzIG5vIGNoYW5nZXMgdG8gZXhpc3RpbmcgcHJvdG9jb2xzLCB0aGVyZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7YXJlIG5vIHByb3RvY29sIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PmFuZCB3b25kZXJpbmcgaWYgaXQncyBjdXJyZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIGRvY3Vt ZW50LiBJcyAmcXVvdDtubyBjaGFuZ2VzIHRvIGV4aXN0aW5nIHByb3RvY29scyZxdW90OyBzdGls bCB0aGUgcmlnaHQgd2F5IHRvIGNoYXJhY3Rlcml6ZSB0aGlzIGRyYWZ0PyBJZiB5b3Ugd2FudGVk IHRvIHNheTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7ICZuYnNwO0FzIGEgcHJvY2VzcyBtZW1vIHRoYXQgb25seSBhZGRzIGxp bWl0YXRpb25zIHRvIGV4aXN0aW5nIHByb3RvY29scywgdGhlcmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO2FyZSBubyBw cm90b2NvbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ2QgYmUgaGFwcHkgdG8g YmVsaWV2ZSB5b3UgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bRGF2aWQmZ3Q7XSBJIHNlZSB0aGUg Y29uY2VybiwgYW5kIGVkaXRlZCB0aGUgdGV4dCByb3VnaGx5IGFzIHN1Z2dlc3RlZCwgcGx1cyBt b3ZlZCBhIHN1cHBvcnRpbmcNCiBzZW50ZW5jZSBhYm91dCBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBmb3IgdGhlIGV4cGVyaW1lbnRzIHVwIHRvIGpvaW4gdGhpcyBzZW50ZW5jZSwgc28gdGhlIG5l dyBwYXJhZ3JhcGggbm93IHJlYWRzOjwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzAuNzVwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QXMgYSBwcm9jZXNzIG1lbW8gdGhhdCBvbmx5IHJlbW92ZXMgbGltaXRhdGlvbnMgb24gcHJvcG9z ZWQgZXhwZXJpbWVudHMsPGJyPg0KdGhlcmUgYXJlIG5vIHByb3RvY29sIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zLiZuYnNwOyBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhlPGJyPg0KcHJv cG9zZWQgZXhwZXJpbWVudHMgYXJlIGRpc2N1c3NlZCBpbiB0aGUgSW50ZXJuZXQtRHJhZnRzIHRo YXQgcHJvcG9zZSB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3BlbmNlciZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogdHN2 d2cgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnRzdndnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgaW50ZXJu ZXQtPGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+ZHJhZnRzQGlldGYub3JnPC9hPjxicj4NCiZndDsgU2VudDogRnJpZGF5LCBBdWd1c3Qg NCwgMjAxNyA3OjI5IFBNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5j ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFt0c3Z3Z10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA0LnR4dDxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyBUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdyb3Vw IFdHIG9mIHRoZTxicj4NCiZndDsgSUVURi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7OiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBFeHBl cmltZW50YXRpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0F1 dGhvciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBEYXZpZCBCbGFjazxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0wNC50eHQ8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGFnZXMmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMTc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7RGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDog MjAxNy0wOC0wNDxicj4NCiZndDs8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IFRoaXMgbWVtbyB1cGRhdGVzIFJGQyAzMTY4LCB3aGljaCBzcGVjaWZpZXMgRXhwbGlj aXQgQ29uZ2VzdGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IE5vdGlmaWNhdGlvbiAoRUNOKSBh cyBhIHJlcGxhY2VtZW50IGZvciBwYWNrZXQgZHJvcHMgYXMgaW5kaWNhdG9ycyBvZjxicj4NCiZn dDsmbmJzcDsgJm5ic3A7IG5ldHdvcmsgY29uZ2VzdGlvbi4mbmJzcDsgSXQgcmVsYXhlcyByZXN0 cmljdGlvbnMgaW4gUkZDIDMxNjggdGhhdCB3b3VsZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG90 aGVyd2lzZSBoaW5kZXIgZXhwZXJpbWVudGF0aW9uIHRvd2FyZHMgYmVuZWZpdHMgYmV5b25kIGp1 c3QgcmVtb3ZhbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG9mIGxvc3MuJm5ic3A7IFRoaXMgbWVt byBzdW1tYXJpemVzIHRoZSBhbnRpY2lwYXRlZCBhcmVhcyBvZjxicj4NCiZndDsmbmJzcDsgJm5i c3A7IGV4cGVyaW1lbnRhdGlvbiBhbmQgdXBkYXRlcyBSRkMgMzE2OCB0byBlbmFibGUgZXhwZXJp bWVudGF0aW9uIGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdGhlc2UgYXJlYXMuJm5ic3A7IEFu IEV4cGVyaW1lbnRhbCBSRkMgaXMgcmVxdWlyZWQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2Y8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyBhbnkgb2YgdGhlc2UgZW5hYmxpbmcgdXBkYXRlcy4mbmJzcDsgSW4g YWRkaXRpb24sIHRoaXMgbWVtbyBtYWtlcyByZWxhdGVkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg dXBkYXRlcyB0byB0aGUgRUNOIHNwZWNpZmljYXRpb25zIGZvciBSVFAgaW4gUkZDIDY2NzkgYW5k IGZvciBEQ0NQIGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgUkZDIDQzNDEsIFJGQyA0MzQyIGFu ZCBSRkMgNTYyMi4mbmJzcDsgVGhpcyBtZW1vIGFsc28gcmVjb3JkcyB0aGU8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyBjb25jbHVzaW9uIG9mIHRoZSBFQ04gTm9uY2UgZXhwZXJpbWVudCBpbiBSRkMg MzU0MCwgYW5kIHByb3ZpZGVzIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHJhdGlvbmFsZSBm b3IgcmVjbGFzc2lmaWNhdGlvbiBvZiBSRkMgMzU0MCBhcyBIaXN0b3JpYzsgdGhpczxicj4NCiZn dDsmbmJzcDsgJm5ic3A7IHJlY2xhc3NpZmljYXRpb24gZW5hYmxlcyBuZXcgZXhwZXJpbWVudGFs IHVzZSBvZiB0aGUgRUNUKDEpPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgY29kZXBvaW50Ljxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi8iIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl cmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWV4 cGVyaW1lbnRhdGlvbi0wNCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWV4cGVyaW1lbnRhdGlvbi0wNDwvYT48YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi10c3Z3Zy1lY24tIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLTwvYT48YnI+DQomZ3Q7IGV4cGVy aW1lbnRhdGlvbi0wNDxicj4NCiZndDs8YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRp b24tMDQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDQ8L2E+PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQomZ3Q7IHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4u PGJyPg0KJmd0Ozxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949362FC2AB02MX307CL04corpem_-- From nobody Wed Aug 30 09:34:40 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0239D13202D for ; Wed, 30 Aug 2017 09:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xHQJ9tw0fo2 for ; Wed, 30 Aug 2017 09:34:35 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5724D1201F8 for ; Wed, 30 Aug 2017 09:34:35 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id s187so33804720ywf.2 for ; Wed, 30 Aug 2017 09:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VEiU8vTCv8BG/r2hXalgFwwPO6eJueszVqENPFU+V8k=; b=e3kJlscwlCzP5sB8t7adR0txWEkjxTP95ibJK+zRPFlHMV1IRtKGPr1c/LX2vHS05w Ldcs5ElH6MfPf/SUcTGuzuJifsyXboPbehYsIpyiy6CPN6Z3pO0eEuCY+5st75DbCkEm YmLBdG0QOEEMdCBQ+arACEczcMSQv/P6xzRjGyum/iBvcQFpHFBS9An6HnLMju0BkkVE qR8n0xlXoiu40QdLXznop4Tyw5xVGzgmWjstsDxxGNq4PWzpNYplLicDhUtzaD61a4B2 97rJuSEjKemyQJ2x0NOdPBDlpDIP/6uONl51dMqjzYDD2AciKoswL0S4zpBOQsKE1ujp OYDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VEiU8vTCv8BG/r2hXalgFwwPO6eJueszVqENPFU+V8k=; b=uDOqmcTcxDQ8cL9Cy12Ra+w3alBZU1GSuBVB3hcH2v56BHozycrDkcDZYtn4gXKX3g OPayKfA/V1MKXS/4qILZ4WIWJg6EIh4lcm0HEzzONGizjFWRKYaOiTVXW0jTaHpJ7zx3 RGnYSE2Fq3662ZU+AmZUNiKBKQp4JAsRiA1kdsjU9NYJvA2SJKTZDem1EKVmutmer2Fj SgCHGpCUFIcEsY/CcoEh1cfWiupsFylD2+3N5CxVbc2IPGOiD4K4V3U+cqEzuuEZw4wx eqTftf0S1OiyqmZOXwDTEJP6D9MiyiDvinXcx07sboPlWp0wrQGZlDNIGBygJWgHXkUD rPNg== X-Gm-Message-State: AHYfb5gbUi9Ow6BHT5Uk3PEkEiLixyruz0BBS3BvHNaJy3UZ5644zWtr pdDwePR5XJxV6CLogjH+SCYPfteqVg== X-Received: by 10.129.158.140 with SMTP id v134mr1825117ywg.339.1504110874302; Wed, 30 Aug 2017 09:34:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Wed, 30 Aug 2017 09:34:33 -0700 (PDT) In-Reply-To: References: <150188933148.18701.4807220216565950086@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 30 Aug 2017 11:34:33 -0500 Message-ID: To: "Black, David" Cc: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b78985d9d190557fb1a87" Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:34:39 -0000 --94eb2c0b78985d9d190557fb1a87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, David, On Wed, Aug 30, 2017 at 11:09 AM, Black, David wrote= : > Ok, I=E2=80=99ll drop =E2=80=9CAlexa=E2=80=9D and upload the result. > Thanks! Spencer, who was visualizing someone thinking "Alexa Morris has a 'top 1M websites'? Who knew?" ;-) > Thanks, --David > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* Wednesday, August 30, 2017 11:57 AM > > *To:* Black, David > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn- > experimentation-04.txt > > > > Hi, David, > > > > Thanks, and welcome back :-) > > > > This mostly looks uber-reasonable, but I have one reply on Alexa below. > > > > On Wed, Aug 30, 2017 at 10:30 AM, Black, David > wrote: > > Hi Spencer, > > > > Resurfacing from trying to take vacation in August =E2=80=93 many thanks = for this > detailed review. Comments inline. > > > > I have a -05 ready to go if these changes are ok with you. > > > > Thanks, --David > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* Monday, August 7, 2017 2:37 PM > *To:* Black, David > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn- > experimentation-04.txt > > > > Hi, David, > > > > On Fri, Aug 4, 2017 at 6:31 PM, Black, David wrote= : > > As discussed in Prague, this is a small update to request that IANA remov= e > the registration of the TCP header flag used by RFC 3540 (ECN Nonce). A= ny > reassignment of that flag will be handled by the TCPM WG. This update al= so > changes the name of one of the areas of ECN experimentation to be differe= nt > from the name of the experiment proposed in that area. > > Thanks, --David > > > > Hi, David, > > > > I really like this draft. Thanks to you and your ACK list for your effort= s > - the result is very clear and complete. > > > > I have a few questions before I push the button on Last Call. They're > minor enough that I don't think we need to wait for Gorry to be present f= or > the discussion (of course, if people disagree, just let me know). > > > > I tried to offer text for most of them, but you might also answer them by > saying that TSVWG needs a much smarter responsible AD ;-) ... > > > > In this text, > > > > An Experimental RFC MUST be published for any protocol > > or mechanism that takes advantage of any of these enabling updates. > > > > I think I know what you're saying, but this formulation confuses me > because it's placing a commitment on what a future working group must do > (like, what if the draft describing the experimental protocol is incohere= nt > - can the working group Just Say No, or can the authors say "but you have > to request publication, because "An Experimental RFC MUST be published > ..."). > > *[David>] The working group can Just Say No, and that outcome would be a > =E2=80=9Cfeature=E2=80=9D =E2=80=93 if the experimental protocol is probl= ematic, then the > experiment shouldn=E2=80=99t be run at scale in the Internet, and the WG = will have > done the right thing by saying so. * > > > > Is your point that any protocol or mechanism that takes advantage of thes= e > enabling updates can't be Standards-Track? > > *[David>] No =E2=80=93 a Standards-Track protocol RFC can simply update R= FC 3168 > (and any other RFCs that it needs to) directly, and doesn=E2=80=99t need = this > draft=E2=80=99s permission to do so, as the next sentence states =E2=80= =A6* > > > > In this text, > > > > There is no need to make changes for protocols and mechanisms that > > are documented in Standards Track RFCs, as any Standards Track RFC > > can update RFC 3168 without needing a standards process exception. > > > > we've been talking using this terminology for at least a year that I can > remember, but I'm not totally sure that an average IESG would even approv= e > an Experimental draft that updated a standards-track RFC. How badly do yo= u > need to say this at all, since you're just confirming a well-understood > fact that I think we all agree on? > > *[David>] This has been brought up too many times in WG discussion of thi= s > draft to leave out, IMHO.* > > > > In this text, > > > > A study of the ECN behaviour of the Alexa top 1M web > > servers using 2014 data [Trammell15] > > > > I'm wondering whether it's useful to say "Alexa top 1M web servers" in an > RFC that will probably last longer than Alexa lasts ... > > *[David>] I view this as a =E2=80=9Cshow your work=E2=80=9D item =E2=80= =A6 this is the data that > was used at the time.* > > > > I'm sorry that my comment wasn't clear. What I was asking was if there wa= s > any more description of Alexa (or for extra credit, a URL) so that a read= er > in ten years can do more than google "Alexa top 1M web server" to figure > out what this is. > > > > So I'm wondering if you need to qualify "top 1M web servers" as "Alexa to= p > 1M web servers", because I'm thinking adding the adjective doesn't add as > much as it takes away. > > > > It may be that the answer is "not really", and that would be A Fine > Answer, but I wanted to make sure you understood what I was thinking, > because it apparently wasn't what I was typing :-) > > > > Either way, I'm ready for you to send the updated version and have me > initiate Last Call, and thanks for horsing this through. > > > > Spencer > > > > In this text, > > > > Significantly more aggressive sender responses to ECN > > are required to make effective use of such shallow queues; Datacenter > > ^^^^^^^^ > > TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. > > > > I'm tangled up in passive tense ("who is required to do what?"). Is it > correct to say > > > > Significantly more aggressive sender responses to ECN > > are needed in order to make effective use of such shallow queues; > > Datacenter TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provides an example. > > > > ? > > *[David>] Yes, change made.* > > > > I see that the draft uses both the terms "shallow queues" and "nearly > empty queues". Do these terms mean the same thing? If so, perhaps it's > worth either picking one term, or saying that they mean the same thing. > Right now, I'm trying to imagine what the difference might be, since both > phrases are used. > > *[David>] Good point, changed to consistently use =E2=80=9Cvery shallow= =E2=80=9D > everywhere.* > > > > You folks are the experts on this stuff, but I'm looking at this quoted > text from RFC 3168 > > > > RFC 3168 prohibits use of ECN for TCP control packets and > > retransmitted packets in a number of places: > > > > o "To ensure the reliable delivery of the congestion indication of > > the CE codepoint, an ECT codepoint MUST NOT be set in a packet > > unless the loss of that packet in the network would be detected by > > the end nodes and interpreted as an indication of congestion." > > (Section 5.2) > > > > o "A host MUST NOT set ECT on SYN or SYN-ACK packets." > > (Section 6.1.1) > > > > o "pure acknowledgement packets (e.g., packets that do not contain > > any accompanying data) MUST be sent with the not-ECT codepoint." > > (Section 6.1.4) > > > > o "This document specifies ECN-capable TCP implementations MUST NOT > > set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for > > retransmitted data packets, and that the TCP data receiver SHOULD > > ignore the ECN field on arriving data packets that are outside of > > the receiver's current window." (Section 6.1.5) > > > > o "the TCP data sender MUST NOT set either an ECT codepoint or the > > CWR bit on window probe packets." (Section 6.1.6) > > > > and noticing that only the text in 6.1.5 explicitly mentions the TCP data > receiver ignoring the "MUST NOT set" ECN field. I took a quick spin throu= gh > RFC 3168 searching for "ignore", but didn't see something that explicitly > covered the other cases. > > > > Because these are "MUST NOT set" constraints, I could imagine implementer= s > who never anticipated that an ECN(0) or ECN(1) would be set, and don't lo= ok > at the field (probably good), but I can also imagine implementers > validating that ECN(0) and ECN(1) are not set (probably bad). Do people > have any concerns about encountering "ECT values MUST be cleared" > implementations during this experiment? > > > > I suppose if some implementation that does this is deployed and you folks > run the experiment, then we'll know :D ... > > *[David>] I would leave this to the drafts/RFCS that describe the > experiments, as I expect implementers of the experiments to look there, a= nd > not at this process RFC (to be).* > > > > But I wonder if it's worth making that clear for receivers, since you're > updating RFC 3168 anyway? > > > > In this text, > > > > Random ECT values MUST NOT be used, as that may expose RTP to > > differences in network treatment of traffic marked with ECT(1) and > > ECT(0) and differences in associated endpoint congestion > > responses, > > > > is "Random ECT values" the right word? I could imagine this prohibiting > using ECT(0) and ECT(1) interchangeably, but if that's what's intended, I > could also imagine this prohibiting simply not explicitly setting the ECT > values at all, so missing your point. > > *[David>] Yes, =E2=80=9CRandom=E2=80=9D is the right word, as the text qu= oted from RFC > 6679 uses the word =E2=80=9Crandom=E2=80=9D so that is the correct word t= o use here, and > further explanation can be found in RFC 6679.* > > > > I'm looking at this text > > > > As a process memo that makes no changes to existing protocols, there > > are no protocol security considerations. > > > > and wondering if it's current with the rest of the document. Is "no > changes to existing protocols" still the right way to characterize this > draft? If you wanted to say > > > > As a process memo that only adds limitations to existing protocols, > there > > are no protocol security considerations. > > > > I'd be happy to believe you ... > > *[David>] I see the concern, and edited the text roughly as suggested, > plus moved a supporting sentence about security considerations for the > experiments up to join this sentence, so the new paragraph now reads:* > > > > As a process memo that only removes limitations on proposed experiments, > there are no protocol security considerations. Security considerations > for the > proposed experiments are discussed in the Internet-Drafts that propose > them. > > > > Thanks, > > > > Spencer > > > > > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Friday, August 4, 2017 7:29 PM > > To: i-d-announce@ietf.org > > Cc: tsvwg@ietf.org > > Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-04.tx= t > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Area Working Group WG of the > > IETF. > > > > Title : Explicit Congestion Notification (ECN) > Experimentation > > Author : David Black > > Filename : draft-ietf-tsvwg-ecn-experimentation-04.txt > > Pages : 17 > > Date : 2017-08-04 > > > > Abstract: > > This memo updates RFC 3168, which specifies Explicit Congestion > > Notification (ECN) as a replacement for packet drops as indicators o= f > > network congestion. It relaxes restrictions in RFC 3168 that would > > otherwise hinder experimentation towards benefits beyond just remova= l > > of loss. This memo summarizes the anticipated areas of > > experimentation and updates RFC 3168 to enable experimentation in > > these areas. An Experimental RFC is required to take advantage of > > any of these enabling updates. In addition, this memo makes related > > updates to the ECN specifications for RTP in RFC 6679 and for DCCP i= n > > RFC 4341, RFC 4342 and RFC 5622. This memo also records the > > conclusion of the ECN Nonce experiment in RFC 3540, and provides the > > rationale for reclassification of RFC 3540 as Historic; this > > reclassification enables new experimental use of the ECT(1) > > codepoint. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn- > > experimentation-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-ecn- > experimentation-04 > > > > > > 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/ > > > > > --94eb2c0b78985d9d190557fb1a87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,

On Wed, Aug 30, 2017 at 11:09 AM, Black, David = <David.Black@d= ell.com> wrote:

Thanks!

Spencer, who was visualizing someone thinking "= Alexa Morris has a 'top 1M websites'? Who knew?" ;-)
=C2=A0

Thanks, --David

=C2=A0

From: Spencer Dawkins at IETF [mailt= o:spence= rdawkins.ietf@gmail.com]
Sent: Wednesday, August 30, 2017 11:57 AM


To: Black, David <david.black@emc.com>
Cc: tsvwg@ietf.o= rg
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimen= tation-04.txt

=C2=A0

Hi, David,

=C2=A0

Thanks, and welcome back :-)

=C2=A0

This mostly looks uber-reasonable, but I have one re= ply on Alexa below.

=C2=A0

On Wed, Aug 30, 2017 at 10:30 AM, Black, David <<= a href=3D"mailto:David.Black@dell.com" target=3D"_blank">David.Black@dell.c= om> wrote:

Hi Spencer,

=C2=A0

Resurfacing from trying to take vacat= ion in August =E2=80=93 many thanks for this detailed review.=C2=A0 Comment= s inline.

=C2=A0

I have a -05 ready to go if these cha= nges are ok with you.

=C2=A0

Thanks, --David<= /p>

=C2=A0

From: Spencer Dawkins at IETF [mailt= o:spence= rdawkins.ietf@gmail.com]
Sent: Monday, August 7, 2017 2:37 PM
To: Black, David <david.black@emc.com>
Cc: tsvwg@ietf.o= rg
Subject: Re: [tsvwg] I-D = Action: draft-ietf-tsvwg-ecn-experimentation-04.txt

=C2=A0

Hi, David,

=C2=A0

On Fri, Aug 4, 2017 at 6:31 PM, Black, David <David.Black@dell.com= > wrote:

As discussed in Prague, this is a small update to re= quest that IANA remove the registration of the TCP header flag used by RFC = 3540 (ECN Nonce).=C2=A0 =C2=A0Any reassignment of that flag will be handled by the TCPM WG.=C2=A0 This update also changes the name of= one of the areas of ECN experimentation to be different from the name of t= he experiment proposed in that area.

Thanks, --David

=C2=A0

Hi, David,

=C2=A0

I really like this draft. Thanks to you and your ACK= list for your efforts - the result is very clear and complete.

=C2=A0

I have a few questions before I push the button on L= ast Call. They're minor enough that I don't think we need to wait f= or Gorry to be present for the discussion (of course, if people disagree, just let me know).

=C2=A0

I tried to offer text for most of them, but you migh= t also answer them by saying that TSVWG needs a much smarter responsible AD= ;-) ...

=C2=A0

In this text,

=C2=A0

=C2=A0 =C2=A0An Experimental RFC MUST be published f= or any protocol

=C2=A0 =C2=A0or mechanism that takes advantage of an= y of these enabling updates.

=C2=A0 =C2=A0

I think I know what you're saying, but this form= ulation confuses me because it's placing a commitment on what a future = working group must do (like, what if the draft describing the experimental protocol is incoherent - can the working group Just Say N= o, or can the authors say "but you have to request publication, becaus= e "An Experimental RFC MUST be published ...").

[David>] The working group c= an Just Say No, and that outcome would be a =E2=80=9Cfeature=E2=80=9D =E2= =80=93 if the experimental protocol is problematic, then the experiment shouldn=E2=80=99t be run at s= cale in the Internet, and the WG will have done the right thing by saying s= o.

=C2=A0

Is your point that any protocol or mechanism that ta= kes advantage of these enabling updates can't be Standards-Track?

[David>] No =E2=80=93 a Stan= dards-Track protocol RFC can simply update RFC 3168 (and any other RFCs tha= t it needs to) directly, and doesn=E2=80=99t need this draft=E2=80=99s permi= ssion to do so, as the next sentence states =E2=80=A6=

=C2=A0

In this text,=C2=A0

=C2=A0

=C2=A0 =C2=A0There is no need to make changes for pr= otocols and mechanisms that

=C2=A0 =C2=A0are documented in Standards Track RFCs,= as any Standards Track RFC

=C2=A0 =C2=A0can update RFC 3168 without needing a s= tandards process exception.

=C2=A0

we've been talking using this terminology for at= least a year that I can remember, but I'm not totally sure that an ave= rage IESG would even approve an Experimental draft that updated a standards-track RFC. How badly do you need to say this at all, since you= 're just confirming a well-understood fact that I think we all agree on= ?

[David>] This has been broug= ht up too many times in WG discussion of this draft to leave out, IMHO.

=C2=A0

In this text,

=C2=A0

=C2=A0 =C2=A0A study of the ECN behaviour of the Ale= xa top 1M web

=C2=A0 =C2=A0servers using 2014 data [Trammell15]=C2= =A0

=C2=A0 =C2=A0

I'm wondering whether it's useful to say &qu= ot;Alexa top 1M web servers" in an RFC that will probably last longer = than Alexa lasts ...

[David>] I view this as a = =E2=80=9Cshow your work=E2=80=9D item =E2=80=A6 this is the data that was u= sed at the time.

=C2=A0

I'm sorry that my comment wasn't clear. What= I was asking was if there was any more description of Alexa (or for extra = credit, a URL) so that a reader in ten years can do more than google "= Alexa top 1M web server" to figure out what this is.

=C2=A0

So I'm wondering if you need to qualify "to= p 1M web servers" as "Alexa top 1M web servers", because I&#= 39;m thinking adding the adjective doesn't add as much as it takes away= .=C2=A0

=C2=A0

It may be that the answer is "not really",= and that would be A Fine Answer, but I wanted to make sure you understood = what I was thinking, because it apparently wasn't what I was typing :-)=

=C2=A0

Either way, I'm ready for you to send the update= d version and have me initiate Last Call, and thanks for horsing this throu= gh.

=C2=A0

Spencer

=C2=A0

In this text,

=C2=A0

=C2=A0 =C2=A0Significantly more aggressive sender re= sponses to ECN

=C2=A0 =C2=A0are required to make effective use of s= uch shallow queues; Datacenter

=C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^

=C2=A0 =C2=A0TCP (DCTCP) [I-D.ietf-tcpm-dctcp] provi= des an example. =C2=A0

=C2=A0 =C2=A0

I'm tangled up in passive tense ("who is re= quired to do what?"). Is it correct to say=C2=A0

=C2=A0

=C2=A0 =C2=A0Significantly more aggressive sender re= sponses to ECN

=C2=A0 =C2=A0are needed in order to make effective u= se of such shallow queues;=C2=A0

=C2=A0 =C2=A0Datacenter TCP (DCTCP) [I-D.ietf-tcpm-d= ctcp] provides an example. =C2=A0

=C2=A0

?

=C2=A0 =C2=A0[Da= vid>] Yes, change made.

=C2=A0

I see that the draft uses both the terms "shall= ow queues" and "nearly empty queues". Do these terms mean th= e same thing? If so, perhaps it's worth either picking one term, or say= ing that they mean the same thing. Right now, I'm trying to imagine what t= he difference might be, since both phrases are used.

[David>] Good point, changed= to consistently use =E2=80=9Cvery shallow=E2=80=9D everywhere.<= /b>

=C2=A0

You folks are the experts on this stuff, but I'm= looking at this quoted text from RFC 3168

=C2=A0

=C2=A0RFC 3168 prohibits use of ECN for TCP control = packets and

=C2=A0 =C2=A0retransmitted packets in a number of pl= aces:

=C2=A0

=C2=A0 =C2=A0o =C2=A0"To ensure the reliable de= livery of the congestion indication of

=C2=A0 =C2=A0 =C2=A0 the CE codepoint, an ECT codepo= int MUST NOT be set in a packet

=C2=A0 =C2=A0 =C2=A0 unless the loss of that packet = in the network would be detected by

=C2=A0 =C2=A0 =C2=A0 the end nodes and interpreted a= s an indication of congestion."

=C2=A0 =C2=A0 =C2=A0 (Section 5.2)

=C2=A0

=C2=A0 =C2=A0o =C2=A0"A host MUST NOT set ECT o= n SYN or SYN-ACK packets."

=C2=A0 =C2=A0 =C2=A0 (Section 6.1.1)

=C2=A0

=C2=A0 =C2=A0o =C2=A0"pure acknowledgement pack= ets (e.g., packets that do not contain

=C2=A0 =C2=A0 =C2=A0 any accompanying data) MUST be = sent with the not-ECT codepoint."

=C2=A0 =C2=A0 =C2=A0 (Section 6.1.4)

=C2=A0

=C2=A0 =C2=A0o =C2=A0"This document specifies E= CN-capable TCP implementations MUST NOT

=C2=A0 =C2=A0 =C2=A0 set either ECT codepoint (ECT(0= ) or ECT(1)) in the IP header for

=C2=A0 =C2=A0 =C2=A0 retransmitted data packets, and= that the TCP data receiver SHOULD

=C2=A0 =C2=A0 =C2=A0 ignore the ECN field on arrivin= g data packets that are outside of

=C2=A0 =C2=A0 =C2=A0 the receiver's current wind= ow." =C2=A0(Section 6.1.5)

=C2=A0

=C2=A0 =C2=A0o =C2=A0"the TCP data sender MUST = NOT set either an ECT codepoint or the

=C2=A0 =C2=A0 =C2=A0 CWR bit on window probe packets= ." =C2=A0(Section 6.1.6)

=C2=A0 =C2=A0 =C2=A0=C2=A0

and noticing that only the text in 6.1.5 explicitly = mentions the TCP data receiver ignoring the "MUST NOT set" ECN fi= eld. I took a quick spin through RFC 3168 searching for "ignore", but didn't see something that explicitly covered the other cases.

=C2=A0

Because these are "MUST NOT set" constrain= ts, I could imagine implementers who never anticipated that an ECN(0) or EC= N(1) would be set, and don't look at the field (probably good), but I can also imagine implementers validating that ECN(0) and ECN(1) are = not set (probably bad). Do people have any concerns about encountering &quo= t;ECT values MUST be cleared" implementations during this experiment?<= u>

=C2=A0

I suppose if some implementation that does this is d= eployed and you folks run the experiment, then we'll know :D ...=

[David>] I would leave this = to the drafts/RFCS that describe the experiments, as I expect implementers of the experiments to look there, and not at this process RFC (to be).

=C2=A0

But I wonder if it's worth making that clear for= receivers, since you're updating RFC 3168 anyway?

=C2=A0

In this text,

=C2=A0

=C2=A0 =C2=A0 =C2=A0 Random ECT values MUST NOT be u= sed, as that may expose RTP to

=C2=A0 =C2=A0 =C2=A0 differences in network treatmen= t of traffic marked with ECT(1) and

=C2=A0 =C2=A0 =C2=A0 ECT(0) and differences in assoc= iated endpoint congestion

=C2=A0 =C2=A0 =C2=A0 responses,

=C2=A0 =C2=A0 =C2=A0=C2=A0

is "Random ECT values" the right word? I c= ould imagine this prohibiting using ECT(0) and ECT(1) interchangeably, but = if that's what's intended, I could also imagine this prohibiting simply not explicitly setting the ECT values at all, so missing your point= .

[David>] Yes, =E2=80=9CRando= m=E2=80=9D is the right word, as the text quoted from RFC 6679 uses the wor= d =E2=80=9Crandom=E2=80=9D so that is the correct word to use here, and further explanation can be fo= und in RFC 6679.

=C2=A0

I'm looking at this text

=C2=A0

=C2=A0 =C2=A0As a process memo that makes no changes= to existing protocols, there

=C2=A0 =C2=A0are no protocol security considerations= .

=C2=A0 =C2=A0

and wondering if it's current with the rest of t= he document. Is "no changes to existing protocols" still the righ= t way to characterize this draft? If you wanted to say

=C2=A0

=C2=A0 =C2=A0As a process memo that only adds limita= tions to existing protocols, there

=C2=A0 =C2=A0are no protocol security considerations= .

=C2=A0 =C2=A0

I'd be happy to believe you ...

[David>] I see the concern, = and edited the text roughly as suggested, plus moved a supporting sentence about security considerations for the experiments up to join this= sentence, so the new paragraph now reads:

=C2=A0=

As a process memo that only removes limitations on proposed = experiments,
there are no protocol security considerations.=C2=A0 Security consideration= s for the
proposed experiments are discussed in the Internet-Drafts that propose them= .

=C2=A0

Thanks,

=C2=A0

Spencer=C2=A0

=C2=A0


> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Friday, August 4, 2017 7:29 PM
> To: i-d-ann= ounce@ietf.org
> Cc: tsvwg@ietf.org=
> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation= -04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Transport Area Working Group WG of th= e
> IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Explicit Congestion Notification (ECN) Experimentation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : David Black
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tsvwg-ecn-experimentation-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 17
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-08-04
>
> Abstract:
>=C2=A0 =C2=A0 This memo updates RFC 3168, which specifies Explicit Cong= estion
>=C2=A0 =C2=A0 Notification (ECN) as a replacement for packet drops as i= ndicators of
>=C2=A0 =C2=A0 network congestion.=C2=A0 It relaxes restrictions in RFC = 3168 that would
>=C2=A0 =C2=A0 otherwise hinder experimentation towards benefits beyond = just removal
>=C2=A0 =C2=A0 of loss.=C2=A0 This memo summarizes the anticipated areas= of
>=C2=A0 =C2=A0 experimentation and updates RFC 3168 to enable experiment= ation in
>=C2=A0 =C2=A0 these areas.=C2=A0 An Experimental RFC is required to tak= e advantage of
>=C2=A0 =C2=A0 any of these enabling updates.=C2=A0 In addition, this me= mo makes related
>=C2=A0 =C2=A0 updates to the ECN specifications for RTP in RFC 6679 and= for DCCP in
>=C2=A0 =C2=A0 RFC 4341, RFC 4342 and RFC 5622.=C2=A0 This memo also rec= ords the
>=C2=A0 =C2=A0 conclusion of the ECN Nonce experiment in RFC 3540, and p= rovides the
>=C2=A0 =C2=A0 rationale for reclassification of RFC 3540 as Historic; t= his
>=C2=A0 =C2=A0 reclassification enables new experimental use of the ECT(= 1)
>=C2=A0 =C2=A0 codepoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimenta= tion/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-= 04
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-
> experimentation-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-ecn-experime= ntation-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/

=C2=A0

=C2=A0


--94eb2c0b78985d9d190557fb1a87-- From nobody Wed Aug 30 09:51:36 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44596126BFD; Wed, 30 Aug 2017 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 xoxDCKovLZ3m; Wed, 30 Aug 2017 09:51:28 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D8413213D; Wed, 30 Aug 2017 09:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6043; q=dns/txt; s=iport; t=1504111887; x=1505321487; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/X+PjXpR0lZ2Lj+XfP6za0CNkhSUnSS4mmFboWuR9zk=; b=ksR1vxhgWkUTkUQjmVmJl5rh6emjnlWzwcafsVNHoTal0eBd3UxBb6E9 lJvCDH+DUgwYKF6nczB3D+FhZX83vk9XGLCJkJ6yM3FhWDcFmMqegJQB7 tuKqjqh8O9kEumVjRjdUQIug5sa13SioSGQOrQfK+26TmnlUJj/0ccYDg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAgAj7KZZ/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBiUqLEqlQhUcChGoUAQIBAQEBAQEBayiFGQYjFTgJEAsaAiYCAlcGAQw?= =?us-ascii?q?IAQEXihascoIni0IBAQEBAQEBAQEBAQEBAQEBASGBDYIdg1CBYyuBcIENiAiCY?= =?us-ascii?q?QEEigiWZIg5jBOCEoVng1mHGY1QiHM2IYENMiEIHBWFYRyBaT6LQgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,449,1498521600"; d="scan'208";a="657131680" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 16:51:22 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7UGpMkM029954; Wed, 30 Aug 2017 16:51:22 GMT To: Michael Tuexen , Stefan Winter Cc: ops-dir@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org, tsvwg@ietf.org, ietf@ietf.org, IESG IESG References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> From: Benoit Claise Message-ID: Date: Wed, 30 Aug 2017 18:51:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:51:30 -0000 Michael, I stumbled on the same point as Stefan. First of, I had to review RFC4960 for TSN/SSN. I was not sure whether TSN was per stream or not It would have helped me to repeat this information in the intro. Ok, to be candid, I deduced this information from figure 1 and 2. >> >>>> And the rest are only musings not needing any action if the authors don't want >>>> to action on them: >>>> >>>> The introduction presents a good use case, quoting: "e.g., when the >>>> transmission of an urgent >>>> message is blocked from transmission because the sender has started >>>> the transmission of another, possibly large, message". >>>> >>>> The later queueing example in figure 1 has three SIDs being queued >>>> simultanseously. It is not clear which of those "has already started" and which >>> There is actually one message queued for stream 0, three messages for stream 1, >>> and one message for stream 2. >>>> are the important ones being delayed. For a better understanding of the reader, >>> The figure is about in which sequence they are put on the wire. So no >>> transmission has startet. This examples also does not deal with the case >>> of one stream having a higher priority than another. That would be an >>> example using a priority scheduler. This examples illustrates the round >>> robin scheduler. >>> The point here is that a single scheduler (the round robin scheduler, for >>> example) behaves differently when user message interleaving is used or not. >>> That is an important point: You can even use the schedulers with regular >>> DATA chunk, i.e. with user message interleaving being negotiated. This was my source of confusion. With figure 1 and figure 2, you want to show the effect of Round Robin Scheduler with and without User Message Interleaving, while we were expecting the figure 2 to be the solution from this spec. Hence Stefan and I were looking for this "urgent message" in figure 2. >>>> it might be useful to revise the figure so that the head-of-line blocking >>>> happens for SID 1 because transmission of 0 and 2 has already started (and >>>> declare SID 1 to be the "important" message). The ASCII art would just have to >>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), and the resulting >>>> serialisation would then put all the SID 1 messages at the very end, when 0 and >>>> 2 have been completely submitted (right?). >>> One could think about adding another example based on the priority scheduler >>> and giving stream 1 a higher priority. But for illustrating the point of >>> schedulers behaving differently depending on the negotiation of user message >>> interleaving this seems not necessary. >> That second example might indeed be useful. >> >> It's simply a bit strange that in the introduction you speak about an >> "urgent" message (something deserving a higher-priority sending) and >> that another transmission has already started - but then the example has >> none of those two. Exactly. Please add this extra example. This would also clarify from the introduction that when you write ... The sending of such large messages over SCTP as specified in [RFC4960] can result in a form of sender side head of line blocking (e.g., when the transmission of an urgent message is blocked from transmission because the sender has started the transmission of another, possibly large, message). .. the notion of transmission urgency is not within a stream but across streams, and that can be achieved with a priority scheduler. The text might have to be rephrased to explain that this spec provides the ability to create stream scheduler with different relative stream treatments. And also that urgent message would be placed in this high priority stream scheduler (reliable, I guess, but that's orthogonal) stream. > What about removing the word "urgent" from that sentence. >> In fact I wonder why you speak about urgent things in the introduction >> at all. Neither the scheduler nor the interleaving are designed to help >> urgent things to be sent earlier. >> >> All they do is make the transmission fairer so that *all* chunks get a >> more even serialised distribution on the wire. > That is not true in general. If you use the priority scheduler, one > stream gets preferred treatment. It also makes sure that the time > of a message spent in the stream queue is shorter. So these messages > get sent earlier. > In the case of the round robin scheduler, you are right that this is > about getting fairer treatment. If you take the WFQ scheduler, the > streams don't get the same treatment, but it depends on the weight > given to the stream. >> So, rather than saying that the spec helps urgent things to be sent >> earlier, it should maybe rather state that the spec helps every message >> getting an equal, and equally distributed, share of the medium. > It is not meant that the spec does this. It was one example, what > a particular stream scheduler does. But there are multiple schedulers > defined in the document. > > The RR scheduler example is not intended to illustrate what you can do > with all the schedulers, but that using message interleaving or not > has an impact on the scheduler. That is meant by stating: > > This document also defines several stream schedulers for general SCTP associations. > The stream schedulers may behave differently depending on whether user message > interleaving has been negotiated for the association or not. > > This is followed by illustrating this using the RR scheduler. > > Best regards Also, I don't see the value of the last sentence in this paragraph, especially with RFC2119 MAY. This section defines several stream schedulers. The stream schedulers may behave differently depending on whether user message interleaving has been negotiated for the association or not. An implementation MAY implement any subset of them. Regards, Benoit From nobody Wed Aug 30 09:53:12 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4683C13213D; Wed, 30 Aug 2017 09:53:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150411198528.21565.4589277414442965246.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 09:53:05 -0700 Archived-At: Subject: [tsvwg] Benoit Claise's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 16:53:05 -0000 Benoit Claise has entered the following ballot position for draft-ietf-tsvwg-sctp-ndata-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- See the "Re: [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12" email thread From nobody Wed Aug 30 10:08:42 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7853132344; Wed, 30 Aug 2017 10:08:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150411292076.21586.3758411835007069062@ietfa.amsl.com> Date: Wed, 30 Aug 2017 10:08:40 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 17:08:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Explicit Congestion Notification (ECN) Experimentation Author : David Black Filename : draft-ietf-tsvwg-ecn-experimentation-05.txt Pages : 17 Date : 2017-08-30 Abstract: This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC 3168 that would otherwise hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, and provides the rationale for reclassification of RFC 3540 as Historic; this reclassification enables new experimental use of the ECT(1) codepoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-05 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/ From nobody Wed Aug 30 10:10:16 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DCC1201F8 for ; Wed, 30 Aug 2017 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=dQ2Wnt8N; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=qfRixkPD 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 mTTfc9twGm5i for ; Wed, 30 Aug 2017 10:10:14 -0700 (PDT) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 506691323B4 for ; Wed, 30 Aug 2017 10:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1504113014; x=1535649014; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CZ0hvcVC72wp70fuyj7SCXpg7ChmyGN5M2DHmqiGv6c=; b=dQ2Wnt8N5MnvHItwrbzmOepJzpUHrfSok7eL/u+hK5Vpd664/UU98Nyi 6lL1shPH8xWj6yONYFPCYwEvDyBgV/1171j1xyUAA1DDGjdxleUHpTj24 lr9kQyi4VwhGguZHaP+6WxiCIpLyefUkbw4eaqTQYjsTBO8/h8uv5WM6V A=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 12:10:13 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 23:10:13 +0600 Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7UHABnX027032 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 30 Aug 2017 13:10:12 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v7UHABnX027032 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1504113012; bh=Wy2vUevYpYQI1qmQyKeTX33CvLg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=qfRixkPDyZRQlZ3mUjCsaAK9QASAhzBDhr7/Ev4RenW2cKUHP7doe7eccg3Dhpi6N 1WXg+v3t21Yu05xK/Zuo2GRbYjvc+yBgYqOXflTGUr7evXOVkqoV/rTlgj5TfWlhEA dEjEqti18gCvitmDT/wIIwvnA3DLKmOm9f6LrZ6A= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v7UHABnX027032 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd04.lss.emc.com (RSA Interceptor) for ; Wed, 30 Aug 2017 13:08:56 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7UH9vKr022273 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 30 Aug 2017 13:09:57 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 13:09:56 -0400 To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-ietf-tsvwg-ecn-experimentation-05.txt Thread-Index: AQHTIbKmjK2JJDcl6EWcXrzXgdBsgqKdIhkQ Date: Wed, 30 Aug 2017 17:09:56 +0000 Message-ID: References: <150411292098.21586.12094916227404292009.idtracker@ietfa.amsl.com> In-Reply-To: <150411292098.21586.12094916227404292009.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.2.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Subject: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-ecn-experimentation-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 17:10:16 -0000 VGhpcyB2ZXJzaW9uIGNvbnRhaW5zIG1pbm9yIGVkaXRvcmlhbCB1cGRhdGVzIGZyb20gU3BlbmNl cidzIEFEIHJldmlldy4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMzAsIDIwMTcgMTowOSBQ TQ0KVG86IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0 aW9uLTA1LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXRzdndnLWVj bi1leHBlcmltZW50YXRpb24tMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IERhdmlkIEJsYWNrIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5h bWU6CQlkcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24NClJldmlzaW9uOgkwNQ0K VGl0bGU6CQlFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBFeHBlcmltZW50 YXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTctMDgtMzANCkdyb3VwOgkJdHN2d2cNClBhZ2VzOgkJ MTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA1LnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctZWNu LWV4cGVyaW1lbnRhdGlvbi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA1DQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRz dndnLWVjbi1leHBlcmltZW50YXRpb24tMDUNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9u LTA1DQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIHVwZGF0ZXMgUkZDIDMxNjgsIHdoaWNoIHNw ZWNpZmllcyBFeHBsaWNpdCBDb25nZXN0aW9uDQogICBOb3RpZmljYXRpb24gKEVDTikgYXMgYSBy ZXBsYWNlbWVudCBmb3IgcGFja2V0IGRyb3BzIGFzIGluZGljYXRvcnMgb2YNCiAgIG5ldHdvcmsg Y29uZ2VzdGlvbi4gIEl0IHJlbGF4ZXMgcmVzdHJpY3Rpb25zIGluIFJGQyAzMTY4IHRoYXQgd291 bGQNCiAgIG90aGVyd2lzZSBoaW5kZXIgZXhwZXJpbWVudGF0aW9uIHRvd2FyZHMgYmVuZWZpdHMg YmV5b25kIGp1c3QgcmVtb3ZhbA0KICAgb2YgbG9zcy4gIFRoaXMgbWVtbyBzdW1tYXJpemVzIHRo ZSBhbnRpY2lwYXRlZCBhcmVhcyBvZg0KICAgZXhwZXJpbWVudGF0aW9uIGFuZCB1cGRhdGVzIFJG QyAzMTY4IHRvIGVuYWJsZSBleHBlcmltZW50YXRpb24gaW4NCiAgIHRoZXNlIGFyZWFzLiAgQW4g RXhwZXJpbWVudGFsIFJGQyBpcyByZXF1aXJlZCB0byB0YWtlIGFkdmFudGFnZSBvZg0KICAgYW55 IG9mIHRoZXNlIGVuYWJsaW5nIHVwZGF0ZXMuICBJbiBhZGRpdGlvbiwgdGhpcyBtZW1vIG1ha2Vz IHJlbGF0ZWQNCiAgIHVwZGF0ZXMgdG8gdGhlIEVDTiBzcGVjaWZpY2F0aW9ucyBmb3IgUlRQIGlu IFJGQyA2Njc5IGFuZCBmb3IgRENDUCBpbg0KICAgUkZDIDQzNDEsIFJGQyA0MzQyIGFuZCBSRkMg NTYyMi4gIFRoaXMgbWVtbyBhbHNvIHJlY29yZHMgdGhlDQogICBjb25jbHVzaW9uIG9mIHRoZSBF Q04gTm9uY2UgZXhwZXJpbWVudCBpbiBSRkMgMzU0MCwgYW5kIHByb3ZpZGVzIHRoZQ0KICAgcmF0 aW9uYWxlIGZvciByZWNsYXNzaWZpY2F0aW9uIG9mIFJGQyAzNTQwIGFzIEhpc3RvcmljOyB0aGlz DQogICByZWNsYXNzaWZpY2F0aW9uIGVuYWJsZXMgbmV3IGV4cGVyaW1lbnRhbCB1c2Ugb2YgdGhl IEVDVCgxKQ0KICAgY29kZXBvaW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Wed Aug 30 13:55:03 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AEF1321F1; Wed, 30 Aug 2017 13:54:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150412649452.21628.12275686716505796045.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 13:54:54 -0700 Archived-At: Subject: [tsvwg] Kathleen Moriarty's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:54:55 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-tsvwg-sctp-ndata-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I looked at the references for security considerations, [RFC4960] and [RFC6458], and don't see an explicit mention of fragmentation overlap and in my skim, didn't see that it was covered for reassembly as a warning. Does this need to be added? If not, can you explain how it is covered? From nobody Thu Aug 31 01:01:40 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFE01320B5; Thu, 31 Aug 2017 01:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vu3b-ZQj_bRI; Thu, 31 Aug 2017 01:01:36 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CDE132335; Thu, 31 Aug 2017 01:01:34 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e] (p200300CD6BCC5600FC8643679FA8604E.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9687571B09A83; Thu, 31 Aug 2017 10:01:16 +0200 (CEST) From: Michael Tuexen Message-Id: <6AA4DF70-A0FF-487F-A540-61D605F8A6C7@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_93B390EF-5D09-4DC5-A098-CC53BA07AC8B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 10:01:15 +0200 In-Reply-To: <150412649452.21628.12275686716505796045.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org To: Kathleen Moriarty References: <150412649452.21628.12275686716505796045.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Kathleen Moriarty's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 08:01:39 -0000 --Apple-Mail=_93B390EF-5D09-4DC5-A098-CC53BA07AC8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30. Aug 2017, at 22:54, Kathleen Moriarty = wrote: >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tsvwg-sctp-ndata-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I looked at the references for security considerations, [RFC4960] and > [RFC6458], and don't see an explicit mention of fragmentation overlap = and in my > skim, didn't see that it was covered for reassembly as a warning. = Does this > need to be added? If not, can you explain how it is covered? Hi Kathleen, the fragments don't use a byte range which could overlap, but a sequence numbers. So if the peer doesn't violate the protocol specification, = there can not be any overlap. If the peer does not follow the specification, it could try to send different I-DATA chunks (using different TSNs) but with the same SID, U bit and FSN. A receiver can detect this. In the FreeBSD implementation we ABORT the association in this case indicating a Protocol Violation. An alternative would be to just drop the first (in case it is not partially delivered yet) or drop the second I-DATA chunk. I guess this is implementation dependent. We had already in RFC = 4960 the situation that we have no specified the various ways on inconsistent parameter combinations and how to deal with them. Does this clarify this issue?=20 Best regards Michael >=20 >=20 --Apple-Mail=_93B390EF-5D09-4DC5-A098-CC53BA07AC8B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzEwODAxMTVaMCMGCSqGSIb3DQEJBDEWBBRjx3cRbGM5SUzxjVdM Dw2QVntrkDCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQCsGAOCsk9Z+Sc4L4xia92/5b32k+nMqLgZ jWXk2ZnsLNOuNIpFGJA8Z7Fh6a7X7pfzQofAbIIUa58W/DGZqL5t5m4NgBy8tgOPZ72hKfCS+Z3p 0EZR5X6x/p8zkd35KRYoOk0Ui5axGUaoffgNYuv9nYBThjS8hrc4RS77QxAm5AUMaYNeveuOAOXl hm+6odItIk1kfJ2sunEvProFIK0O6LAduQfqXSj3MIYmrwTgPcSs8Vh5eF+NZ2R+k+eRqFvC4ynv IrRVe2S4zFyHgfR5JKHHeHwEOxzr6MO/vwmF25N8bj/vXnPEf9zUuK+SHTOFYXgypbe7PyzfJ5+1 V2fMAAAAAAAA --Apple-Mail=_93B390EF-5D09-4DC5-A098-CC53BA07AC8B-- From nobody Thu Aug 31 04:19:37 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AD2132D5F; Thu, 31 Aug 2017 04:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-nJVFPIpuPA; Thu, 31 Aug 2017 04:19:33 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 0D449132D56; Thu, 31 Aug 2017 04:19:31 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id v20so1417785qtg.3; Thu, 31 Aug 2017 04:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XhaezG76qJoMerM48u6q11Trh8gO5uzvJWf8UuYvbhs=; b=DWActSyJwwCgjzPgi/8t5j4l3ZHZYcqKSdxhpBion2MJjylpVUdxNsS791E1lncXLD D/hgsPe1ZpRqXU9LIC0Ve/uTm08A1W10PxY7FDxMyeVYbuFJc9I/2rUFyoO+OMk/RdiZ OXMwk9YpivBK5VWJn9Sv5N5ROG0v+AljtB1pnhjRyKXQNoUQ+quk2ONd9EvvvBiC5vxI 8STnDT2QMlT78K5WrZdZK6qJTE6FBol3+vQ+itd+M1GxI5yBxc6ErmMr3zkA94/yWSTw PNAYLrxTH9p8RFwFa8WULduNMXBaWo1rRLFtoQcdxPs8RoJI4db+T5SEkHJA3HDdgNY8 z9SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XhaezG76qJoMerM48u6q11Trh8gO5uzvJWf8UuYvbhs=; b=dUjMVjue3IaR+3hXjrCfq3eQKjDKA9YvvUu7oHtl0W29agXM2cmWDvN7mlaQfFxvKs JfxmDG3rYCK/CpwkQottqofDI1A1O9OjwuNRkrLKfEQMc+/rjPY+jF1KL1yKIbKZ+EZr RdeYvHGUjFD+APwgSUStD6TVsSnUVOr5GTuDzkj0BzU63Op8llNHtenWiZ8gIIaE7yyR L/upUrNR4+VlhWXEICEL7vvEXkH89lHUmlHO7U94vxIWDTwpxYi7kk4GqWRaK+7iFXhZ 03oytddvAuEcPIAGzMvoJ+uDT6nnj9gIGrJw1bcFPwcCXD8ls31VTv0C08MYKUTm9GgI gW0w== X-Gm-Message-State: AHYfb5gkxRCJQECd4eWUMwky79DIslS6vgUnD9cWdHEefCplT1AaCcSt xHkW526qF7de3IzNqWc= X-Google-Smtp-Source: ADKCNb7x8EIsGAS/qGc7nhz8ZdyozDWZObDuIigqyIh+LQnqm3ff02lLGF8VrENgdgRlG8gmMbEmJQ== X-Received: by 10.200.54.137 with SMTP id a9mr6184085qtc.242.1504178370862; Thu, 31 Aug 2017 04:19:30 -0700 (PDT) Received: from [192.168.1.13] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id r48sm5201298qte.57.2017.08.31.04.19.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 04:19:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <6AA4DF70-A0FF-487F-A540-61D605F8A6C7@fh-muenster.de> Date: Thu, 31 Aug 2017 07:19:28 -0400 Cc: The IESG , draft-ietf-tsvwg-sctp-ndata@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150412649452.21628.12275686716505796045.idtracker@ietfa.amsl.com> <6AA4DF70-A0FF-487F-A540-61D605F8A6C7@fh-muenster.de> To: Michael Tuexen Archived-At: Subject: Re: [tsvwg] Kathleen Moriarty's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:19:35 -0000 Sent from my iPhone On Aug 31, 2017, at 4:01 AM, Michael Tuexen wrote: >> On 30. Aug 2017, at 22:54, Kathleen Moriarty wrote: >>=20 >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-tsvwg-sctp-ndata-12: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> I looked at the references for security considerations, [RFC4960] and >> [RFC6458], and don't see an explicit mention of fragmentation overlap and= in my >> skim, didn't see that it was covered for reassembly as a warning. Does t= his >> need to be added? If not, can you explain how it is covered? > Hi Kathleen, >=20 > the fragments don't use a byte range which could overlap, but a sequence > numbers. So if the peer doesn't violate the protocol specification, there > can not be any overlap. If the peer does not follow the specification, > it could try to send different I-DATA chunks (using different TSNs) but > with the same SID, U bit and FSN. A receiver can detect this. In the > FreeBSD implementation we ABORT the association in this case indicating > a Protocol Violation. An alternative would be to just drop the first > (in case it is not partially delivered yet) or drop the second I-DATA > chunk. I guess this is implementation dependent. We had already in RFC 496= 0 > the situation that we have no specified the various ways on inconsistent > parameter combinations and how to deal with them. >=20 > Does this clarify this issue?=20 Yes, thank you. Kathleen=20 >=20 > Best regards > Michael >>=20 >>=20 >=20 From nobody Thu Aug 31 05:00:36 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD611132D4E; Thu, 31 Aug 2017 05:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 jeZh6Efl3oEA; Thu, 31 Aug 2017 05:00:24 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C34132D5A; Thu, 31 Aug 2017 05:00:19 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e] (p200300CD6BCC5600FC8643679FA8604E.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id E0E9871E3F8DC; Thu, 31 Aug 2017 14:00:06 +0200 (CEST) From: Michael Tuexen Message-Id: <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_C4475747-0DBC-4EE5-A518-4111208F0FD3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 14:00:05 +0200 In-Reply-To: Cc: Stefan Winter , ops-dir@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org, tsvwg@ietf.org, ietf@ietf.org, IESG IESG To: Benoit Claise References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:00:29 -0000 --Apple-Mail=_C4475747-0DBC-4EE5-A518-4111208F0FD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30. Aug 2017, at 18:51, Benoit Claise wrote: >=20 > Michael, >=20 > I stumbled on the same point as Stefan. Hi Benoit, thanks for reviewing the document. See my comments in-line. Best regards Michael >=20 > First of, I had to review RFC4960 for TSN/SSN. I was not sure whether = TSN was per stream or not > It would have helped me to repeat this information in the intro. > Ok, to be candid, I deduced this information from figure 1 and 2. >>>=20 >>>>> And the rest are only musings not needing any action if the = authors don't want >>>>> to action on them: >>>>>=20 >>>>> The introduction presents a good use case, quoting: "e.g., when = the >>>>> transmission of an urgent >>>>> message is blocked from transmission because the sender has = started >>>>> the transmission of another, possibly large, message". >>>>>=20 >>>>> The later queueing example in figure 1 has three SIDs being queued >>>>> simultanseously. It is not clear which of those "has already = started" and which >>>> There is actually one message queued for stream 0, three messages = for stream 1, >>>> and one message for stream 2. >>>>> are the important ones being delayed. For a better understanding = of the reader, >>>> The figure is about in which sequence they are put on the wire. So = no >>>> transmission has startet. This examples also does not deal with the = case >>>> of one stream having a higher priority than another. That would be = an >>>> example using a priority scheduler. This examples illustrates the = round >>>> robin scheduler. >>>> The point here is that a single scheduler (the round robin = scheduler, for >>>> example) behaves differently when user message interleaving is used = or not. >>>> That is an important point: You can even use the schedulers with = regular >>>> DATA chunk, i.e. with user message interleaving being negotiated. > This was my source of confusion. > With figure 1 and figure 2, you want to show the effect of Round Robin = Scheduler with and without User Message Interleaving, while we were = expecting the figure 2 to be the solution from this spec. Hence Stefan = and I were looking for this "urgent message" in figure 2. I don't know what you mean with "solution from this spec" means. This = spec introduces stream schedulers and a protocol extension to allow interleaving of user = messages. Using this to implement an "urgent" concept is only one possibility: = usage of a strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is = misleading. It seems to ring the wrong bells. That is why I suggested to remove it... >=20 >>>>> it might be useful to revise the figure so that the head-of-line = blocking >>>>> happens for SID 1 because transmission of 0 and 2 has already = started (and >>>>> declare SID 1 to be the "important" message). The ASCII art would = just have to >>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), and = the resulting >>>>> serialisation would then put all the SID 1 messages at the very = end, when 0 and >>>>> 2 have been completely submitted (right?). >>>> One could think about adding another example based on the priority = scheduler >>>> and giving stream 1 a higher priority. But for illustrating the = point of >>>> schedulers behaving differently depending on the negotiation of = user message >>>> interleaving this seems not necessary. >>> That second example might indeed be useful. >>>=20 >>> It's simply a bit strange that in the introduction you speak about = an >>> "urgent" message (something deserving a higher-priority sending) and >>> that another transmission has already started - but then the example = has >>> none of those two. > Exactly. > Please add this extra example. > This would also clarify from the introduction that when you write ... >=20 > The sending of such large messages over > SCTP as specified in [RFC4960] can result in a form of sender side > head of line blocking (e.g., when the transmission of an urgent > message is blocked from transmission because the sender has started > the transmission of another, possibly large, message). >=20 > .. the notion of transmission urgency is not within a stream but = across streams, and that can be achieved with a priority scheduler. I would actually prefer to remove the word "urgent" from that sentence. = This just rings the wrong bells. > The text might have to be rephrased to explain that this spec provides = the ability to create stream scheduler with different relative stream = treatments. What about: OLD TEXT This document also defines several stream schedulers for general SCTP associations. The stream schedulers may behave differently depending on whether user message interleaving has been negotiated for the association or not. NEW TEXT This document also defines several stream schedulers for general SCTP associations allowing different relative stream treatments. The stream schedulers may behave differently depending on whether user message interleaving has been negotiated for the association or not. Would that address this issue? =20 > And also that urgent message would be placed in this high priority = stream scheduler (reliable, I guess, but that's orthogonal) stream. I really would like to get rid of this. I don't think giving the strict priority scheduler as specific role here is a good idea. The RR scheduler was chosen as the simplest scheduler to illustrate that scheduler can behave differently when using interleaving or not. >> What about removing the word "urgent" from that sentence. >>> In fact I wonder why you speak about urgent things in the = introduction >>> at all. Neither the scheduler nor the interleaving are designed to = help >>> urgent things to be sent earlier. >>>=20 >>> All they do is make the transmission fairer so that *all* chunks get = a >>> more even serialised distribution on the wire. >> That is not true in general. If you use the priority scheduler, one >> stream gets preferred treatment. It also makes sure that the time >> of a message spent in the stream queue is shorter. So these messages >> get sent earlier. >> In the case of the round robin scheduler, you are right that this is >> about getting fairer treatment. If you take the WFQ scheduler, the >> streams don't get the same treatment, but it depends on the weight >> given to the stream. >>> So, rather than saying that the spec helps urgent things to be sent >>> earlier, it should maybe rather state that the spec helps every = message >>> getting an equal, and equally distributed, share of the medium. >> It is not meant that the spec does this. It was one example, what >> a particular stream scheduler does. But there are multiple schedulers >> defined in the document. >>=20 >> The RR scheduler example is not intended to illustrate what you can = do >> with all the schedulers, but that using message interleaving or not >> has an impact on the scheduler. That is meant by stating: >>=20 >> This document also defines several stream schedulers for general SCTP = associations. >> The stream schedulers may behave differently depending on whether = user message >> interleaving has been negotiated for the association or not. >>=20 >> This is followed by illustrating this using the RR scheduler. >>=20 >> Best regards > Also, I don't see the value of the last sentence in this paragraph, = especially with RFC2119 MAY. >=20 > This section defines several stream schedulers. The stream > schedulers may behave differently depending on whether user message > interleaving has been negotiated for the association or not. An > implementation MAY implement any subset of them. During the review the question was brought up which scheduler have to be = implemented by an implementation. This sentence was add to address it. If you want, I can remove it. >=20 >=20 > Regards, Benoit --Apple-Mail=_C4475747-0DBC-4EE5-A518-4111208F0FD3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzExMjAwMDZaMCMGCSqGSIb3DQEJBDEWBBT3Zjz4KhGgMKRKoR1+ G5eOcAssQzCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQCEsHoF6y9d/h/T9TRhZ3uCOviJIUPh9aNV ksUnsTYnbrDoN9xy4NzGspatHf93gObjt3OXtueV+5OcXHAhC5S2w+78Bn7kIrXcjIh5472p04/S Q1FokQ0yWlffHPavfzM5iDrafOcEcO6sRDXWKSGDMHK2gi5OBeaqAOImTcG5pDmHK1MMacvjuvcb js2+0LkVISvXkk+w4iN0FknV7+ljxfDWNMcQ+B0APSnvLjg6QMdU6DdV4tEWINbu37UN5+KyhiN8 Mnfv0JXLhQ0zw7Ms9rrKjCbdwcjIv9lLBw9LDfcJiDsquqCIAhtoc5I4jRUf61ITTWOC5qfaAF6C ybdnAAAAAAAA --Apple-Mail=_C4475747-0DBC-4EE5-A518-4111208F0FD3-- From nobody Thu Aug 31 05:14:26 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEF4132C28; Thu, 31 Aug 2017 05:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uNG9WH4XqA10; Thu, 31 Aug 2017 05:14:12 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937181321A5; Thu, 31 Aug 2017 05:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8285; q=dns/txt; s=iport; t=1504181651; x=1505391251; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=nbwDEJ9D8OAM51hwM7RC86bUNF+gLqGdFxrKzfU376M=; b=gJ8lUlMMb9HTFABFvR0PsW83eHNDOYNUVWUfzsQ/QDzhrsi6surFaIXC R4saLkt/6an/S2jM5GZVKfnYbBcxIJzK3cDpCr9eSYpaB1/tA7RUgFK0K KEo7k2cy1ReQFGrdbp26GWEQCqLEEFPFYeXiiMeUF5NytKvjLBwLzBsx/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQBZ/KdZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhVOPC5B5IneXQoVHAoRZFAECAQEBAQEBAWsohRkBBTg4CRALGC5?= =?us-ascii?q?XBg0GAgEBF4oWsSaLRQEBAQEBAQEBAgEBAQEBAQEBAQEBHYMqg1CBYysLgWVYN?= =?us-ascii?q?YppBYoIlmeIPIwVghOFZ4NZhxuNUohzNiGBDTIhCBwVhWEcgWk+NopMAQEB?= X-IronPort-AV: E=Sophos;i="5.41,453,1498521600"; d="scan'208";a="657149266" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 12:14:06 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7VCE42P014125; Thu, 31 Aug 2017 12:14:05 GMT To: Michael Tuexen Cc: Stefan Winter , ops-dir@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org, tsvwg@ietf.org, ietf@ietf.org, IESG IESG References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> From: Benoit Claise Message-ID: <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> Date: Thu, 31 Aug 2017 14:14:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:14:15 -0000 Hi Michael, >> On 30. Aug 2017, at 18:51, Benoit Claise wrote: >> >> Michael, >> >> I stumbled on the same point as Stefan. > Hi Benoit, > > thanks for reviewing the document. See my comments in-line. > > Best regards > Michael >> First of, I had to review RFC4960 for TSN/SSN. I was not sure whether TSN was per stream or not >> It would have helped me to repeat this information in the intro. >> Ok, to be candid, I deduced this information from figure 1 and 2. >>>>>> And the rest are only musings not needing any action if the authors don't want >>>>>> to action on them: >>>>>> >>>>>> The introduction presents a good use case, quoting: "e.g., when the >>>>>> transmission of an urgent >>>>>> message is blocked from transmission because the sender has started >>>>>> the transmission of another, possibly large, message". >>>>>> >>>>>> The later queueing example in figure 1 has three SIDs being queued >>>>>> simultanseously. It is not clear which of those "has already started" and which >>>>> There is actually one message queued for stream 0, three messages for stream 1, >>>>> and one message for stream 2. >>>>>> are the important ones being delayed. For a better understanding of the reader, >>>>> The figure is about in which sequence they are put on the wire. So no >>>>> transmission has startet. This examples also does not deal with the case >>>>> of one stream having a higher priority than another. That would be an >>>>> example using a priority scheduler. This examples illustrates the round >>>>> robin scheduler. >>>>> The point here is that a single scheduler (the round robin scheduler, for >>>>> example) behaves differently when user message interleaving is used or not. >>>>> That is an important point: You can even use the schedulers with regular >>>>> DATA chunk, i.e. with user message interleaving being negotiated. >> This was my source of confusion. >> With figure 1 and figure 2, you want to show the effect of Round Robin Scheduler with and without User Message Interleaving, while we were expecting the figure 2 to be the solution from this spec. Hence Stefan and I were looking for this "urgent message" in figure 2. > I don't know what you mean with "solution from this spec" means. This spec introduces > stream schedulers and a protocol extension to allow interleaving of user messages. > Using this to implement an "urgent" concept is only one possibility: usage of a > strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is misleading. It seems > to ring the wrong bells. That is why I suggested to remove it... >>>>>> it might be useful to revise the figure so that the head-of-line blocking >>>>>> happens for SID 1 because transmission of 0 and 2 has already started (and >>>>>> declare SID 1 to be the "important" message). The ASCII art would just have to >>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), and the resulting >>>>>> serialisation would then put all the SID 1 messages at the very end, when 0 and >>>>>> 2 have been completely submitted (right?). >>>>> One could think about adding another example based on the priority scheduler >>>>> and giving stream 1 a higher priority. But for illustrating the point of >>>>> schedulers behaving differently depending on the negotiation of user message >>>>> interleaving this seems not necessary. >>>> That second example might indeed be useful. >>>> >>>> It's simply a bit strange that in the introduction you speak about an >>>> "urgent" message (something deserving a higher-priority sending) and >>>> that another transmission has already started - but then the example has >>>> none of those two. >> Exactly. >> Please add this extra example. >> This would also clarify from the introduction that when you write ... >> >> The sending of such large messages over >> SCTP as specified in [RFC4960] can result in a form of sender side >> head of line blocking (e.g., when the transmission of an urgent >> message is blocked from transmission because the sender has started >> the transmission of another, possibly large, message). >> >> .. the notion of transmission urgency is not within a stream but across streams, and that can be achieved with a priority scheduler. > I would actually prefer to remove the word "urgent" from that sentence. This just rings the wrong bells. That's a missed opportunity in mind, but your call. >> The text might have to be rephrased to explain that this spec provides the ability to create stream scheduler with different relative stream treatments. > What about: > > OLD TEXT > This document also defines several stream schedulers for general SCTP > associations. The stream schedulers may behave differently depending > on whether user message interleaving has been negotiated for the > association or not. > > NEW TEXT > This document also defines several stream schedulers for general SCTP > associations allowing different relative stream treatments. > The stream schedulers may behave differently depending > on whether user message interleaving has been negotiated for the > association or not. > > Would that address this issue? ok. > >> And also that urgent message would be placed in this high priority stream scheduler (reliable, I guess, but that's orthogonal) stream. > I really would like to get rid of this. I don't think giving the strict > priority scheduler as specific role here is a good idea. > > The RR scheduler was chosen as the simplest scheduler to illustrate > that scheduler can behave differently when using interleaving or not. >>> What about removing the word "urgent" from that sentence. >>>> In fact I wonder why you speak about urgent things in the introduction >>>> at all. Neither the scheduler nor the interleaving are designed to help >>>> urgent things to be sent earlier. >>>> >>>> All they do is make the transmission fairer so that *all* chunks get a >>>> more even serialised distribution on the wire. >>> That is not true in general. If you use the priority scheduler, one >>> stream gets preferred treatment. It also makes sure that the time >>> of a message spent in the stream queue is shorter. So these messages >>> get sent earlier. >>> In the case of the round robin scheduler, you are right that this is >>> about getting fairer treatment. If you take the WFQ scheduler, the >>> streams don't get the same treatment, but it depends on the weight >>> given to the stream. >>>> So, rather than saying that the spec helps urgent things to be sent >>>> earlier, it should maybe rather state that the spec helps every message >>>> getting an equal, and equally distributed, share of the medium. >>> It is not meant that the spec does this. It was one example, what >>> a particular stream scheduler does. But there are multiple schedulers >>> defined in the document. >>> >>> The RR scheduler example is not intended to illustrate what you can do >>> with all the schedulers, but that using message interleaving or not >>> has an impact on the scheduler. That is meant by stating: >>> >>> This document also defines several stream schedulers for general SCTP associations. >>> The stream schedulers may behave differently depending on whether user message >>> interleaving has been negotiated for the association or not. >>> >>> This is followed by illustrating this using the RR scheduler. >>> >>> Best regards >> Also, I don't see the value of the last sentence in this paragraph, especially with RFC2119 MAY. >> >> This section defines several stream schedulers. The stream >> schedulers may behave differently depending on whether user message >> interleaving has been negotiated for the association or not. An >> implementation MAY implement any subset of them. > During the review the question was brought up which scheduler have to be implemented > by an implementation. This sentence was add to address it. > If you want, I can remove it. The point is that the MAY is that sentence doesn't mean anything. Maybe you mean: An implementation MUST implement at least one stream scheduler. Regards, B. >> >> Regards, Benoit From nobody Thu Aug 31 05:26:09 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5EC132D89; Thu, 31 Aug 2017 05:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 K8horQYwViPi; Thu, 31 Aug 2017 05:25:59 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9AE132D7A; Thu, 31 Aug 2017 05:25:58 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e] (p200300CD6BCC5600FC8643679FA8604E.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id EF2AA71E3F8DC; Thu, 31 Aug 2017 14:25:45 +0200 (CEST) From: Michael Tuexen Message-Id: <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_AAD0B188-5B38-426F-8798-1F4C7B98335D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 14:25:44 +0200 In-Reply-To: <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> Cc: Stefan Winter , ops-dir@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org, tsvwg@ietf.org, ietf@ietf.org, IESG IESG To: Benoit Claise References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:26:02 -0000 --Apple-Mail=_AAD0B188-5B38-426F-8798-1F4C7B98335D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 31. Aug 2017, at 14:14, Benoit Claise wrote: >=20 > Hi Michael, >>> On 30. Aug 2017, at 18:51, Benoit Claise wrote: >>>=20 >>> Michael, >>>=20 >>> I stumbled on the same point as Stefan. >> Hi Benoit, >>=20 >> thanks for reviewing the document. See my comments in-line. >>=20 >> Best regards >> Michael >>> First of, I had to review RFC4960 for TSN/SSN. I was not sure = whether TSN was per stream or not >>> It would have helped me to repeat this information in the intro. >>> Ok, to be candid, I deduced this information from figure 1 and 2. >>>>>>> And the rest are only musings not needing any action if the = authors don't want >>>>>>> to action on them: >>>>>>>=20 >>>>>>> The introduction presents a good use case, quoting: "e.g., when = the >>>>>>> transmission of an urgent >>>>>>> message is blocked from transmission because the sender has = started >>>>>>> the transmission of another, possibly large, message". >>>>>>>=20 >>>>>>> The later queueing example in figure 1 has three SIDs being = queued >>>>>>> simultanseously. It is not clear which of those "has already = started" and which >>>>>> There is actually one message queued for stream 0, three messages = for stream 1, >>>>>> and one message for stream 2. >>>>>>> are the important ones being delayed. For a better understanding = of the reader, >>>>>> The figure is about in which sequence they are put on the wire. = So no >>>>>> transmission has startet. This examples also does not deal with = the case >>>>>> of one stream having a higher priority than another. That would = be an >>>>>> example using a priority scheduler. This examples illustrates the = round >>>>>> robin scheduler. >>>>>> The point here is that a single scheduler (the round robin = scheduler, for >>>>>> example) behaves differently when user message interleaving is = used or not. >>>>>> That is an important point: You can even use the schedulers with = regular >>>>>> DATA chunk, i.e. with user message interleaving being negotiated. >>> This was my source of confusion. >>> With figure 1 and figure 2, you want to show the effect of Round = Robin Scheduler with and without User Message Interleaving, while we = were expecting the figure 2 to be the solution from this spec. Hence = Stefan and I were looking for this "urgent message" in figure 2. >> I don't know what you mean with "solution from this spec" means. This = spec introduces >> stream schedulers and a protocol extension to allow interleaving of = user messages. >> Using this to implement an "urgent" concept is only one possibility: = usage of a >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is = misleading. It seems >> to ring the wrong bells. That is why I suggested to remove it... >>>>>>> it might be useful to revise the figure so that the head-of-line = blocking >>>>>>> happens for SID 1 because transmission of 0 and 2 has already = started (and >>>>>>> declare SID 1 to be the "important" message). The ASCII art = would just have to >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), = and the resulting >>>>>>> serialisation would then put all the SID 1 messages at the very = end, when 0 and >>>>>>> 2 have been completely submitted (right?). >>>>>> One could think about adding another example based on the = priority scheduler >>>>>> and giving stream 1 a higher priority. But for illustrating the = point of >>>>>> schedulers behaving differently depending on the negotiation of = user message >>>>>> interleaving this seems not necessary. >>>>> That second example might indeed be useful. >>>>>=20 >>>>> It's simply a bit strange that in the introduction you speak about = an >>>>> "urgent" message (something deserving a higher-priority sending) = and >>>>> that another transmission has already started - but then the = example has >>>>> none of those two. >>> Exactly. >>> Please add this extra example. >>> This would also clarify from the introduction that when you write = ... >>>=20 >>> The sending of such large messages over >>> SCTP as specified in [RFC4960] can result in a form of sender side >>> head of line blocking (e.g., when the transmission of an urgent >>> message is blocked from transmission because the sender has = started >>> the transmission of another, possibly large, message). >>>=20 >>> .. the notion of transmission urgency is not within a stream but = across streams, and that can be achieved with a priority scheduler. >> I would actually prefer to remove the word "urgent" from that = sentence. This just rings the wrong bells. > That's a missed opportunity in mind, but your call. Hmm. Let me remove the word "urgent"... >>> The text might have to be rephrased to explain that this spec = provides the ability to create stream scheduler with different relative = stream treatments. >> What about: >>=20 >> OLD TEXT >> This document also defines several stream schedulers for general = SCTP >> associations. The stream schedulers may behave differently = depending >> on whether user message interleaving has been negotiated for the >> association or not. >>=20 >> NEW TEXT >> This document also defines several stream schedulers for general = SCTP >> associations allowing different relative stream treatments. >> The stream schedulers may behave differently depending >> on whether user message interleaving has been negotiated for the >> association or not. >>=20 >> Would that address this issue? > ok. Fixed. >> =20 >>> And also that urgent message would be placed in this high priority = stream scheduler (reliable, I guess, but that's orthogonal) stream. >> I really would like to get rid of this. I don't think giving the = strict >> priority scheduler as specific role here is a good idea. >>=20 >> The RR scheduler was chosen as the simplest scheduler to illustrate >> that scheduler can behave differently when using interleaving or not. >>>> What about removing the word "urgent" from that sentence. >>>>> In fact I wonder why you speak about urgent things in the = introduction >>>>> at all. Neither the scheduler nor the interleaving are designed to = help >>>>> urgent things to be sent earlier. >>>>>=20 >>>>> All they do is make the transmission fairer so that *all* chunks = get a >>>>> more even serialised distribution on the wire. >>>> That is not true in general. If you use the priority scheduler, one >>>> stream gets preferred treatment. It also makes sure that the time >>>> of a message spent in the stream queue is shorter. So these = messages >>>> get sent earlier. >>>> In the case of the round robin scheduler, you are right that this = is >>>> about getting fairer treatment. If you take the WFQ scheduler, the >>>> streams don't get the same treatment, but it depends on the weight >>>> given to the stream. >>>>> So, rather than saying that the spec helps urgent things to be = sent >>>>> earlier, it should maybe rather state that the spec helps every = message >>>>> getting an equal, and equally distributed, share of the medium. >>>> It is not meant that the spec does this. It was one example, what >>>> a particular stream scheduler does. But there are multiple = schedulers >>>> defined in the document. >>>>=20 >>>> The RR scheduler example is not intended to illustrate what you can = do >>>> with all the schedulers, but that using message interleaving or not >>>> has an impact on the scheduler. That is meant by stating: >>>>=20 >>>> This document also defines several stream schedulers for general = SCTP associations. >>>> The stream schedulers may behave differently depending on whether = user message >>>> interleaving has been negotiated for the association or not. >>>>=20 >>>> This is followed by illustrating this using the RR scheduler. >>>>=20 >>>> Best regards >>> Also, I don't see the value of the last sentence in this paragraph, = especially with RFC2119 MAY. >>>=20 >>> This section defines several stream schedulers. The stream >>> schedulers may behave differently depending on whether user = message >>> interleaving has been negotiated for the association or not. An >>> implementation MAY implement any subset of them. >> During the review the question was brought up which scheduler have to = be implemented >> by an implementation. This sentence was add to address it. >> If you want, I can remove it. > The point is that the MAY is that sentence doesn't mean anything. > Maybe you mean: >=20 > An implementation MUST implement at least one stream scheduler. That would require an implementation to implement at least one of the ones being listed. You are right in the sense that an implementation MUST implement at least one stream scheduler, but the original text allows that one not to be specified in this document. Are you saying that an implementation MUST implement one of list defined by this document? Best regards Michael >=20 > Regards, B. >>>=20 >>> Regards, Benoit >=20 --Apple-Mail=_AAD0B188-5B38-426F-8798-1F4C7B98335D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzExMjI1NDRaMCMGCSqGSIb3DQEJBDEWBBRd0E4XEZcDQqh9dQvY p3u40gZxSjCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQA84RsndYwSXhJOgw5oF/pa+A2XDuSXCSfF v5cIHQqF4A6YOD8XolKEPG4F25qL1+h3YEe4/vqSW0XLjdDKSxld3nDjmnZpxpmFMLoZaoYzwhiG tIig9og0nfE1lQ31qLcE+OuSWKOfrS84Xf28X0Y4ukcpfzt2C7P2F8UKh+ZPPjKl2fHlAVnNzSmg Zxt1dhF5hW7OvMXOxXSQ5rgPlX1nuNtpqBRHRAO4rwXlju1JAkNbWprQ5ff6fN3yIrV/zPCKNUS2 mGeYECoPrRuPRNc7JgavVXFnYxPLihN701XPWxXN92eEEoA3kesETY5iTprINS+eInWRjDcH7MfA wW7MAAAAAAAA --Apple-Mail=_AAD0B188-5B38-426F-8798-1F4C7B98335D-- From nobody Thu Aug 31 05:51:13 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93598132D5B; Thu, 31 Aug 2017 05:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhcSX58KI36o; Thu, 31 Aug 2017 05:50:44 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A938A132D8C; Thu, 31 Aug 2017 05:50:44 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id s187so2712229ywf.2; Thu, 31 Aug 2017 05:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZjTj+gd9Jygj3Ez/rXn7FvYoqYJUILFoivuog0b57C8=; b=FzT/diQtHLiDD5Z3d5uOeNPE3ZhPkBq4+dMJJRX5/8CaXWGOfpL3TP2ftBe8xugqCH vJ7PahQFq1J0PNTRRnXLEHAgT8Z6kVF+9TgpCJQdxqdhmH9sUVRxuVyPapsi4vPGLYsL fS+l9t88pNTWEKJPOcu4hHhwLnmfsWT2q+O3FNkn/Tqrvxrs4wMpGHPsbohJG03zPlDJ vIf1ToO7hugEDRsE7kTa2u/cI6nT8ngVLFmA4Pa0YjicTS97KghxwutSyC2TaqrO6rZv 1+79ZHWc2K8VHqIlJeOEe5gSmzEbUEnZjWi7BtcAXHgRqjHdm3nYuYk7xQKNaBdYX4l+ XIWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZjTj+gd9Jygj3Ez/rXn7FvYoqYJUILFoivuog0b57C8=; b=S3JKX6eWVyxMkTv77OZH3rX1OmPHlvitytocublNP78jON7NOL+/+N+lNpPPRU/Yd8 iRM+gKY0hf30cgzvNMpRr6KQKqj6EGo7aIWWOwceI4WPghwidD4EK0ymnnEeYDtbo/T3 HQFQTGMijbK3vIKhlmjGYH2fNQa3kn307cXdj3mlhXoyupeUyj5NAi+k9QI08Yi3Qja/ myVo0UAq0vjfwPOPvRdd+9MuCul/ZT520qav8ueSAoYMKIvOD73V+P5F+C/hZiZD1yof Upq/sVYrptOYFOhACDhCemzKNs4jvXxXz5/IPjyjFXQ/3tyooyQwqMwTmXAhh1P+pJfb K/Ww== X-Gm-Message-State: AHYfb5j/m6Y6FBggORJ1tn1av7aHqRULSyVFiAl5U/itmUtfu70MrXsO AgpNJcfiarM9WAfqkJ72zvnc9RoCKg== X-Google-Smtp-Source: ADKCNb4wQb4IW/X9vrVur9QB3m0/yesiu8U95f20fuxOpUOncwQQykJ/Qqbb4HwWY8/EryPHlgqYg6gLSecd8mspwQ0= X-Received: by 10.129.122.77 with SMTP id v74mr4548310ywc.218.1504183843774; Thu, 31 Aug 2017 05:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 31 Aug 2017 05:50:43 -0700 (PDT) In-Reply-To: <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> From: Spencer Dawkins at IETF Date: Thu, 31 Aug 2017 07:50:43 -0500 Message-ID: To: Michael Tuexen Cc: Benoit Claise , Stefan Winter , "ops-dir@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org, "tsvwg@ietf.org" , "ietf@ietf.org" , IESG IESG Content-Type: multipart/alternative; boundary="94eb2c0a87d6af678c05580c17e6" Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:50:47 -0000 --94eb2c0a87d6af678c05580c17e6 Content-Type: text/plain; charset="UTF-8" Just interjecting ... On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen wrote: > > > On 31. Aug 2017, at 14:14, Benoit Claise wrote: > > > > Hi Michael, > >>> On 30. Aug 2017, at 18:51, Benoit Claise wrote: > >>> > >>> Michael, > >>> > >>> I stumbled on the same point as Stefan. > >> Hi Benoit, > >> > >> thanks for reviewing the document. See my comments in-line. > >> > >> Best regards > >> Michael > >>> First of, I had to review RFC4960 for TSN/SSN. I was not sure whether > TSN was per stream or not > >>> It would have helped me to repeat this information in the intro. > >>> Ok, to be candid, I deduced this information from figure 1 and 2. > >>>>>>> And the rest are only musings not needing any action if the > authors don't want > >>>>>>> to action on them: > >>>>>>> > >>>>>>> The introduction presents a good use case, quoting: "e.g., when the > >>>>>>> transmission of an urgent > >>>>>>> message is blocked from transmission because the sender has > started > >>>>>>> the transmission of another, possibly large, message". > >>>>>>> > >>>>>>> The later queueing example in figure 1 has three SIDs being queued > >>>>>>> simultanseously. It is not clear which of those "has already > started" and which > >>>>>> There is actually one message queued for stream 0, three messages > for stream 1, > >>>>>> and one message for stream 2. > >>>>>>> are the important ones being delayed. For a better understanding > of the reader, > >>>>>> The figure is about in which sequence they are put on the wire. So > no > >>>>>> transmission has startet. This examples also does not deal with the > case > >>>>>> of one stream having a higher priority than another. That would be > an > >>>>>> example using a priority scheduler. This examples illustrates the > round > >>>>>> robin scheduler. > >>>>>> The point here is that a single scheduler (the round robin > scheduler, for > >>>>>> example) behaves differently when user message interleaving is used > or not. > >>>>>> That is an important point: You can even use the schedulers with > regular > >>>>>> DATA chunk, i.e. with user message interleaving being negotiated. > >>> This was my source of confusion. > >>> With figure 1 and figure 2, you want to show the effect of Round Robin > Scheduler with and without User Message Interleaving, while we were > expecting the figure 2 to be the solution from this spec. Hence Stefan and > I were looking for this "urgent message" in figure 2. > >> I don't know what you mean with "solution from this spec" means. This > spec introduces > >> stream schedulers and a protocol extension to allow interleaving of > user messages. > >> Using this to implement an "urgent" concept is only one possibility: > usage of a > >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is > misleading. It seems > >> to ring the wrong bells. That is why I suggested to remove it... > >>>>>>> it might be useful to revise the figure so that the head-of-line > blocking > >>>>>>> happens for SID 1 because transmission of 0 and 2 has already > started (and > >>>>>>> declare SID 1 to be the "important" message). The ASCII art would > just have to > >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), and > the resulting > >>>>>>> serialisation would then put all the SID 1 messages at the very > end, when 0 and > >>>>>>> 2 have been completely submitted (right?). > >>>>>> One could think about adding another example based on the priority > scheduler > >>>>>> and giving stream 1 a higher priority. But for illustrating the > point of > >>>>>> schedulers behaving differently depending on the negotiation of > user message > >>>>>> interleaving this seems not necessary. > >>>>> That second example might indeed be useful. > >>>>> > >>>>> It's simply a bit strange that in the introduction you speak about an > >>>>> "urgent" message (something deserving a higher-priority sending) and > >>>>> that another transmission has already started - but then the example > has > >>>>> none of those two. > >>> Exactly. > >>> Please add this extra example. > >>> This would also clarify from the introduction that when you write ... > >>> > >>> The sending of such large messages over > >>> SCTP as specified in [RFC4960] can result in a form of sender side > >>> head of line blocking (e.g., when the transmission of an urgent > >>> message is blocked from transmission because the sender has started > >>> the transmission of another, possibly large, message). > >>> > >>> .. the notion of transmission urgency is not within a stream but > across streams, and that can be achieved with a priority scheduler. > >> I would actually prefer to remove the word "urgent" from that sentence. > This just rings the wrong bells. > > That's a missed opportunity in mind, but your call. > Hmm. Let me remove the word "urgent"... > Yes, please! I wasn't wild about it, either. > >>> The text might have to be rephrased to explain that this spec provides > the ability to create stream scheduler with different relative stream > treatments. > >> What about: > >> > >> OLD TEXT > >> This document also defines several stream schedulers for general SCTP > >> associations. The stream schedulers may behave differently depending > >> on whether user message interleaving has been negotiated for the > >> association or not. > >> > >> NEW TEXT > >> This document also defines several stream schedulers for general SCTP > >> associations allowing different relative stream treatments. > >> The stream schedulers may behave differently depending > >> on whether user message interleaving has been negotiated for the > >> association or not. > >> > >> Would that address this issue? > > ok. > Fixed. > >> > >>> And also that urgent message would be placed in this high priority > stream scheduler (reliable, I guess, but that's orthogonal) stream. > >> I really would like to get rid of this. I don't think giving the strict > >> priority scheduler as specific role here is a good idea. > >> > >> The RR scheduler was chosen as the simplest scheduler to illustrate > >> that scheduler can behave differently when using interleaving or not. > >>>> What about removing the word "urgent" from that sentence. > >>>>> In fact I wonder why you speak about urgent things in the > introduction > >>>>> at all. Neither the scheduler nor the interleaving are designed to > help > >>>>> urgent things to be sent earlier. > >>>>> > >>>>> All they do is make the transmission fairer so that *all* chunks get > a > >>>>> more even serialised distribution on the wire. > >>>> That is not true in general. If you use the priority scheduler, one > >>>> stream gets preferred treatment. It also makes sure that the time > >>>> of a message spent in the stream queue is shorter. So these messages > >>>> get sent earlier. > >>>> In the case of the round robin scheduler, you are right that this is > >>>> about getting fairer treatment. If you take the WFQ scheduler, the > >>>> streams don't get the same treatment, but it depends on the weight > >>>> given to the stream. > >>>>> So, rather than saying that the spec helps urgent things to be sent > >>>>> earlier, it should maybe rather state that the spec helps every > message > >>>>> getting an equal, and equally distributed, share of the medium. > >>>> It is not meant that the spec does this. It was one example, what > >>>> a particular stream scheduler does. But there are multiple schedulers > >>>> defined in the document. > >>>> > >>>> The RR scheduler example is not intended to illustrate what you can do > >>>> with all the schedulers, but that using message interleaving or not > >>>> has an impact on the scheduler. That is meant by stating: > >>>> > >>>> This document also defines several stream schedulers for general SCTP > associations. > >>>> The stream schedulers may behave differently depending on whether > user message > >>>> interleaving has been negotiated for the association or not. > >>>> > >>>> This is followed by illustrating this using the RR scheduler. > >>>> > >>>> Best regards > >>> Also, I don't see the value of the last sentence in this paragraph, > especially with RFC2119 MAY. > >>> > >>> This section defines several stream schedulers. The stream > >>> schedulers may behave differently depending on whether user message > >>> interleaving has been negotiated for the association or not. An > >>> implementation MAY implement any subset of them. > >> During the review the question was brought up which scheduler have to > be implemented > >> by an implementation. This sentence was add to address it. > >> If you want, I can remove it. > > The point is that the MAY is that sentence doesn't mean anything. > > Maybe you mean: > > > > An implementation MUST implement at least one stream scheduler. > That would require an implementation to implement at least one of > the ones being listed. You are right in the sense that an implementation > MUST implement at least one stream scheduler, but the original text > allows that one not to be specified in this document. > > Are you saying that an implementation MUST implement one of list defined > by this document? I'm pretty sure (and this came up in my AD review) the problem is that the original specification DID define a stream scheduler, that's wasn't called a stream scheduler, but SCTP implementations did schedule streams. And that didn't matter until there was more than one way to schedule streams (as in this document). So you're working out better wording that says something like "in addition to the way the original specification scheduled streams, we're defining more of them". I think. ? Spencer --94eb2c0a87d6af678c05580c17e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just interjecting ...=C2=A0

=
On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen = <tuexen@fh-muenster.de> wrote:

> On 31. Aug 2017, at 14:14, Benoit Claise <bclaise@cisco.com> wrote:
>
> Hi Michael,
>>> On 30. Aug 2017, at 18:51, Benoit Claise <bclaise@cisco.com> wrote:
>>>
>>> Michael,
>>>
>>> I stumbled on the same point as Stefan.
>> Hi Benoit,
>>
>> thanks for reviewing the document. See my comments in-line.
>>
>> Best regards
>> Michael
>>> First of, I had to review RFC4960 for TSN/SSN. I was not sure = whether TSN was per stream or not
>>> It would have helped me to repeat this information in the intr= o.
>>> Ok, to be candid, I deduced this information from figure 1 and= 2.
>>>>>>> And the rest are only musings not needing any = action if the authors don't want
>>>>>>> to action on them:
>>>>>>>
>>>>>>> The introduction presents a good use case, quo= ting: "e.g., when the
>>>>>>> transmission of an urgent
>>>>>>>=C2=A0 message is blocked from transmission bec= ause the sender has started
>>>>>>>=C2=A0 the transmission of another, possibly la= rge, message".
>>>>>>>
>>>>>>> The later queueing example in figure 1 has thr= ee SIDs being queued
>>>>>>> simultanseously. It is not clear which of thos= e "has already started" and which
>>>>>> There is actually one message queued for stream 0,= three messages for stream 1,
>>>>>> and one message for stream 2.
>>>>>>> are the important ones being delayed. For a be= tter understanding of the reader,
>>>>>> The figure is about in which sequence they are put= on the wire. So no
>>>>>> transmission has startet. This examples also does = not deal with the case
>>>>>> of one stream having a higher priority than anothe= r. That would be an
>>>>>> example using a priority scheduler. This examples = illustrates the round
>>>>>> robin scheduler.
>>>>>> The point here is that a single scheduler (the rou= nd robin scheduler, for
>>>>>> example) behaves differently when user message int= erleaving is used or not.
>>>>>> That is an important point: You can even use the s= chedulers with regular
>>>>>> DATA chunk, i.e. with user message interleaving be= ing negotiated.
>>> This was my source of confusion.
>>> With figure 1 and figure 2, you want to show the effect of Rou= nd Robin Scheduler with and without User Message Interleaving, while we wer= e expecting the figure 2 to be the solution from this spec. Hence Stefan an= d I were looking for this "urgent message" in figure 2.
>> I don't know what you mean with "solution from this spec&= quot; means. This spec introduces
>> stream schedulers and a protocol extension to allow interleaving o= f user messages.
>> Using this to implement an "urgent" concept is only one = possibility: usage of a
>> strict priority scheduler (SCTP_SS_PRIO). So this "urgent&quo= t; is misleading. It seems
>> to ring the wrong bells. That is why I suggested to remove it... >>>>>>> it might be useful to revise the figure so tha= t the head-of-line blocking
>>>>>>> happens for SID 1 because transmission of=C2= =A0 0 and 2 has already started (and
>>>>>>> declare SID 1 to be the "important" = message). The ASCII art would just have to
>>>>>>> indent SID 1 content a bit (placing 0 and 2 ea= rlier in time), and the resulting
>>>>>>> serialisation would then put all the SID 1 mes= sages at the very end, when 0 and
>>>>>>> 2 have been completely submitted (right?).
>>>>>> One could think about adding another example based= on the priority scheduler
>>>>>> and giving stream 1 a higher priority. But for ill= ustrating the point of
>>>>>> schedulers behaving differently depending on the n= egotiation of user message
>>>>>> interleaving this seems not necessary.
>>>>> That second example might indeed be useful.
>>>>>
>>>>> It's simply a bit strange that in the introduction= you speak about an
>>>>> "urgent" message (something deserving a high= er-priority sending) and
>>>>> that another transmission has already started - but th= en the example has
>>>>> none of those two.
>>> Exactly.
>>> Please add this extra example.
>>> This would also clarify from the introduction that when you wr= ite ...
>>>
>>>=C2=A0 =C2=A0The sending of such large messages over
>>>=C2=A0 =C2=A0SCTP as specified in [RFC4960] can result in a for= m of sender side
>>>=C2=A0 =C2=A0head of line blocking (e.g., when the transmission= of an urgent
>>>=C2=A0 =C2=A0message is blocked from transmission because the s= ender has started
>>>=C2=A0 =C2=A0the transmission of another, possibly large, messa= ge).
>>>
>>> .. the notion of transmission urgency is not within a stream b= ut across streams, and that can be achieved with a priority scheduler.
>> I would actually prefer to remove the word "urgent" from= that sentence. This just rings the wrong bells.
> That's a missed opportunity in mind, but your call.
Hmm. Let me remove the word "urgent"...

Yes, please! I wasn't wild about it, either.
=C2=A0
>>> The text might have to be rephrased to explai= n that this spec provides the ability to create stream scheduler with diffe= rent relative stream treatments.
>> What about:
>>
>> OLD TEXT
>>=C2=A0 =C2=A0 This document also defines several stream schedulers = for general SCTP
>>=C2=A0 =C2=A0 associations.=C2=A0 The stream schedulers may behave = differently depending
>>=C2=A0 =C2=A0 on whether user message interleaving has been negotia= ted for the
>>=C2=A0 =C2=A0 association or not.
>>
>> NEW TEXT
>>=C2=A0 =C2=A0 This document also defines several stream schedulers = for general SCTP
>>=C2=A0 =C2=A0 associations allowing different relative stream treat= ments.
>>=C2=A0 =C2=A0 The stream schedulers may behave differently dependin= g
>>=C2=A0 =C2=A0 on whether user message interleaving has been negotia= ted for the
>>=C2=A0 =C2=A0 association or not.
>>
>> Would that address this issue?
> ok.
Fixed.
>>
>>> And also that urgent message would be placed in this high prio= rity stream scheduler (reliable, I guess, but that's orthogonal) stream= .
>> I really would like to get rid of this. I don't think giving t= he strict
>> priority scheduler as specific role here is a good idea.
>>
>> The RR scheduler was chosen as the simplest scheduler to illustrat= e
>> that scheduler can behave differently when using interleaving or n= ot.
>>>> What about removing the word "urgent" from that = sentence.
>>>>> In fact I wonder why you speak about urgent things in = the introduction
>>>>> at all. Neither the scheduler nor the interleaving are= designed to help
>>>>> urgent things to be sent earlier.
>>>>>
>>>>> All they do is make the transmission fairer so that *a= ll* chunks get a
>>>>> more even serialised distribution on the wire.
>>>> That is not true in general. If you use the priority sched= uler, one
>>>> stream gets preferred treatment. It also makes sure that t= he time
>>>> of a message spent in the stream queue is shorter. So thes= e messages
>>>> get sent earlier.
>>>> In the case of the round robin scheduler, you are right th= at this is
>>>> about getting fairer treatment. If you take the WFQ schedu= ler, the
>>>> streams don't get the same treatment, but it depends o= n the weight
>>>> given to the stream.
>>>>> So, rather than saying that the spec helps urgent thin= gs to be sent
>>>>> earlier, it should maybe rather state that the spec he= lps every message
>>>>> getting an equal, and equally distributed, share of th= e medium.
>>>> It is not meant that the spec does this. It was one exampl= e, what
>>>> a particular stream scheduler does. But there are multiple= schedulers
>>>> defined in the document.
>>>>
>>>> The RR scheduler example is not intended to illustrate wha= t you can do
>>>> with all the schedulers, but that using message interleavi= ng or not
>>>> has an impact on the scheduler. That is meant by stating:<= br> >>>>
>>>> This document also defines several stream schedulers for g= eneral SCTP associations.
>>>> The stream schedulers may behave differently depending on = whether user message
>>>> interleaving has been negotiated for the association or no= t.
>>>>
>>>> This is followed by illustrating this using the RR schedul= er.
>>>>
>>>> Best regards
>>> Also, I don't see the value of the last sentence in this p= aragraph, especially with RFC2119 MAY.
>>>
>>>=C2=A0 =C2=A0This section defines several stream schedulers.=C2= =A0 The stream
>>>=C2=A0 =C2=A0schedulers may behave differently depending on whe= ther user message
>>>=C2=A0 =C2=A0interleaving has been negotiated for the associati= on or not.=C2=A0 An
>>>=C2=A0 =C2=A0implementation MAY implement any subset of them. >> During the review the question was brought up which scheduler have= to be implemented
>> by an implementation. This sentence was add to address it.
>> If you want, I can remove it.
> The point is that the MAY is that sentence doesn't mean anything.<= br> > Maybe you mean:
>
> An implementation MUST implement at least one stream scheduler.
That would require an implementation to implement at least one = of
the ones being listed. You are right in the sense that an implementation MUST implement at least one stream scheduler, but the original text
allows that one not to be specified in this document.

Are you saying that an implementation MUST implement one of list defined by this document?

I'm pretty sure (and = this came up in my AD review) the problem is that the original specificatio= n DID define a stream scheduler, that's wasn't called a stream sche= duler, but SCTP implementations did schedule streams. And that didn't m= atter until there was more than one way to schedule streams (as in this doc= ument).

So you're working out better wording t= hat says something like "in addition to the way the original specifica= tion scheduled streams, we're defining more of them". I think.

?

Spencer=C2=A0
<= /div>
--94eb2c0a87d6af678c05580c17e6-- From nobody Thu Aug 31 06:03:00 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFED1132DF7; Thu, 31 Aug 2017 06:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 elf2Yk8V_Moa; Thu, 31 Aug 2017 06:02:23 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914C2132D9B; Thu, 31 Aug 2017 06:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1265; q=dns/txt; s=iport; t=1504184543; x=1505394143; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ce6yeIkEJI/s59yuKOC3mluA45IFqE6VQcAUMASkIWs=; b=cqb3CtP28o8KnQEIlizlhR/tQK/yvs9eO4VJjVPd4r9eXadzSLTESeMI IMONFglU6B22FtKeOcGfjmWOOAQelwdGlS8DjTMvu8K7mLKsHnS5yHlvn IG0lS4MUyr0kPwlGY7XU5vaV6CJsYdNdmiWvpFPs/XRxHhmI6H3N75qpY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQBYCKhZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBlF6pVIVHAoRLFAECAQEBAQEBAWsohRkGOEEQC0ZXBg0IAQGKLbB?= =?us-ascii?q?ki0YBAQEBAQEBAQEBAQEBAQEBASGDKoNQgWMrgn2KaQWgb5RRi1OHG41SiHM2I?= =?us-ascii?q?YENMiEIHBVJhx0+iwIBAQE?= X-IronPort-AV: E=Sophos;i="5.41,453,1498521600"; d="scan'208";a="655330196" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 13:02:18 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7VD2IDc002017; Thu, 31 Aug 2017 13:02:18 GMT To: Michael Tuexen Cc: Stefan Winter , ops-dir@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org, tsvwg@ietf.org, ietf@ietf.org, IESG IESG References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> From: Benoit Claise Message-ID: Date: Thu, 31 Aug 2017 15:02:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:02:30 -0000 >>>> Also, I don't see the value of the last sentence in this paragraph, especially with RFC2119 MAY. >>>> >>>> This section defines several stream schedulers. The stream >>>> schedulers may behave differently depending on whether user message >>>> interleaving has been negotiated for the association or not. An >>>> implementation MAY implement any subset of them. >>> During the review the question was brought up which scheduler have to be implemented >>> by an implementation. This sentence was add to address it. >>> If you want, I can remove it. >> The point is that the MAY is that sentence doesn't mean anything. >> Maybe you mean: >> >> An implementation MUST implement at least one stream scheduler. > That would require an implementation to implement at least one of > the ones being listed. You are right in the sense that an implementation > MUST implement at least one stream scheduler, but the original text > allows that one not to be specified in this document. > > Are you saying that an implementation MUST implement one of list defined > by this document? I'm saying that "An implementation MAY implement any subset of them." as a sentence doesn't make sense. Are we going in circle here? Regards, B. From nobody Thu Aug 31 06:25:46 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFD4132DA2; Thu, 31 Aug 2017 06:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5bk7OswzUvVw; Thu, 31 Aug 2017 06:25:23 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA40132D83; Thu, 31 Aug 2017 06:25:21 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e] (p200300CD6BCC5600FC8643679FA8604E.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2A80471E3F8DC; Thu, 31 Aug 2017 15:25:04 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9CC9ACD9-08A6-47E4-B2E6-EC77129A2A2A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 15:25:02 +0200 In-Reply-To: Cc: Benoit Claise , Stefan Winter , "ops-dir@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org, "tsvwg@ietf.org" , "ietf@ietf.org" , IESG IESG To: Spencer Dawkins at IETF References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:25:27 -0000 --Apple-Mail=_9CC9ACD9-08A6-47E4-B2E6-EC77129A2A2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF = wrote: >=20 > Just interjecting ...=20 >=20 > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen = wrote: >=20 > > On 31. Aug 2017, at 14:14, Benoit Claise wrote: > > > > Hi Michael, > >>> On 30. Aug 2017, at 18:51, Benoit Claise = wrote: > >>> > >>> Michael, > >>> > >>> I stumbled on the same point as Stefan. > >> Hi Benoit, > >> > >> thanks for reviewing the document. See my comments in-line. > >> > >> Best regards > >> Michael > >>> First of, I had to review RFC4960 for TSN/SSN. I was not sure = whether TSN was per stream or not > >>> It would have helped me to repeat this information in the intro. > >>> Ok, to be candid, I deduced this information from figure 1 and 2. > >>>>>>> And the rest are only musings not needing any action if the = authors don't want > >>>>>>> to action on them: > >>>>>>> > >>>>>>> The introduction presents a good use case, quoting: "e.g., = when the > >>>>>>> transmission of an urgent > >>>>>>> message is blocked from transmission because the sender has = started > >>>>>>> the transmission of another, possibly large, message". > >>>>>>> > >>>>>>> The later queueing example in figure 1 has three SIDs being = queued > >>>>>>> simultanseously. It is not clear which of those "has already = started" and which > >>>>>> There is actually one message queued for stream 0, three = messages for stream 1, > >>>>>> and one message for stream 2. > >>>>>>> are the important ones being delayed. For a better = understanding of the reader, > >>>>>> The figure is about in which sequence they are put on the wire. = So no > >>>>>> transmission has startet. This examples also does not deal with = the case > >>>>>> of one stream having a higher priority than another. That would = be an > >>>>>> example using a priority scheduler. This examples illustrates = the round > >>>>>> robin scheduler. > >>>>>> The point here is that a single scheduler (the round robin = scheduler, for > >>>>>> example) behaves differently when user message interleaving is = used or not. > >>>>>> That is an important point: You can even use the schedulers = with regular > >>>>>> DATA chunk, i.e. with user message interleaving being = negotiated. > >>> This was my source of confusion. > >>> With figure 1 and figure 2, you want to show the effect of Round = Robin Scheduler with and without User Message Interleaving, while we = were expecting the figure 2 to be the solution from this spec. Hence = Stefan and I were looking for this "urgent message" in figure 2. > >> I don't know what you mean with "solution from this spec" means. = This spec introduces > >> stream schedulers and a protocol extension to allow interleaving of = user messages. > >> Using this to implement an "urgent" concept is only one = possibility: usage of a > >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is = misleading. It seems > >> to ring the wrong bells. That is why I suggested to remove it... > >>>>>>> it might be useful to revise the figure so that the = head-of-line blocking > >>>>>>> happens for SID 1 because transmission of 0 and 2 has already = started (and > >>>>>>> declare SID 1 to be the "important" message). The ASCII art = would just have to > >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), = and the resulting > >>>>>>> serialisation would then put all the SID 1 messages at the = very end, when 0 and > >>>>>>> 2 have been completely submitted (right?). > >>>>>> One could think about adding another example based on the = priority scheduler > >>>>>> and giving stream 1 a higher priority. But for illustrating the = point of > >>>>>> schedulers behaving differently depending on the negotiation of = user message > >>>>>> interleaving this seems not necessary. > >>>>> That second example might indeed be useful. > >>>>> > >>>>> It's simply a bit strange that in the introduction you speak = about an > >>>>> "urgent" message (something deserving a higher-priority sending) = and > >>>>> that another transmission has already started - but then the = example has > >>>>> none of those two. > >>> Exactly. > >>> Please add this extra example. > >>> This would also clarify from the introduction that when you write = ... > >>> > >>> The sending of such large messages over > >>> SCTP as specified in [RFC4960] can result in a form of sender = side > >>> head of line blocking (e.g., when the transmission of an urgent > >>> message is blocked from transmission because the sender has = started > >>> the transmission of another, possibly large, message). > >>> > >>> .. the notion of transmission urgency is not within a stream but = across streams, and that can be achieved with a priority scheduler. > >> I would actually prefer to remove the word "urgent" from that = sentence. This just rings the wrong bells. > > That's a missed opportunity in mind, but your call. > Hmm. Let me remove the word "urgent"... >=20 > Yes, please! I wasn't wild about it, either. It's done: = https://github.com/sctplab/sctp-idata/commit/cf7b331512cd85d6195eb88fa9636= 0673293323f > =20 > >>> The text might have to be rephrased to explain that this spec = provides the ability to create stream scheduler with different relative = stream treatments. > >> What about: > >> > >> OLD TEXT > >> This document also defines several stream schedulers for general = SCTP > >> associations. The stream schedulers may behave differently = depending > >> on whether user message interleaving has been negotiated for the > >> association or not. > >> > >> NEW TEXT > >> This document also defines several stream schedulers for general = SCTP > >> associations allowing different relative stream treatments. > >> The stream schedulers may behave differently depending > >> on whether user message interleaving has been negotiated for the > >> association or not. > >> > >> Would that address this issue? > > ok. > Fixed. > >> > >>> And also that urgent message would be placed in this high priority = stream scheduler (reliable, I guess, but that's orthogonal) stream. > >> I really would like to get rid of this. I don't think giving the = strict > >> priority scheduler as specific role here is a good idea. > >> > >> The RR scheduler was chosen as the simplest scheduler to illustrate > >> that scheduler can behave differently when using interleaving or = not. > >>>> What about removing the word "urgent" from that sentence. > >>>>> In fact I wonder why you speak about urgent things in the = introduction > >>>>> at all. Neither the scheduler nor the interleaving are designed = to help > >>>>> urgent things to be sent earlier. > >>>>> > >>>>> All they do is make the transmission fairer so that *all* chunks = get a > >>>>> more even serialised distribution on the wire. > >>>> That is not true in general. If you use the priority scheduler, = one > >>>> stream gets preferred treatment. It also makes sure that the time > >>>> of a message spent in the stream queue is shorter. So these = messages > >>>> get sent earlier. > >>>> In the case of the round robin scheduler, you are right that this = is > >>>> about getting fairer treatment. If you take the WFQ scheduler, = the > >>>> streams don't get the same treatment, but it depends on the = weight > >>>> given to the stream. > >>>>> So, rather than saying that the spec helps urgent things to be = sent > >>>>> earlier, it should maybe rather state that the spec helps every = message > >>>>> getting an equal, and equally distributed, share of the medium. > >>>> It is not meant that the spec does this. It was one example, what > >>>> a particular stream scheduler does. But there are multiple = schedulers > >>>> defined in the document. > >>>> > >>>> The RR scheduler example is not intended to illustrate what you = can do > >>>> with all the schedulers, but that using message interleaving or = not > >>>> has an impact on the scheduler. That is meant by stating: > >>>> > >>>> This document also defines several stream schedulers for general = SCTP associations. > >>>> The stream schedulers may behave differently depending on whether = user message > >>>> interleaving has been negotiated for the association or not. > >>>> > >>>> This is followed by illustrating this using the RR scheduler. > >>>> > >>>> Best regards > >>> Also, I don't see the value of the last sentence in this = paragraph, especially with RFC2119 MAY. > >>> > >>> This section defines several stream schedulers. The stream > >>> schedulers may behave differently depending on whether user = message > >>> interleaving has been negotiated for the association or not. An > >>> implementation MAY implement any subset of them. > >> During the review the question was brought up which scheduler have = to be implemented > >> by an implementation. This sentence was add to address it. > >> If you want, I can remove it. > > The point is that the MAY is that sentence doesn't mean anything. > > Maybe you mean: > > > > An implementation MUST implement at least one stream scheduler. > That would require an implementation to implement at least one of > the ones being listed. You are right in the sense that an = implementation > MUST implement at least one stream scheduler, but the original text > allows that one not to be specified in this document. >=20 > Are you saying that an implementation MUST implement one of list = defined > by this document? >=20 > I'm pretty sure (and this came up in my AD review) the problem is that = the original specification DID define a stream scheduler, that's wasn't = called a stream scheduler, but SCTP implementations did schedule = streams. And that didn't matter until there was more than one way to = schedule streams (as in this document). The original specification did NOT specify a stream scheduler and left = this completely implementation specific. Right now Linux is using (and only supporting a single scheduler) what = we call in this document SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in this = document SCTP_SS_RR and Solaris uses one of these, forgot which one. Among these kernel = implementations, only FreeBSD supports multiple streams schedulers and its selection. Possibly other = closed source SCTP implementations might support other schedulers. Don't know. >=20 > So you're working out better wording that says something like "in = addition to the way the original specification scheduled streams, we're = defining more of them". I think. I think we wanted to say something like: Here is a list of schedulers. Your implementation might support some of = them, but this is left open. So you can't rely on it. The list of schedulers we specified includes the ones being used as = default by FreeBSD, Linux and Solaris and was extended by the ones supported by FreeBSD and the one = explicitly required by WebRTC, which is SCTP_SS_WFQ. What about this change: OLD TEXT: An implementation MAY implement any subset of them. NEW TEXT: An implementation MAY implement any subset of them. If the = implementation is used for WebRTC Datachannels as specified in = [I-D.ietf-rtcweb-data-channel] it MUST implement the Weighted Fair Queueing Scheduler defined in = Section 3.6. Best regards Michael >=20 > ? >=20 > Spencer=20 --Apple-Mail=_9CC9ACD9-08A6-47E4-B2E6-EC77129A2A2A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzExMzI1MDNaMCMGCSqGSIb3DQEJBDEWBBTud2ygZ2M1PUXG/Tfk zVgB/c0a/zCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQC93atIFKzuhKDcSAioqnSJ93THbuE3jW2T +HtMjLaTptpcye+AIfk1S0bo8QSbpCvTL9PDvdK+pSId4zA1kgnk+Hnb7K5OuE1X112EU5jl1D3h +TzOi+vbuDD4qVadWCyb97xXz11eckdRUlmpqi4SquLusgSZp/lr+pLe9tq8v72MOQOiUxbQUFBo w4TGCijBXsEzwbspQrdbzsCSlLcGuNPIumBURm5QzWvzYagIMsKX16/XguV+VwicS5RI9NQ9YnbT 0CIhO3gWck5YhvLW/hjx+U+Z+DNG9+HD2dAzdUqI8PIZovnJhDhy+KfhxdpW4chf/Gr/AbqqTC15 5sdbAAAAAAAA --Apple-Mail=_9CC9ACD9-08A6-47E4-B2E6-EC77129A2A2A-- From nobody Thu Aug 31 06:26:38 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7D0132DF4; Thu, 31 Aug 2017 06:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 UGz4zIxfN024; Thu, 31 Aug 2017 06:25:45 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3260B132E07; Thu, 31 Aug 2017 06:25:39 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e] (p200300CD6BCC5600FC8643679FA8604E.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:fc86:4367:9fa8:604e]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 18DB071E3F8E0; Thu, 31 Aug 2017 15:25:23 +0200 (CEST) From: Michael Tuexen Message-Id: <33532776-F3E6-443A-B26C-2F80BC2F88E3@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_98D04D7E-A798-47F3-8D52-6AB88EFB5EB3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 15:25:22 +0200 In-Reply-To: Cc: Stefan Winter , ops-dir@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org, tsvwg@ietf.org, ietf@ietf.org, IESG IESG To: Benoit Claise References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:25:48 -0000 --Apple-Mail=_98D04D7E-A798-47F3-8D52-6AB88EFB5EB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 31. Aug 2017, at 15:02, Benoit Claise wrote: >=20 >=20 >>>>> Also, I don't see the value of the last sentence in this = paragraph, especially with RFC2119 MAY. >>>>>=20 >>>>> This section defines several stream schedulers. The stream >>>>> schedulers may behave differently depending on whether user = message >>>>> interleaving has been negotiated for the association or not. An >>>>> implementation MAY implement any subset of them. >>>> During the review the question was brought up which scheduler have = to be implemented >>>> by an implementation. This sentence was add to address it. >>>> If you want, I can remove it. >>> The point is that the MAY is that sentence doesn't mean anything. >>> Maybe you mean: >>>=20 >>> An implementation MUST implement at least one stream scheduler. >> That would require an implementation to implement at least one of >> the ones being listed. You are right in the sense that an = implementation >> MUST implement at least one stream scheduler, but the original text >> allows that one not to be specified in this document. >>=20 >> Are you saying that an implementation MUST implement one of list = defined >> by this document? > I'm saying that "An implementation MAY implement any subset of them." = as a sentence doesn't make sense. > Are we going in circle here? What about: What about this change: OLD TEXT: An implementation MAY implement any subset of them. NEW TEXT: An implementation MAY implement any subset of them. If the = implementation is used for WebRTC Datachannels as specified in = [I-D.ietf-rtcweb-data-channel] it MUST implement the Weighted Fair Queueing Scheduler defined in = Section 3.6. Best regards Michael >=20 > Regards, B. --Apple-Mail=_98D04D7E-A798-47F3-8D52-6AB88EFB5EB3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzExMzI1MjNaMCMGCSqGSIb3DQEJBDEWBBSLT+lVYYcU8DYKBFMc nYrMCgulhjCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQAw0aYxbowsuYNAg2cB9jQhf6o3xJVLe4Wu 6ExQL6l2M5bnia72kAcXNW+fOKLTiCNCl47pvc8US/uVxBC+GqiB1aJNn394cs+drIwos9DW+mL7 j/1wuD8QDYjbZOgMfeasFk8lyB9mL7XvUSaFueZnDbEiUnOne4qq5fTduKdFGtqLzs3BtQ9fR7ce 3NjZ0gTgGhXeU/ckQ0vo0FGrtZNfEameKBZYpb+7L/PsHSx/wfuf1BOBTv2rRM+fPpJFfdGUXpM6 Cn02I4oBwoYS50b+aN0JmMjOXWCk5kYZrG1AQiJ/PadS9cfbcFgoEkG8RzXIrjTsqaxduYmQQlJW fAOVAAAAAAAA --Apple-Mail=_98D04D7E-A798-47F3-8D52-6AB88EFB5EB3-- From nobody Thu Aug 31 06:46:37 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD67132DA2; Thu, 31 Aug 2017 06:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI-WytcrKvSk; Thu, 31 Aug 2017 06:46:14 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 C7C22132D91; Thu, 31 Aug 2017 06:46:13 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id s143so3527047ywg.0; Thu, 31 Aug 2017 06:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mfiZmmQ/N6ptode9/iozv1GiLqTvO9Tlyu6sve+pne4=; b=oEcs9orssIoUlouJSL4KDUXeuhvR0ebGidbmRkjQQVbGZvRJ1R6WipV/jirnuroimF 8w0WjPrsuOMGN60zjSBqbGMmj8+fDwry+dOg5MHazCVo0LqmklY823WpHMbLqjfcapeW S8VbnmIe3mWx5xEgRuRqX/u//2IYINxPG7dm9kd5g05GU/1R8qLP+wikdeSveCtgxqbL xY1LJSUwz5Q6gsUR7vFd+zqRZGS6ie32wn+TqkbJexIdHN5zatXB/nknxeDkCesx7WLt 578afsq7ePrx9lG4V/Rzqn+R5ceGZXg9pw1QANzbb8C66RyFKf/z7MbjgRqXtxDvZJHa p4Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mfiZmmQ/N6ptode9/iozv1GiLqTvO9Tlyu6sve+pne4=; b=ColzcBSrZmCwcHoggdmw0iiGBKTkg0yJtpzoAYzlYzLhZybYTTgQdO9VuNa/i0+7lI f1vX2LxidneVejc3vIp0GqtO1nbkABnonAbTUEMXUOGeMLKZ0Y2dES8an2st4JtiMtNf CprmRSoF5vM02caaZXv8QuM8U3aaDtUDiBssfxnntFBcVw19e42uuXf+3sMKeH8GAZiN yrgAW9Gf2LxR6N8XQ20fZ7eklS2zVBLrJs1wRwfudqKuFsaUUDJCsKj9vbvAb2/xp2r9 AAbdsvLOBDL8Ux9vgSnwrmAuHCO9a7a9DclV/BeUJOZ1IWOyPQPI9fHxZTvETg4fJUMN RQzA== X-Gm-Message-State: AHYfb5gPR+K08Xb2S+Hmkcqao6Gn3QFyKCk17NMP1Dg0R7POIexn1fqE /n/3550hj+RKpuYxdoh//hCfMXrvpg== X-Google-Smtp-Source: ADKCNb67xkl4YjMIvf0aEzbKvML+Gi5V01zAMq23HQkdMte+Y1uCZAJ6lMRQzVQlwudE8jlbQYQlAUM4c9wonhFzlI8= X-Received: by 10.129.122.77 with SMTP id v74mr4748957ywc.218.1504187173028; Thu, 31 Aug 2017 06:46:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 31 Aug 2017 06:46:12 -0700 (PDT) In-Reply-To: References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> From: Spencer Dawkins at IETF Date: Thu, 31 Aug 2017 08:46:12 -0500 Message-ID: To: Michael Tuexen Cc: Benoit Claise , Stefan Winter , "ops-dir@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org, "tsvwg@ietf.org" , "ietf@ietf.org" , IESG IESG Content-Type: multipart/alternative; boundary="94eb2c0a87d61fc74005580cde5e" Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:46:18 -0000 --94eb2c0a87d61fc74005580cde5e Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen wrote: > > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Just interjecting ... > > > > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen > wrote: > > > > > On 31. Aug 2017, at 14:14, Benoit Claise wrote: > > > > > > Hi Michael, > > >>> On 30. Aug 2017, at 18:51, Benoit Claise wrote: > > >>> > > >>> Michael, > > >>> > > >>> I stumbled on the same point as Stefan. > > >> Hi Benoit, > > >> > > >> thanks for reviewing the document. See my comments in-line. > > >> > > >> Best regards > > >> Michael > > >>> First of, I had to review RFC4960 for TSN/SSN. I was not sure > whether TSN was per stream or not > > >>> It would have helped me to repeat this information in the intro. > > >>> Ok, to be candid, I deduced this information from figure 1 and 2. > > >>>>>>> And the rest are only musings not needing any action if the > authors don't want > > >>>>>>> to action on them: > > >>>>>>> > > >>>>>>> The introduction presents a good use case, quoting: "e.g., when > the > > >>>>>>> transmission of an urgent > > >>>>>>> message is blocked from transmission because the sender has > started > > >>>>>>> the transmission of another, possibly large, message". > > >>>>>>> > > >>>>>>> The later queueing example in figure 1 has three SIDs being > queued > > >>>>>>> simultanseously. It is not clear which of those "has already > started" and which > > >>>>>> There is actually one message queued for stream 0, three messages > for stream 1, > > >>>>>> and one message for stream 2. > > >>>>>>> are the important ones being delayed. For a better understanding > of the reader, > > >>>>>> The figure is about in which sequence they are put on the wire. > So no > > >>>>>> transmission has startet. This examples also does not deal with > the case > > >>>>>> of one stream having a higher priority than another. That would > be an > > >>>>>> example using a priority scheduler. This examples illustrates the > round > > >>>>>> robin scheduler. > > >>>>>> The point here is that a single scheduler (the round robin > scheduler, for > > >>>>>> example) behaves differently when user message interleaving is > used or not. > > >>>>>> That is an important point: You can even use the schedulers with > regular > > >>>>>> DATA chunk, i.e. with user message interleaving being negotiated. > > >>> This was my source of confusion. > > >>> With figure 1 and figure 2, you want to show the effect of Round > Robin Scheduler with and without User Message Interleaving, while we were > expecting the figure 2 to be the solution from this spec. Hence Stefan and > I were looking for this "urgent message" in figure 2. > > >> I don't know what you mean with "solution from this spec" means. This > spec introduces > > >> stream schedulers and a protocol extension to allow interleaving of > user messages. > > >> Using this to implement an "urgent" concept is only one possibility: > usage of a > > >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is > misleading. It seems > > >> to ring the wrong bells. That is why I suggested to remove it... > > >>>>>>> it might be useful to revise the figure so that the head-of-line > blocking > > >>>>>>> happens for SID 1 because transmission of 0 and 2 has already > started (and > > >>>>>>> declare SID 1 to be the "important" message). The ASCII art > would just have to > > >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), > and the resulting > > >>>>>>> serialisation would then put all the SID 1 messages at the very > end, when 0 and > > >>>>>>> 2 have been completely submitted (right?). > > >>>>>> One could think about adding another example based on the > priority scheduler > > >>>>>> and giving stream 1 a higher priority. But for illustrating the > point of > > >>>>>> schedulers behaving differently depending on the negotiation of > user message > > >>>>>> interleaving this seems not necessary. > > >>>>> That second example might indeed be useful. > > >>>>> > > >>>>> It's simply a bit strange that in the introduction you speak about > an > > >>>>> "urgent" message (something deserving a higher-priority sending) > and > > >>>>> that another transmission has already started - but then the > example has > > >>>>> none of those two. > > >>> Exactly. > > >>> Please add this extra example. > > >>> This would also clarify from the introduction that when you write ... > > >>> > > >>> The sending of such large messages over > > >>> SCTP as specified in [RFC4960] can result in a form of sender side > > >>> head of line blocking (e.g., when the transmission of an urgent > > >>> message is blocked from transmission because the sender has started > > >>> the transmission of another, possibly large, message). > > >>> > > >>> .. the notion of transmission urgency is not within a stream but > across streams, and that can be achieved with a priority scheduler. > > >> I would actually prefer to remove the word "urgent" from that > sentence. This just rings the wrong bells. > > > That's a missed opportunity in mind, but your call. > > Hmm. Let me remove the word "urgent"... > > > > Yes, please! I wasn't wild about it, either. > It's done: > https://github.com/sctplab/sctp-idata/commit/ > cf7b331512cd85d6195eb88fa96360673293323f > > > > >>> The text might have to be rephrased to explain that this spec > provides the ability to create stream scheduler with different relative > stream treatments. > > >> What about: > > >> > > >> OLD TEXT > > >> This document also defines several stream schedulers for general > SCTP > > >> associations. The stream schedulers may behave differently > depending > > >> on whether user message interleaving has been negotiated for the > > >> association or not. > > >> > > >> NEW TEXT > > >> This document also defines several stream schedulers for general > SCTP > > >> associations allowing different relative stream treatments. > > >> The stream schedulers may behave differently depending > > >> on whether user message interleaving has been negotiated for the > > >> association or not. > > >> > > >> Would that address this issue? > > > ok. > > Fixed. > > >> > > >>> And also that urgent message would be placed in this high priority > stream scheduler (reliable, I guess, but that's orthogonal) stream. > > >> I really would like to get rid of this. I don't think giving the > strict > > >> priority scheduler as specific role here is a good idea. > > >> > > >> The RR scheduler was chosen as the simplest scheduler to illustrate > > >> that scheduler can behave differently when using interleaving or not. > > >>>> What about removing the word "urgent" from that sentence. > > >>>>> In fact I wonder why you speak about urgent things in the > introduction > > >>>>> at all. Neither the scheduler nor the interleaving are designed to > help > > >>>>> urgent things to be sent earlier. > > >>>>> > > >>>>> All they do is make the transmission fairer so that *all* chunks > get a > > >>>>> more even serialised distribution on the wire. > > >>>> That is not true in general. If you use the priority scheduler, one > > >>>> stream gets preferred treatment. It also makes sure that the time > > >>>> of a message spent in the stream queue is shorter. So these messages > > >>>> get sent earlier. > > >>>> In the case of the round robin scheduler, you are right that this is > > >>>> about getting fairer treatment. If you take the WFQ scheduler, the > > >>>> streams don't get the same treatment, but it depends on the weight > > >>>> given to the stream. > > >>>>> So, rather than saying that the spec helps urgent things to be sent > > >>>>> earlier, it should maybe rather state that the spec helps every > message > > >>>>> getting an equal, and equally distributed, share of the medium. > > >>>> It is not meant that the spec does this. It was one example, what > > >>>> a particular stream scheduler does. But there are multiple > schedulers > > >>>> defined in the document. > > >>>> > > >>>> The RR scheduler example is not intended to illustrate what you can > do > > >>>> with all the schedulers, but that using message interleaving or not > > >>>> has an impact on the scheduler. That is meant by stating: > > >>>> > > >>>> This document also defines several stream schedulers for general > SCTP associations. > > >>>> The stream schedulers may behave differently depending on whether > user message > > >>>> interleaving has been negotiated for the association or not. > > >>>> > > >>>> This is followed by illustrating this using the RR scheduler. > > >>>> > > >>>> Best regards > > >>> Also, I don't see the value of the last sentence in this paragraph, > especially with RFC2119 MAY. > > >>> > > >>> This section defines several stream schedulers. The stream > > >>> schedulers may behave differently depending on whether user message > > >>> interleaving has been negotiated for the association or not. An > > >>> implementation MAY implement any subset of them. > > >> During the review the question was brought up which scheduler have to > be implemented > > >> by an implementation. This sentence was add to address it. > > >> If you want, I can remove it. > > > The point is that the MAY is that sentence doesn't mean anything. > > > Maybe you mean: > > > > > > An implementation MUST implement at least one stream scheduler. > > That would require an implementation to implement at least one of > > the ones being listed. You are right in the sense that an implementation > > MUST implement at least one stream scheduler, but the original text > > allows that one not to be specified in this document. > > > > Are you saying that an implementation MUST implement one of list defined > > by this document? > > > > I'm pretty sure (and this came up in my AD review) the problem is that > the original specification DID define a stream scheduler, that's wasn't > called a stream scheduler, but SCTP implementations did schedule streams. > And that didn't matter until there was more than one way to schedule > streams (as in this document). > The original specification did NOT specify a stream scheduler and left > this completely implementation > specific. > Right now Linux is using (and only supporting a single scheduler) what we > call in this document > SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in this document > SCTP_SS_RR and > Solaris uses one of these, forgot which one. Among these kernel > implementations, only FreeBSD > supports multiple streams schedulers and its selection. Possibly other > closed source SCTP > implementations might support other schedulers. Don't know. Thanks for getting that right for me ... Spencer > > So you're working out better wording that says something like "in > addition to the way the original specification scheduled streams, we're > defining more of them". I think. I think we wanted to say something like: > > Here is a list of schedulers. Your implementation might support some of > them, but this is > left open. So you can't rely on it. > > The list of schedulers we specified includes the ones being used as > default by FreeBSD, Linux and > Solaris and was extended by the ones supported by FreeBSD and the one > explicitly required by > WebRTC, which is SCTP_SS_WFQ. > > What about this change: > > OLD TEXT: > An implementation MAY implement any subset of them. > > NEW TEXT: > An implementation MAY implement any subset of them. If the > implementation > is used for WebRTC Datachannels as specified in > [I-D.ietf-rtcweb-data-channel] > it MUST implement the Weighted Fair Queueing Scheduler defined in > Section 3.6. That works for me, but I'll let Benoit reply. Spencer > Best regards > Michael > > > > ? > > > > Spencer > > --94eb2c0a87d61fc74005580cde5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen <tuexen@fh= -muenster.de> wrote:
> On 31. Aug 2017, at 14:50, Spencer D= awkins at IETF <spencer= dawkins.ietf@gmail.com> wrote:
>
> Just interjecting ...
>
> On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
>
> > On 31. Aug 2017, at 14:14, Benoit Claise <bclaise@cisco.com> wrote:
> >
> > Hi Michael,
> >>> On 30. Aug 2017, at 18:51, Benoit Claise <bclaise@cisco.com> wrote:
> >>>
> >>> Michael,
> >>>
> >>> I stumbled on the same point as Stefan.
> >> Hi Benoit,
> >>
> >> thanks for reviewing the document. See my comments in-line. > >>
> >> Best regards
> >> Michael
> >>> First of, I had to review RFC4960 for TSN/SSN. I was not = sure whether TSN was per stream or not
> >>> It would have helped me to repeat this information in the= intro.
> >>> Ok, to be candid, I deduced this information from figure = 1 and 2.
> >>>>>>> And the rest are only musings not needing= any action if the authors don't want
> >>>>>>> to action on them:
> >>>>>>>
> >>>>>>> The introduction presents a good use case= , quoting: "e.g., when the
> >>>>>>> transmission of an urgent
> >>>>>>>=C2=A0 message is blocked from transmissio= n because the sender has started
> >>>>>>>=C2=A0 the transmission of another, possib= ly large, message".
> >>>>>>>
> >>>>>>> The later queueing example in figure 1 ha= s three SIDs being queued
> >>>>>>> simultanseously. It is not clear which of= those "has already started" and which
> >>>>>> There is actually one message queued for stre= am 0, three messages for stream 1,
> >>>>>> and one message for stream 2.
> >>>>>>> are the important ones being delayed. For= a better understanding of the reader,
> >>>>>> The figure is about in which sequence they ar= e put on the wire. So no
> >>>>>> transmission has startet. This examples also = does not deal with the case
> >>>>>> of one stream having a higher priority than a= nother. That would be an
> >>>>>> example using a priority scheduler. This exam= ples illustrates the round
> >>>>>> robin scheduler.
> >>>>>> The point here is that a single scheduler (th= e round robin scheduler, for
> >>>>>> example) behaves differently when user messag= e interleaving is used or not.
> >>>>>> That is an important point: You can even use = the schedulers with regular
> >>>>>> DATA chunk, i.e. with user message interleavi= ng being negotiated.
> >>> This was my source of confusion.
> >>> With figure 1 and figure 2, you want to show the effect o= f Round Robin Scheduler with and without User Message Interleaving, while w= e were expecting the figure 2 to be the solution from this spec. Hence Stef= an and I were looking for this "urgent message" in figure 2.
> >> I don't know what you mean with "solution from this = spec" means. This spec introduces
> >> stream schedulers and a protocol extension to allow interleav= ing of user messages.
> >> Using this to implement an "urgent" concept is only= one possibility: usage of a
> >> strict priority scheduler (SCTP_SS_PRIO). So this "urgen= t" is misleading. It seems
> >> to ring the wrong bells. That is why I suggested to remove it= ...
> >>>>>>> it might be useful to revise the figure s= o that the head-of-line blocking
> >>>>>>> happens for SID 1 because transmission of= =C2=A0 0 and 2 has already started (and
> >>>>>>> declare SID 1 to be the "important&q= uot; message). The ASCII art would just have to
> >>>>>>> indent SID 1 content a bit (placing 0 and= 2 earlier in time), and the resulting
> >>>>>>> serialisation would then put all the SID = 1 messages at the very end, when 0 and
> >>>>>>> 2 have been completely submitted (right?)= .
> >>>>>> One could think about adding another example = based on the priority scheduler
> >>>>>> and giving stream 1 a higher priority. But fo= r illustrating the point of
> >>>>>> schedulers behaving differently depending on = the negotiation of user message
> >>>>>> interleaving this seems not necessary.
> >>>>> That second example might indeed be useful.
> >>>>>
> >>>>> It's simply a bit strange that in the introdu= ction you speak about an
> >>>>> "urgent" message (something deserving a= higher-priority sending) and
> >>>>> that another transmission has already started - b= ut then the example has
> >>>>> none of those two.
> >>> Exactly.
> >>> Please add this extra example.
> >>> This would also clarify from the introduction that when y= ou write ...
> >>>
> >>>=C2=A0 =C2=A0The sending of such large messages over
> >>>=C2=A0 =C2=A0SCTP as specified in [RFC4960] can result in = a form of sender side
> >>>=C2=A0 =C2=A0head of line blocking (e.g., when the transmi= ssion of an urgent
> >>>=C2=A0 =C2=A0message is blocked from transmission because = the sender has started
> >>>=C2=A0 =C2=A0the transmission of another, possibly large, = message).
> >>>
> >>> .. the notion of transmission urgency is not within a str= eam but across streams, and that can be achieved with a priority scheduler.=
> >> I would actually prefer to remove the word "urgent"= from that sentence. This just rings the wrong bells.
> > That's a missed opportunity in mind, but your call.
> Hmm. Let me remove the word "urgent"...
>
> Yes, please! I wasn't wild about it, either.
It's done:
https://github.= com/sctplab/sctp-idata/commit/cf7b331512cd85d6195eb88fa96360= 673293323f
>
> >>> The text might have to be rephrased to explain that this = spec provides the ability to create stream scheduler with different relativ= e stream treatments.
> >> What about:
> >>
> >> OLD TEXT
> >>=C2=A0 =C2=A0 This document also defines several stream schedu= lers for general SCTP
> >>=C2=A0 =C2=A0 associations.=C2=A0 The stream schedulers may be= have differently depending
> >>=C2=A0 =C2=A0 on whether user message interleaving has been ne= gotiated for the
> >>=C2=A0 =C2=A0 association or not.
> >>
> >> NEW TEXT
> >>=C2=A0 =C2=A0 This document also defines several stream schedu= lers for general SCTP
> >>=C2=A0 =C2=A0 associations allowing different relative stream = treatments.
> >>=C2=A0 =C2=A0 The stream schedulers may behave differently dep= ending
> >>=C2=A0 =C2=A0 on whether user message interleaving has been ne= gotiated for the
> >>=C2=A0 =C2=A0 association or not.
> >>
> >> Would that address this issue?
> > ok.
> Fixed.
> >>
> >>> And also that urgent message would be placed in this high= priority stream scheduler (reliable, I guess, but that's orthogonal) s= tream.
> >> I really would like to get rid of this. I don't think giv= ing the strict
> >> priority scheduler as specific role here is a good idea.
> >>
> >> The RR scheduler was chosen as the simplest scheduler to illu= strate
> >> that scheduler can behave differently when using interleaving= or not.
> >>>> What about removing the word "urgent" from = that sentence.
> >>>>> In fact I wonder why you speak about urgent thing= s in the introduction
> >>>>> at all. Neither the scheduler nor the interleavin= g are designed to help
> >>>>> urgent things to be sent earlier.
> >>>>>
> >>>>> All they do is make the transmission fairer so th= at *all* chunks get a
> >>>>> more even serialised distribution on the wire. > >>>> That is not true in general. If you use the priority = scheduler, one
> >>>> stream gets preferred treatment. It also makes sure t= hat the time
> >>>> of a message spent in the stream queue is shorter. So= these messages
> >>>> get sent earlier.
> >>>> In the case of the round robin scheduler, you are rig= ht that this is
> >>>> about getting fairer treatment. If you take the WFQ s= cheduler, the
> >>>> streams don't get the same treatment, but it depe= nds on the weight
> >>>> given to the stream.
> >>>>> So, rather than saying that the spec helps urgent= things to be sent
> >>>>> earlier, it should maybe rather state that the sp= ec helps every message
> >>>>> getting an equal, and equally distributed, share = of the medium.
> >>>> It is not meant that the spec does this. It was one e= xample, what
> >>>> a particular stream scheduler does. But there are mul= tiple schedulers
> >>>> defined in the document.
> >>>>
> >>>> The RR scheduler example is not intended to illustrat= e what you can do
> >>>> with all the schedulers, but that using message inter= leaving or not
> >>>> has an impact on the scheduler. That is meant by stat= ing:
> >>>>
> >>>> This document also defines several stream schedulers = for general SCTP associations.
> >>>> The stream schedulers may behave differently dependin= g on whether user message
> >>>> interleaving has been negotiated for the association = or not.
> >>>>
> >>>> This is followed by illustrating this using the RR sc= heduler.
> >>>>
> >>>> Best regards
> >>> Also, I don't see the value of the last sentence in t= his paragraph, especially with RFC2119 MAY.
> >>>
> >>>=C2=A0 =C2=A0This section defines several stream scheduler= s.=C2=A0 The stream
> >>>=C2=A0 =C2=A0schedulers may behave differently depending o= n whether user message
> >>>=C2=A0 =C2=A0interleaving has been negotiated for the asso= ciation or not.=C2=A0 An
> >>>=C2=A0 =C2=A0implementation MAY implement any subset of th= em.
> >> During the review the question was brought up which scheduler= have to be implemented
> >> by an implementation. This sentence was add to address it. > >> If you want, I can remove it.
> > The point is that the MAY is that sentence doesn't mean anyth= ing.
> > Maybe you mean:
> >
> > An implementation MUST implement at least one stream scheduler. > That would require an implementation to implement at least one of
> the ones being listed. You are right in the sense that an implementati= on
> MUST implement at least one stream scheduler, but the original text > allows that one not to be specified in this document.
>
> Are you saying that an implementation MUST implement one of list defin= ed
> by this document?
>
> I'm pretty sure (and this came up in my AD review) the problem is = that the original specification DID define a stream scheduler, that's w= asn't called a stream scheduler, but SCTP implementations did schedule = streams. And that didn't matter until there was more than one way to sc= hedule streams (as in this document).
The original specification did NOT specify a stream scheduler a= nd left this completely implementation
specific.
Right now Linux is using (and only supporting a single scheduler) what we c= all in this document
SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in this docum= ent SCTP_SS_RR and
Solaris uses one of these, forgot which one. Among these kernel implementat= ions, only FreeBSD
supports multiple streams schedulers and its selection. Possibly other clos= ed source SCTP
implementations might support other schedulers. Don't know.

Thanks for getting that right for me ...
Spencer
=C2=A0
= =C2=A0> So you're working out better wording that says something lik= e "in addition to the way the original specification scheduled streams= , we're defining more of them". I think.
I think we wanted to say something like:

Here is a list of schedulers. Your implementation might support some of the= m, but this is
left open. So you can't rely on it.

The list of schedulers we specified includes the ones being used as default= by FreeBSD, Linux and
Solaris and was extended by the ones supported by FreeBSD and the one expli= citly required by
WebRTC, which is SCTP_SS_WFQ.

What about this change:

OLD TEXT:
=C2=A0 =C2=A0An implementation MAY implement any subset of= them.

NEW TEXT:
=C2=A0 =C2=A0An implementation MAY implement any subset of them. If the imp= lementation
=C2=A0 =C2=A0is used for WebRTC Datachannels as specified in [I-D.ietf-rtcw= eb-data-channel]
=C2=A0 =C2=A0it MUST implement the Weighted Fair Queueing Scheduler defined= in Section 3.6.

That works for me, but I&#= 39;ll let Benoit reply.

Spencer
=C2=A0
Best regards
Michael
>
> ?
>
> Spencer


--94eb2c0a87d61fc74005580cde5e-- From nobody Thu Aug 31 12:56:47 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D841326FE; Thu, 31 Aug 2017 12:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 fIM2XkLmq_q5; Thu, 31 Aug 2017 12:56:09 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7B11326ED; Thu, 31 Aug 2017 12:56:08 -0700 (PDT) Received: from [IPv6:2003:cd:6bcc:5600:fc8d:74e5:a8fb:f5f9] (p200300CD6BCC5600FC8D74E5A8FBF5F9.dip0.t-ipconnect.de [IPv6:2003:cd:6bcc:5600:fc8d:74e5:a8fb:f5f9]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 813FE71E3F8DF; Thu, 31 Aug 2017 21:56:05 +0200 (CEST) From: Michael Tuexen Message-Id: <0E628ABF-6E0E-40A6-87EE-CA94A93FE0A5@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_28642E5D-A8DE-4456-8499-F55BF38F7C89"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 21:56:04 +0200 In-Reply-To: Cc: Spencer Dawkins at IETF , Stefan Winter , "ops-dir@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org, "tsvwg@ietf.org" , "ietf@ietf.org" , IESG IESG To: Benoit Claise References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 19:56:13 -0000 --Apple-Mail=_28642E5D-A8DE-4456-8499-F55BF38F7C89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 31. Aug 2017, at 15:46, Spencer Dawkins at IETF = wrote: >=20 > Hi, Michael, >=20 > On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen = wrote: > > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF = wrote: > > > > Just interjecting ... > > > > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen = wrote: > > > > > On 31. Aug 2017, at 14:14, Benoit Claise = wrote: > > > > > > Hi Michael, > > >>> On 30. Aug 2017, at 18:51, Benoit Claise = wrote: > > >>> > > >>> Michael, > > >>> > > >>> I stumbled on the same point as Stefan. > > >> Hi Benoit, > > >> > > >> thanks for reviewing the document. See my comments in-line. > > >> > > >> Best regards > > >> Michael > > >>> First of, I had to review RFC4960 for TSN/SSN. I was not sure = whether TSN was per stream or not > > >>> It would have helped me to repeat this information in the intro. > > >>> Ok, to be candid, I deduced this information from figure 1 and = 2. > > >>>>>>> And the rest are only musings not needing any action if the = authors don't want > > >>>>>>> to action on them: > > >>>>>>> > > >>>>>>> The introduction presents a good use case, quoting: "e.g., = when the > > >>>>>>> transmission of an urgent > > >>>>>>> message is blocked from transmission because the sender has = started > > >>>>>>> the transmission of another, possibly large, message". > > >>>>>>> > > >>>>>>> The later queueing example in figure 1 has three SIDs being = queued > > >>>>>>> simultanseously. It is not clear which of those "has already = started" and which > > >>>>>> There is actually one message queued for stream 0, three = messages for stream 1, > > >>>>>> and one message for stream 2. > > >>>>>>> are the important ones being delayed. For a better = understanding of the reader, > > >>>>>> The figure is about in which sequence they are put on the = wire. So no > > >>>>>> transmission has startet. This examples also does not deal = with the case > > >>>>>> of one stream having a higher priority than another. That = would be an > > >>>>>> example using a priority scheduler. This examples illustrates = the round > > >>>>>> robin scheduler. > > >>>>>> The point here is that a single scheduler (the round robin = scheduler, for > > >>>>>> example) behaves differently when user message interleaving = is used or not. > > >>>>>> That is an important point: You can even use the schedulers = with regular > > >>>>>> DATA chunk, i.e. with user message interleaving being = negotiated. > > >>> This was my source of confusion. > > >>> With figure 1 and figure 2, you want to show the effect of Round = Robin Scheduler with and without User Message Interleaving, while we = were expecting the figure 2 to be the solution from this spec. Hence = Stefan and I were looking for this "urgent message" in figure 2. > > >> I don't know what you mean with "solution from this spec" means. = This spec introduces > > >> stream schedulers and a protocol extension to allow interleaving = of user messages. > > >> Using this to implement an "urgent" concept is only one = possibility: usage of a > > >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is = misleading. It seems > > >> to ring the wrong bells. That is why I suggested to remove it... > > >>>>>>> it might be useful to revise the figure so that the = head-of-line blocking > > >>>>>>> happens for SID 1 because transmission of 0 and 2 has = already started (and > > >>>>>>> declare SID 1 to be the "important" message). The ASCII art = would just have to > > >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in = time), and the resulting > > >>>>>>> serialisation would then put all the SID 1 messages at the = very end, when 0 and > > >>>>>>> 2 have been completely submitted (right?). > > >>>>>> One could think about adding another example based on the = priority scheduler > > >>>>>> and giving stream 1 a higher priority. But for illustrating = the point of > > >>>>>> schedulers behaving differently depending on the negotiation = of user message > > >>>>>> interleaving this seems not necessary. > > >>>>> That second example might indeed be useful. > > >>>>> > > >>>>> It's simply a bit strange that in the introduction you speak = about an > > >>>>> "urgent" message (something deserving a higher-priority = sending) and > > >>>>> that another transmission has already started - but then the = example has > > >>>>> none of those two. > > >>> Exactly. > > >>> Please add this extra example. > > >>> This would also clarify from the introduction that when you = write ... > > >>> > > >>> The sending of such large messages over > > >>> SCTP as specified in [RFC4960] can result in a form of sender = side > > >>> head of line blocking (e.g., when the transmission of an = urgent > > >>> message is blocked from transmission because the sender has = started > > >>> the transmission of another, possibly large, message). > > >>> > > >>> .. the notion of transmission urgency is not within a stream but = across streams, and that can be achieved with a priority scheduler. > > >> I would actually prefer to remove the word "urgent" from that = sentence. This just rings the wrong bells. > > > That's a missed opportunity in mind, but your call. > > Hmm. Let me remove the word "urgent"... > > > > Yes, please! I wasn't wild about it, either. > It's done: > = https://github.com/sctplab/sctp-idata/commit/cf7b331512cd85d6195eb88fa9636= 0673293323f > > > > >>> The text might have to be rephrased to explain that this spec = provides the ability to create stream scheduler with different relative = stream treatments. > > >> What about: > > >> > > >> OLD TEXT > > >> This document also defines several stream schedulers for = general SCTP > > >> associations. The stream schedulers may behave differently = depending > > >> on whether user message interleaving has been negotiated for = the > > >> association or not. > > >> > > >> NEW TEXT > > >> This document also defines several stream schedulers for = general SCTP > > >> associations allowing different relative stream treatments. > > >> The stream schedulers may behave differently depending > > >> on whether user message interleaving has been negotiated for = the > > >> association or not. > > >> > > >> Would that address this issue? > > > ok. > > Fixed. > > >> > > >>> And also that urgent message would be placed in this high = priority stream scheduler (reliable, I guess, but that's orthogonal) = stream. > > >> I really would like to get rid of this. I don't think giving the = strict > > >> priority scheduler as specific role here is a good idea. > > >> > > >> The RR scheduler was chosen as the simplest scheduler to = illustrate > > >> that scheduler can behave differently when using interleaving or = not. > > >>>> What about removing the word "urgent" from that sentence. > > >>>>> In fact I wonder why you speak about urgent things in the = introduction > > >>>>> at all. Neither the scheduler nor the interleaving are = designed to help > > >>>>> urgent things to be sent earlier. > > >>>>> > > >>>>> All they do is make the transmission fairer so that *all* = chunks get a > > >>>>> more even serialised distribution on the wire. > > >>>> That is not true in general. If you use the priority scheduler, = one > > >>>> stream gets preferred treatment. It also makes sure that the = time > > >>>> of a message spent in the stream queue is shorter. So these = messages > > >>>> get sent earlier. > > >>>> In the case of the round robin scheduler, you are right that = this is > > >>>> about getting fairer treatment. If you take the WFQ scheduler, = the > > >>>> streams don't get the same treatment, but it depends on the = weight > > >>>> given to the stream. > > >>>>> So, rather than saying that the spec helps urgent things to be = sent > > >>>>> earlier, it should maybe rather state that the spec helps = every message > > >>>>> getting an equal, and equally distributed, share of the = medium. > > >>>> It is not meant that the spec does this. It was one example, = what > > >>>> a particular stream scheduler does. But there are multiple = schedulers > > >>>> defined in the document. > > >>>> > > >>>> The RR scheduler example is not intended to illustrate what you = can do > > >>>> with all the schedulers, but that using message interleaving or = not > > >>>> has an impact on the scheduler. That is meant by stating: > > >>>> > > >>>> This document also defines several stream schedulers for = general SCTP associations. > > >>>> The stream schedulers may behave differently depending on = whether user message > > >>>> interleaving has been negotiated for the association or not. > > >>>> > > >>>> This is followed by illustrating this using the RR scheduler. > > >>>> > > >>>> Best regards > > >>> Also, I don't see the value of the last sentence in this = paragraph, especially with RFC2119 MAY. > > >>> > > >>> This section defines several stream schedulers. The stream > > >>> schedulers may behave differently depending on whether user = message > > >>> interleaving has been negotiated for the association or not. = An > > >>> implementation MAY implement any subset of them. > > >> During the review the question was brought up which scheduler = have to be implemented > > >> by an implementation. This sentence was add to address it. > > >> If you want, I can remove it. > > > The point is that the MAY is that sentence doesn't mean anything. > > > Maybe you mean: > > > > > > An implementation MUST implement at least one stream scheduler. > > That would require an implementation to implement at least one of > > the ones being listed. You are right in the sense that an = implementation > > MUST implement at least one stream scheduler, but the original text > > allows that one not to be specified in this document. > > > > Are you saying that an implementation MUST implement one of list = defined > > by this document? > > > > I'm pretty sure (and this came up in my AD review) the problem is = that the original specification DID define a stream scheduler, that's = wasn't called a stream scheduler, but SCTP implementations did schedule = streams. And that didn't matter until there was more than one way to = schedule streams (as in this document). > The original specification did NOT specify a stream scheduler and left = this completely implementation > specific. > Right now Linux is using (and only supporting a single scheduler) what = we call in this document > SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in this = document SCTP_SS_RR and > Solaris uses one of these, forgot which one. Among these kernel = implementations, only FreeBSD > supports multiple streams schedulers and its selection. Possibly other = closed source SCTP > implementations might support other schedulers. Don't know. >=20 > Thanks for getting that right for me ... >=20 > Spencer > =20 > > So you're working out better wording that says something like "in = addition to the way the original specification scheduled streams, we're = defining more of them". I think. > I think we wanted to say something like: >=20 > Here is a list of schedulers. Your implementation might support some = of them, but this is > left open. So you can't rely on it. >=20 > The list of schedulers we specified includes the ones being used as = default by FreeBSD, Linux and > Solaris and was extended by the ones supported by FreeBSD and the one = explicitly required by > WebRTC, which is SCTP_SS_WFQ. >=20 > What about this change: >=20 > OLD TEXT: > An implementation MAY implement any subset of them. >=20 > NEW TEXT: > An implementation MAY implement any subset of them. If the = implementation > is used for WebRTC Datachannels as specified in = [I-D.ietf-rtcweb-data-channel] > it MUST implement the Weighted Fair Queueing Scheduler defined in = Section 3.6. >=20 > That works for me, but I'll let Benoit reply. Benoit? >=20 > Spencer > =20 > Best regards > Michael > > > > ? > > > > Spencer >=20 >=20 --Apple-Mail=_28642E5D-A8DE-4456-8499-F55BF38F7C89 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MzExOTU2MDRaMCMGCSqGSIb3DQEJBDEWBBSH8rs70wJLrTrbzGeG Pmi0dxdI1zCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQCawfm+8wQ4NHop/SJ99IMuDRN8l/UiXp9N +oMA0gN7SjermU1wWgDZ01/q/slF1zRfF9Xr55nrtXra6Wd4VUnDGESXcrYqIpWlABJCymFelUIU CeD3DsqYgJBU8m2hAbABiOE9m8QywShyZb3gWg5ZADw4ggzlsA/oKdaxrYmBowepZLYfccjNYO2g avuXkl85F0Z/7ooVP3Z2hs/1r/+xjDPtk+nGvU4AzyhZ20gRRke3vmyB2I+82td2z6tsbJGxnBW6 zmGeHH6d157YWqZ9vxLRt8yeAl+hwyvmyTiJD32qjfUrvjlf2SUHFWEsXZDjQTpS7D7j4owWUoh9 qjNeAAAAAAAA --Apple-Mail=_28642E5D-A8DE-4456-8499-F55BF38F7C89-- From nobody Thu Aug 31 13:25:49 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEFF132223; Thu, 31 Aug 2017 13:25:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk CC: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, draft-ietf-tsvwg-ecn-experimentation@ietf.org, spencerdawkins.ietf@gmail.com, Gorry Fairhurst , tsvwg-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150421114169.16785.16881315519955204652.idtracker@ietfa.amsl.com> Date: Thu, 31 Aug 2017 13:25:41 -0700 Archived-At: Subject: [tsvwg] Last Call: (Explicit Congestion Notification (ECN) Experimentation) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 20:25:42 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Explicit Congestion Notification (ECN) Experimentation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC 3168 that would otherwise hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, and provides the rationale for reclassification of RFC 3540 as Historic; this reclassification enables new experimental use of the ECT(1) codepoint. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5622: Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental - IETF stream) From nobody Thu Aug 31 14:08:14 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2511329E3; Thu, 31 Aug 2017 14:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckW8a9uOzjbh; Thu, 31 Aug 2017 14:07:33 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 96CFD132351; Thu, 31 Aug 2017 14:07:33 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h127so4180329ywf.3; Thu, 31 Aug 2017 14:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pzR2w3m+KU9mzWudVXpfvpWdAsEEk/8Hy6LLz3ucd60=; b=DC0h44M2eYEmkDk+7GJXtelQ5lNE92mx6f/8ovCi8hbdPxBRpNKNA0GI8UWPdDA406 WedrhMKdDvFGC2mRF5m6IEnxvz7GZqbwySt0tMa/BOJgKYhS8UlTKrZehfZJ5yQYQ7V3 DQxv+OdHnXIAWNRUtKz6bT7KmHugVATkIEW0MpVEDPWUWryTpDDaUaur2kSDjmlw9Hcu CvobAzOwZUoqrMxUalip9vkPysWdDlwgy/wWSf1gQv5jtYcKbTDBxHA0Jc9oQxQZttkc ryOVwc6/KGiZtLKXVuaDSptvWX/6LCoDJmdTWBJ699/An9tpNzJK5TwzmQrhseklhx88 Q+sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pzR2w3m+KU9mzWudVXpfvpWdAsEEk/8Hy6LLz3ucd60=; b=PxJ7jiExx0D7eGyTU8xeZStv6r3Qpu1RHjOSlAHf2ljrgn7yBSrvY+SyY9M7BUfb7P h84lGt+JIKyoKEaRJgzGYKhEYIBd5lkmQJ3HeeimqSVWfpi/rywxhsheCf4S8siemjgP wv9X2vDBo2/redwyRHBgiZYVjuPqz/C3Hw8057i2L4wpmTSTlIf6/1FI5Bye9SiTK0lS e41qSCISHH/LkU42ZUb13FtsMf9QBpJy1RGbViYYALuzRRdvClNJT8sogm4UiAwUH6dV 4p3UfakKkoM6xQaxiwd7ps4KrJO8qRAZvXkcspbqrm5tkH+NFw9pnZ3mhBVWMg+dSiPR RtGw== X-Gm-Message-State: AHYfb5jk4bs88SoDmj3cohwniUoqezn4ciu/g7zHG5UDngmnOq2G4ipd CPgSES3SsDc0H+QWE0OujgScPpOJOA== X-Google-Smtp-Source: ADKCNb6ATaCmw7rqZBzsxj4fTZI6U0lqobDj1KL/MAufndk2KWtxUzsUs+ZDeIsmB+rKj2C+awPQM3YLn9LQWrggMSQ= X-Received: by 10.37.88.86 with SMTP id m83mr6032881ybb.170.1504213298155; Thu, 31 Aug 2017 14:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 31 Aug 2017 14:01:37 -0700 (PDT) In-Reply-To: <0E628ABF-6E0E-40A6-87EE-CA94A93FE0A5@fh-muenster.de> References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> <0E628ABF-6E0E-40A6-87EE-CA94A93FE0A5@fh-muenster.de> From: Spencer Dawkins at IETF Date: Thu, 31 Aug 2017 16:01:37 -0500 Message-ID: To: Michael Tuexen Cc: Benoit Claise , Stefan Winter , "ops-dir@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org, "tsvwg@ietf.org" , "ietf@ietf.org" , IESG IESG Content-Type: multipart/alternative; boundary="001a114166d44d94e8055812f3b4" Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 21:07:37 -0000 --001a114166d44d94e8055812f3b4 Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Thu, Aug 31, 2017 at 2:56 PM, Michael Tuexen wrote: > > > On 31. Aug 2017, at 15:46, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Hi, Michael, > > > > On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen > wrote: > > > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > > > Just interjecting ... > > > > > > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen > wrote: > > > > > > > On 31. Aug 2017, at 14:14, Benoit Claise wrote: > > > > > > > > Hi Michael, > > > >>> On 30. Aug 2017, at 18:51, Benoit Claise > wrote: > > > >>> > > > >>> Michael, > > > >>> > > > >>> I stumbled on the same point as Stefan. > > > >> Hi Benoit, > > > >> > > > >> thanks for reviewing the document. See my comments in-line. > > > >> > > > >> Best regards > > > >> Michael > > > >>> First of, I had to review RFC4960 for TSN/SSN. I was not sure > whether TSN was per stream or not > > > >>> It would have helped me to repeat this information in the intro. > > > >>> Ok, to be candid, I deduced this information from figure 1 and 2. > > > >>>>>>> And the rest are only musings not needing any action if the > authors don't want > > > >>>>>>> to action on them: > > > >>>>>>> > > > >>>>>>> The introduction presents a good use case, quoting: "e.g., > when the > > > >>>>>>> transmission of an urgent > > > >>>>>>> message is blocked from transmission because the sender has > started > > > >>>>>>> the transmission of another, possibly large, message". > > > >>>>>>> > > > >>>>>>> The later queueing example in figure 1 has three SIDs being > queued > > > >>>>>>> simultanseously. It is not clear which of those "has already > started" and which > > > >>>>>> There is actually one message queued for stream 0, three > messages for stream 1, > > > >>>>>> and one message for stream 2. > > > >>>>>>> are the important ones being delayed. For a better > understanding of the reader, > > > >>>>>> The figure is about in which sequence they are put on the wire. > So no > > > >>>>>> transmission has startet. This examples also does not deal with > the case > > > >>>>>> of one stream having a higher priority than another. That would > be an > > > >>>>>> example using a priority scheduler. This examples illustrates > the round > > > >>>>>> robin scheduler. > > > >>>>>> The point here is that a single scheduler (the round robin > scheduler, for > > > >>>>>> example) behaves differently when user message interleaving is > used or not. > > > >>>>>> That is an important point: You can even use the schedulers > with regular > > > >>>>>> DATA chunk, i.e. with user message interleaving being > negotiated. > > > >>> This was my source of confusion. > > > >>> With figure 1 and figure 2, you want to show the effect of Round > Robin Scheduler with and without User Message Interleaving, while we were > expecting the figure 2 to be the solution from this spec. Hence Stefan and > I were looking for this "urgent message" in figure 2. > > > >> I don't know what you mean with "solution from this spec" means. > This spec introduces > > > >> stream schedulers and a protocol extension to allow interleaving of > user messages. > > > >> Using this to implement an "urgent" concept is only one > possibility: usage of a > > > >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is > misleading. It seems > > > >> to ring the wrong bells. That is why I suggested to remove it... > > > >>>>>>> it might be useful to revise the figure so that the > head-of-line blocking > > > >>>>>>> happens for SID 1 because transmission of 0 and 2 has already > started (and > > > >>>>>>> declare SID 1 to be the "important" message). The ASCII art > would just have to > > > >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), > and the resulting > > > >>>>>>> serialisation would then put all the SID 1 messages at the > very end, when 0 and > > > >>>>>>> 2 have been completely submitted (right?). > > > >>>>>> One could think about adding another example based on the > priority scheduler > > > >>>>>> and giving stream 1 a higher priority. But for illustrating the > point of > > > >>>>>> schedulers behaving differently depending on the negotiation of > user message > > > >>>>>> interleaving this seems not necessary. > > > >>>>> That second example might indeed be useful. > > > >>>>> > > > >>>>> It's simply a bit strange that in the introduction you speak > about an > > > >>>>> "urgent" message (something deserving a higher-priority sending) > and > > > >>>>> that another transmission has already started - but then the > example has > > > >>>>> none of those two. > > > >>> Exactly. > > > >>> Please add this extra example. > > > >>> This would also clarify from the introduction that when you write > ... > > > >>> > > > >>> The sending of such large messages over > > > >>> SCTP as specified in [RFC4960] can result in a form of sender > side > > > >>> head of line blocking (e.g., when the transmission of an urgent > > > >>> message is blocked from transmission because the sender has > started > > > >>> the transmission of another, possibly large, message). > > > >>> > > > >>> .. the notion of transmission urgency is not within a stream but > across streams, and that can be achieved with a priority scheduler. > > > >> I would actually prefer to remove the word "urgent" from that > sentence. This just rings the wrong bells. > > > > That's a missed opportunity in mind, but your call. > > > Hmm. Let me remove the word "urgent"... > > > > > > Yes, please! I wasn't wild about it, either. > > It's done: > > https://github.com/sctplab/sctp-idata/commit/cf7b331512cd85d > 6195eb88fa96360673293323f > > > > > > >>> The text might have to be rephrased to explain that this spec > provides the ability to create stream scheduler with different relative > stream treatments. > > > >> What about: > > > >> > > > >> OLD TEXT > > > >> This document also defines several stream schedulers for general > SCTP > > > >> associations. The stream schedulers may behave differently > depending > > > >> on whether user message interleaving has been negotiated for the > > > >> association or not. > > > >> > > > >> NEW TEXT > > > >> This document also defines several stream schedulers for general > SCTP > > > >> associations allowing different relative stream treatments. > > > >> The stream schedulers may behave differently depending > > > >> on whether user message interleaving has been negotiated for the > > > >> association or not. > > > >> > > > >> Would that address this issue? > > > > ok. > > > Fixed. > > > >> > > > >>> And also that urgent message would be placed in this high priority > stream scheduler (reliable, I guess, but that's orthogonal) stream. > > > >> I really would like to get rid of this. I don't think giving the > strict > > > >> priority scheduler as specific role here is a good idea. > > > >> > > > >> The RR scheduler was chosen as the simplest scheduler to illustrate > > > >> that scheduler can behave differently when using interleaving or > not. > > > >>>> What about removing the word "urgent" from that sentence. > > > >>>>> In fact I wonder why you speak about urgent things in the > introduction > > > >>>>> at all. Neither the scheduler nor the interleaving are designed > to help > > > >>>>> urgent things to be sent earlier. > > > >>>>> > > > >>>>> All they do is make the transmission fairer so that *all* chunks > get a > > > >>>>> more even serialised distribution on the wire. > > > >>>> That is not true in general. If you use the priority scheduler, > one > > > >>>> stream gets preferred treatment. It also makes sure that the time > > > >>>> of a message spent in the stream queue is shorter. So these > messages > > > >>>> get sent earlier. > > > >>>> In the case of the round robin scheduler, you are right that this > is > > > >>>> about getting fairer treatment. If you take the WFQ scheduler, the > > > >>>> streams don't get the same treatment, but it depends on the weight > > > >>>> given to the stream. > > > >>>>> So, rather than saying that the spec helps urgent things to be > sent > > > >>>>> earlier, it should maybe rather state that the spec helps every > message > > > >>>>> getting an equal, and equally distributed, share of the medium. > > > >>>> It is not meant that the spec does this. It was one example, what > > > >>>> a particular stream scheduler does. But there are multiple > schedulers > > > >>>> defined in the document. > > > >>>> > > > >>>> The RR scheduler example is not intended to illustrate what you > can do > > > >>>> with all the schedulers, but that using message interleaving or > not > > > >>>> has an impact on the scheduler. That is meant by stating: > > > >>>> > > > >>>> This document also defines several stream schedulers for general > SCTP associations. > > > >>>> The stream schedulers may behave differently depending on whether > user message > > > >>>> interleaving has been negotiated for the association or not. > > > >>>> > > > >>>> This is followed by illustrating this using the RR scheduler. > > > >>>> > > > >>>> Best regards > > > >>> Also, I don't see the value of the last sentence in this > paragraph, especially with RFC2119 MAY. > > > >>> > > > >>> This section defines several stream schedulers. The stream > > > >>> schedulers may behave differently depending on whether user > message > > > >>> interleaving has been negotiated for the association or not. An > > > >>> implementation MAY implement any subset of them. > > > >> During the review the question was brought up which scheduler have > to be implemented > > > >> by an implementation. This sentence was add to address it. > > > >> If you want, I can remove it. > > > > The point is that the MAY is that sentence doesn't mean anything. > > > > Maybe you mean: > > > > > > > > An implementation MUST implement at least one stream scheduler. > > > That would require an implementation to implement at least one of > > > the ones being listed. You are right in the sense that an > implementation > > > MUST implement at least one stream scheduler, but the original text > > > allows that one not to be specified in this document. > > > > > > Are you saying that an implementation MUST implement one of list > defined > > > by this document? > > > > > > I'm pretty sure (and this came up in my AD review) the problem is that > the original specification DID define a stream scheduler, that's wasn't > called a stream scheduler, but SCTP implementations did schedule streams. > And that didn't matter until there was more than one way to schedule > streams (as in this document). > > The original specification did NOT specify a stream scheduler and left > this completely implementation > > specific. > > Right now Linux is using (and only supporting a single scheduler) what > we call in this document > > SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in this > document SCTP_SS_RR and > > Solaris uses one of these, forgot which one. Among these kernel > implementations, only FreeBSD > > supports multiple streams schedulers and its selection. Possibly other > closed source SCTP > > implementations might support other schedulers. Don't know. > > > > Thanks for getting that right for me ... > > > > Spencer > > > > > So you're working out better wording that says something like "in > addition to the way the original specification scheduled streams, we're > defining more of them". I think. > > I think we wanted to say something like: > > > > Here is a list of schedulers. Your implementation might support some of > them, but this is > > left open. So you can't rely on it. > > > > The list of schedulers we specified includes the ones being used as > default by FreeBSD, Linux and > > Solaris and was extended by the ones supported by FreeBSD and the one > explicitly required by > > WebRTC, which is SCTP_SS_WFQ. > > > > What about this change: > > > > OLD TEXT: > > An implementation MAY implement any subset of them. > > > > NEW TEXT: > > An implementation MAY implement any subset of them. If the > implementation > > is used for WebRTC Datachannels as specified in > [I-D.ietf-rtcweb-data-channel] > > it MUST implement the Weighted Fair Queueing Scheduler defined in > Section 3.6. > > > > That works for me, but I'll let Benoit reply. > Benoit? > Since I'm not sure which timezone Benoit is in (except that I know it's Yang Central Time), I'll respond by saying that I did talk with Benoit on the call, after sending him this privately: This is tripping over the same thing I was tripping over - SCTP standards haven't had a stream scheduler, but SCTP implementations scheduled streams. So Michael was thinking that you were asking about forcing existing implementations to implement one of the new ones. His response was to propose text basically saying "in addition to what you're doing now, you MAY do one or more of the following". I'm sorry I garbled my point so badly. Benoit said on the call (if I understood him correctly) that my explanation (filtered through your correction) worked for him. The point I was trying to make earlier was that SCTP implementations scheduled streams somehow, and that your document wasn't an effort to tell them to stop doing what they were doing, but that implementers now had more standardized options than they did before. I think your proposed text says that well. At this point, I think you're ready to submit a revised ID to reflect the comments you've received. I'll review your changes, and that will give Benoit a chance to interrupt if he needs to - he's quite responsive, especially when he doesn't spend the evening on a telechat. Thanks, and it's always a pleasure. Spencer > > > > Spencer > > > > Best regards > > Michael > > > > > > ? > > > > > > Spencer > > > > > > --001a114166d44d94e8055812f3b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

On Thu, Aug 31, 2017 at 2:56 PM, Michael Tuexen <tuexen@fh= -muenster.de> wrote:

> On 31. Aug 2017, at 15:46, Spencer Dawkins at IETF <spencerdawkins.ietf@gma= il.com> wrote:
>
> Hi, Michael,
>
> On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen <tuexen@fh-muenster.de> wrot= e:
> > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF <spencerdawkins.iet= f@gmail.com> wrote:
> >
> > Just interjecting ...
> >
> > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen <tuexen@fh-muenster.de>= wrote:
> >
> > > On 31. Aug 2017, at 14:14, Benoit Claise <bclaise@cisco.com> wrote: > > >
> > > Hi Michael,
> > >>> On 30. Aug 2017, at 18:51, Benoit Claise <bclaise@cisco.com> w= rote:
> > >>>
> > >>> Michael,
> > >>>
> > >>> I stumbled on the same point as Stefan.
> > >> Hi Benoit,
> > >>
> > >> thanks for reviewing the document. See my comments in-li= ne.
> > >>
> > >> Best regards
> > >> Michael
> > >>> First of, I had to review RFC4960 for TSN/SSN. I was= not sure whether TSN was per stream or not
> > >>> It would have helped me to repeat this information i= n the intro.
> > >>> Ok, to be candid, I deduced this information from fi= gure 1 and 2.
> > >>>>>>> And the rest are only musings not ne= eding any action if the authors don't want
> > >>>>>>> to action on them:
> > >>>>>>>
> > >>>>>>> The introduction presents a good use= case, quoting: "e.g., when the
> > >>>>>>> transmission of an urgent
> > >>>>>>>=C2=A0 message is blocked from transm= ission because the sender has started
> > >>>>>>>=C2=A0 the transmission of another, p= ossibly large, message".
> > >>>>>>>
> > >>>>>>> The later queueing example in figure= 1 has three SIDs being queued
> > >>>>>>> simultanseously. It is not clear whi= ch of those "has already started" and which
> > >>>>>> There is actually one message queued for= stream 0, three messages for stream 1,
> > >>>>>> and one message for stream 2.
> > >>>>>>> are the important ones being delayed= . For a better understanding of the reader,
> > >>>>>> The figure is about in which sequence th= ey are put on the wire. So no
> > >>>>>> transmission has startet. This examples = also does not deal with the case
> > >>>>>> of one stream having a higher priority t= han another. That would be an
> > >>>>>> example using a priority scheduler. This= examples illustrates the round
> > >>>>>> robin scheduler.
> > >>>>>> The point here is that a single schedule= r (the round robin scheduler, for
> > >>>>>> example) behaves differently when user m= essage interleaving is used or not.
> > >>>>>> That is an important point: You can even= use the schedulers with regular
> > >>>>>> DATA chunk, i.e. with user message inter= leaving being negotiated.
> > >>> This was my source of confusion.
> > >>> With figure 1 and figure 2, you want to show the eff= ect of Round Robin Scheduler with and without User Message Interleaving, wh= ile we were expecting the figure 2 to be the solution from this spec. Hence= Stefan and I were looking for this "urgent message" in figure 2.=
> > >> I don't know what you mean with "solution from = this spec" means. This spec introduces
> > >> stream schedulers and a protocol extension to allow inte= rleaving of user messages.
> > >> Using this to implement an "urgent" concept is= only one possibility: usage of a
> > >> strict priority scheduler (SCTP_SS_PRIO). So this "= urgent" is misleading. It seems
> > >> to ring the wrong bells. That is why I suggested to remo= ve it...
> > >>>>>>> it might be useful to revise the fig= ure so that the head-of-line blocking
> > >>>>>>> happens for SID 1 because transmissi= on of=C2=A0 0 and 2 has already started (and
> > >>>>>>> declare SID 1 to be the "import= ant" message). The ASCII art would just have to
> > >>>>>>> indent SID 1 content a bit (placing = 0 and 2 earlier in time), and the resulting
> > >>>>>>> serialisation would then put all the= SID 1 messages at the very end, when 0 and
> > >>>>>>> 2 have been completely submitted (ri= ght?).
> > >>>>>> One could think about adding another exa= mple based on the priority scheduler
> > >>>>>> and giving stream 1 a higher priority. B= ut for illustrating the point of
> > >>>>>> schedulers behaving differently dependin= g on the negotiation of user message
> > >>>>>> interleaving this seems not necessary. > > >>>>> That second example might indeed be useful.<= br> > > >>>>>
> > >>>>> It's simply a bit strange that in the in= troduction you speak about an
> > >>>>> "urgent" message (something deserv= ing a higher-priority sending) and
> > >>>>> that another transmission has already starte= d - but then the example has
> > >>>>> none of those two.
> > >>> Exactly.
> > >>> Please add this extra example.
> > >>> This would also clarify from the introduction that w= hen you write ...
> > >>>
> > >>>=C2=A0 =C2=A0The sending of such large messages over<= br> > > >>>=C2=A0 =C2=A0SCTP as specified in [RFC4960] can resul= t in a form of sender side
> > >>>=C2=A0 =C2=A0head of line blocking (e.g., when the tr= ansmission of an urgent
> > >>>=C2=A0 =C2=A0message is blocked from transmission bec= ause the sender has started
> > >>>=C2=A0 =C2=A0the transmission of another, possibly la= rge, message).
> > >>>
> > >>> .. the notion of transmission urgency is not within = a stream but across streams, and that can be achieved with a priority sched= uler.
> > >> I would actually prefer to remove the word "urgent&= quot; from that sentence. This just rings the wrong bells.
> > > That's a missed opportunity in mind, but your call.
> > Hmm. Let me remove the word "urgent"...
> >
> > Yes, please! I wasn't wild about it, either.
> It's done:
> https://gi= thub.com/sctplab/sctp-idata/commit/cf7b331512cd85d6195eb88fa96360= 673293323f
> >
> > >>> The text might have to be rephrased to explain that = this spec provides the ability to create stream scheduler with different re= lative stream treatments.
> > >> What about:
> > >>
> > >> OLD TEXT
> > >>=C2=A0 =C2=A0 This document also defines several stream s= chedulers for general SCTP
> > >>=C2=A0 =C2=A0 associations.=C2=A0 The stream schedulers m= ay behave differently depending
> > >>=C2=A0 =C2=A0 on whether user message interleaving has be= en negotiated for the
> > >>=C2=A0 =C2=A0 association or not.
> > >>
> > >> NEW TEXT
> > >>=C2=A0 =C2=A0 This document also defines several stream s= chedulers for general SCTP
> > >>=C2=A0 =C2=A0 associations allowing different relative st= ream treatments.
> > >>=C2=A0 =C2=A0 The stream schedulers may behave differentl= y depending
> > >>=C2=A0 =C2=A0 on whether user message interleaving has be= en negotiated for the
> > >>=C2=A0 =C2=A0 association or not.
> > >>
> > >> Would that address this issue?
> > > ok.
> > Fixed.
> > >>
> > >>> And also that urgent message would be placed in this= high priority stream scheduler (reliable, I guess, but that's orthogon= al) stream.
> > >> I really would like to get rid of this. I don't thin= k giving the strict
> > >> priority scheduler as specific role here is a good idea.=
> > >>
> > >> The RR scheduler was chosen as the simplest scheduler to= illustrate
> > >> that scheduler can behave differently when using interle= aving or not.
> > >>>> What about removing the word "urgent" = from that sentence.
> > >>>>> In fact I wonder why you speak about urgent = things in the introduction
> > >>>>> at all. Neither the scheduler nor the interl= eaving are designed to help
> > >>>>> urgent things to be sent earlier.
> > >>>>>
> > >>>>> All they do is make the transmission fairer = so that *all* chunks get a
> > >>>>> more even serialised distribution on the wir= e.
> > >>>> That is not true in general. If you use the prio= rity scheduler, one
> > >>>> stream gets preferred treatment. It also makes s= ure that the time
> > >>>> of a message spent in the stream queue is shorte= r. So these messages
> > >>>> get sent earlier.
> > >>>> In the case of the round robin scheduler, you ar= e right that this is
> > >>>> about getting fairer treatment. If you take the = WFQ scheduler, the
> > >>>> streams don't get the same treatment, but it= depends on the weight
> > >>>> given to the stream.
> > >>>>> So, rather than saying that the spec helps u= rgent things to be sent
> > >>>>> earlier, it should maybe rather state that t= he spec helps every message
> > >>>>> getting an equal, and equally distributed, s= hare of the medium.
> > >>>> It is not meant that the spec does this. It was = one example, what
> > >>>> a particular stream scheduler does. But there ar= e multiple schedulers
> > >>>> defined in the document.
> > >>>>
> > >>>> The RR scheduler example is not intended to illu= strate what you can do
> > >>>> with all the schedulers, but that using message = interleaving or not
> > >>>> has an impact on the scheduler. That is meant by= stating:
> > >>>>
> > >>>> This document also defines several stream schedu= lers for general SCTP associations.
> > >>>> The stream schedulers may behave differently dep= ending on whether user message
> > >>>> interleaving has been negotiated for the associa= tion or not.
> > >>>>
> > >>>> This is followed by illustrating this using the = RR scheduler.
> > >>>>
> > >>>> Best regards
> > >>> Also, I don't see the value of the last sentence= in this paragraph, especially with RFC2119 MAY.
> > >>>
> > >>>=C2=A0 =C2=A0This section defines several stream sche= dulers.=C2=A0 The stream
> > >>>=C2=A0 =C2=A0schedulers may behave differently depend= ing on whether user message
> > >>>=C2=A0 =C2=A0interleaving has been negotiated for the= association or not.=C2=A0 An
> > >>>=C2=A0 =C2=A0implementation MAY implement any subset = of them.
> > >> During the review the question was brought up which sche= duler have to be implemented
> > >> by an implementation. This sentence was add to address i= t.
> > >> If you want, I can remove it.
> > > The point is that the MAY is that sentence doesn't mean = anything.
> > > Maybe you mean:
> > >
> > > An implementation MUST implement at least one stream schedul= er.
> > That would require an implementation to implement at least one of=
> > the ones being listed. You are right in the sense that an impleme= ntation
> > MUST implement at least one stream scheduler, but the original te= xt
> > allows that one not to be specified in this document.
> >
> > Are you saying that an implementation MUST implement one of list = defined
> > by this document?
> >
> > I'm pretty sure (and this came up in my AD review) the proble= m is that the original specification DID define a stream scheduler, that= 9;s wasn't called a stream scheduler, but SCTP implementations did sche= dule streams. And that didn't matter until there was more than one way = to schedule streams (as in this document).
> The original specification did NOT specify a stream scheduler and left= this completely implementation
> specific.
> Right now Linux is using (and only supporting a single scheduler) what= we call in this document
> SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in this = document SCTP_SS_RR and
> Solaris uses one of these, forgot which one. Among these kernel implem= entations, only FreeBSD
> supports multiple streams schedulers and its selection. Possibly other= closed source SCTP
> implementations might support other schedulers. Don't know.
>
> Thanks for getting that right for me ...
>
> Spencer
>
>=C2=A0 > So you're working out better wording that says somethin= g like "in addition to the way the original specification scheduled st= reams, we're defining more of them". I think.
> I think we wanted to say something like:
>
> Here is a list of schedulers. Your implementation might support some o= f them, but this is
> left open. So you can't rely on it.
>
> The list of schedulers we specified includes the ones being used as de= fault by FreeBSD, Linux and
> Solaris and was extended by the ones supported by FreeBSD and the one = explicitly required by
> WebRTC, which is SCTP_SS_WFQ.
>
> What about this change:
>
> OLD TEXT:
>=C2=A0 =C2=A0 An implementation MAY implement any subset of them.
>
> NEW TEXT:
>=C2=A0 =C2=A0 An implementation MAY implement any subset of them. If th= e implementation
>=C2=A0 =C2=A0 is used for WebRTC Datachannels as specified in [I-D.ietf= -rtcweb-data-channel]
>=C2=A0 =C2=A0 it MUST implement the Weighted Fair Queueing Scheduler de= fined in Section 3.6.
>
> That works for me, but I'll let Benoit reply.
Benoit?

Since I'm not s= ure which timezone Benoit is in (except that I know it's Yang Central T= ime), I'll respond by saying that I did talk with Benoit on the call, a= fter sending him this privately:

This is tripping over the same thing I wa= s tripping over - SCTP standards haven't had a stream scheduler, but SC= TP implementations scheduled streams. So Michael was thinking that you were= asking about forcing existing implementations to implement one of the new = ones.=C2=A0

His response was to propose text b= asically saying "in addition to what you're doing now, you MAY do = one or more of the following".=C2=A0

I= 9;m sorry I garbled my point so badly.

Benoit said on the call (if I understood him correctly) that= my explanation (filtered through your correction) worked for him. The poin= t I was trying to make earlier was that SCTP implementations scheduled stre= ams somehow, and that your document wasn't an effort to tell them to st= op doing what they were doing, but that implementers now had more standardi= zed options than they did before.

I think your proposed = text says that well.=C2=A0

At this point, I think yo= u're ready to submit a revised ID to reflect the comments you've re= ceived. I'll review your changes, and that will give Benoit a chance to= interrupt if he needs to - he's quite responsive, especially when he d= oesn't spend the evening on a telechat.

Thanks= , and it's always a pleasure.

Spencer
=C2=A0
>
> Spencer
>
> Best regards
> Michael
> >
> > ?
> >
> > Spencer
>
>


--001a114166d44d94e8055812f3b4-- From nobody Thu Aug 31 19:01:35 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3423D1330F3; Thu, 31 Aug 2017 19:01:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: Cc: draft-ietf-tsvwg-ecn-experimentation.all@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150423129417.4604.2689843099266054478@ietfa.amsl.com> Date: Thu, 31 Aug 2017 19:01:34 -0700 Archived-At: Subject: [tsvwg] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 02:01:34 -0000 Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-tsvwg-ecn-experimentation-05 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tsvwg-ecn-experimentation-05.txt Reviewer: Brian Carpenter Review Date: 2017-09-01 IETF LC End Date: 2017-09-14 IESG Telechat date: 2017-09-14 Summary: Ready with (minor) issues -------- Comment: Very clear from the technical standpoint. -------- Minor Issues: ------------- > 3. ECN Nonce and RFC 3540 ... > o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce > and use of ECT(1) for that Nonce. The specific text updates are > omitted for brevity. I understand the desire for brevity, but this bothers me a bit. What is the reader to make of RFC3168 Section 20.2, for example? My feeling is that a short Appendix outlining the specific updates would be useful. There's already too much spaghetti to untangle. I see no reason why RFC3540 and RFC5622 need to be normative references (and therefore downrefs). They aren't required reading in order to understand this draft. --