From nobody Wed Oct 5 07:27:56 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6136B129751; Wed, 5 Oct 2016 07:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996] 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 v7tBWFJXZfoD; Wed, 5 Oct 2016 07:27:47 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 137AF1288B8; Wed, 5 Oct 2016 07:27:47 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E43D490AA19; Wed, 5 Oct 2016 10:27:45 -0400 (EDT) Date: Wed, 5 Oct 2016 10:27:45 -0400 From: John Leslie To: "Black, David" Message-ID: <20161005142745.GK94244@verdi> References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "tsvwg@ietf.org" , "tcpPrague@ietf.org" Subject: Re: [tcpPrague] [tsvwg] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 14:27:51 -0000 Black, David wrote: > > This is the process-oriented draft on ECN experimentation that I promised > at the TSVWG meeting in Berlin. Comments are welcome, but please keep > the process focus in mind - the intent is to leave documentation of the > actual ECN changes and rationale to the referenced drafts that document > the ECN experiments. Thank you. I have read this draft; and agree it covers what it needs to. I note the intended status is "Standards Track". Is this intended for action by the TSVWG group? -- John Leslie From nobody Thu Oct 6 01:31:42 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D881297B0; Thu, 6 Oct 2016 01:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 KGCL5vmtrOcN; Thu, 6 Oct 2016 01:31:37 -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 1CE8D1297A4; Thu, 6 Oct 2016 01:31:36 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-33-57f60be741d7 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 7E.3F.02458.7EB06F75; Thu, 6 Oct 2016 10:31:35 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Oct 2016 10:31:31 +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=klMoDvlvk0pPe8OJ7l+hBnciKQqrMHB3f8PzyQVtekw=; b=K1Yjz18/GSuLOp00xacpiJzGtsnqMuT+Ull3LSOramTc03yfPjgTqxj13EfeyjSzdL9zDtslfZYj5XeMKbWI4wrb0SafIMy+FS+y0gmbW5NA3VHkKUu5WI++ZWcA0dRsR5xZlcz49p/QJi2AkYkdLVKLiUC5Y6cxnhtRgUTquP4= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Thu, 6 Oct 2016 08:31:31 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0649.024; Thu, 6 Oct 2016 08:31:31 +0000 From: Ingemar Johansson S To: "Black, David" , "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSHBZGHx9sUXyObEi9tVnmmFrvjKCa+yXw Date: Thu, 6 Oct 2016 08:31:30 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.89] x-ms-office365-filtering-correlation-id: 8a27b6fd-2085-4127-6156-08d3edc32c8a x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 6:wpWd2cHRdFlOPxMk+I0H9AQs9GUycRvjIw5TUIsy958r65yvlhToK3XEH1cGTn24pSenCzJ/PjNxJapgzS0+V7hhIlgf1lDQKBr7b25gURbQGBkLWl0UjuAb9uePyJwRzB5sRt8xCgLQKa13+ktnFiuPCherO/sgm/m+rqKln4NRi14yHe3lUZQFUBUKjNIQ6puEzUWxg/1tuLcEN/GZOqfu0SlOkFrNUXyKzCL9S8Mim4/fjTDAgO3ZKGF6WMqec+xp+hv8D95+K8dIDqg2i4E3Tb/yanrtG2qC6cxYM9E=; 5:cs4yhbsTvTvz5dPgIzr1cDBkRIguyf7dlQkWjzYvqNAvJ2KF1Wvg22mCOWfcnFKe5G6++e+KgEDW+a0WaqG51VcaHiAu5JXMF/1KsVovVJw/m7Yu2x+KHl02ujoB+P/0B4yAY7srraD0zu/yr+9zCQ==; 24:fCFJLN++hQ5y9uOESZNwNfd0PeahIgPtm3Ojhn7muMI8zvf0uhXdHJPCKWsKrSFjA+tW77523ulrhyIhJEH4V6pBUbOzgS9CPdds6KR5s9I=; 7:POd5DVSbJ7i95+ArRaKykOxk/I1DM3QgPLTTx8MGGSuBEjfApnDhUca+M9znaczzfhRE6Gal6RP5CyVSLvbxL5Wjr6gAJt9B+zAc/MrJFdqNnhKXOITrZdO98eRxS/BAv+utEmOftnGHaLkmHFqumhGXFCSQkhaL166H2Z9A2MUs2TArzhdiUuRAFra7psLNGAh1c1AQJHCmds+MP1ddzdHQ/WswBULUs6xs+W2eH+pr1hCl0Kh+ncoce6/BprEkusdjK9nBLFWw99+h9eL4U6KQ3kak+0MA+29QKsktis7nm7KoUes3RlUOO9W5lEZG x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB346; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(56004941905204); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(199003)(377454003)(189002)(13464003)(74316002)(3660700001)(586003)(102836003)(33656002)(86362001)(3846002)(6116002)(76176999)(2201001)(50986999)(230783001)(10400500002)(5660300001)(106116001)(3280700002)(105586002)(189998001)(4001430100002)(5002640100001)(101416001)(11100500001)(7696004)(8936002)(54356999)(2501003)(106356001)(68736007)(5001770100001)(2900100001)(66066001)(15975445007)(81166006)(81156014)(2950100002)(97736004)(8666005)(19580395003)(77096005)(4326007)(305945005)(7846002)(9686002)(19580405001)(122556002)(92566002)(7736002)(87936001)(2906002)(76576001)(107886002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2016 08:31:30.0555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjm2znbzmarr6X4amk2IsFsmXQRUVMiVEK7/JmsKIce1PLWOUsy IUYlMlMxK3EmOC/LaZkWkoIpbGBD8wYadvEWLUUzS1lesllux6B/z/s+z/c+7/PyUYS0mO9J paSraSZdlSoTiEldXGvAgWmXJUXA8Lh30EJ5DRlUUGMXBD3UmMig13NjgnAyqkRXRkTV1q7y zvCU4pBEOjUli2YOhsWLk7/05RGZ9b7X76zfIzSoY3c+ElGAD0Neu02Qj8SUFDchmCnq5HOF BcFbm8lZkLiQgE9Dq6TjiRQ/4MGaMYdTdSGwPvkmcBACHAL15mXkIFxxA4KCnkKhgyBwMNgs dsKBd2AFVPwYdE5yxXGga2sScjgQpgz9zj6J90J5T9+GnqIkWAkTvZGcWTEC7d0RnkMjwrHQ 0T/qnImwF0wsj5Oclzt8sFbyuHAYal8NEBx2g5nP63xOnwCL7wv5XN8HLEYuAOAYGK6cdQYA 3CgEzXrVJnES7FWtPMdCgFPgVxFw7VMw2Vcq5PQvETR0z20a74LRCi2PIwwCGOhu3rwdDXWN uYi7hCeMDWtRMfIr/29xDvuDvn1RwOH98LjqK+HAErwdunVWUo/IBuTG0iyblhQYKKeZlASW zUiXp9PqF2jjn5ha1oLbkGk6wowwhWRbJPrjPxVSviqLzU4zI6AImaukWrykkEoSVdk3aCbj EnMtlWbNaCdFytwlR+snFFKcpFLTV2g6k2b+sTxK5KlBxuiYfb6Nob0nXObLcxjvEmsXHjKG P789++fdI1UdOpYfERs2qNzjZRSdFv7WetQZQvr9Y69aq+WW8+qZ4fn5gXM+8st28unFjAv8 j9OGmzZSIwpv9vWIlCgnR0gbSN90HinIXShVn4WVlmfbbkVvvb84FF/2faV1KlTfMggykk1W HfIjGFb1F2QazggjAwAA Archived-At: Cc: Ingemar Johansson S Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 08:31:40 -0000 Hi Thanks for writing up this draft. I have some comments on the contents Intended status : Standards track. I interpret this that it means that this= document becomes standards track.=20 Are there any ideas around the intended status for a document such as brisc= oe-tsvwg-ecn-l4s-id, will it be experimental first or ? Section 4.2 : " "Unless otherwise specified by an Experimental RFC, routers= treat the ECT(0) and ECT(1) codepoints as equivalent, and senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis."" In some way I find it to contradict the proposed statement in section 3 " = Protocols and senders that only require a single ECT codepoint SHOULD use = ECT(0)." I see here a risk that the statement in 4.2 can delay deployment of L4S cap= ability based on the use of ECT(1) in the networks ? Section 5 : I see the main problem with RFC6679 (in this context) in the us= e of the nonce. Don't however see any major problem to use feedback also fo= r an L4S capable sender/receiver using ECT(1).=20 For that purpose it may be better to rewrite : Use of ECT(1) and random ECT values is discouraged, as that may expose RTP to differences in network treatment of ECT(1) and ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. To : Use of ECT values is discouraged, as that may expose RTP to differences in network treatment of ECT(1) and ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. Further ... quote " In support of Alternative Backoff experimentation ...".= I would say that this applies to L4S as well. As an example, SCReAM (RMCAT= WG congestion control candidate) is easily modified to support L4S, and th= e RFC6679 feedback can be used with SCReAM. For that reason it may be bette= r to rephrase it like=20 " In support of Alternative Backoff experimentation and experiments based o= n [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar Regards /Ingemar > -----Original Message----- > From: Black, David [mailto:David.Black@dell.com] > Sent: den 1 oktober 2016 00:42 > To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > Cc: Black, David > Subject: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentatio= n- > 00.txt >=20 > This is the process-oriented draft on ECN experimentation that I promised= at > the TSVWG > meeting in Berlin. Comments are welcome, but please keep the process > focus in mind - > the intent is to leave documentation of the actual ECN changes and ration= ale > to the referenced drafts that document the ECN experiments. >=20 > Thanks, --David >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, September 30, 2016 6:24 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Explicit Congestion Notification (ECN) Experime= ntation > Author : David Black > Filename : draft-black-tsvwg-ecn-experimentation-00.txt > Pages : 10 > Date : 2016-09-30 >=20 > Abstract: > Multiple protocol experiments have been proposed that involve changes > to Explicit Congestion Notification (ECN) as specified in RFC 3168. > This memo summarizes the proposed areas of experimentation to provide > an overview to the Internet community and updates RFC 3168, a > Proposed Standard RFC, to allow the experiments to proceed without > requiring a standards process exception for each Experimental RFC to > update RFC 3168. This memo also makes related updates to the ECN > specification for RTP in RFC 6679 for the same reason. Each > experiment is still required to be documented in an Experimental RFC. > This memo also records the conclusion of the ECN Nonce experiment in > RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentation/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From nobody Thu Oct 6 17:00:05 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ECE1294C6; Thu, 6 Oct 2016 16:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 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=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=z3qvjRsH; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=nH8E+57m 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 Ka1QwSVNZZaP; Thu, 6 Oct 2016 16:59:57 -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 7E97A1294B6; Thu, 6 Oct 2016 16:59:57 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=tZpUnzyx/8PqDDdcSAzTWkVUBIfEighxW4w2X113LVTCBqpBqytpxZf6 KBMKq9Adee2t/DbPL+BV144puue8hxQXWvBqb8gq0wDq7E/B2o+Sp9mMY GZkpQ5D5ZYhwFVs2A1G7EwZT2/botV9yAhyz2EKOPjh9qPpxJWnJ54CTU A=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1475798397; x=1507334397; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Npg809joX+tF2jUtUeSq6O6W+pPGFezRQFTfImt36II=; b=z3qvjRsHs9Sy3bd5nC6GtC7fumiQwDHaEYFS5VgEyAZVIodvIMTZDauF wCJu6/4A6WHudNy8c9yVy0QDZoEpg0vwC/VBx7OTppgf1XTmqc6Hekxto 6nDS7+DH1DaCU1tJg/dctQvlo97jLYEe7VNjP9OKUlsPSxTP6NxctD1F9 4=; 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; 06 Oct 2016 18:59:56 -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; 07 Oct 2016 05:59:55 +0600 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u96NxqVp023518 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Oct 2016 19:59:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u96NxqVp023518 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1475798395; bh=8MHZmbMddGTZJIlDIwIfZUcHN1s=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nH8E+57mNPZ+yqCIdHZtCbzCI2hKdqjO2oMpJqnuU7uryG8lN5090psHUYYBAkFs5 L5UCeGCoHm1X1fN6xzoJEug485mw5ODILgWDqXje9LS7neNxbhOKcyWsoaeGDeFuPV 9tQsKunLXY6W0/2J1q7ETeMhEX+C1vnRLf7CMX7Q= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u96NxqVp023518 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd05.lss.emc.com (RSA Interceptor); Thu, 6 Oct 2016 19:59:33 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u96NxZZh009535 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 6 Oct 2016 19:59:36 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Thu, 6 Oct 2016 19:59:34 -0400 To: John Leslie Thread-Topic: [tsvwg] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSG2lu78AbxlWIl0mB4/rUtZANMqCSn4DggAeWAoCAAe7UIA== Date: Thu, 6 Oct 2016 23:59:33 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> <20161005142745.GK94244@verdi> In-Reply-To: <20161005142745.GK94244@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "tsvwg@ietf.org" , "tcpPrague@ietf.org" Subject: Re: [tcpPrague] [tsvwg] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 00:00:00 -0000 John, > Thank you. I have read this draft; and agree it covers what it needs t= o. Thank you. > I note the intended status is "Standards Track". Is this intended for > action by the TSVWG group? Yes, Thanks, --David > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Wednesday, October 05, 2016 10:28 AM > To: Black, David > Cc: tsvwg@ietf.org; tcpPrague@ietf.org > Subject: Re: [tsvwg] FW: I-D Action: draft-black-tsvwg-ecn-experimentatio= n- > 00.txt >=20 > Black, David wrote: > > > > This is the process-oriented draft on ECN experimentation that I promis= ed > > at the TSVWG meeting in Berlin. Comments are welcome, but please keep > > the process focus in mind - the intent is to leave documentation of the > > actual ECN changes and rationale to the referenced drafts that document > > the ECN experiments. >=20 > Thank you. I have read this draft; and agree it covers what it needs t= o. >=20 > I note the intended status is "Standards Track". Is this intended for > action by the TSVWG group? >=20 > -- > John Leslie From nobody Thu Oct 6 17:28:43 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C741A129476; Thu, 6 Oct 2016 17:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=UNj4LBRl; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=v2i6bjmZ 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 65dhQkqZxXam; Thu, 6 Oct 2016 17:28:36 -0700 (PDT) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 25B37129424; Thu, 6 Oct 2016 17:28:35 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=vET1BIola1V2cvabUkNm8nuvmTpjmILsFzY47LXajIqut6OLJIiEC4yD jqAE+/2LwGyjijJ53Dij1NxDhj51KntoiJwgqo07wJcdkHJP4/Ra2U+KC l4lwP4PxVfUALHuZuOPRb1JyVQnzwHGspCtnCsZhFlyienpjSt32lXuFs M=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1475800116; x=1507336116; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AD4dy7mG5/EbwenjB1B4FfFlxYbWH/WWS/YPxASOhBY=; b=UNj4LBRlVOxfmvVEE6hlsNKzx4aVan85T5Tffv6bVnm3lXdcMHrk9lPM FALNlFePlLa/+PkACc33yGhx29ApuCpMmLgJOFJfjBB31M28QQ3sGA8qi ik3CTGUNC2qTrDZmWVAdgFKgps2oSDnzCX0VXABUeWNM/TGx+wsfjzuV7 k=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2016 19:28:34 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2016 06:28:33 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u970SU9o030474 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Oct 2016 20:28:32 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u970SU9o030474 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1475800113; bh=gsW4cnNa70r5dItrPQ5gF1Sjv90=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=v2i6bjmZVI9mEHCRbKEWeziI3n7KUstZdseR5YAKHbZVtjxzynPn6fJUwXCTEeZI9 EKOwm009tUkJrnbDF7NhG4s++l8ZtyrdlBH/q73iaK/AYzbeH3mn/Kp+fx/jw0Amr8 VyaekwFjXQOG7UwkkXezaJgCcxo7jaf3pdkgnM7c= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u970SU9o030474 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd56.lss.emc.com (RSA Interceptor); Thu, 6 Oct 2016 20:28:05 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u970SDfZ003641 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 6 Oct 2016 20:28:13 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Thu, 6 Oct 2016 20:28:12 -0400 To: Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSH6wQv2w1nNbalEmS9LcageCkg6CcHCiw Date: Fri, 7 Oct 2016 00:28:12 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@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.238.45.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 00:28:39 -0000 Hi Ingemar, David> Inline Thanks, --David > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: Thursday, October 06, 2016 4:32 AM > To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.or= g > Cc: Ingemar Johansson S > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experiment= ation- > 00.txt >=20 > Hi >=20 > Thanks for writing up this draft. I have some comments on the contents Thanks for carefully reading the draft. > Intended status : Standards track. I interpret this that it means that th= is > document becomes standards track. > Are there any ideas around the intended status for a document such as bri= scoe- > tsvwg-ecn-l4s-id, will it be experimental first or ? Possibly - I don' t know. The ecn-experimentation draft is not intended to settle that question for the l4s-id draft or any of the other drafts involv= ed in the described areas of experimentation. I wrote the ecn-experimentation draft to allow the experiments to be specif= ied in Experimental RFCs without each experiment also needing a companion Stand= ards Track RFC just to open up space for the experiment. If any of the experim= ents pan out so well that they deserve to be immediately written up as a Standar= ds Track RFC without bothering with an Experimental RFC, then that would be wonderful, IMHO. =20 > Section 4.2 : " "Unless otherwise specified by an Experimental RFC, route= rs treat > the ECT(0) and ECT(1) codepoints as equivalent, and senders are > free to use either the ECT(0) or the ECT(1) codepoint to indicate > ECT, on a packet-by-packet basis."" > In some way I find it to contradict the proposed statement in section 3 = " > Protocols and senders that only require a single ECT codepoint SHOULD us= e > ECT(0)." > I see here a risk that the statement in 4.2 can delay deployment of L4S c= apability > based on the use of ECT(1) in the networks ? My understanding is that L4S requires both ECT(0) and ECT(1), as it couples treatments of traffic marked with those codepoints. For that reason, the statement in section 3 (which is quoted from RFC 3168) does not apply to L4S. OTOH, I see your concern, namely that "free to use" in the RFC 3168 text qu= oted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the RFC 3168 text qu= oted in section 3. This is a concern with RFC 3168 itself. Would it help for this ecn-experimentation draft to update RFC 3168 by removing the words "and senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." ? > Section 5 : I see the main problem with RFC6679 (in this context) in the = use of the > nonce. Don't however see any major problem to use feedback also for an L4= S > capable sender/receiver using ECT(1). > For that purpose it may be better to rewrite : > Use of ECT(1) and random ECT values is discouraged, as that may > expose RTP to differences in network treatment of ECT(1) and > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. > To : > Use of ECT values is discouraged, as that may > expose RTP to differences in network treatment of ECT(1) and > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. Good point - I agree. I would insert "random" after "Use of" in the "To:" = text. I'll make that change in my working copy that will become -01. > Further ... quote " In support of Alternative Backoff experimentation ...= ". I would > say that this applies to L4S as well. As an example, SCReAM (RMCAT WG > congestion control candidate) is easily modified to support L4S, and the = RFC6679 > feedback can be used with SCReAM. For that reason it may be better to rep= hrase > it like > " In support of Alternative Backoff experimentation and experiments based= on > [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar I'd prefer to do something different. I think L4S is an example of both t= he Alternative Backoff and ECT Differences areas of experimentation, and hence I'd suggest= citing an L4S draft in the description of the Alternative Backoff experiment scope= in Section 2. Which L4S draft would you suggest? >=20 > Regards > /Ingemar >=20 > > -----Original Message----- > > From: Black, David [mailto:David.Black@dell.com] > > Sent: den 1 oktober 2016 00:42 > > To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > > Cc: Black, David > > Subject: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentat= ion- > > 00.txt > > > > This is the process-oriented draft on ECN experimentation that I promis= ed at > > the TSVWG > > meeting in Berlin. Comments are welcome, but please keep the process > > focus in mind - > > the intent is to leave documentation of the actual ECN changes and rati= onale > > to the referenced drafts that document the ECN experiments. > > > > Thanks, --David > > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Friday, September 30, 2016 6:24 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > > > Title : Explicit Congestion Notification (ECN) Experi= mentation > > Author : David Black > > Filename : draft-black-tsvwg-ecn-experimentation-00.txt > > Pages : 10 > > Date : 2016-09-30 > > > > Abstract: > > Multiple protocol experiments have been proposed that involve change= s > > to Explicit Congestion Notification (ECN) as specified in RFC 3168. > > This memo summarizes the proposed areas of experimentation to provid= e > > an overview to the Internet community and updates RFC 3168, a > > Proposed Standard RFC, to allow the experiments to proceed without > > requiring a standards process exception for each Experimental RFC to > > update RFC 3168. This memo also makes related updates to the ECN > > specification for RTP in RFC 6679 for the same reason. Each > > experiment is still required to be documented in an Experimental RFC= . > > This memo also records the conclusion of the ECN Nonce experiment in > > RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentation/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-00 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From nobody Thu Oct 6 23:38:27 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF3A129531; Thu, 6 Oct 2016 23:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 uDiulpIvNmQS; Thu, 6 Oct 2016 23:38:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 7C331129447; Thu, 6 Oct 2016 23:38:19 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-c8-57f742d99f39 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 90.A8.03250.9D247F75; Fri, 7 Oct 2016 08:38:17 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 7 Oct 2016 08:38:07 +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=jMbchGfs1+ZQhOSZzCIL0D3L224uPkEHdt+Yf6M487U=; b=cHC24xZmfwoyOPOJUN2mTyogTkfV9MugealtbIH7kJDP5BdUGIprd4lgXo0B8rnbHbKZ/xVQa/N5434K1lwDS9TVUCrGmoX4UqXaUUVz+u93I3nDdPuKeQt7Z1rLpicGiNRlbd6XpQBPL2ZLaL/KJ+4Lv1RfdY0f1PRIem4kyV4= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Fri, 7 Oct 2016 06:38:06 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0649.024; Fri, 7 Oct 2016 06:38:06 +0000 From: Ingemar Johansson S To: "Black, David" , "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSHBZGHx9sUXyObEi9tVnmmFrvjKCa+yXwgAEwDQCAAGBBsA== Date: Fri, 7 Oct 2016 06:38:06 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.89] x-ms-office365-filtering-correlation-id: 3b8966cf-56c8-499e-70b3-08d3ee7c7f1d x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:BEQCp6cYC3Cpv8vBB1FjR4s1MtdInu/5+LqODb+hrDuS5J0ErtItW4Mg3MdVfl7z6IEfoL3A0L9UcVR6an36wLAb7hTEExXVQDK7ugxr9cb5gd8uRFwa3RiFehHzP0jdJ8TtPH/CGcRCPtNcgPjhrOlf9gTONSCyq68pfjoqSU3iD0NE8XlbgDxn0O0lTxWsjRvWM6IE09dt63XjfsyfFjS4DngM0eTJu6IW5FSHA4nV6VwENuJXGASPWte9T+8aUjxTYzN2wfpO8SKrphfML2RZwgx/lEcG9o/HYXuRIWP9xfRIkUCXfTuBJ6WZLyoD; 5:gzfB+GbmhiCJl9sAalxwh7XXMtmhm/Sv4FA7q2ba50JqmnJ8Ih9z3RFP8MF0Ikax2pIFxAEBfpWwKb/B3lrPfelrUlaNkgH5qE5Gmi3lvWCkAE7w4knByampQ3EVL6bcQshp8IEN4tLudaL9jYKrSq6YMuuMpGY74l7dFDtDFKo=; 24:W72SMTxpOzddmR+ObDBneoU1cKLmNw0/JjllSR4wKEPGsxHXuZOCaqmHRamEOz1gkN/CQwwsse9Fcb65d7DHW1NqUA/tss/KhJIk/DRgUkI=; 7:81/p6DuuDi/6oa6RgIhuNavAyWdmY1xcNj9iNPtR4zoKQQC4vp4MAU/n9KYm/D2CLItu0Xo+3QOy3AKmuasUK1Tr8mvy9ynZ8i83dPq7iXybY+ndl/GZZrOudCOtrJAfUuYnh08kJjCzChpU1NTPO93IHzBjBP+XBaVysliozslJfgJ1R4uMhUmsr61NN63bK4Dgj9jy6GKYywgWarVFgr67Y9EXlOh3WOs5vrPsYtmvbzM8QXzvIbRAhsvtyGLzXBWTCtHtB3j4cl62Kx/dTttIptLOK13wEMkX+rEgMe5HMIa9vWhQdKuv6YL4wVKMdnkp4GYm+Tm3T2yyaSz/Zg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(56004941905204); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(13464003)(377454003)(377424004)(4001430100002)(102836003)(3846002)(586003)(106116001)(105586002)(106356001)(101416001)(2501003)(81156014)(3280700002)(81166006)(5660300001)(87936001)(7696004)(97736004)(5001770100001)(189998001)(122556002)(3660700001)(107886002)(5002640100001)(2950100002)(6116002)(76576001)(4326007)(11100500001)(74316002)(2906002)(10400500002)(2900100001)(7736002)(305945005)(19580405001)(2201001)(19580395003)(230783001)(92566002)(93886004)(86362001)(54356999)(76176999)(50986999)(9686002)(8936002)(15975445007)(66066001)(7846002)(68736007)(33656002)(77096005)(8666005)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2016 06:38:06.2981 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SYUhTURTHuXtvz7fR5LZmnsxCVohomlqJllTTTAmSMGLmCJ36Ukmnbc40 CPxgkEvRMqmZ1My52koFCxtYkcsc2gejjLBSCxWTKTqnDs1pbs+gb7///Z//ueceLk0Ia7l+ dJ6imFEq5Pliik9qU1/Ghg7FOaXhlbrAaHtDMxld1eyiouvLu8no3ulh6jiZdFt7j0jS65c5 Zzhp/NhsJj+vhFHuP5rBz122dhJFo0mlv8dOlSNDjAbRNOCD4KgK0SA+LcTtCMzLesQKK4LF pU8eQeJqAhzT5RzWqeeA8bXBS4N4G+I9gorGNDdTOBaMFqcnIcImBFX91Z4iAh+GBauLcPM2 LIXGuY+km0U4FbTmdi+W48C2oqPcTOK9YLI3cdwswGnQ29y4OVMLB3rW7Z5GPJwMHd+feRjh XTDqHCHZy3zh2/hDTxgwBv2rAYJlH5gaW+Oy9VkwP1TNZc8DwPpkhmL5NNQ9eup5JuBZL3A9 nyRZIwEcM9OI5TxYtT3YbCqDxsUFig10Iuia02wG/OGdbZ5kjXYK+to+I3ZhDDxuvY7YXfjB 8GAlqkXBDf9NzvI+0HXNUyyHgKHJRjR41rEV+rTjpA6RJuSjYlSZBTmRkWGMMi9LpSpUhCmY 4g608U+6X/wJN6OpSYkFYRqJtwh+pi5JhVx5iaqswIKAJsQiwVmJUyoUZMvLrjLKwnSlOp9R WdBOmhT7CqKMo1IhzpEXM5cYpohR/nM5NM+vHB0YDD8ZbKe840ccX+PPp0SkSMwVA3SAqyao KKVDbVTzkCAofbu49MhszUqbRnKrTrMqGpe9SciUBXivd/Mn7D2tZOIhy4Uo9a8r95XddTE3 Av11ydzLMpMu9G3GpOXmnv6MlQ8t3HN3Zr74rv04dlG4W2aY2CGZPWG7lnA30UdMqnLlEcGE UiX/C07j00kjAwAA Archived-At: Cc: Ingemar Johansson S Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 06:38:22 -0000 Hi Comments inline [IJ] > -----Original Message----- > From: Black, David [mailto:David.Black@dell.com] > Sent: den 7 oktober 2016 02:28 > To: Ingemar Johansson S ; > tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > Cc: Black, David > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > experimentation-00.txt >=20 > Hi Ingemar, >=20 > David> Inline >=20 > Thanks, --David >=20 > > -----Original Message----- > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > Sent: Thursday, October 06, 2016 4:32 AM > > To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; > > tcpPrague@ietf.org > > Cc: Ingemar Johansson S > > Subject: RE: [tcpPrague] FW: I-D Action: > > draft-black-tsvwg-ecn-experimentation- > > 00.txt > > > > Hi > > > > Thanks for writing up this draft. I have some comments on the contents >=20 > Thanks for carefully reading the draft. >=20 > > Intended status : Standards track. I interpret this that it means that > > this document becomes standards track. > > Are there any ideas around the intended status for a document such as > > briscoe- tsvwg-ecn-l4s-id, will it be experimental first or ? >=20 > Possibly - I don' t know. The ecn-experimentation draft is not intended = to > settle that question for the l4s-id draft or any of the other drafts invo= lved in > the described areas of experimentation. >=20 > I wrote the ecn-experimentation draft to allow the experiments to be > specified in Experimental RFCs without each experiment also needing a > companion Standards > Track RFC just to open up space for the experiment. If any of the > experiments > pan out so well that they deserve to be immediately written up as a > Standards Track RFC without bothering with an Experimental RFC, then that > would be wonderful, IMHO. >=20 > > Section 4.2 : " "Unless otherwise specified by an Experimental RFC, rou= ters > treat > > the ECT(0) and ECT(1) codepoints as equivalent, and senders are > > free to use either the ECT(0) or the ECT(1) codepoint to indicate > > ECT, on a packet-by-packet basis."" > > In some way I find it to contradict the proposed statement in section = 3 " > > Protocols and senders that only require a single ECT codepoint SHOULD > > use ECT(0)." > > I see here a risk that the statement in 4.2 can delay deployment of > > L4S capability based on the use of ECT(1) in the networks ? >=20 > My understanding is that L4S requires both ECT(0) and ECT(1), as it coupl= es > treatments of traffic marked with those codepoints. For that reason, the > statement in section 3 (which is quoted from RFC 3168) does not apply to = L4S. [IJ] It is perhaps here I see things differently.=20 My interpretation is that L4S is that senders mark packets with some specia= l codepoint (let's call it ECT(1) ) and network queues detect this and send= the packets to a dedicated queue which marks these packets to ECN-CE at a = very low queue delay. A special case may be that senders are networks are 1= 00% L4S (Data centers), this means that only the code point ECT(1) is in us= e. The handling of ECT(0) and not-ECT packets goes outside the L4S definition = and definitely requires dualQ solution and classification.=20 It is quite possible that my interpretation is flawed.=20 >=20 > OTOH, I see your concern, namely that "free to use" in the RFC 3168 text > quoted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the RFC 316= 8 > text quoted in section 3. This is a concern with RFC 3168 itself. >=20 > Would it help for this ecn-experimentation draft to update RFC 3168 by > removing the words "and senders are free to use either the ECT(0) or the > ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." ? [IJ] Yes, it probably solves things, mind though that reason why I brought = this is up is that I may interpret the definition of L4S differently. >=20 > > Section 5 : I see the main problem with RFC6679 (in this context) in > > the use of the nonce. Don't however see any major problem to use > > feedback also for an L4S capable sender/receiver using ECT(1). > > For that purpose it may be better to rewrite : > > Use of ECT(1) and random ECT values is discouraged, as that may > > expose RTP to differences in network treatment of ECT(1) and > > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. > > To : > > Use of ECT values is discouraged, as that may > > expose RTP to differences in network treatment of ECT(1) and > > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. >=20 > Good point - I agree. I would insert "random" after "Use of" in the "To:= " text. > I'll make that change in my working copy that will become -01. >=20 > > Further ... quote " In support of Alternative Backoff experimentation > > ...". I would say that this applies to L4S as well. As an example, > > SCReAM (RMCAT WG congestion control candidate) is easily modified to > > support L4S, and the RFC6679 feedback can be used with SCReAM. For > > that reason it may be better to rephrase it like " In support of > > Alternative Backoff experimentation and experiments based on > > [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar >=20 > I'd prefer to do something different. I think L4S is an example of both= the > Alternative > Backoff and ECT Differences areas of experimentation, and hence I'd sugge= st > citing an L4S draft in the description of the Alternative Backoff experim= ent > scope in Section 2. Which L4S draft would you suggest? [IJ] Good question.. Not sure what is required here?. Our proprietary SCReA= M research code has support for L4S, one possibility is to update the SCReA= M draft with a description of this functionality. An example was shown at t= he L4S BoF (page 6-7 in https://www.ietf.org/proceedings/96/slides/slides-9= 6-l4s-2.pdf ) >=20 > > > > Regards > > /Ingemar > > > > > -----Original Message----- > > > From: Black, David [mailto:David.Black@dell.com] > > > Sent: den 1 oktober 2016 00:42 > > > To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > > > Cc: Black, David > > > Subject: [tcpPrague] FW: I-D Action: > > > draft-black-tsvwg-ecn-experimentation- > > > 00.txt > > > > > > This is the process-oriented draft on ECN experimentation that I > > > promised at the TSVWG > > > meeting in Berlin. Comments are welcome, but please keep the proces= s > > > focus in mind - > > > the intent is to leave documentation of the actual ECN changes and > > > rationale to the referenced drafts that document the ECN experiments. > > > > > > Thanks, --David > > > > > > -----Original Message----- > > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf > > > Of internet-drafts@ietf.org > > > Sent: Friday, September 30, 2016 6:24 PM > > > To: i-d-announce@ietf.org > > > Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > > > > Title : Explicit Congestion Notification (ECN) Expe= rimentation > > > Author : David Black > > > Filename : draft-black-tsvwg-ecn-experimentation-00.txt > > > Pages : 10 > > > Date : 2016-09-30 > > > > > > Abstract: > > > Multiple protocol experiments have been proposed that involve > changes > > > to Explicit Congestion Notification (ECN) as specified in RFC 3168= . > > > This memo summarizes the proposed areas of experimentation to > provide > > > an overview to the Internet community and updates RFC 3168, a > > > Proposed Standard RFC, to allow the experiments to proceed without > > > requiring a standards process exception for each Experimental RFC = to > > > update RFC 3168. This memo also makes related updates to the ECN > > > specification for RTP in RFC 6679 for the same reason. Each > > > experiment is still required to be documented in an Experimental R= FC. > > > This memo also records the conclusion of the ECN Nonce experiment = in > > > RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentati > > > on/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-00 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > From nobody Fri Oct 7 09:29:32 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7412966D; Fri, 7 Oct 2016 09:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 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=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=dB40Y+Al; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=XTD88nYb 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 n1lG4JneWVpa; Fri, 7 Oct 2016 09:29:28 -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 521191295F6; Fri, 7 Oct 2016 09:29:28 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=0Km6CRj8q6jlAqITQPWKAjjI0bmt/NgnMEDoMNRLjuCVenyks621fOiZ RRRpPZrQQIJIcU8UjaXIAhkhg/fCOYVf12gAMD9CEdk2rr6mPI0paSKhx mC3O2E92XziniPeiEQPhHPlSRR5kEPSEWCZKHDzEHtahTHpGNPEYseO3r 4=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1475857768; x=1507393768; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3axoTWzuqkEOD3Io0tS/POO75VxiU/HEgWTFBCbmeag=; b=dB40Y+AlZWG7v7TxIc2J/N9sVoQSrjpAbXJndnlPohUr/5lCkqPR1Ty9 ZvzSzSimAc9sPLYR3Kj3mvlcJkfYxhv+ym47kebnm/ROmRuKaRDiQawbR HHAhJExY+9n6Y42UOemACDRMM3+mqSJVKosIgNYrn9qrBuKBZ12JoTS+0 I=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2016 11:29:27 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2016 22:29:26 +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 u97GTOOv025367 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Oct 2016 12:29:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u97GTOOv025367 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1475857766; bh=lIS5AlgK1gk6P0Ta3LeGwgTXRPg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=XTD88nYbMS/WAAIhmlTMwqmS3uKTiqHWxHMvNTVXabCt23CfzFDgxh4JXRu8DRBg8 SOXCXVHnTDFyJ23pZmUwN0MNUy9ex7PggPdlLbEzaJrh/5dlmV5R9ET+TVewZLIUp8 AE4WFiC3fpuz8bRRdFBnyAu3PU1UXzLWHmy75+MQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u97GTOOv025367 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 7 Oct 2016 12:28:31 -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 u97GT7gJ014466 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 7 Oct 2016 12:29:07 -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.0266.001; Fri, 7 Oct 2016 12:29:06 -0400 To: Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSH6wQv2w1nNbalEmS9LcageCkg6CcHCiwgACyRgCAAFiOQA== Date: Fri, 7 Oct 2016 16:29:06 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@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.238.45.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 16:29:31 -0000 Ingemar, Summarizing: [1] Section 4.2 - "free to use" text. The full quote from RFC 3168 is: "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are= free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." I've revised my working version of the -01 draft to remove the second sente= nce as part of this proposed update to RFC 3168. That's both simpler and c= learer than what's in the posted -00. In addition, doing this obviates the= need to say anything in this section about the possible L4S relationships = between the ECT(0) and ECT(1) queues. [2] Section 2 - L4S and description of Alternative Backoff. If one of the = folks directly involved in L4S would like to suggest a draft to cite that d= escribes the L4S backoff for the low latency/higher-CE-marking-probability = functionality, I'm happy to cite that as an additional example of Alternati= ve Backoff. Thanks, --David > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: Friday, October 07, 2016 2:38 AM > To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.or= g > Cc: Ingemar Johansson S > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experiment= ation- > 00.txt >=20 > Hi >=20 > Comments inline [IJ] >=20 > > -----Original Message----- > > From: Black, David [mailto:David.Black@dell.com] > > Sent: den 7 oktober 2016 02:28 > > To: Ingemar Johansson S ; > > tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > > Cc: Black, David > > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > > experimentation-00.txt > > > > Hi Ingemar, > > > > David> Inline > > > > Thanks, --David > > > > > -----Original Message----- > > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > > Sent: Thursday, October 06, 2016 4:32 AM > > > To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; > > > tcpPrague@ietf.org > > > Cc: Ingemar Johansson S > > > Subject: RE: [tcpPrague] FW: I-D Action: > > > draft-black-tsvwg-ecn-experimentation- > > > 00.txt > > > > > > Hi > > > > > > Thanks for writing up this draft. I have some comments on the content= s > > > > Thanks for carefully reading the draft. > > > > > Intended status : Standards track. I interpret this that it means tha= t > > > this document becomes standards track. > > > Are there any ideas around the intended status for a document such as > > > briscoe- tsvwg-ecn-l4s-id, will it be experimental first or ? > > > > Possibly - I don' t know. The ecn-experimentation draft is not intende= d to > > settle that question for the l4s-id draft or any of the other drafts in= volved in > > the described areas of experimentation. > > > > I wrote the ecn-experimentation draft to allow the experiments to be > > specified in Experimental RFCs without each experiment also needing a > > companion Standards > > Track RFC just to open up space for the experiment. If any of the > > experiments > > pan out so well that they deserve to be immediately written up as a > > Standards Track RFC without bothering with an Experimental RFC, then th= at > > would be wonderful, IMHO. > > > > > Section 4.2 : " "Unless otherwise specified by an Experimental RFC, r= outers > > treat > > > the ECT(0) and ECT(1) codepoints as equivalent, and senders are > > > free to use either the ECT(0) or the ECT(1) codepoint to indica= te > > > ECT, on a packet-by-packet basis."" > > > In some way I find it to contradict the proposed statement in sectio= n 3 " > > > Protocols and senders that only require a single ECT codepoint SHOUL= D > > > use ECT(0)." > > > I see here a risk that the statement in 4.2 can delay deployment of > > > L4S capability based on the use of ECT(1) in the networks ? > > > > My understanding is that L4S requires both ECT(0) and ECT(1), as it cou= ples > > treatments of traffic marked with those codepoints. For that reason, t= he > > statement in section 3 (which is quoted from RFC 3168) does not apply t= o L4S. > [IJ] It is perhaps here I see things differently. > My interpretation is that L4S is that senders mark packets with some spec= ial > codepoint (let's call it ECT(1) ) and network queues detect this and send= the > packets to a dedicated queue which marks these packets to ECN-CE at a ver= y low > queue delay. A special case may be that senders are networks are 100% L4S= (Data > centers), this means that only the code point ECT(1) is in use. > The handling of ECT(0) and not-ECT packets goes outside the L4S definitio= n and > definitely requires dualQ solution and classification. > It is quite possible that my interpretation is flawed. >=20 > > > > OTOH, I see your concern, namely that "free to use" in the RFC 3168 tex= t > > quoted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the RFC 3= 168 > > text quoted in section 3. This is a concern with RFC 3168 itself. > > > > Would it help for this ecn-experimentation draft to update RFC 3168 by > > removing the words "and senders are free to use either the ECT(0) or th= e > > ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." ? > [IJ] Yes, it probably solves things, mind though that reason why I brough= t this is > up is that I may interpret the definition of L4S differently. >=20 > > > > > Section 5 : I see the main problem with RFC6679 (in this context) in > > > the use of the nonce. Don't however see any major problem to use > > > feedback also for an L4S capable sender/receiver using ECT(1). > > > For that purpose it may be better to rewrite : > > > Use of ECT(1) and random ECT values is discouraged, as that may > > > expose RTP to differences in network treatment of ECT(1) and > > > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. > > > To : > > > Use of ECT values is discouraged, as that may > > > expose RTP to differences in network treatment of ECT(1) and > > > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. > > > > Good point - I agree. I would insert "random" after "Use of" in the "T= o:" text. > > I'll make that change in my working copy that will become -01. > > > > > Further ... quote " In support of Alternative Backoff experimentation > > > ...". I would say that this applies to L4S as well. As an example, > > > SCReAM (RMCAT WG congestion control candidate) is easily modified to > > > support L4S, and the RFC6679 feedback can be used with SCReAM. For > > > that reason it may be better to rephrase it like " In support of > > > Alternative Backoff experimentation and experiments based on > > > [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar > > > > I'd prefer to do something different. I think L4S is an example of bo= th the > > Alternative > > Backoff and ECT Differences areas of experimentation, and hence I'd sug= gest > > citing an L4S draft in the description of the Alternative Backoff exper= iment > > scope in Section 2. Which L4S draft would you suggest? > [IJ] Good question.. Not sure what is required here?. Our proprietary SCR= eAM > research code has support for L4S, one possibility is to update the SCReA= M draft > with a description of this functionality. An example was shown at the L4S= BoF > (page 6-7 in https://www.ietf.org/proceedings/96/slides/slides-96-l4s-2.p= df ) >=20 > > > > > > > > Regards > > > /Ingemar > > > > > > > -----Original Message----- > > > > From: Black, David [mailto:David.Black@dell.com] > > > > Sent: den 1 oktober 2016 00:42 > > > > To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > > > > Cc: Black, David > > > > Subject: [tcpPrague] FW: I-D Action: > > > > draft-black-tsvwg-ecn-experimentation- > > > > 00.txt > > > > > > > > This is the process-oriented draft on ECN experimentation that I > > > > promised at the TSVWG > > > > meeting in Berlin. Comments are welcome, but please keep the proc= ess > > > > focus in mind - > > > > the intent is to leave documentation of the actual ECN changes and > > > > rationale to the referenced drafts that document the ECN experiment= s. > > > > > > > > Thanks, --David > > > > > > > > -----Original Message----- > > > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf > > > > Of internet-drafts@ietf.org > > > > Sent: Friday, September 30, 2016 6:24 PM > > > > To: i-d-announce@ietf.org > > > > Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > > > > > > > Title : Explicit Congestion Notification (ECN) Ex= perimentation > > > > Author : David Black > > > > Filename : draft-black-tsvwg-ecn-experimentation-00.txt > > > > Pages : 10 > > > > Date : 2016-09-30 > > > > > > > > Abstract: > > > > Multiple protocol experiments have been proposed that involve > > changes > > > > to Explicit Congestion Notification (ECN) as specified in RFC 31= 68. > > > > This memo summarizes the proposed areas of experimentation to > > provide > > > > an overview to the Internet community and updates RFC 3168, a > > > > Proposed Standard RFC, to allow the experiments to proceed witho= ut > > > > requiring a standards process exception for each Experimental RF= C to > > > > update RFC 3168. This memo also makes related updates to the EC= N > > > > specification for RTP in RFC 6679 for the same reason. Each > > > > experiment is still required to be documented in an Experimental= RFC. > > > > This memo also records the conclusion of the ECN Nonce experimen= t in > > > > RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentat= i > > > > on/ > > > > > > > > There's also a htmlized version available at: > > > > https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-0= 0 > > > > > > > > > > > > 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/ > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > From nobody Fri Oct 14 12:20:10 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D652129899 for ; Fri, 14 Oct 2016 12:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=unavailable 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 UNsWLeN9i8KB for ; Fri, 14 Oct 2016 12:20:06 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 0A784129898 for ; Fri, 14 Oct 2016 12:20:03 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bv81R-0001vn-4G for tcpprague@ietf.org; Fri, 14 Oct 2016 21:20:01 +0200 Received: from 151.red-88-21-19.staticip.rima-tde.net ([88.21.19.151] helo=[10.2.5.169]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bv81P-0006KP-QT; Fri, 14 Oct 2016 21:20:00 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Fri, 14 Oct 2016 21:19:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C6C3121-20FC-478C-B200-7BBC0A84BDDB@ifi.uio.no> References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 12 sum msgs/h 5 total rcpts 47236 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 09093B7A6AE40BCE9DB611AFF93D7D4F72C48E22 X-UiO-SPAM-Test: remote_host: 88.21.19.151 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 18 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Ingemar Johansson S , "tsvwg@ietf.org" , "tcpPrague@ietf.org" , "tcpm-chairs@ietf.org" Subject: Re: [tcpPrague] I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 19:20:08 -0000 Dear all, I=E2=80=99d like to state, on behalf of the ABE authors, that we=E2=80=99r= e fine with the draft as it stands, including the update below. Just a note of clarification, answering a comment from you in a previous = email of yours: "My understanding is that L4S requires both ECT(0) and ECT(1), as it = couples treatments of traffic marked with those codepoints.=E2=80=9D =3D> No. L4S uses ECT(1), ABE uses ECT(0), and because of that, the two are = compatible. ( Maybe you got confused by past discussion that was less clear in that = respect. ) I repeat this for others, as I just received an unrelated email from = someone else pointing me at L4S possibly competing with ABE: L4S and ABE are *not* competing proposals. Because L4S uses the ECT(1) = codepoint, it is gradually deployable without creating a conflict with = ABE (or current RFC3168-style senders). Cheers, Michael > On 7. okt. 2016, at 18.29, Black, David wrote: >=20 > Ingemar, >=20 > Summarizing: >=20 > [1] Section 4.2 - "free to use" text. The full quote from RFC 3168 = is: >=20 > "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. = Senders are free to use either the ECT(0) > or the ECT(1) codepoint to indicate ECT, on a packet-by-packet = basis." >=20 > I've revised my working version of the -01 draft to remove the second = sentence as part of this proposed update to RFC 3168. That's both = simpler and clearer than what's in the posted -00. In addition, doing = this obviates the need to say anything in this section about the = possible L4S relationships between the ECT(0) and ECT(1) queues. >=20 > [2] Section 2 - L4S and description of Alternative Backoff. If one of = the folks directly involved in L4S would like to suggest a draft to cite = that describes the L4S backoff for the low = latency/higher-CE-marking-probability functionality, I'm happy to cite = that as an additional example of Alternative Backoff. >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >> Sent: Friday, October 07, 2016 2:38 AM >> To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; = tcpPrague@ietf.org >> Cc: Ingemar Johansson S >> Subject: RE: [tcpPrague] FW: I-D Action: = draft-black-tsvwg-ecn-experimentation- >> 00.txt >>=20 >> Hi >>=20 >> Comments inline [IJ] >>=20 >>> -----Original Message----- >>> From: Black, David [mailto:David.Black@dell.com] >>> Sent: den 7 oktober 2016 02:28 >>> To: Ingemar Johansson S ; >>> tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org >>> Cc: Black, David >>> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- >>> experimentation-00.txt >>>=20 >>> Hi Ingemar, >>>=20 >>> David> Inline >>>=20 >>> Thanks, --David >>>=20 >>>> -----Original Message----- >>>> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >>>> Sent: Thursday, October 06, 2016 4:32 AM >>>> To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; >>>> tcpPrague@ietf.org >>>> Cc: Ingemar Johansson S >>>> Subject: RE: [tcpPrague] FW: I-D Action: >>>> draft-black-tsvwg-ecn-experimentation- >>>> 00.txt >>>>=20 >>>> Hi >>>>=20 >>>> Thanks for writing up this draft. I have some comments on the = contents >>>=20 >>> Thanks for carefully reading the draft. >>>=20 >>>> Intended status : Standards track. I interpret this that it means = that >>>> this document becomes standards track. >>>> Are there any ideas around the intended status for a document such = as >>>> briscoe- tsvwg-ecn-l4s-id, will it be experimental first or ? >>>=20 >>> Possibly - I don' t know. The ecn-experimentation draft is not = intended to >>> settle that question for the l4s-id draft or any of the other drafts = involved in >>> the described areas of experimentation. >>>=20 >>> I wrote the ecn-experimentation draft to allow the experiments to be >>> specified in Experimental RFCs without each experiment also needing = a >>> companion Standards >>> Track RFC just to open up space for the experiment. If any of the >>> experiments >>> pan out so well that they deserve to be immediately written up as a >>> Standards Track RFC without bothering with an Experimental RFC, then = that >>> would be wonderful, IMHO. >>>=20 >>>> Section 4.2 : " "Unless otherwise specified by an Experimental RFC, = routers >>> treat >>>> the ECT(0) and ECT(1) codepoints as equivalent, and senders = are >>>> free to use either the ECT(0) or the ECT(1) codepoint to = indicate >>>> ECT, on a packet-by-packet basis."" >>>> In some way I find it to contradict the proposed statement in = section 3 " >>>> Protocols and senders that only require a single ECT codepoint = SHOULD >>>> use ECT(0)." >>>> I see here a risk that the statement in 4.2 can delay deployment of >>>> L4S capability based on the use of ECT(1) in the networks ? >>>=20 >>> My understanding is that L4S requires both ECT(0) and ECT(1), as it = couples >>> treatments of traffic marked with those codepoints. For that = reason, the >>> statement in section 3 (which is quoted from RFC 3168) does not = apply to L4S. >> [IJ] It is perhaps here I see things differently. >> My interpretation is that L4S is that senders mark packets with some = special >> codepoint (let's call it ECT(1) ) and network queues detect this and = send the >> packets to a dedicated queue which marks these packets to ECN-CE at a = very low >> queue delay. A special case may be that senders are networks are 100% = L4S (Data >> centers), this means that only the code point ECT(1) is in use. >> The handling of ECT(0) and not-ECT packets goes outside the L4S = definition and >> definitely requires dualQ solution and classification. >> It is quite possible that my interpretation is flawed. >>=20 >>>=20 >>> OTOH, I see your concern, namely that "free to use" in the RFC 3168 = text >>> quoted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the = RFC 3168 >>> text quoted in section 3. This is a concern with RFC 3168 itself. >>>=20 >>> Would it help for this ecn-experimentation draft to update RFC 3168 = by >>> removing the words "and senders are free to use either the ECT(0) or = the >>> ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." ? >> [IJ] Yes, it probably solves things, mind though that reason why I = brought this is >> up is that I may interpret the definition of L4S differently. >>=20 >>>=20 >>>> Section 5 : I see the main problem with RFC6679 (in this context) = in >>>> the use of the nonce. Don't however see any major problem to use >>>> feedback also for an L4S capable sender/receiver using ECT(1). >>>> For that purpose it may be better to rewrite : >>>> Use of ECT(1) and random ECT values is discouraged, as that = may >>>> expose RTP to differences in network treatment of ECT(1) and >>>> ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. >>>> To : >>>> Use of ECT values is discouraged, as that may >>>> expose RTP to differences in network treatment of ECT(1) and >>>> ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. >>>=20 >>> Good point - I agree. I would insert "random" after "Use of" in the = "To:" text. >>> I'll make that change in my working copy that will become -01. >>>=20 >>>> Further ... quote " In support of Alternative Backoff = experimentation >>>> ...". I would say that this applies to L4S as well. As an example, >>>> SCReAM (RMCAT WG congestion control candidate) is easily modified = to >>>> support L4S, and the RFC6679 feedback can be used with SCReAM. For >>>> that reason it may be better to rephrase it like " In support of >>>> Alternative Backoff experimentation and experiments based on >>>> [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar >>>=20 >>> I'd prefer to do something different. I think L4S is an example of = both the >>> Alternative >>> Backoff and ECT Differences areas of experimentation, and hence I'd = suggest >>> citing an L4S draft in the description of the Alternative Backoff = experiment >>> scope in Section 2. Which L4S draft would you suggest? >> [IJ] Good question.. Not sure what is required here?. Our proprietary = SCReAM >> research code has support for L4S, one possibility is to update the = SCReAM draft >> with a description of this functionality. An example was shown at the = L4S BoF >> (page 6-7 in = https://www.ietf.org/proceedings/96/slides/slides-96-l4s-2.pdf ) >>=20 >>>=20 >>>>=20 >>>> Regards >>>> /Ingemar >>>>=20 >>>>> -----Original Message----- >>>>> From: Black, David [mailto:David.Black@dell.com] >>>>> Sent: den 1 oktober 2016 00:42 >>>>> To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org >>>>> Cc: Black, David >>>>> Subject: [tcpPrague] FW: I-D Action: >>>>> draft-black-tsvwg-ecn-experimentation- >>>>> 00.txt >>>>>=20 >>>>> This is the process-oriented draft on ECN experimentation that I >>>>> promised at the TSVWG >>>>> meeting in Berlin. Comments are welcome, but please keep the = process >>>>> focus in mind - >>>>> the intent is to leave documentation of the actual ECN changes and >>>>> rationale to the referenced drafts that document the ECN = experiments. >>>>>=20 >>>>> Thanks, --David >>>>>=20 >>>>> -----Original Message----- >>>>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On = Behalf >>>>> Of internet-drafts@ietf.org >>>>> Sent: Friday, September 30, 2016 6:24 PM >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>>>=20 >>>>>=20 >>>>> Title : Explicit Congestion Notification (ECN) = Experimentation >>>>> Author : David Black >>>>> Filename : draft-black-tsvwg-ecn-experimentation-00.txt >>>>> Pages : 10 >>>>> Date : 2016-09-30 >>>>>=20 >>>>> Abstract: >>>>> Multiple protocol experiments have been proposed that involve >>> changes >>>>> to Explicit Congestion Notification (ECN) as specified in RFC = 3168. >>>>> This memo summarizes the proposed areas of experimentation to >>> provide >>>>> an overview to the Internet community and updates RFC 3168, a >>>>> Proposed Standard RFC, to allow the experiments to proceed = without >>>>> requiring a standards process exception for each Experimental = RFC to >>>>> update RFC 3168. This memo also makes related updates to the = ECN >>>>> specification for RTP in RFC 6679 for the same reason. Each >>>>> experiment is still required to be documented in an Experimental = RFC. >>>>> This memo also records the conclusion of the ECN Nonce = experiment in >>>>> RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> = https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentati >>>>> on/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> = https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-00 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>=20 >=20 > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague From nobody Fri Oct 14 14:59:06 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757E71298CE; Fri, 14 Oct 2016 14:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnJJxk-uGr0N; Fri, 14 Oct 2016 14:59:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A9A9B1298D1; Fri, 14 Oct 2016 14:59:00 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 246185D302017; Fri, 14 Oct 2016 21:58:54 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9ELwv8I018404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Oct 2016 21:58:58 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u9ELwv3w005436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Oct 2016 23:58:57 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.121]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Fri, 14 Oct 2016 23:58:57 +0200 From: "De Schepper, Koen (Nokia - BE)" To: "Black, David" , Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSH6wWI61lpnnM/Uu82quAPO1dcqCcAoAAgABnWQCAAKUgAIALKVnQ Date: Fri, 14 Oct 2016 21:58:56 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 21:59:04 -0000 Hi all, Thanks David, I think this draft is useful to support further L4S=20 specifications. Some excerpts and comments from the mails below:=20 I agree with Ingemar that the text: "Unless otherwise specified by an Experimental RFC, routers treat the ECT(0) and ECT(1) codepoints as equivalent, and senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." Should better become: "Unless otherwise specified by an Experimental RFC, routers treat the ECT(0) and ECT(1) codepoints as equivalent, and senders should use only the ECT(0) codepoint to indicate ECT." There is no reason anymore to use ECT(1) by senders, unless an Experimental RFC specifies differently. > I've revised my working version of the -01 draft to remove the second > sentence as part of this proposed update to RFC 3168. I think it is clearer to explicitly state that only ECT(0) should be used. > My understanding is that L4S requires both ECT(0) and ECT(1), as it coupl= es > treatments of traffic marked with those codepoints. For that reason, the > statement in section 3 (which is quoted from RFC 3168) does not apply to = L4S. L4S is not changing the meaning of non-ECT or ECT(0) packets.=20 It still assumes a response by the sender equal as a response to drop. The= =20 coupling is only towards ECT(1). Routers will more frequently mark ECT(1) packets to compensate the more aggressive behavior of L4S. ECT(1) marking is steered by the non-ECT drop and ECT(0) marking probability such that=20 flow rates become equal independent of (non-)ECT(0/1). > The handling of ECT(0) and non-ECT packets goes outside the L4S definitio= n Correct. Nothing changes for L4S. > [2] Section 2 - L4S and description of Alternative Backoff. If one of th= e > folks directly involved in L4S would like to suggest a draft to cite that > describes the L4S backoff for the low latency/higher-CE-marking-probabili= ty > functionality Technically speaking L4S has an alternative response to a CE marked packet,= =20 but only to a packet that was sender-marked as ECT(1) and when the network marks packets more frequently by the routers. I think we need to clarify if the text in this section is intended only=20 for responses in the sender "without" a compensating change in the network= =20 between drop and CE marks, or also "with" a compensation. In the first case we should also specify this, and in the second case we just can also refer to the L4S draft (where we assume a DCTCP or TCP-Prague response). Regards, Koen. > -----Original Message----- > From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Black, > David > Sent: vrijdag 7 oktober 2016 18:29 > To: Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@ietf.org; > tcpPrague@ietf.org > Cc: Black, David > Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > experimentation-00.txt >=20 > Ingemar, >=20 > Summarizing: >=20 > [1] Section 4.2 - "free to use" text. The full quote from RFC 3168 is: >=20 > "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. > Senders are free to use either the ECT(0) > or the ECT(1) codepoint to indicate ECT, on a packet-by-packet > basis." >=20 > I've revised my working version of the -01 draft to remove the second > sentence as part of this proposed update to RFC 3168. That's both simple= r > and clearer than what's in the posted -00. In addition, doing this obvia= tes > the need to say anything in this section about the possible L4S > relationships between the ECT(0) and ECT(1) queues. >=20 > [2] Section 2 - L4S and description of Alternative Backoff. If one of th= e > folks directly involved in L4S would like to suggest a draft to cite that > describes the L4S backoff for the low latency/higher-CE-marking-probabili= ty > functionality, I'm happy to cite that as an additional example of > Alternative Backoff. >=20 > Thanks, --David >=20 > > -----Original Message----- > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > Sent: Friday, October 07, 2016 2:38 AM > > To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.= org > > Cc: Ingemar Johansson S > > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > experimentation- > > 00.txt > > > > Hi > > > > Comments inline [IJ] > > > > > -----Original Message----- > > > From: Black, David [mailto:David.Black@dell.com] > > > Sent: den 7 oktober 2016 02:28 > > > To: Ingemar Johansson S ; > > > tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > > > Cc: Black, David > > > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > > > experimentation-00.txt > > > > > > Hi Ingemar, > > > > > > David> Inline > > > > > > Thanks, --David > > > > > > > -----Original Message----- > > > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > > > Sent: Thursday, October 06, 2016 4:32 AM > > > > To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; > > > > tcpPrague@ietf.org > > > > Cc: Ingemar Johansson S > > > > Subject: RE: [tcpPrague] FW: I-D Action: > > > > draft-black-tsvwg-ecn-experimentation- > > > > 00.txt > > > > > > > > Hi > > > > > > > > Thanks for writing up this draft. I have some comments on the conte= nts > > > > > > Thanks for carefully reading the draft. > > > > > > > Intended status : Standards track. I interpret this that it means t= hat > > > > this document becomes standards track. > > > > Are there any ideas around the intended status for a document such = as > > > > briscoe- tsvwg-ecn-l4s-id, will it be experimental first or ? > > > > > > Possibly - I don' t know. The ecn-experimentation draft is not inten= ded > to > > > settle that question for the l4s-id draft or any of the other drafts > involved in > > > the described areas of experimentation. > > > > > > I wrote the ecn-experimentation draft to allow the experiments to be > > > specified in Experimental RFCs without each experiment also needing a > > > companion Standards > > > Track RFC just to open up space for the experiment. If any of the > > > experiments > > > pan out so well that they deserve to be immediately written up as a > > > Standards Track RFC without bothering with an Experimental RFC, then > that > > > would be wonderful, IMHO. > > > > > > > Section 4.2 : " "Unless otherwise specified by an Experimental RFC, > routers > > > treat > > > > the ECT(0) and ECT(1) codepoints as equivalent, and senders a= re > > > > free to use either the ECT(0) or the ECT(1) codepoint to > indicate > > > > ECT, on a packet-by-packet basis."" > > > > In some way I find it to contradict the proposed statement in sect= ion > 3 " > > > > Protocols and senders that only require a single ECT codepoint SHO= ULD > > > > use ECT(0)." > > > > I see here a risk that the statement in 4.2 can delay deployment of > > > > L4S capability based on the use of ECT(1) in the networks ? > > > > > > My understanding is that L4S requires both ECT(0) and ECT(1), as it > couples > > > treatments of traffic marked with those codepoints. For that reason, > the > > > statement in section 3 (which is quoted from RFC 3168) does not apply= to > L4S. > > [IJ] It is perhaps here I see things differently. > > My interpretation is that L4S is that senders mark packets with some > special > > codepoint (let's call it ECT(1) ) and network queues detect this and se= nd > the > > packets to a dedicated queue which marks these packets to ECN-CE at a v= ery > low > > queue delay. A special case may be that senders are networks are 100% L= 4S > (Data > > centers), this means that only the code point ECT(1) is in use. > > The handling of ECT(0) and not-ECT packets goes outside the L4S definit= ion > and > > definitely requires dualQ solution and classification. > > It is quite possible that my interpretation is flawed. > > > > > > > > OTOH, I see your concern, namely that "free to use" in the RFC 3168 t= ext > > > quoted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the RFC > 3168 > > > text quoted in section 3. This is a concern with RFC 3168 itself. > > > > > > Would it help for this ecn-experimentation draft to update RFC 3168 b= y > > > removing the words "and senders are free to use either the ECT(0) or = the > > > ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." ? > > [IJ] Yes, it probably solves things, mind though that reason why I brou= ght > this is > > up is that I may interpret the definition of L4S differently. > > > > > > > > > Section 5 : I see the main problem with RFC6679 (in this context) i= n > > > > the use of the nonce. Don't however see any major problem to use > > > > feedback also for an L4S capable sender/receiver using ECT(1). > > > > For that purpose it may be better to rewrite : > > > > Use of ECT(1) and random ECT values is discouraged, as that m= ay > > > > expose RTP to differences in network treatment of ECT(1) and > > > > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. > > > > To : > > > > Use of ECT values is discouraged, as that may > > > > expose RTP to differences in network treatment of ECT(1) and > > > > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. > > > > > > Good point - I agree. I would insert "random" after "Use of" in the > "To:" text. > > > I'll make that change in my working copy that will become -01. > > > > > > > Further ... quote " In support of Alternative Backoff experimentati= on > > > > ...". I would say that this applies to L4S as well. As an example, > > > > SCReAM (RMCAT WG congestion control candidate) is easily modified t= o > > > > support L4S, and the RFC6679 feedback can be used with SCReAM. For > > > > that reason it may be better to rephrase it like " In support of > > > > Alternative Backoff experimentation and experiments based on > > > > [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar > > > > > > I'd prefer to do something different. I think L4S is an example of > both the > > > Alternative > > > Backoff and ECT Differences areas of experimentation, and hence I'd > suggest > > > citing an L4S draft in the description of the Alternative Backoff > experiment > > > scope in Section 2. Which L4S draft would you suggest? > > [IJ] Good question.. Not sure what is required here?. Our proprietary > SCReAM > > research code has support for L4S, one possibility is to update the SCR= eAM > draft > > with a description of this functionality. An example was shown at the L= 4S > BoF > > (page 6-7 in https://www.ietf.org/proceedings/96/slides/slides-96-l4s- > 2.pdf ) > > > > > > > > > > > > > Regards > > > > /Ingemar > > > > > > > > > -----Original Message----- > > > > > From: Black, David [mailto:David.Black@dell.com] > > > > > Sent: den 1 oktober 2016 00:42 > > > > > To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > > > > > Cc: Black, David > > > > > Subject: [tcpPrague] FW: I-D Action: > > > > > draft-black-tsvwg-ecn-experimentation- > > > > > 00.txt > > > > > > > > > > This is the process-oriented draft on ECN experimentation that I > > > > > promised at the TSVWG > > > > > meeting in Berlin. Comments are welcome, but please keep the > process > > > > > focus in mind - > > > > > the intent is to leave documentation of the actual ECN changes an= d > > > > > rationale to the referenced drafts that document the ECN > experiments. > > > > > > > > > > Thanks, --David > > > > > > > > > > -----Original Message----- > > > > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Beha= lf > > > > > Of internet-drafts@ietf.org > > > > > Sent: Friday, September 30, 2016 6:24 PM > > > > > To: i-d-announce@ietf.org > > > > > Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Draft= s > > > directories. > > > > > > > > > > > > > > > Title : Explicit Congestion Notification (ECN) > Experimentation > > > > > Author : David Black > > > > > Filename : draft-black-tsvwg-ecn-experimentation-00.txt > > > > > Pages : 10 > > > > > Date : 2016-09-30 > > > > > > > > > > Abstract: > > > > > Multiple protocol experiments have been proposed that involve > > > changes > > > > > to Explicit Congestion Notification (ECN) as specified in RFC > 3168. > > > > > This memo summarizes the proposed areas of experimentation to > > > provide > > > > > an overview to the Internet community and updates RFC 3168, a > > > > > Proposed Standard RFC, to allow the experiments to proceed > without > > > > > requiring a standards process exception for each Experimental = RFC > to > > > > > update RFC 3168. This memo also makes related updates to the = ECN > > > > > specification for RTP in RFC 6679 for the same reason. Each > > > > > experiment is still required to be documented in an Experiment= al > RFC. > > > > > This memo also records the conclusion of the ECN Nonce experim= ent > in > > > > > RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experiment= ati > > > > > on/ > > > > > > > > > > There's also a htmlized version available at: > > > > > https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation= -00 > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > _______________________________________________ > > > > > I-D-Announce mailing list > > > > > I-D-Announce@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >=20 > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague From nobody Sun Oct 16 11:21:33 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C44129443; Sun, 16 Oct 2016 11:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=xrg6Lm2R; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=WnkD7x5C 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 kJGdAq-vElq3; Sun, 16 Oct 2016 11:21:29 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 127F812940E; Sun, 16 Oct 2016 11:21:28 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=pH7+Ez+ifPhtXairiY0MfmpIiKHLdeOTd42gNpwm9U/2BUiJhYa0E46b SA4dovmXnBHdKYQtur9qlwJ7L/eAE/F1zYdOBsfRagCKk5gWeMveoBhut p9DesJYzRgKmi63UHnjCUqXl4ReMbxED3icXTSKjkKY2yJhOM3XFy9LZM s=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1476642089; x=1508178089; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=E1ylwqIjvarQeagQtvjEy0gN685eX7HlFA/xcuioK2U=; b=xrg6Lm2RzQ0nqVH41bgum6NaAUm/NMocfJzN26pU97bI0oR97BchppMa 3xbEgJy3aZX/klXl3ChHXRMTu7wGWZt+A/qGp3/Bm8E68bxIrQeyJIBAp VHEHF1GVaONb+aQ31lHVw1lkx+9yMST85I1nQ+ydW1u+x4oRRPRkXhkqU Y=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2016 13:21:27 -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; 17 Oct 2016 00:21:26 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9GILOkO016378 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Oct 2016 14:21:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u9GILOkO016378 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1476642085; bh=CDZiJbU+ob8k6qoUXjWmg7pTAm0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=WnkD7x5Cm8vlBYPiuMNtj7x0ZZ0ZI2xarpIMlcQ7oiHLF2hxFu86N4NU0cl3vx07i pD8CjY8IDEncQUDzjfeoG14CWV2+iy81Nih6d9ECUeMoOeps+SZqbQCe9MgM7DMkMS Nf3Qh/shVZLiSzsdz61a45ob6a7D9mHiTNA8Bu58= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u9GILOkO016378 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Sun, 16 Oct 2016 14:20:31 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9GILDDc000473 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sun, 16 Oct 2016 14:21:14 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Sun, 16 Oct 2016 14:21:12 -0400 To: "De Schepper, Koen (Nokia - BE)" , Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSJmYvj8ED7chUmECqekIdzFz9XaCrZRqg Date: Sun, 16 Oct 2016 18:21:12 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@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.105.8.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Cc: "Black, David" Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 18:21:32 -0000 [1]=20 > I agree with Ingemar that the text: > "Unless otherwise specified by an Experimental RFC, routers treat > the ECT(0) and ECT(1) codepoints as equivalent, and senders are > free to use either the ECT(0) or the ECT(1) codepoint to indicate > ECT, on a packet-by-packet basis." > Should better become: > "Unless otherwise specified by an Experimental RFC, routers treat > the ECT(0) and ECT(1) codepoints as equivalent, and senders should > use only the ECT(0) codepoint to indicate ECT." > There is no reason anymore to use ECT(1) by senders, unless an Experiment= al > RFC specifies differently. Ok. [... snip...] > I think it is clearer to explicitly state that only ECT(0) should be used= . That's already been done in -00, via section 3 quoting this stronger text from RFC 3168: Protocols and senders that only require a single ECT codepoint SHOULD use ECT(0). That should suffice. [2]=20 > I think we need to clarify if the text in this section is intended only > for responses in the sender "without" a compensating change in the networ= k > between drop and CE marks, or also "with" a compensation. In the first ca= se > we should also specify this, and in the second case we just can also refe= r > to the L4S draft (where we assume a DCTCP or TCP-Prague response). Which L4S draft should be referenced? I believe I agree in general with th= e above concern, but I need to know which L4S draft should be referenced on the "with" approach in order to write the actual text for the ECN Experimen= tation draft. Thanks, --David > -----Original Message----- > From: De Schepper, Koen (Nokia - BE) [mailto:koen.de_schepper@nokia-bell- > labs.com] > Sent: Friday, October 14, 2016 5:59 PM > To: Black, David; Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@ietf.o= rg; > tcpPrague@ietf.org > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experiment= ation- > 00.txt >=20 > Hi all, >=20 > Thanks David, I think this draft is useful to support further L4S > specifications. >=20 > Some excerpts and comments from the mails below: >=20 > I agree with Ingemar that the text: > "Unless otherwise specified by an Experimental RFC, routers treat > the ECT(0) and ECT(1) codepoints as equivalent, and senders are > free to use either the ECT(0) or the ECT(1) codepoint to indicate > ECT, on a packet-by-packet basis." > Should better become: > "Unless otherwise specified by an Experimental RFC, routers treat > the ECT(0) and ECT(1) codepoints as equivalent, and senders should > use only the ECT(0) codepoint to indicate ECT." > There is no reason anymore to use ECT(1) by senders, unless an Experiment= al > RFC specifies differently. >=20 > > I've revised my working version of the -01 draft to remove the second > > sentence as part of this proposed update to RFC 3168. > I think it is clearer to explicitly state that only ECT(0) should be used= . >=20 > > My understanding is that L4S requires both ECT(0) and ECT(1), as it cou= ples > > treatments of traffic marked with those codepoints. For that reason, t= he > > statement in section 3 (which is quoted from RFC 3168) does not apply t= o L4S. > L4S is not changing the meaning of non-ECT or ECT(0) packets. > It still assumes a response by the sender equal as a response to drop. Th= e > coupling is only towards ECT(1). Routers will more frequently mark ECT(1) > packets to compensate the more aggressive behavior of L4S. ECT(1) marking > is steered by the non-ECT drop and ECT(0) marking probability such that > flow rates become equal independent of (non-)ECT(0/1). >=20 > > The handling of ECT(0) and non-ECT packets goes outside the L4S definit= ion > Correct. Nothing changes for L4S. >=20 > > [2] Section 2 - L4S and description of Alternative Backoff. If one of = the > > folks directly involved in L4S would like to suggest a draft to cite th= at > > describes the L4S backoff for the low latency/higher-CE-marking-probabi= lity > > functionality > Technically speaking L4S has an alternative response to a CE marked packe= t, > but only to a packet that was sender-marked as ECT(1) and when the networ= k > marks packets more frequently by the routers. >=20 > I think we need to clarify if the text in this section is intended only > for responses in the sender "without" a compensating change in the networ= k > between drop and CE marks, or also "with" a compensation. In the first ca= se > we should also specify this, and in the second case we just can also refe= r > to the L4S draft (where we assume a DCTCP or TCP-Prague response). >=20 > Regards, > Koen. >=20 >=20 >=20 > > -----Original Message----- > > From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Black, > > David > > Sent: vrijdag 7 oktober 2016 18:29 > > To: Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@ietf.org; > > tcpPrague@ietf.org > > Cc: Black, David > > Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > > experimentation-00.txt > > > > Ingemar, > > > > Summarizing: > > > > [1] Section 4.2 - "free to use" text. The full quote from RFC 3168 is: > > > > "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. > > Senders are free to use either the ECT(0) > > or the ECT(1) codepoint to indicate ECT, on a packet-by-packet > > basis." > > > > I've revised my working version of the -01 draft to remove the second > > sentence as part of this proposed update to RFC 3168. That's both simp= ler > > and clearer than what's in the posted -00. In addition, doing this obv= iates > > the need to say anything in this section about the possible L4S > > relationships between the ECT(0) and ECT(1) queues. > > > > [2] Section 2 - L4S and description of Alternative Backoff. If one of = the > > folks directly involved in L4S would like to suggest a draft to cite th= at > > describes the L4S backoff for the low latency/higher-CE-marking-probabi= lity > > functionality, I'm happy to cite that as an additional example of > > Alternative Backoff. > > > > Thanks, --David > > > > > -----Original Message----- > > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > > Sent: Friday, October 07, 2016 2:38 AM > > > To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@iet= f.org > > > Cc: Ingemar Johansson S > > > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > > experimentation- > > > 00.txt > > > > > > Hi > > > > > > Comments inline [IJ] > > > > > > > -----Original Message----- > > > > From: Black, David [mailto:David.Black@dell.com] > > > > Sent: den 7 oktober 2016 02:28 > > > > To: Ingemar Johansson S ; > > > > tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > > > > Cc: Black, David > > > > Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > > > > experimentation-00.txt > > > > > > > > Hi Ingemar, > > > > > > > > David> Inline > > > > > > > > Thanks, --David > > > > > > > > > -----Original Message----- > > > > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.co= m] > > > > > Sent: Thursday, October 06, 2016 4:32 AM > > > > > To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; > > > > > tcpPrague@ietf.org > > > > > Cc: Ingemar Johansson S > > > > > Subject: RE: [tcpPrague] FW: I-D Action: > > > > > draft-black-tsvwg-ecn-experimentation- > > > > > 00.txt > > > > > > > > > > Hi > > > > > > > > > > Thanks for writing up this draft. I have some comments on the con= tents > > > > > > > > Thanks for carefully reading the draft. > > > > > > > > > Intended status : Standards track. I interpret this that it means= that > > > > > this document becomes standards track. > > > > > Are there any ideas around the intended status for a document suc= h as > > > > > briscoe- tsvwg-ecn-l4s-id, will it be experimental first or ? > > > > > > > > Possibly - I don' t know. The ecn-experimentation draft is not int= ended > > to > > > > settle that question for the l4s-id draft or any of the other draft= s > > involved in > > > > the described areas of experimentation. > > > > > > > > I wrote the ecn-experimentation draft to allow the experiments to b= e > > > > specified in Experimental RFCs without each experiment also needing= a > > > > companion Standards > > > > Track RFC just to open up space for the experiment. If any of the > > > > experiments > > > > pan out so well that they deserve to be immediately written up as a > > > > Standards Track RFC without bothering with an Experimental RFC, the= n > > that > > > > would be wonderful, IMHO. > > > > > > > > > Section 4.2 : " "Unless otherwise specified by an Experimental RF= C, > > routers > > > > treat > > > > > the ECT(0) and ECT(1) codepoints as equivalent, and senders= are > > > > > free to use either the ECT(0) or the ECT(1) codepoint to > > indicate > > > > > ECT, on a packet-by-packet basis."" > > > > > In some way I find it to contradict the proposed statement in se= ction > > 3 " > > > > > Protocols and senders that only require a single ECT codepoint S= HOULD > > > > > use ECT(0)." > > > > > I see here a risk that the statement in 4.2 can delay deployment = of > > > > > L4S capability based on the use of ECT(1) in the networks ? > > > > > > > > My understanding is that L4S requires both ECT(0) and ECT(1), as it > > couples > > > > treatments of traffic marked with those codepoints. For that reaso= n, > > the > > > > statement in section 3 (which is quoted from RFC 3168) does not app= ly to > > L4S. > > > [IJ] It is perhaps here I see things differently. > > > My interpretation is that L4S is that senders mark packets with some > > special > > > codepoint (let's call it ECT(1) ) and network queues detect this and = send > > the > > > packets to a dedicated queue which marks these packets to ECN-CE at a= very > > low > > > queue delay. A special case may be that senders are networks are 100%= L4S > > (Data > > > centers), this means that only the code point ECT(1) is in use. > > > The handling of ECT(0) and not-ECT packets goes outside the L4S defin= ition > > and > > > definitely requires dualQ solution and classification. > > > It is quite possible that my interpretation is flawed. > > > > > > > > > > > OTOH, I see your concern, namely that "free to use" in the RFC 3168= text > > > > quoted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the R= FC > > 3168 > > > > text quoted in section 3. This is a concern with RFC 3168 itself. > > > > > > > > Would it help for this ecn-experimentation draft to update RFC 3168= by > > > > removing the words "and senders are free to use either the ECT(0) o= r the > > > > ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." ? > > > [IJ] Yes, it probably solves things, mind though that reason why I br= ought > > this is > > > up is that I may interpret the definition of L4S differently. > > > > > > > > > > > > Section 5 : I see the main problem with RFC6679 (in this context)= in > > > > > the use of the nonce. Don't however see any major problem to use > > > > > feedback also for an L4S capable sender/receiver using ECT(1). > > > > > For that purpose it may be better to rewrite : > > > > > Use of ECT(1) and random ECT values is discouraged, as that= may > > > > > expose RTP to differences in network treatment of ECT(1) an= d > > > > > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]= . > > > > > To : > > > > > Use of ECT values is discouraged, as that may > > > > > expose RTP to differences in network treatment of ECT(1) an= d > > > > > ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]= . > > > > > > > > Good point - I agree. I would insert "random" after "Use of" in th= e > > "To:" text. > > > > I'll make that change in my working copy that will become -01. > > > > > > > > > Further ... quote " In support of Alternative Backoff experimenta= tion > > > > > ...". I would say that this applies to L4S as well. As an example= , > > > > > SCReAM (RMCAT WG congestion control candidate) is easily modified= to > > > > > support L4S, and the RFC6679 feedback can be used with SCReAM. Fo= r > > > > > that reason it may be better to rephrase it like " In support of > > > > > Alternative Backoff experimentation and experiments based on > > > > > [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar > > > > > > > > I'd prefer to do something different. I think L4S is an example o= f > > both the > > > > Alternative > > > > Backoff and ECT Differences areas of experimentation, and hence I'd > > suggest > > > > citing an L4S draft in the description of the Alternative Backoff > > experiment > > > > scope in Section 2. Which L4S draft would you suggest? > > > [IJ] Good question.. Not sure what is required here?. Our proprietary > > SCReAM > > > research code has support for L4S, one possibility is to update the S= CReAM > > draft > > > with a description of this functionality. An example was shown at the= L4S > > BoF > > > (page 6-7 in https://www.ietf.org/proceedings/96/slides/slides-96-l4s= - > > 2.pdf ) > > > > > > > > > > > > > > > > > Regards > > > > > /Ingemar > > > > > > > > > > > -----Original Message----- > > > > > > From: Black, David [mailto:David.Black@dell.com] > > > > > > Sent: den 1 oktober 2016 00:42 > > > > > > To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > > > > > > Cc: Black, David > > > > > > Subject: [tcpPrague] FW: I-D Action: > > > > > > draft-black-tsvwg-ecn-experimentation- > > > > > > 00.txt > > > > > > > > > > > > This is the process-oriented draft on ECN experimentation that = I > > > > > > promised at the TSVWG > > > > > > meeting in Berlin. Comments are welcome, but please keep the > > process > > > > > > focus in mind - > > > > > > the intent is to leave documentation of the actual ECN changes = and > > > > > > rationale to the referenced drafts that document the ECN > > experiments. > > > > > > > > > > > > Thanks, --David > > > > > > > > > > > > -----Original Message----- > > > > > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Be= half > > > > > > Of internet-drafts@ietf.org > > > > > > Sent: Friday, September 30, 2016 6:24 PM > > > > > > To: i-d-announce@ietf.org > > > > > > Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.t= xt > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Dra= fts > > > > directories. > > > > > > > > > > > > > > > > > > Title : Explicit Congestion Notification (ECN= ) > > Experimentation > > > > > > Author : David Black > > > > > > Filename : draft-black-tsvwg-ecn-experimentation-00.txt > > > > > > Pages : 10 > > > > > > Date : 2016-09-30 > > > > > > > > > > > > Abstract: > > > > > > Multiple protocol experiments have been proposed that involv= e > > > > changes > > > > > > to Explicit Congestion Notification (ECN) as specified in RF= C > > 3168. > > > > > > This memo summarizes the proposed areas of experimentation t= o > > > > provide > > > > > > an overview to the Internet community and updates RFC 3168, = a > > > > > > Proposed Standard RFC, to allow the experiments to proceed > > without > > > > > > requiring a standards process exception for each Experimenta= l RFC > > to > > > > > > update RFC 3168. This memo also makes related updates to th= e ECN > > > > > > specification for RTP in RFC 6679 for the same reason. Each > > > > > > experiment is still required to be documented in an Experime= ntal > > RFC. > > > > > > This memo also records the conclusion of the ECN Nonce exper= iment > > in > > > > > > RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic= . > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > > https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experime= ntati > > > > > > on/ > > > > > > > > > > > > There's also a htmlized version available at: > > > > > > https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentati= on-00 > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time = of > > > > > > submission until the htmlized version and diff are available at > > > > tools.ietf.org. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > _______________________________________________ > > > > > > I-D-Announce mailing list > > > > > > I-D-Announce@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > _______________________________________________ > > tcpPrague mailing list > > tcpPrague@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpprague From nobody Mon Oct 24 22:12:05 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB1A129610 for ; Mon, 24 Oct 2016 22:12:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=networkplumber-org.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 4o5M6LMlDy5z for ; Mon, 24 Oct 2016 22:12:02 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 179E3129454 for ; Mon, 24 Oct 2016 22:12:02 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id y2so77747166oie.0 for ; Mon, 24 Oct 2016 22:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xAdzo+JSa9NcR+eHfsPkaP4OTQksp5dqUmzm7R+jag8=; b=iP0jNcjCk6UeGpZc8IDooctIgvkmeNrik0orluUHPMMgpztXqcqt4nyLEMazzv1die WLXeEqHwgfqAQOwpY4MH0JeH4vca+aNAe8YtOO6weHpA7jfzjSYlD5Vyk6MA6GXdpZ8q 1oMCPUxU33XbC07PxWN2RVGWZ3FGCnX0R6ajD5GqobExcZMlzrFMyZkDfgt1wV8IAIb4 IdxZ+TtVFfzp3G865yUmojl1RJZjNbHZtKBJyZyS/zQKr2e196YX2mmyyoEpKLOdONz8 t59kY9r7xjWoaFmLN5Rd9WTXin/uB2vVxGg8mxJwr98HFsga1EQ6x5jPekMU3nNM0WYT YU4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xAdzo+JSa9NcR+eHfsPkaP4OTQksp5dqUmzm7R+jag8=; b=P7ag7GOH1Pc5bwdPpbCNLhlJeJcmcDX7Ty30sV3A+MVrxljKwHgd/nWlUXcoMmFNuB DNmIomueKUuyHSnFsxHE3oTEE2teBxDt2qJm0OOj0JPWUmY/SPU7K9iODfoneWBtpTqV ud46gMS2jVJH7ZBI0cgYoay7dbv3IEx+X2hvXpSVgY2F8vAe5Wlri6hFkU5g1H5FpIH5 OSbsdE7z0N7Z8KSXSI+dHzh0pv9JEcwNOam4mZrptG5lZyeg4wFaZcspBdHqwNrlfPc2 W4z5hpFNtj6azWNH/p2Ywgj+cUxRO3lCl7coBo7Uas1ZAOTk04bozUiNHRTU4+47gYDg SrvA== X-Gm-Message-State: ABUngvfL3phC8qbEo9QTDrwm8I76OMOyh45sY4cLCQqG/7anx/eRVSJQkNjmfg8CW+UXCvdlcLcENsH7/cQ1DA== X-Received: by 10.36.83.213 with SMTP id n204mr581455itb.100.1477372321252; Mon, 24 Oct 2016 22:12:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.20 with HTTP; Mon, 24 Oct 2016 22:12:00 -0700 (PDT) In-Reply-To: References: <68b1c3f2-dfc3-ffc3-da8b-24c535d77df0@pollere.com> From: Stephen Hemminger Date: Mon, 24 Oct 2016 22:12:00 -0700 Message-ID: To: "De Schepper, Koen (Nokia - BE)" Content-Type: multipart/alternative; boundary=001a113f55c268dc09053fa98c30 Archived-At: Cc: TCP Prague List , bloat Subject: Re: [tcpPrague] [Bloat] DualPI2 qdisc implementation available for Linux X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 05:12:04 -0000 --001a113f55c268dc09053fa98c30 Content-Type: text/plain; charset=UTF-8 Why not submit it upstream where it can get more review and will get picked up by more users? On Fri, Jul 29, 2016 at 2:08 AM, De Schepper, Koen (Nokia - BE) < koen.de_schepper@nokia-bell-labs.com> wrote: > Hi all, > > For those who missed the L4S BoF, the PI2 AQM with DualQ option is > available on the following git: https://github.com/olgabo/dualpi2 > > PI2 (PI Improved with a Square) is a simplification of PIE (PI Enhanced) > with the advantage of also supporting L4S congestion controls (like DCTCP). > PI2 controls by default a single queue, with a common target (default > 20ms). To get the most out of the L4S traffic you need a second L4S queue > and a coupled AQM. PI2 supports this by specifying the "dualq" option. The > L4S queue is having an immediate step ECN marker at 1ms, while the classic > queue still has the 20ms target (with mark/drop coupled back to both L4S > and Classic). > > Note that PI2 supports DCTCP, but DCTCP is not the target to be used on > the internet. The TCP-Prague requirements (https://tools.ietf.org/html/ > draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-02#appendix-A) defines > what is needed to have an end-system CC implementation which behaves > similar to what FQ-X achieves in the network. FQ-X is a way the network can > correct the behavior of classic TCP CCs, TCP-Prague is the end-system > alternative that keeps the network simple and transport layer independent. > > Feel free to try it out, and join in developing a TCP CC that meets the > TCP-Prague requirements. > > Regards, > Koen. > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --001a113f55c268dc09053fa98c30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why not submit it upstream where it can get more review an= d will get picked up by more users?


On Fri, Jul 29, 2016 at 2:08 AM, De = Schepper, Koen (Nokia - BE) <koen.de_schepper@nokia-bel= l-labs.com> wrote:
Hi all,<= br>
For those who missed the L4S BoF, the PI2 AQM with DualQ option is availabl= e on the following git: https://github.com/olgabo/dualpi2

PI2 (PI Improved with a Square) is a simplification of PIE (PI Enhanced) wi= th the advantage of also supporting L4S congestion controls (like DCTCP). P= I2 controls by default a single queue, with a common target (default 20ms).= To get the most out of the L4S traffic you need a second L4S queue and a c= oupled AQM. PI2 supports this by specifying the "dualq" option. T= he L4S queue is having an immediate step ECN marker at 1ms, while the class= ic queue still has the 20ms target (with mark/drop coupled back to both L4S= and Classic).

Note that PI2 supports DCTCP, but DCTCP is not the target to be used on the= internet. The TCP-Prague requirements (https://tools.ietf.org/html/draft-briscoe-= tsvwg-aqm-tcpm-rmcat-l4s-problem-02#appendix-A) defines what = is needed to have an end-system CC implementation which behaves similar to = what FQ-X achieves in the network. FQ-X is a way the network can correct th= e behavior of classic TCP CCs, TCP-Prague is the end-system alternative tha= t keeps the network simple and transport layer independent.

Feel free to try it out, and join in developing a TCP CC that meets the TCP= -Prague requirements.

Regards,
Koen.


_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--001a113f55c268dc09053fa98c30-- From in@bobbriscoe.net Mon Oct 24 10:56:56 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0821295DD; Mon, 24 Oct 2016 10:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_7_tiGuYnXr; Mon, 24 Oct 2016 10:56:54 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 1AAAC1296DC; Mon, 24 Oct 2016 10:56:54 -0700 (PDT) Received: from 213.6.208.46.dyn.plus.net ([46.208.6.213]:57412 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1byjUR-0004qV-Uo; Mon, 24 Oct 2016 18:56:52 +0100 To: "Black, David" , "De Schepper, Koen (Nokia - BE)" , Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> From: Bob Briscoe Message-ID: <379e8b8a-734e-04ee-c3cb-f1c428b21e38@bobbriscoe.net> Date: Mon, 24 Oct 2016 18:56:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: X-Mailman-Approved-At: Tue, 25 Oct 2016 04:04:45 -0700 Subject: Re: [tcpPrague] [tsvwg] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:59:10 -0000 David, A couple of responses inline... On 16/10/16 19:21, Black, David wrote: > [1] > >> I agree with Ingemar that the text: >> "Unless otherwise specified by an Experimental RFC, routers treat >> the ECT(0) and ECT(1) codepoints as equivalent, and senders are >> free to use either the ECT(0) or the ECT(1) codepoint to indicate >> ECT, on a packet-by-packet basis." >> Should better become: >> "Unless otherwise specified by an Experimental RFC, routers treat >> the ECT(0) and ECT(1) codepoints as equivalent, and senders should >> use only the ECT(0) codepoint to indicate ECT." >> There is no reason anymore to use ECT(1) by senders, unless an Experimental >> RFC specifies differently. > Ok. > > [... snip...] > >> I think it is clearer to explicitly state that only ECT(0) should be used. > That's already been done in -00, via section 3 quoting this stronger text > from RFC 3168: > > Protocols and senders that only require a single ECT codepoint > SHOULD use ECT(0). > > That should suffice. [BB] If we're going to rely on that sentence, we need to add your exception for experimental RFCs to it. Then it becomes: "Unless otherwise specified by an Experimental RFC, when the ECN nonce has not already been implemented, protocols and senders MUST solely use ECT(0)." The SHOULD has to turn into a MUST, because all the possible exceptions that the original SHOULD allowed are now listed explicitly in the sentence, leaving no other exceptions that you want to allow. > > [2] > >> I think we need to clarify if the text in this section is intended only >> for responses in the sender "without" a compensating change in the network >> between drop and CE marks, or also "with" a compensation. In the first case >> we should also specify this, and in the second case we just can also refer >> to the L4S draft (where we assume a DCTCP or TCP-Prague response). > Which L4S draft should be referenced? I believe I agree in general with the > above concern, but I need to know which L4S draft should be referenced on > the "with" approach in order to write the actual text for the ECN Experimentation > draft. [BB] draft-briscoe-tsvwg-ecn-l4s-id-01 has the text you need. It attempts to specify both the difference in network behaviour and sender behaviour that is associated with ECT(1). Specifically, our current attempt to specify the transport behaviour is in: https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-01#section-2.3 Cheers Bob > > Thanks, --David > >> -----Original Message----- >> From: De Schepper, Koen (Nokia - BE) [mailto:koen.de_schepper@nokia-bell- >> labs.com] >> Sent: Friday, October 14, 2016 5:59 PM >> To: Black, David; Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@ietf.org; >> tcpPrague@ietf.org >> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation- >> 00.txt >> >> Hi all, >> >> Thanks David, I think this draft is useful to support further L4S >> specifications. >> >> Some excerpts and comments from the mails below: >> >> I agree with Ingemar that the text: >> "Unless otherwise specified by an Experimental RFC, routers treat >> the ECT(0) and ECT(1) codepoints as equivalent, and senders are >> free to use either the ECT(0) or the ECT(1) codepoint to indicate >> ECT, on a packet-by-packet basis." >> Should better become: >> "Unless otherwise specified by an Experimental RFC, routers treat >> the ECT(0) and ECT(1) codepoints as equivalent, and senders should >> use only the ECT(0) codepoint to indicate ECT." >> There is no reason anymore to use ECT(1) by senders, unless an Experimental >> RFC specifies differently. >> >>> I've revised my working version of the -01 draft to remove the second >>> sentence as part of this proposed update to RFC 3168. >> I think it is clearer to explicitly state that only ECT(0) should be used. >> >>> My understanding is that L4S requires both ECT(0) and ECT(1), as it couples >>> treatments of traffic marked with those codepoints. For that reason, the >>> statement in section 3 (which is quoted from RFC 3168) does not apply to L4S. >> L4S is not changing the meaning of non-ECT or ECT(0) packets. >> It still assumes a response by the sender equal as a response to drop. The >> coupling is only towards ECT(1). Routers will more frequently mark ECT(1) >> packets to compensate the more aggressive behavior of L4S. ECT(1) marking >> is steered by the non-ECT drop and ECT(0) marking probability such that >> flow rates become equal independent of (non-)ECT(0/1). >> >>> The handling of ECT(0) and non-ECT packets goes outside the L4S definition >> Correct. Nothing changes for L4S. >> >>> [2] Section 2 - L4S and description of Alternative Backoff. If one of the >>> folks directly involved in L4S would like to suggest a draft to cite that >>> describes the L4S backoff for the low latency/higher-CE-marking-probability >>> functionality >> Technically speaking L4S has an alternative response to a CE marked packet, >> but only to a packet that was sender-marked as ECT(1) and when the network >> marks packets more frequently by the routers. >> >> I think we need to clarify if the text in this section is intended only >> for responses in the sender "without" a compensating change in the network >> between drop and CE marks, or also "with" a compensation. In the first case >> we should also specify this, and in the second case we just can also refer >> to the L4S draft (where we assume a DCTCP or TCP-Prague response). >> >> Regards, >> Koen. >> >> >> >>> -----Original Message----- >>> From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Black, >>> David >>> Sent: vrijdag 7 oktober 2016 18:29 >>> To: Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@ietf.org; >>> tcpPrague@ietf.org >>> Cc: Black, David >>> Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- >>> experimentation-00.txt >>> >>> Ingemar, >>> >>> Summarizing: >>> >>> [1] Section 4.2 - "free to use" text. The full quote from RFC 3168 is: >>> >>> "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. >>> Senders are free to use either the ECT(0) >>> or the ECT(1) codepoint to indicate ECT, on a packet-by-packet >>> basis." >>> >>> I've revised my working version of the -01 draft to remove the second >>> sentence as part of this proposed update to RFC 3168. That's both simpler >>> and clearer than what's in the posted -00. In addition, doing this obviates >>> the need to say anything in this section about the possible L4S >>> relationships between the ECT(0) and ECT(1) queues. >>> >>> [2] Section 2 - L4S and description of Alternative Backoff. If one of the >>> folks directly involved in L4S would like to suggest a draft to cite that >>> describes the L4S backoff for the low latency/higher-CE-marking-probability >>> functionality, I'm happy to cite that as an additional example of >>> Alternative Backoff. >>> >>> Thanks, --David >>> >>>> -----Original Message----- >>>> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >>>> Sent: Friday, October 07, 2016 2:38 AM >>>> To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org >>>> Cc: Ingemar Johansson S >>>> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- >>> experimentation- >>>> 00.txt >>>> >>>> Hi >>>> >>>> Comments inline [IJ] >>>> >>>>> -----Original Message----- >>>>> From: Black, David [mailto:David.Black@dell.com] >>>>> Sent: den 7 oktober 2016 02:28 >>>>> To: Ingemar Johansson S ; >>>>> tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org >>>>> Cc: Black, David >>>>> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- >>>>> experimentation-00.txt >>>>> >>>>> Hi Ingemar, >>>>> >>>>> David> Inline >>>>> >>>>> Thanks, --David >>>>> >>>>>> -----Original Message----- >>>>>> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >>>>>> Sent: Thursday, October 06, 2016 4:32 AM >>>>>> To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; >>>>>> tcpPrague@ietf.org >>>>>> Cc: Ingemar Johansson S >>>>>> Subject: RE: [tcpPrague] FW: I-D Action: >>>>>> draft-black-tsvwg-ecn-experimentation- >>>>>> 00.txt >>>>>> >>>>>> Hi >>>>>> >>>>>> Thanks for writing up this draft. I have some comments on the contents >>>>> Thanks for carefully reading the draft. >>>>> >>>>>> Intended status : Standards track. I interpret this that it means that >>>>>> this document becomes standards track. >>>>>> Are there any ideas around the intended status for a document such as >>>>>> briscoe- tsvwg-ecn-l4s-id, will it be experimental first or ? >>>>> Possibly - I don' t know. The ecn-experimentation draft is not intended >>> to >>>>> settle that question for the l4s-id draft or any of the other drafts >>> involved in >>>>> the described areas of experimentation. >>>>> >>>>> I wrote the ecn-experimentation draft to allow the experiments to be >>>>> specified in Experimental RFCs without each experiment also needing a >>>>> companion Standards >>>>> Track RFC just to open up space for the experiment. If any of the >>>>> experiments >>>>> pan out so well that they deserve to be immediately written up as a >>>>> Standards Track RFC without bothering with an Experimental RFC, then >>> that >>>>> would be wonderful, IMHO. >>>>> >>>>>> Section 4.2 : " "Unless otherwise specified by an Experimental RFC, >>> routers >>>>> treat >>>>>> the ECT(0) and ECT(1) codepoints as equivalent, and senders are >>>>>> free to use either the ECT(0) or the ECT(1) codepoint to >>> indicate >>>>>> ECT, on a packet-by-packet basis."" >>>>>> In some way I find it to contradict the proposed statement in section >>> 3 " >>>>>> Protocols and senders that only require a single ECT codepoint SHOULD >>>>>> use ECT(0)." >>>>>> I see here a risk that the statement in 4.2 can delay deployment of >>>>>> L4S capability based on the use of ECT(1) in the networks ? >>>>> My understanding is that L4S requires both ECT(0) and ECT(1), as it >>> couples >>>>> treatments of traffic marked with those codepoints. For that reason, >>> the >>>>> statement in section 3 (which is quoted from RFC 3168) does not apply to >>> L4S. >>>> [IJ] It is perhaps here I see things differently. >>>> My interpretation is that L4S is that senders mark packets with some >>> special >>>> codepoint (let's call it ECT(1) ) and network queues detect this and send >>> the >>>> packets to a dedicated queue which marks these packets to ECN-CE at a very >>> low >>>> queue delay. A special case may be that senders are networks are 100% L4S >>> (Data >>>> centers), this means that only the code point ECT(1) is in use. >>>> The handling of ECT(0) and not-ECT packets goes outside the L4S definition >>> and >>>> definitely requires dualQ solution and classification. >>>> It is quite possible that my interpretation is flawed. >>>> >>>>> OTOH, I see your concern, namely that "free to use" in the RFC 3168 text >>>>> quoted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the RFC >>> 3168 >>>>> text quoted in section 3. This is a concern with RFC 3168 itself. >>>>> >>>>> Would it help for this ecn-experimentation draft to update RFC 3168 by >>>>> removing the words "and senders are free to use either the ECT(0) or the >>>>> ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." ? >>>> [IJ] Yes, it probably solves things, mind though that reason why I brought >>> this is >>>> up is that I may interpret the definition of L4S differently. >>>> >>>>>> Section 5 : I see the main problem with RFC6679 (in this context) in >>>>>> the use of the nonce. Don't however see any major problem to use >>>>>> feedback also for an L4S capable sender/receiver using ECT(1). >>>>>> For that purpose it may be better to rewrite : >>>>>> Use of ECT(1) and random ECT values is discouraged, as that may >>>>>> expose RTP to differences in network treatment of ECT(1) and >>>>>> ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. >>>>>> To : >>>>>> Use of ECT values is discouraged, as that may >>>>>> expose RTP to differences in network treatment of ECT(1) and >>>>>> ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. >>>>> Good point - I agree. I would insert "random" after "Use of" in the >>> "To:" text. >>>>> I'll make that change in my working copy that will become -01. >>>>> >>>>>> Further ... quote " In support of Alternative Backoff experimentation >>>>>> ...". I would say that this applies to L4S as well. As an example, >>>>>> SCReAM (RMCAT WG congestion control candidate) is easily modified to >>>>>> support L4S, and the RFC6679 feedback can be used with SCReAM. For >>>>>> that reason it may be better to rephrase it like " In support of >>>>>> Alternative Backoff experimentation and experiments based on >>>>>> [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar >>>>> I'd prefer to do something different. I think L4S is an example of >>> both the >>>>> Alternative >>>>> Backoff and ECT Differences areas of experimentation, and hence I'd >>> suggest >>>>> citing an L4S draft in the description of the Alternative Backoff >>> experiment >>>>> scope in Section 2. Which L4S draft would you suggest? >>>> [IJ] Good question.. Not sure what is required here?. Our proprietary >>> SCReAM >>>> research code has support for L4S, one possibility is to update the SCReAM >>> draft >>>> with a description of this functionality. An example was shown at the L4S >>> BoF >>>> (page 6-7 in https://www.ietf.org/proceedings/96/slides/slides-96-l4s- >>> 2.pdf ) >>>>>> Regards >>>>>> /Ingemar >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Black, David [mailto:David.Black@dell.com] >>>>>>> Sent: den 1 oktober 2016 00:42 >>>>>>> To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org >>>>>>> Cc: Black, David >>>>>>> Subject: [tcpPrague] FW: I-D Action: >>>>>>> draft-black-tsvwg-ecn-experimentation- >>>>>>> 00.txt >>>>>>> >>>>>>> This is the process-oriented draft on ECN experimentation that I >>>>>>> promised at the TSVWG >>>>>>> meeting in Berlin. Comments are welcome, but please keep the >>> process >>>>>>> focus in mind - >>>>>>> the intent is to leave documentation of the actual ECN changes and >>>>>>> rationale to the referenced drafts that document the ECN >>> experiments. >>>>>>> Thanks, --David >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf >>>>>>> Of internet-drafts@ietf.org >>>>>>> Sent: Friday, September 30, 2016 6:24 PM >>>>>>> To: i-d-announce@ietf.org >>>>>>> Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>>>> >>>>>>> Title : Explicit Congestion Notification (ECN) >>> Experimentation >>>>>>> Author : David Black >>>>>>> Filename : draft-black-tsvwg-ecn-experimentation-00.txt >>>>>>> Pages : 10 >>>>>>> Date : 2016-09-30 >>>>>>> >>>>>>> Abstract: >>>>>>> Multiple protocol experiments have been proposed that involve >>>>> changes >>>>>>> to Explicit Congestion Notification (ECN) as specified in RFC >>> 3168. >>>>>>> This memo summarizes the proposed areas of experimentation to >>>>> provide >>>>>>> an overview to the Internet community and updates RFC 3168, a >>>>>>> Proposed Standard RFC, to allow the experiments to proceed >>> without >>>>>>> requiring a standards process exception for each Experimental RFC >>> to >>>>>>> update RFC 3168. This memo also makes related updates to the ECN >>>>>>> specification for RTP in RFC 6679 for the same reason. Each >>>>>>> experiment is still required to be documented in an Experimental >>> RFC. >>>>>>> This memo also records the conclusion of the ECN Nonce experiment >>> in >>>>>>> RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentati >>>>>>> on/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-00 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> I-D-Announce mailing list >>>>>>> I-D-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>> >>> _______________________________________________ >>> tcpPrague mailing list >>> tcpPrague@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpprague > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Tue Oct 25 13:56:39 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340DB1299C2; Tue, 25 Oct 2016 13:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=cuYIJACZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=YDeD/weZ 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 NFaGdoRbBALE; Tue, 25 Oct 2016 13:56:29 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 D063F1295E3; Tue, 25 Oct 2016 13:56:28 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=E5VbosJ1S5nHlZXHzNu3gdV2g95nj5oSW6O+TZnN8AuCyWZrv2lg60vR JSdml+nnDhFQIEoFmaSoj1q88uV+cxj5nCsxM1dpXouH0ebQufDbrgTPC 8FCV+CtWD2OYRVNHTeexzkLRG0rxFqZ1ishxxF+XeGcUhm+n3aMZ5GOpy w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477428988; x=1508964988; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Q/LldfEGTRN1YC6VkCSk9Afyq7AUiouELcdu0qg94E0=; b=cuYIJACZanlLCjv+RSNLKRIaKCVF7BEy6EuLzeWBF7752eC23FgOVQ0u ovkvoAkQhdIfBT+ywfajdhd6M429zBfLmaDcN2QVZzj/sskB7rx6AZpaN vQa6tojmMtB+RA6nL04IMzOoREfFqOuEntO5JCrTCtME2hHnYoORRlqg4 g=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2016 15:56:28 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2016 02:56:27 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9PKuPeN001453 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Oct 2016 16:56:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com u9PKuPeN001453 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1477428986; bh=8lGuIvvJOjis0OFXYhUM0LiH38M=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YDeD/weZVvgStgntlb/IyQZ1sEd225fDXrgPb+tHEaSogMK0j1rF9P5fRR4qxpyZZ PU0X9XLO5i7iecLMTwm3tVmM6b2z+D+Zg6jo+6WT8jjfU+on92/Dmc2gEFwRGoylAx /p8mRA4AslGPkMGohTsZlselgKF+3+gGtX3UFDLA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com u9PKuPeN001453 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 25 Oct 2016 16:56:09 -0400 Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9PKu8Vk023415 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 25 Oct 2016 16:56:08 -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.0266.001; Tue, 25 Oct 2016 16:56:08 -0400 To: "tsvwg@ietf.org" , "tcpPrague@ietf.org" , "tcpm-chairs@ietf.org" Thread-Topic: I-D Action: draft-black-tsvwg-ecn-experimentation-01.txt Thread-Index: AQHSLwGpmKT6SAZ8f0S08njGgwdeRaC5peuQ Date: Tue, 25 Oct 2016 20:56:07 +0000 Message-ID: References: <147742872435.8463.161239363245980645.idtracker@ietfa.amsl.com> In-Reply-To: <147742872435.8463.161239363245980645.idtracker@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.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-01.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 20:56:34 -0000 This version picks up all the review comments, with the exception of Bob Br= iscoe's - Bob sent me a very extensive review privately that merits spending another = version of the draft on - watch for a -02 version of this draft soon. Thanks, --David -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, October 25, 2016 4:52 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Explicit Congestion Notification (ECN) Experiment= ation Author : David Black Filename : draft-black-tsvwg-ecn-experimentation-01.txt Pages : 10 Date : 2016-10-25 Abstract: Multiple protocol experiments have been proposed that involve changes to Explicit Congestion Notification (ECN) as specified in RFC 3168. This memo summarizes the proposed areas of experimentation to provide an overview to the Internet community and updates RFC 3168, a Proposed Standard RFC, to allow the experiments to proceed without requiring a standards process exception for each Experimental RFC to update RFC 3168. In addition, this memo makes related updates to the ECN specification for RTP in RFC 6679 for the same reason. Each experiment is still required to be documented in an Experimental RFC. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-black-tsvwg-ecn-experimentation-0= 1 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Oct 27 14:46:13 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F08129979; Thu, 27 Oct 2016 14:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2TkvbxZ2-cP; Thu, 27 Oct 2016 14:46:06 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6EDE6129970; Thu, 27 Oct 2016 14:46:06 -0700 (PDT) Received: from 213.6.208.46.dyn.plus.net ([46.208.6.213]:41451 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bzsUu-0002HD-Fz; Thu, 27 Oct 2016 22:46:04 +0100 To: "Black, David" References: <147742872435.8463.161239363245980645.idtracker@ietfa.amsl.com> From: Bob Briscoe Message-ID: <740f0f23-8c14-4094-5980-08fce8237848@bobbriscoe.net> Date: Thu, 27 Oct 2016 22:46:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "tcpm-chairs@ietf.org" , "tsvwg@ietf.org" , "tcpPrague@ietf.org" Subject: [tcpPrague] One additional edit for draft-black-tsvwg-ecn-experimentation-01.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 21:46:09 -0000 David, On 25/10/16 21:56, Black, David wrote: > This version picks up all the review comments, with the exception of Bob Briscoe's - > Bob sent me a very extensive review privately that merits spending another version > of the draft on - watch for a -02 version of this draft soon. In addition to my prior offlist review comments, here's one more I noticed, while checking the -01: 2. Scope CURRENT: ECT Differences: Use ECT(1) to request ECN congestion marking behavior in the network that differs from ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- marked traffic not receive different treatment in the network. PROPOSED: ECT Differences: Use ECT(1) to request more frequent ECN congestion marking behavior in the network counterbalanced by a reduced response to each mark at the sender, both of which differ from ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- marked traffic not receive different treatment. RATIONALE: L4S alters both sender and network behaviour, not just network. Bob > > Thanks, --David > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, October 25, 2016 4:52 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Explicit Congestion Notification (ECN) Experimentation > Author : David Black > Filename : draft-black-tsvwg-ecn-experimentation-01.txt > Pages : 10 > Date : 2016-10-25 > > Abstract: > Multiple protocol experiments have been proposed that involve changes > to Explicit Congestion Notification (ECN) as specified in RFC 3168. > This memo summarizes the proposed areas of experimentation to provide > an overview to the Internet community and updates RFC 3168, a > Proposed Standard RFC, to allow the experiments to proceed without > requiring a standards process exception for each Experimental RFC to > update RFC 3168. In addition, this memo makes related updates to the > ECN specification for RTP in RFC 6679 for the same reason. Each > experiment is still required to be documented in an Experimental RFC. > This memo also records the conclusion of the ECN Nonce experiment in > RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentation/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-black-tsvwg-ecn-experimentation-01 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Oct 28 17:55:55 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1129512951D; Fri, 28 Oct 2016 17:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=GJaj+S19; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=bbOu4bod 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 DUGfJ7iBp2fm; Fri, 28 Oct 2016 17:55:47 -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 0A0AA128E18; Fri, 28 Oct 2016 17:55:46 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=LZdS90fE+BTyk8/f0eoTuY9LNI1GeuRb7QaUnNxiT/nc+hjv8hR2Pklm u0ugc+LzWv6Xhhr0zpsE1Q0spGbu5rrreznr1sLzW/EAqYuAWJGrLTVhG IcS7nvHUbj3Tj/AZOJlXLg42yPyRBcrmtBqZ3YFJ0cFtG/Bop7Vgrb9hT Q=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477702547; x=1509238547; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2ghkFxgMFH1pQfp7aPPjJkv7dp/VRcei2lqfpKoeQus=; b=GJaj+S19Ox+wCE6hjrTcvMXg+KvyiO5/Q6pZYAP9tcBLbVP1Iei/tdbt lGA33xBJn9efhyclNXBW5lzXCqIn8beCdoKiMHYYkhK+Ho/fdjPoNEwJq waN6jMo6HrvQtQ6K0PmTPQAxuo/mhu2R1/Q9IOtj7cn2rpBynGqWB3ch7 Y=; 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; 28 Oct 2016 19:55:46 -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; 29 Oct 2016 06:55:44 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T0teiq006774 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Oct 2016 20:55:43 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u9T0teiq006774 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1477702544; bh=28QaWZk1YGNXtYIDsH9kkFFw9Fw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bbOu4bodM6lRhC2y+TD6A50qka63rcglFiLJxMKK4ZeXIgqm/ndenbMP8b7pvesqX mjj1eVq9BY6scinegB5ykQkdHDusIxnH/F6yx1m9TioPxYJNbfGsXumq16DZYXmOWz tec9lDOs8OXWPhWzTFEt1zfu7GGlbFHHhuPx+8Pk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u9T0teiq006774 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 28 Oct 2016 20:55:22 -0400 Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com [10.146.3.28]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T0tMCo003923 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 28 Oct 2016 20:55:22 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([10.146.3.28]) with mapi id 14.03.0266.001; Fri, 28 Oct 2016 20:55:21 -0400 To: Bob Briscoe , "De Schepper, Koen (Nokia - BE)" , Ingemar Johansson S , "tsvwg@ietf.org" , "tcpm-chairs@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: [tsvwg] [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt Thread-Index: AQHSJmYvj8ED7chUmECqekIdzFz9XaCrZRqggAzRJoCABnbmwA== Date: Sat, 29 Oct 2016 00:55:20 +0000 Message-ID: References: <147527426837.20369.878763602331124041.idtracker@ietfa.amsl.com> <379e8b8a-734e-04ee-c3cb-f1c428b21e38@bobbriscoe.net> In-Reply-To: <379e8b8a-734e-04ee-c3cb-f1c428b21e38@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Cc: "Black, David" Subject: Re: [tcpPrague] [tsvwg] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 00:55:50 -0000 Bob, Thanks for this follow-up. [1] Should ECT(1) be Reserved now? At this point, I think this issue ought to go to the Seoul TSVWG meeting, s= o the -02 version, will contain the current RFC 3168 "SHOULD use" for ECT(0)= , and indicate that whether that ought to become a "MUST use" for ECT(0) is an op= en issue. [2] Relationship of L4S to Alternate Backoff Thanks for the L4S draft reference, there will be text in the -02 of the EC= N experimentation draft on this. Thanks, --David > -----Original Message----- > From: Bob Briscoe [mailto:in@bobbriscoe.net] > Sent: Monday, October 24, 2016 1:57 PM > To: Black, David; De Schepper, Koen (Nokia - BE); Ingemar Johansson S; > tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > Subject: Re: [tsvwg] [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > experimentation-00.txt >=20 > David, >=20 > A couple of responses inline... >=20 > On 16/10/16 19:21, Black, David wrote: > > [1] > > > >> I agree with Ingemar that the text: > >> "Unless otherwise specified by an Experimental RFC, routers trea= t > >> the ECT(0) and ECT(1) codepoints as equivalent, and senders are > >> free to use either the ECT(0) or the ECT(1) codepoint to indica= te > >> ECT, on a packet-by-packet basis." > >> Should better become: > >> "Unless otherwise specified by an Experimental RFC, routers trea= t > >> the ECT(0) and ECT(1) codepoints as equivalent, and senders sho= uld > >> use only the ECT(0) codepoint to indicate ECT." > >> There is no reason anymore to use ECT(1) by senders, unless an Experim= ental > >> RFC specifies differently. > > Ok. > > > > [... snip...] > > > >> I think it is clearer to explicitly state that only ECT(0) should be u= sed. > > That's already been done in -00, via section 3 quoting this stronger te= xt > > from RFC 3168: > > > > Protocols and senders that only require a single ECT codepoint > > SHOULD use ECT(0). > > > > That should suffice. > [BB] If we're going to rely on that sentence, we need to add your > exception for experimental RFCs to it. Then it becomes: >=20 > "Unless otherwise specified by an Experimental RFC, when the ECN > nonce has not already been implemented, protocols and senders MUST > solely use ECT(0)." >=20 > The SHOULD has to turn into a MUST, because all the possible exceptions > that the original SHOULD allowed are now listed explicitly in the > sentence, leaving no other exceptions that you want to allow. >=20 > > > > [2] > > > >> I think we need to clarify if the text in this section is intended onl= y > >> for responses in the sender "without" a compensating change in the net= work > >> between drop and CE marks, or also "with" a compensation. In the first= case > >> we should also specify this, and in the second case we just can also r= efer > >> to the L4S draft (where we assume a DCTCP or TCP-Prague response). > > Which L4S draft should be referenced? I believe I agree in general wit= h the > > above concern, but I need to know which L4S draft should be referenced = on > > the "with" approach in order to write the actual text for the ECN > Experimentation > > draft. > [BB] draft-briscoe-tsvwg-ecn-l4s-id-01 has the text you need. > It attempts to specify both the difference in network behaviour and > sender behaviour that is associated with ECT(1). >=20 > Specifically, our current attempt to specify the transport behaviour is i= n: > https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-01#section-2.3 >=20 >=20 >=20 > Cheers >=20 >=20 >=20 > Bob > > > > Thanks, --David > > > >> -----Original Message----- > >> From: De Schepper, Koen (Nokia - BE) [mailto:koen.de_schepper@nokia-be= ll- > >> labs.com] > >> Sent: Friday, October 14, 2016 5:59 PM > >> To: Black, David; Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@iet= f.org; > >> tcpPrague@ietf.org > >> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > experimentation- > >> 00.txt > >> > >> Hi all, > >> > >> Thanks David, I think this draft is useful to support further L4S > >> specifications. > >> > >> Some excerpts and comments from the mails below: > >> > >> I agree with Ingemar that the text: > >> "Unless otherwise specified by an Experimental RFC, routers trea= t > >> the ECT(0) and ECT(1) codepoints as equivalent, and senders are > >> free to use either the ECT(0) or the ECT(1) codepoint to indica= te > >> ECT, on a packet-by-packet basis." > >> Should better become: > >> "Unless otherwise specified by an Experimental RFC, routers trea= t > >> the ECT(0) and ECT(1) codepoints as equivalent, and senders sho= uld > >> use only the ECT(0) codepoint to indicate ECT." > >> There is no reason anymore to use ECT(1) by senders, unless an Experim= ental > >> RFC specifies differently. > >> > >>> I've revised my working version of the -01 draft to remove the second > >>> sentence as part of this proposed update to RFC 3168. > >> I think it is clearer to explicitly state that only ECT(0) should be u= sed. > >> > >>> My understanding is that L4S requires both ECT(0) and ECT(1), as it c= ouples > >>> treatments of traffic marked with those codepoints. For that reason,= the > >>> statement in section 3 (which is quoted from RFC 3168) does not apply= to > L4S. > >> L4S is not changing the meaning of non-ECT or ECT(0) packets. > >> It still assumes a response by the sender equal as a response to drop.= The > >> coupling is only towards ECT(1). Routers will more frequently mark ECT= (1) > >> packets to compensate the more aggressive behavior of L4S. ECT(1) mark= ing > >> is steered by the non-ECT drop and ECT(0) marking probability such tha= t > >> flow rates become equal independent of (non-)ECT(0/1). > >> > >>> The handling of ECT(0) and non-ECT packets goes outside the L4S defin= ition > >> Correct. Nothing changes for L4S. > >> > >>> [2] Section 2 - L4S and description of Alternative Backoff. If one o= f the > >>> folks directly involved in L4S would like to suggest a draft to cite = that > >>> describes the L4S backoff for the low latency/higher-CE-marking-proba= bility > >>> functionality > >> Technically speaking L4S has an alternative response to a CE marked pa= cket, > >> but only to a packet that was sender-marked as ECT(1) and when the net= work > >> marks packets more frequently by the routers. > >> > >> I think we need to clarify if the text in this section is intended onl= y > >> for responses in the sender "without" a compensating change in the net= work > >> between drop and CE marks, or also "with" a compensation. In the first= case > >> we should also specify this, and in the second case we just can also r= efer > >> to the L4S draft (where we assume a DCTCP or TCP-Prague response). > >> > >> Regards, > >> Koen. > >> > >> > >> > >>> -----Original Message----- > >>> From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Blac= k, > >>> David > >>> Sent: vrijdag 7 oktober 2016 18:29 > >>> To: Ingemar Johansson S; tsvwg@ietf.org; tcpm-chairs@ietf.org; > >>> tcpPrague@ietf.org > >>> Cc: Black, David > >>> Subject: Re: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > >>> experimentation-00.txt > >>> > >>> Ingemar, > >>> > >>> Summarizing: > >>> > >>> [1] Section 4.2 - "free to use" text. The full quote from RFC 3168 i= s: > >>> > >>> "Routers treat the ECT(0) and ECT(1) codepoints as equivalent. > >>> Senders are free to use either the ECT(0) > >>> or the ECT(1) codepoint to indicate ECT, on a packet-by-packet > >>> basis." > >>> > >>> I've revised my working version of the -01 draft to remove the second > >>> sentence as part of this proposed update to RFC 3168. That's both si= mpler > >>> and clearer than what's in the posted -00. In addition, doing this o= bviates > >>> the need to say anything in this section about the possible L4S > >>> relationships between the ECT(0) and ECT(1) queues. > >>> > >>> [2] Section 2 - L4S and description of Alternative Backoff. If one o= f the > >>> folks directly involved in L4S would like to suggest a draft to cite = that > >>> describes the L4S backoff for the low latency/higher-CE-marking-proba= bility > >>> functionality, I'm happy to cite that as an additional example of > >>> Alternative Backoff. > >>> > >>> Thanks, --David > >>> > >>>> -----Original Message----- > >>>> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > >>>> Sent: Friday, October 07, 2016 2:38 AM > >>>> To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ie= tf.org > >>>> Cc: Ingemar Johansson S > >>>> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > >>> experimentation- > >>>> 00.txt > >>>> > >>>> Hi > >>>> > >>>> Comments inline [IJ] > >>>> > >>>>> -----Original Message----- > >>>>> From: Black, David [mailto:David.Black@dell.com] > >>>>> Sent: den 7 oktober 2016 02:28 > >>>>> To: Ingemar Johansson S ; > >>>>> tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > >>>>> Cc: Black, David > >>>>> Subject: RE: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn- > >>>>> experimentation-00.txt > >>>>> > >>>>> Hi Ingemar, > >>>>> > >>>>> David> Inline > >>>>> > >>>>> Thanks, --David > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com= ] > >>>>>> Sent: Thursday, October 06, 2016 4:32 AM > >>>>>> To: Black, David; tsvwg@ietf.org; tcpm-chairs@ietf.org; > >>>>>> tcpPrague@ietf.org > >>>>>> Cc: Ingemar Johansson S > >>>>>> Subject: RE: [tcpPrague] FW: I-D Action: > >>>>>> draft-black-tsvwg-ecn-experimentation- > >>>>>> 00.txt > >>>>>> > >>>>>> Hi > >>>>>> > >>>>>> Thanks for writing up this draft. I have some comments on the cont= ents > >>>>> Thanks for carefully reading the draft. > >>>>> > >>>>>> Intended status : Standards track. I interpret this that it means = that > >>>>>> this document becomes standards track. > >>>>>> Are there any ideas around the intended status for a document such= as > >>>>>> briscoe- tsvwg-ecn-l4s-id, will it be experimental first or ? > >>>>> Possibly - I don' t know. The ecn-experimentation draft is not int= ended > >>> to > >>>>> settle that question for the l4s-id draft or any of the other draft= s > >>> involved in > >>>>> the described areas of experimentation. > >>>>> > >>>>> I wrote the ecn-experimentation draft to allow the experiments to b= e > >>>>> specified in Experimental RFCs without each experiment also needing= a > >>>>> companion Standards > >>>>> Track RFC just to open up space for the experiment. If any of the > >>>>> experiments > >>>>> pan out so well that they deserve to be immediately written up as a > >>>>> Standards Track RFC without bothering with an Experimental RFC, the= n > >>> that > >>>>> would be wonderful, IMHO. > >>>>> > >>>>>> Section 4.2 : " "Unless otherwise specified by an Experimental RFC= , > >>> routers > >>>>> treat > >>>>>> the ECT(0) and ECT(1) codepoints as equivalent, and senders= are > >>>>>> free to use either the ECT(0) or the ECT(1) codepoint to > >>> indicate > >>>>>> ECT, on a packet-by-packet basis."" > >>>>>> In some way I find it to contradict the proposed statement in sec= tion > >>> 3 " > >>>>>> Protocols and senders that only require a single ECT codepoint SH= OULD > >>>>>> use ECT(0)." > >>>>>> I see here a risk that the statement in 4.2 can delay deployment o= f > >>>>>> L4S capability based on the use of ECT(1) in the networks ? > >>>>> My understanding is that L4S requires both ECT(0) and ECT(1), as it > >>> couples > >>>>> treatments of traffic marked with those codepoints. For that reaso= n, > >>> the > >>>>> statement in section 3 (which is quoted from RFC 3168) does not app= ly to > >>> L4S. > >>>> [IJ] It is perhaps here I see things differently. > >>>> My interpretation is that L4S is that senders mark packets with some > >>> special > >>>> codepoint (let's call it ECT(1) ) and network queues detect this and= send > >>> the > >>>> packets to a dedicated queue which marks these packets to ECN-CE at = a > very > >>> low > >>>> queue delay. A special case may be that senders are networks are 100= % L4S > >>> (Data > >>>> centers), this means that only the code point ECT(1) is in use. > >>>> The handling of ECT(0) and not-ECT packets goes outside the L4S defi= nition > >>> and > >>>> definitely requires dualQ solution and classification. > >>>> It is quite possible that my interpretation is flawed. > >>>> > >>>>> OTOH, I see your concern, namely that "free to use" in the RFC 3168= text > >>>>> quoted in 4.2 is somewhat at odds with "SHOULD use ECT(0)" in the R= FC > >>> 3168 > >>>>> text quoted in section 3. This is a concern with RFC 3168 itself. > >>>>> > >>>>> Would it help for this ecn-experimentation draft to update RFC 3168= by > >>>>> removing the words "and senders are free to use either the ECT(0) o= r the > >>>>> ECT(1) codepoint to indicate ECT, on a packet-by-packet basis." ? > >>>> [IJ] Yes, it probably solves things, mind though that reason why I b= rought > >>> this is > >>>> up is that I may interpret the definition of L4S differently. > >>>> > >>>>>> Section 5 : I see the main problem with RFC6679 (in this context) = in > >>>>>> the use of the nonce. Don't however see any major problem to use > >>>>>> feedback also for an L4S capable sender/receiver using ECT(1). > >>>>>> For that purpose it may be better to rewrite : > >>>>>> Use of ECT(1) and random ECT values is discouraged, as that= may > >>>>>> expose RTP to differences in network treatment of ECT(1) an= d > >>>>>> ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]= . > >>>>>> To : > >>>>>> Use of ECT values is discouraged, as that may > >>>>>> expose RTP to differences in network treatment of ECT(1) an= d > >>>>>> ECT(0), e.g., as proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]= . > >>>>> Good point - I agree. I would insert "random" after "Use of" in th= e > >>> "To:" text. > >>>>> I'll make that change in my working copy that will become -01. > >>>>> > >>>>>> Further ... quote " In support of Alternative Backoff experimentat= ion > >>>>>> ...". I would say that this applies to L4S as well. As an example, > >>>>>> SCReAM (RMCAT WG congestion control candidate) is easily modified = to > >>>>>> support L4S, and the RFC6679 feedback can be used with SCReAM. For > >>>>>> that reason it may be better to rephrase it like " In support of > >>>>>> Alternative Backoff experimentation and experiments based on > >>>>>> [I-D.briscoe-tsvwg-ecn-l4s-id]....." or something similar > >>>>> I'd prefer to do something different. I think L4S is an example o= f > >>> both the > >>>>> Alternative > >>>>> Backoff and ECT Differences areas of experimentation, and hence I'd > >>> suggest > >>>>> citing an L4S draft in the description of the Alternative Backoff > >>> experiment > >>>>> scope in Section 2. Which L4S draft would you suggest? > >>>> [IJ] Good question.. Not sure what is required here?. Our proprietar= y > >>> SCReAM > >>>> research code has support for L4S, one possibility is to update the = SCReAM > >>> draft > >>>> with a description of this functionality. An example was shown at th= e L4S > >>> BoF > >>>> (page 6-7 in https://www.ietf.org/proceedings/96/slides/slides-96-l4= s- > >>> 2.pdf ) > >>>>>> Regards > >>>>>> /Ingemar > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Black, David [mailto:David.Black@dell.com] > >>>>>>> Sent: den 1 oktober 2016 00:42 > >>>>>>> To: tsvwg@ietf.org; tcpm-chairs@ietf.org; tcpPrague@ietf.org > >>>>>>> Cc: Black, David > >>>>>>> Subject: [tcpPrague] FW: I-D Action: > >>>>>>> draft-black-tsvwg-ecn-experimentation- > >>>>>>> 00.txt > >>>>>>> > >>>>>>> This is the process-oriented draft on ECN experimentation that I > >>>>>>> promised at the TSVWG > >>>>>>> meeting in Berlin. Comments are welcome, but please keep the > >>> process > >>>>>>> focus in mind - > >>>>>>> the intent is to leave documentation of the actual ECN changes an= d > >>>>>>> rationale to the referenced drafts that document the ECN > >>> experiments. > >>>>>>> Thanks, --David > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On > Behalf > >>>>>>> Of internet-drafts@ietf.org > >>>>>>> Sent: Friday, September 30, 2016 6:24 PM > >>>>>>> To: i-d-announce@ietf.org > >>>>>>> Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-00.txt > >>>>>>> > >>>>>>> > >>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s > >>>>> directories. > >>>>>>> > >>>>>>> Title : Explicit Congestion Notification (ECN) > >>> Experimentation > >>>>>>> Author : David Black > >>>>>>> Filename : draft-black-tsvwg-ecn-experimentation-00.txt > >>>>>>> Pages : 10 > >>>>>>> Date : 2016-09-30 > >>>>>>> > >>>>>>> Abstract: > >>>>>>> Multiple protocol experiments have been proposed that involve > >>>>> changes > >>>>>>> to Explicit Congestion Notification (ECN) as specified in RFC > >>> 3168. > >>>>>>> This memo summarizes the proposed areas of experimentation to > >>>>> provide > >>>>>>> an overview to the Internet community and updates RFC 3168, a > >>>>>>> Proposed Standard RFC, to allow the experiments to proceed > >>> without > >>>>>>> requiring a standards process exception for each Experimental= RFC > >>> to > >>>>>>> update RFC 3168. This memo also makes related updates to the= ECN > >>>>>>> specification for RTP in RFC 6679 for the same reason. Each > >>>>>>> experiment is still required to be documented in an Experimen= tal > >>> RFC. > >>>>>>> This memo also records the conclusion of the ECN Nonce experi= ment > >>> in > >>>>>>> RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. > >>>>>>> > >>>>>>> > >>>>>>> The IETF datatracker status page for this draft is: > >>>>>>> https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experiment= ati > >>>>>>> on/ > >>>>>>> > >>>>>>> There's also a htmlized version available at: > >>>>>>> https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation= -00 > >>>>>>> > >>>>>>> > >>>>>>> Please note that it may take a couple of minutes from the time of > >>>>>>> submission until the htmlized version and diff are available at > >>>>> tools.ietf.org. > >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> I-D-Announce mailing list > >>>>>>> I-D-Announce@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or > >>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>>> > >>> _______________________________________________ > >>> tcpPrague mailing list > >>> tcpPrague@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpprague > > >=20 > -- > ______________________________________________________________ > __ > Bob Briscoe http://bobbriscoe.net/ From nobody Fri Oct 28 17:56:34 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8B91293E8; Fri, 28 Oct 2016 17:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=z9VKxV7u; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=ZkD/PFkU 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 I69bPsv3QXUU; Fri, 28 Oct 2016 17:56:31 -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 82F76128E18; Fri, 28 Oct 2016 17:56:31 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=yMkID44k7GeaLM6fKICU1a96Gxdu7Z0TnxZmdD6QRyYe2Wd6L2mvV7hO iiIA7bn5Bu8iq/iD5LQkbcUdRLGUQku4RW9JQIVD28C58+Ep4157z2RqS CRDmhn9zVrbiCVznbl2jSYCEf4ZeJvBltjDaUL7LAX0fMVp8ocy0YG+MG Q=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477702591; x=1509238591; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UJuwgQMEMPquralFaVZruiYWcoFRmu8ypxYrl3MGSy0=; b=z9VKxV7uTeSY6NFExICgHcgFtdXBIb06myO9yKSj5ZO1m5kqHdsxzYse 4JpDooY4YGivGIrumRfEJ9XZxG8C6ECb4bGWvRiSB3RZjcYyyVZXD74SL 3lXf+nfnB7GvnYW6r62WxqWRnge069zpAWygGMVDUfWOVDslwyFC6zeA8 8=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 19:56:31 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2016 06:56:30 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T0uA65011708 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Oct 2016 20:56:11 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u9T0uA65011708 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1477702571; bh=AwaLJ9Dzun496HJO/Nf1P4ptUZw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ZkD/PFkU8L94IYvLLMa4bO9ZJm1QBJzwTdU8FIx2zRqcFFl88hsLrRgO4ASW/6c56 6Q1GvwnagYXwOrP3nO+leVYK1fsImWFyLLgjkdmVaKRQ5QN2w/w/3qCzGgqQGKITfa CeYYsSvaXtKDVh0DdhdWST1UiIm0iCjxOYLbDDq4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u9T0uA65011708 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 28 Oct 2016 20:56:04 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T0u4bX004162 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 28 Oct 2016 20:56:05 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0266.001; Fri, 28 Oct 2016 20:56:04 -0400 To: Bob Briscoe Thread-Topic: One additional edit for draft-black-tsvwg-ecn-experimentation-01.txt Thread-Index: AQHSMJuIrlcBVIOXp0GvL7TGeU5d/qC+nREw Date: Sat, 29 Oct 2016 00:56:03 +0000 Message-ID: References: <147742872435.8463.161239363245980645.idtracker@ietfa.amsl.com> <740f0f23-8c14-4094-5980-08fce8237848@bobbriscoe.net> In-Reply-To: <740f0f23-8c14-4094-5980-08fce8237848@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "tcpm-chairs@ietf.org" , "tsvwg@ietf.org" , "tcpPrague@ietf.org" Subject: Re: [tcpPrague] One additional edit for draft-black-tsvwg-ecn-experimentation-01.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 00:56:33 -0000 Got it, I changed "reduced" to "changed" in the new text. Thanks, --David > -----Original Message----- > From: Bob Briscoe [mailto:ietf@bobbriscoe.net] > Sent: Thursday, October 27, 2016 5:46 PM > To: Black, David > Cc: tsvwg@ietf.org; tcpPrague@ietf.org; tcpm-chairs@ietf.org > Subject: One additional edit for draft-black-tsvwg-ecn-experimentation-01= .txt >=20 > David, >=20 >=20 > On 25/10/16 21:56, Black, David wrote: > > This version picks up all the review comments, with the exception of Bo= b > Briscoe's - > > Bob sent me a very extensive review privately that merits spending anot= her > version > > of the draft on - watch for a -02 version of this draft soon. > In addition to my prior offlist review comments, here's one more I > noticed, while checking the -01: >=20 > 2. Scope >=20 > CURRENT: > ECT Differences: Use ECT(1) to request ECN congestion marking > behavior in the network that differs from ECT(0), e.g., as > proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance > with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- > marked traffic not receive different treatment in the network. > PROPOSED: > ECT Differences: Use ECT(1) to request more frequent ECN congestion > marking > behavior in the network counterbalanced by a reduced response to > each mark > at the sender, both of which differ from ECT(0), e.g., as > proposed in [I-D.briscoe-tsvwg-ecn-l4s-id]. This is at variance > with RFC 3168's requirement that ECT(0)-marked traffic and ECT(1)- > marked traffic not receive different treatment. > RATIONALE: > L4S alters both sender and network behaviour, not just network. >=20 >=20 > Bob > > > > Thanks, --David > > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > > Sent: Tuesday, October 25, 2016 4:52 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-01.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > > > Title : Explicit Congestion Notification (ECN) Exper= imentation > > Author : David Black > > Filename : draft-black-tsvwg-ecn-experimentation-01.txt > > Pages : 10 > > Date : 2016-10-25 > > > > Abstract: > > Multiple protocol experiments have been proposed that involve chang= es > > to Explicit Congestion Notification (ECN) as specified in RFC 3168. > > This memo summarizes the proposed areas of experimentation to provi= de > > an overview to the Internet community and updates RFC 3168, a > > Proposed Standard RFC, to allow the experiments to proceed without > > requiring a standards process exception for each Experimental RFC t= o > > update RFC 3168. In addition, this memo makes related updates to t= he > > ECN specification for RTP in RFC 6679 for the same reason. Each > > experiment is still required to be documented in an Experimental RF= C. > > This memo also records the conclusion of the ECN Nonce experiment i= n > > RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentation/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-black-tsvwg-ecn-experimentati= on-01 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > >=20 > -- > ______________________________________________________________ > __ > Bob Briscoe http://bobbriscoe.net/ From nobody Fri Oct 28 19:06:30 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A885129457; Fri, 28 Oct 2016 19:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=k9A7tzd8; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=iI7mUFeQ 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 qg_62Il39Jtz; Fri, 28 Oct 2016 19:06:28 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 9C55F129406; Fri, 28 Oct 2016 19:06:28 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=wshj/vu8tdaxE+1uMKH3/tJHVcrbOR9VRDb5id85GQ7fWpN1SEF5yi7z dU5dym+8IRoucDp/T+W46rbDWNGYPXch+aK/hiyRY49LOn4GMaesWh13k r+picxq7unS1JL0qY8JSQUJCIWXNq8sJLvxB2AcReygwXozFr6Cne+J3o A=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477706788; x=1509242788; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=16IJOsCZuSNMMwtwEOOZysn6KlqKNaJxxzOapUMgA2w=; b=k9A7tzd8gnQ1QZSYfrS56DAbOPTzoEZhz5rQc0Txv6Ys+gKTRg5+gSQE i1UDxHq5o9ZetjScYvGqTXkfhPQoOxFiW0nWWxVPAkwcf6qDG8DG4Al/f bdly+O6dxz/vUEmC8SgcPzpqnsArF+hBaSMVBjaRV8U55ZTVWd0ByuvsH Q=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 21:06:27 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2016 08:06:27 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T26PP2027336 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Oct 2016 22:06:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u9T26PP2027336 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1477706786; bh=n79s6MMdD/hnmoqIEl3u7VSmKkE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=iI7mUFeQNakMYKDgKF4fJo3p7l9V5tZqY21mbblr26y1g+a96V0k8ZaXvaG/FdPXm GVfW54B0Z1YQlfInjyN3lSVZJOV4DsUNTYC4lZ0bf/Ex1IAbBgqlcxQyxmFTtHzE83 /i1BP5hvjMFZz5dPK9w7BIgkjzfAOxAnr83cOIxY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u9T26PP2027336 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 28 Oct 2016 22:04:40 -0400 Received: from MXHUB316.corp.emc.com (MXHUB316.corp.emc.com [10.146.3.94]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9T266gu013805 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 28 Oct 2016 22:06:07 -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.0266.001; Fri, 28 Oct 2016 22:06:06 -0400 To: "tsvwg@ietf.org" , "tcpm@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: New Version Notification for draft-black-tsvwg-ecn-experimentation-02.txt Thread-Index: AQHSMYhxPK/++Q1yqUuTvYdsXsouuaC+rfCg Date: Sat, 29 Oct 2016 02:06:05 +0000 Message-ID: References: <147770651989.24883.8392540470740722082.idtracker@ietfa.amsl.com> In-Reply-To: <147770651989.24883.8392540470740722082.idtracker@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.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: [tcpPrague] FW: New Version Notification for draft-black-tsvwg-ecn-experimentation-02.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 02:06:30 -0000 VGhlIGNoYW5nZXMgaW4gIHRoZSAtMDIgdmVyc2lvbiBmcm9tIHRoZSAtMDEgYXJlIHByaW1hcmls eSBjb3VydGVzeSBvZiBhDQp0aG9yb3VnaCByZXZpZXcgYnkgQm9iIEJyaXNjb2UuDQoNCldoZXRo ZXIgdG8gcmVxdWlyZSAoTVVTVCkgb3Igc3Ryb25nbHkgZW5jb3VyYWdlIChTSE9VTEQpIHVzZSBv ZiBFQ1QoMCkNCmFuZCBub3QgRUNUKDEpIGlzIGFuIG9wZW4gaXNzdWUgdGhhdCBvdWdodCB0byBi ZSBkaXNjdXNzZWQgaW4gU2VvdWwgKFRTVldHDQppcyB0aGUgbGlrZWx5IHZlbnVlKS4NCg0KQXMg YW4gaW5kaXZpZHVhbCwgSSByZXF1ZXN0IHRoYXQgdGhpcyBkcmFmdCBiZSBwdXQgb24gdGhlIFRT VldHIGFnZW5kYSBmb3INClNlb3VsIHdpdGggYSByZXF1ZXN0IGZvciBUU1ZXRyBXRyBhZG9wdGlv bi4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddIA0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDI4LCAyMDE2IDEwOjAyIFBNDQpUbzogQmxhY2ss IERhdmlkDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJsYWNr LXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWJsYWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDIudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhdmlkIEJsYWNrIGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1ibGFjay10c3Z3Zy1lY24tZXhwZXJp bWVudGF0aW9uDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3Rp ZmljYXRpb24gKEVDTikgRXhwZXJpbWVudGF0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE2LTEwLTI4 DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMg0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ibGFjay10c3Z3 Zy1lY24tZXhwZXJpbWVudGF0aW9uLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJsYWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRp b24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJs YWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDINCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYmxhY2stdHN2d2ctZWNuLWV4cGVyaW1l bnRhdGlvbi0wMg0KDQpBYnN0cmFjdDoNCiAgIE11bHRpcGxlIHByb3RvY29sIGV4cGVyaW1lbnRz IGhhdmUgYmVlbiBwcm9wb3NlZCB0aGF0IGludm9sdmUgY2hhbmdlcw0KICAgdG8gRXhwbGljaXQg Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgYXMgc3BlY2lmaWVkIGluIFJGQyAzMTY4Lg0K ICAgVGhpcyBtZW1vIHN1bW1hcml6ZXMgdGhlIHByb3Bvc2VkIGFyZWFzIG9mIGV4cGVyaW1lbnRh dGlvbiB0byBwcm92aWRlDQogICBhbiBvdmVydmlldyB0byB0aGUgSW50ZXJuZXQgY29tbXVuaXR5 IGFuZCB1cGRhdGVzIFJGQyAzMTY4LCBhDQogICBQcm9wb3NlZCBTdGFuZGFyZCBSRkMsIHRvIGFs bG93IHRoZSBleHBlcmltZW50cyB0byBwcm9jZWVkIHdpdGhvdXQNCiAgIHJlcXVpcmluZyBhIHN0 YW5kYXJkcyBwcm9jZXNzIGV4Y2VwdGlvbiBmb3IgZWFjaCBFeHBlcmltZW50YWwgUkZDIHRvDQog ICB1cGRhdGUgUkZDIDMxNjguICBFYWNoIGV4cGVyaW1lbnQgaXMgc3RpbGwgcmVxdWlyZWQgdG8g YmUgZG9jdW1lbnRlZA0KICAgaW4gYW4gRXhwZXJpbWVudGFsIFJGQy4gIEluIGFkZGl0aW9uLCB0 aGlzIG1lbW8gbWFrZXMgcmVsYXRlZCB1cGRhdGVzDQogICB0byB0aGUgRUNOIHNwZWNpZmljYXRp b25zIGZvciBSVFAgaW4gUkZDIDY2NzkgYW5kIHRvIHRoZSBFQ04NCiAgIHNwZWNpZmljYXRpb25z IGZvciBEQ0NQIGluIFJGQyA0MzQxLCBSRkMgNDM0MiBhbmQgUkZDIDU2MjIuICBUaGlzDQogICBt ZW1vIGFsc28gcmVjb3JkcyB0aGUgY29uY2x1c2lvbiBvZiB0aGUgRUNOIE5vbmNlIGV4cGVyaW1l bnQgaW4gUkZDDQogICAzNTQwLCBvYnNvbGV0ZXMgUkZDIDM1NDAgYW5kIHJlY2xhc3NpZmllcyBp dCBhcyBIaXN0b3JpYyB0byBlbmFibGUNCiAgIG5ldyBleHBlcmltZW50YWwgdXNlIG9mIHRoZSBF Q1QoMSkgY29kZXBvaW50Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Oct 31 16:09:09 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC8D129509; Mon, 31 Oct 2016 16:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=l7g+vDG0; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=W/IDzJSp 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 GJLmZ2v3IH5E; Mon, 31 Oct 2016 16:08:59 -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 6CC8C129ACA; Mon, 31 Oct 2016 16:08:59 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=XfGhO9Sz+pIrvmtBs0KBwptCG6YmRKwaDGSgUxNowHbiFzdHN7HV0xG7 6yGvzTg3b0tswk8nkiQIHfuy6OkGQfXVO++/ATIYslhrg/l/cQ0pDJ3Xr +7qbY6cSplbE91qyRyvfZfi9sh15reSJeZUTG5vR7yMdPrmWx88DgYngP Y=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1477955339; x=1509491339; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2ei2LvlOz01Y/BpZr+8NEkl01XYBRtVYHJpMeEL0CDU=; b=l7g+vDG05GJIg18rCXFjfJXON36FMKUFe+XCgCPRNE8a39pKNZakwahg +g4F5Wqbp7nnuUbdgR88PFij0/4Dzc3XWfSZ5ZudOuASrSjABm290vnJF b35aU+79Okr3YNEFd3E0RUVwfEO73bpP4s13CD2O65fGEbLayjCP8Ycp9 Q=; 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; 31 Oct 2016 18:08:59 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 05:08:58 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9VN8uee000800 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 Oct 2016 19:08:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u9VN8uee000800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1477955337; bh=jRr0tzn+pX55yYiaCbs0Remt0Fo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=W/IDzJSpwHrNBJoa9mhyt5kIJ9qxuk2k3xsq3Qzyu9Sq4Uu+/pdi/9ptxQBxrCaNN cId7yvBHPiF6jmd5K+XAbLvfa1Go39zzAWWwRYwG8zeyOPvVRO0KTkGRuWeYQ/nOV4 U8h3mOoH75m5GAsw64/GE1CYPuFT/CGSk4dvdimE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u9VN8uee000800 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 31 Oct 2016 19:07:19 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u9VN8guP009807 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 31 Oct 2016 19:08:43 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Mon, 31 Oct 2016 19:08:42 -0400 To: "tsvwg@ietf.org" , "tcpm@ietf.org" , "tcpPrague@ietf.org" Thread-Topic: I-D Action: draft-black-tsvwg-ecn-experimentation-03.txt Thread-Index: AQHSM8l4c70ay2gM4E+p3q2EkPlANKDDL3Vg Date: Mon, 31 Oct 2016 23:08:41 +0000 Message-ID: References: <147795434531.23271.3974811936089328519.idtracker@ietfa.amsl.com> In-Reply-To: <147795434531.23271.3974811936089328519.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tcpPrague] FW: I-D Action: draft-black-tsvwg-ecn-experimentation-03.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 23:09:01 -0000 Minor changes: - Bob Briscoe found a couple more small items that needed attention - idnits turned out to be correct about which boilerplate to use. Thanks, --David -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, October 31, 2016 6:52 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-black-tsvwg-ecn-experimentation-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Explicit Congestion Notification (ECN) Experiment= ation Author : David Black Filename : draft-black-tsvwg-ecn-experimentation-03.txt Pages : 13 Date : 2016-10-31 Abstract: Multiple protocol experiments have been proposed that involve changes to Explicit Congestion Notification (ECN) as specified in RFC 3168. This memo summarizes the proposed areas of experimentation to provide an overview to the Internet community and updates RFC 3168, a Proposed Standard RFC, to allow the experiments to proceed without requiring a standards process exception for each Experimental RFC to update RFC 3168. Each experiment is still required to be documented in an Experimental RFC. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and to the ECN specifications for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, obsoletes RFC 3540 and reclassifies it as Historic to enable new experimental use of the ECT(1) codepoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-black-tsvwg-ecn-experimentation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-black-tsvwg-ecn-experimentation-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-black-tsvwg-ecn-experimentation-0= 3 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Oct 31 17:02:25 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E032129C03; Mon, 31 Oct 2016 17:02:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO3M4aoyL5S1; Mon, 31 Oct 2016 17:02:13 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 945ED129BFF; Mon, 31 Oct 2016 17:02:12 -0700 (PDT) Received: from [77.40.224.170] (port=59439 helo=[10.0.102.204]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c1MWp-0002qz-3x; Tue, 01 Nov 2016 00:02:11 +0000 To: tsvwg IETF list , TCP Prague List , AQM IETF list , tcpm IETF list From: Bob Briscoe Message-ID: Date: Tue, 1 Nov 2016 00:02:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8104AF989CDD82CEF66EA35D" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpPrague] L4S status update X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 00:02:16 -0000 This is a multi-part message in MIME format. --------------8104AF989CDD82CEF66EA35D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit tsvwg, aqm, tcpm, tcpPrague mailing lists, A few people have been working away to specify and document all the aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) service, which held a successful BoF in Berlin. As the decision was to try to work across multiple WGs, I thought it would be useful to give ... ... the status collected over all activities and WGs. I've included stuff that has wider applicability but is also needed for L4S. Click on the headings to take you to the page where all these links are collected together. Source Code * Dual Queue Coupled AQM o With Curvy RED for Linux (access available shortly) o With PI2 for Linux [*UPDATED*] * Data Centre TCP (DCTCP) for o Linux (in the mainline kernel ) o FreeBSD patch o ns2 patch . * Accurate ECN TCP Feedback for Linux [*COMPLETED*, but not fully tested] *IETF specs* As the architecture explains, there are three main parts to standardisation: the identifier (#1), the network algorithms (#2) and the host algorithms (#3): * Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture and Problem Statement > [*NEW*] 1. A proposed new identifier for Low Latency, Low Loss, Scalable throughput (L4S) packets > [*UPDATED to reflect the proposed process*] and the IETF’s enabling draft to make way for this > [*NEW*] 2. Then network operators can deploy a new simple active queue management algorithm, that complies with the few constraints specified here: > Example algorithms are given in appendices. [*PI2 pseudocode added to make 2 example**appendices*] 3. And host developers can deploy new scalable TCP algorithms, e.g. Data Centre TCP (DCTCP): > Without steps #2 & #3, scalable TCPs are too aggressive to coexist with classic TCPs like Reno and Cubic, so DCTCP was initially confined to controlled networks like Data Centres, where all classic traffic sources could be upgraded (or isolated). To be safe over the public Internet, scalable TCP algorithms will need to comply with the list of requirements agreed at an informally convened meeting in Prague that have become know as the TCP Prague requirements : * One of these requirements is accurate ECN feedback, which the IETF has recognised will need an update to the TCP protocol, and it has stated the requirements a solution should comply with: > A candidate protocol to satisfy these requirements has been developed and adopted by the IETF: > [*UPDATED*] * The following drafts address other specific TCP Prague requirements: Adding ECN to TCP control packets: > [*UPDATED*] Recommendations for increasing TCP performance in low RTT networks: > Papers * Article in the IETF Journal describing the Demo in Bits-N-Bites at the IETF in Prague, July 2015. “Ultra-Low Delay for All ” IETF Journal, Nov 2015. * Description of an**ambitious demo of five low latency apps on one broadband line, 4 of which were also high throughput: “Ultra-Low Delay for All: Live Experience, Live Analysis “, Proc. ACM Multimedia Systems; Demo Session (May 2016). * “/*PI^2 : A Linearized AQM for both Classic and Scalable TCP*/ ,” Proc. ACM CONEXT 2016 (To appear Dec 2016). [*NEW*] * Finally, a pathetic apology is in order: We prepared a [*NEW*] paper for a top conference giving the full L4S story, with a massive set of testbed-based evaluations, with a wide range of link rates, RTTs, mixtures of numbers of flows in each queue, etc. etc. But we screwed up, and it got rejected without even being read - we exceeded the page limit :( We don't want to publish it on the Web until we've tried again. But if anyone wants a private copy, pls just ask. Otherwise, the following older paper is still available, but not as comprehensive or well-honed: Pre-print of paper explaining why scalable TCP algorithms solve the problem (in plain English and maths), how the Dual Queue Coupled AQM algorithm works, and recording the results of extensive testbed experiments. “`/*Data Centre to the Home’: Ultra-Low Latency for All*/ ” (2015) Thank you to everyone involved so far. Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------8104AF989CDD82CEF66EA35D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit tsvwg, aqm, tcpm, tcpPrague mailing lists,

A few people have been working away to specify and document all the aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) service, which held a successful BoF in Berlin. As the decision was to try to work across multiple WGs, I thought it would be useful to give ...

... the status collected over all activities and WGs. I've included stuff that has wider applicability but is also needed for L4S. Click on the headings to take you to the page where all these links are collected together.

Source Code

IETF specs

As the architecture explains, there are three main parts to standardisation: the identifier (#1), the network algorithms (#2) and the host algorithms (#3):
  • Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture and Problem Statement
    <draft-briscoe-tsvwg-l4s-arch> [NEW]
  1. A proposed new identifier for Low Latency, Low Loss, Scalable throughput (L4S) packets
    <draft-briscoe-tsvwg-ecn-l4s-id> [UPDATED to reflect the proposed process]
    and the IETF’s enabling draft to make way for this
    <draft-black-tsvwg-ecn-experimentation> [NEW]
  2. Then network operators can deploy a new simple active queue management algorithm, that complies with the few constraints specified here:
    <draft-briscoe-tsvwg-aqm-dualq-coupled>
    Example algorithms are given in appendices. [PI2 pseudocode added to make 2 example appendices]
  3. And host developers can deploy new scalable TCP algorithms, e.g. Data Centre TCP (DCTCP):
    <draft-ietf-tcpm-dctcp>
    Without steps #2 & #3, scalable TCPs are too aggressive to coexist with classic TCPs like Reno and Cubic, so DCTCP was initially confined to controlled networks like Data Centres, where all classic traffic sources could be upgraded (or isolated). To be safe over the public Internet, scalable TCP algorithms will need to comply with the list of requirements agreed at an informally convened meeting in Prague that have become know as the TCP Prague requirements:
  • One of these requirements is accurate ECN feedback, which the IETF has recognised will need an update to the TCP protocol, and it has stated the requirements a solution should comply with:
    <RFC7560>
    A candidate protocol to satisfy these requirements has been developed and adopted by the IETF:
    <draft-ietf-tcpm-accurate-ecn> [UPDATED]
  • The following drafts address other specific TCP Prague requirements:
    Adding ECN to TCP control packets:
    <draft-bagnulo-tcpm-generalized-ecn> [UPDATED]
    Recommendations for increasing TCP performance in low RTT networks:
    <draft-bagnulo-tcpm-tcp-low-rtt>

Papers


  • Finally, a pathetic apology is in order: We prepared a [NEW] paper for a top conference giving the full L4S story, with a massive set of testbed-based evaluations, with a wide range of link rates, RTTs, mixtures of numbers of flows in each queue, etc. etc.  But we screwed up, and it got rejected without even being read - we exceeded the page limit :(

    We don't want to publish it on the Web until we've tried again. But if anyone wants a private copy, pls just ask.
    Otherwise, the following older paper is still available, but not as comprehensive or well-honed:

    Pre-print of paper explaining why scalable TCP algorithms solve the problem (in plain English and maths), how the Dual Queue Coupled AQM algorithm works, and recording the results of extensive testbed experiments.

Thank you to everyone involved so far.

Cheers


Bob
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------8104AF989CDD82CEF66EA35D--