From nobody Mon May 9 11:56:49 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957B812D161 for ; Mon, 9 May 2016 11:56:47 -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 rdaHf5CUFK3I for ; Mon, 9 May 2016 11:56:45 -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 4895712B058 for ; Mon, 9 May 2016 11:56:45 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 594AA85784CCB; Mon, 9 May 2016 18:26:15 +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 u49IQIY8008058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 May 2016 18:26:18 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 u49IPAbn020882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 May 2016 20:26:18 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 9 May 2016 20:25:14 +0200 From: "Scharf, Michael (Nokia - DE)" To: "draft-ietf-tcpm-dctcp@tools.ietf.org" Thread-Topic: Some comments on draft-ietf-tcpm-dctcp Thread-Index: AdGqICCR7wWRxmfCSkO9/HVPCvvFdA== Date: Mon, 9 May 2016 18:25:14 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4883C106@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: [tcpm] Some comments on draft-ietf-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 18:56:47 -0000 Dear authors, As individual contributor to TCPM, I have read -01 of the DCTCP draft and I= 've run into some minor issues: * Section 1: I think the following wording was discussed already in the pas= t: It is recommended that DCTCP be deployed in a datacenter environment where the endpoints and the switching fabric are under a single administrative domain. This protocol is not meant for uncontrolled deployment in the global Internet. Reading the document again, I'd prefer a wording that would not generally= recommend DCTCP to all single domain datacenter environments. The smallest= change I could think of would be to add the word "only": =20 It is recommended that DCTCP be only deployed in a datacenter environmen= t where the endpoints and the switching fabric are under a single administrative domain. This protocol is not meant for uncontrolled deployment in the global Internet. * Section 2+3: This is an informative document so RFC 2119 should be used w= ith care, if at all. My impression is that at least some use of RFC 2119 la= nguage could be avoided. Examples: Section 3.1: "Therefore, sender and receiver MUST NOT assume that a par= ticular marking algorithm is implemented by the switching fabric." =3D> I think an implementation of DCTCP inherently follows this and thi= s does not require RFC 2119 statements. Section 3.3: "The congestion estimator on the sender MUST process accep= table ACKs as follows:" =3D> This is a sender-side algorithm that relies on internal TCP state = variables. I am not sure if an implementation really has to implement the a= lgorithm exactly in this way or if slight variations could yield the same r= esult. A "MUST" on the exact algorithm seems a bit restrictive in that case= . =20 (... possibly more ...) * Section 4: This section discusses both discusses implementation issues fo= r DCTCP as well as further TCP tuning that may be used in combination with = DCTCP (lower MinRTO, cwnd idle, ...) but that is not tightly related to the= actual DCTCP protocol mechanisms. Also, partly related to this, Section 4 = is a relatively long text without subsections. I think that Section 4 could= be better structured, e.g., by adding two or three subsection distinguishi= ng DCTCP implementation from other (related) implementation guidance. The a= ctual content may not require rewording, except possibly some reordering of= paragraphs. * Section 5: I am not sure if the following comment on UDP is compatible wi= th draft-ietf-tsvwg-rfc5405bis-12: If the datacenter traffic consists of such traffic (including UDP), one possible mitigation would be to mark IP packets as ECT even when there is no transport that is reacting to the marking. Also, I don't fully understand the contect, e.g., what marking/drop profi= les are here referred to. Maybe some additional explanation could help. As = far as I know, this can be quite device-specific, e.g., many routers would = allow separate queues for non-TCP/non-IP traffic. In any case, the handling= of UDP seems to me rather unrelated to DCTCP, right? If this is considered= useful information for potential implementers, Section 5 should also be be= tter structured into DCTCP deployment issues and other related deployment e= xperiences in environments running DCTCP. Thanks Michael From nobody Mon May 9 12:14:27 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AD612B051 for ; Mon, 9 May 2016 12:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 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, RP_MATCHES_RCVD=-0.996, 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 9MmrObZeFv9M for ; Mon, 9 May 2016 12:14:24 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639DA12D649 for ; Mon, 9 May 2016 12:12:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,601,1455004800"; d="asc'?scan'208";a="110046421" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 09 May 2016 12:12:22 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 9 May 2016 12:12:21 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::7db0:a96:265e:db5e%21]) with mapi id 15.00.1156.000; Mon, 9 May 2016 12:12:21 -0700 From: "Eggert, Lars" To: "Scharf, Michael (Nokia - DE)" Thread-Topic: [tcpm] Some comments on draft-ietf-tcpm-dctcp Thread-Index: AdGqICCR7wWRxmfCSkO9/HVPCvvFdAAQUAMA Date: Mon, 9 May 2016 19:12:21 +0000 Message-ID: <2E9440F5-8847-4A60-A608-64FDDAD643FD@netapp.com> References: <655C07320163294895BBADA28372AF5D4883C106@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D4883C106@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_DC8F2D77-84C8-40AB-8DB9-0714669636F6"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" , "draft-ietf-tcpm-dctcp@tools.ietf.org" Subject: Re: [tcpm] Some comments on draft-ietf-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 19:14:25 -0000 --Apple-Mail=_DC8F2D77-84C8-40AB-8DB9-0714669636F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, on this particular point, a comment: On 2016-05-09, at 20:25, Scharf, Michael (Nokia - DE) = wrote: > * Section 2+3: This is an informative document so RFC 2119 should be = used with care, if at all. My impression is that at least some use of = RFC 2119 language could be avoided. Understood, but RFC2119 terms are well-understood when specifying = protocol behavior, whether it's for standards track or other document = levels. So I'd personally like to keep them, because they bring clarity. = (Plus, I've frequently seen them even in requirements documents, etc.) Since the intent of this document is to describe exactly what the = Windows, Linux and FreeBSD implementations are doing, IMO such language = is helpful. > Examples: >=20 > Section 3.1: "Therefore, sender and receiver MUST NOT assume that a = particular marking algorithm is implemented by the switching fabric." >=20 > =3D> I think an implementation of DCTCP inherently follows this and = this does not require RFC 2119 statements. Not sure. I think it stresses that an implementation that wants to = conform to what MS, FreeBSD and Linux are doing in terms of DCTCP cannot = be cognizant of what the fabric does. (There are optimizations that are = possible in that case, but they are not DCTCP.) > Section 3.3: "The congestion estimator on the sender MUST process = acceptable ACKs as follows:" >=20 > =3D> This is a sender-side algorithm that relies on internal TCP = state variables. I am not sure if an implementation really has to = implement the algorithm exactly in this way or if slight variations = could yield the same result. A "MUST" on the exact algorithm seems a bit = restrictive in that case. But with "slight modifications" it isn't DCTCP as implemented in = Windows, Linux and FreeBSD anymore. Sure, if this was an IETF-designed = protocol we could have a discussion on whether we want to give = implementors leeway here. But if they want to implement what Windows, = Linux and FreeBSD are doing, there isn't leeway. Lars --Apple-Mail=_DC8F2D77-84C8-40AB-8DB9-0714669636F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXMOETAAoJEFS1wwm/cMFXMgsP/i0wHuocqDnOM07mpgjBvcUS /sCqm7HmmCDGA9hHWL1IC1Qyc++b98JZ7105oHBuuM5p0yy109yEMkDCc7hXWsnf eSQvvDkmZ/mwWPRy9lGuTnP3WJzh1PVrCIAL14bL9wRkZe4pcUeGtO9n5pSyI517 qYIvjpZZHnZQsJtzmVlXS3cDH12sUWldALfhlomT3wtKpnk61rNIq/qC3VAE42Rr PrBg7/zMhjnAgC+EHjzekcp6hOD01UNgc2iKvlyh9DHseigSMs2EB7L7qN3rJ+4l Y62C/eExXIrLZHfueYboKQEYwbEswcbq3aqo5PmMTSz4p3LprNltva3UFfCJNVyS nkk2EFBOfTpv147VTFk0McGREZDqVKsI0GqF/tebRS8RaykIELIMP9Ls2oHogpB7 cW/pDRFQST4blPbznQ+AgRX0sA4hU2Otcvrz6hnimdmMCE22xSxtn0V3WqnbIGK4 1XcL3MXT9cdEmUXohV3Labiug3mlHQfntz1QMBLAdDStVqUiSkSEwr1Yg5WzI2De onGP/DKD0zFZk5uLauIKyBW+vxnZVVx8kx0xLP7F/Nt9NCk1wTiIH4jz3VwMWjk3 ZdbMgTekEnVQ5b+7AqHBpmQ/zxPZ6E1pWr+1O0rb28fojMOalf+bQmuV81wTL7AU 90WrbwP5InP91lN68FRD =3p1E -----END PGP SIGNATURE----- --Apple-Mail=_DC8F2D77-84C8-40AB-8DB9-0714669636F6-- From nobody Mon May 9 13:05:17 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE4612D5E1 for ; Mon, 9 May 2016 13:05:15 -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 UZNXmTNX44-s for ; Mon, 9 May 2016 13:05:13 -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 3C5E912D60F for ; Mon, 9 May 2016 13:05:12 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A07514D04DFB5; Mon, 9 May 2016 20:05:06 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u49K562g006628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 May 2016 20:05:07 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u49K56w9018667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 May 2016 22:05:06 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 9 May 2016 22:05:05 +0200 From: "Scharf, Michael (Nokia - DE)" To: "EXT Eggert, Lars" Thread-Topic: [tcpm] Some comments on draft-ietf-tcpm-dctcp Thread-Index: AQHRqia7NldtY2QclEC5+fvnIbEjbJ+xAFWA Date: Mon, 9 May 2016 20:05:05 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4883E49C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D4883C106@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2E9440F5-8847-4A60-A608-64FDDAD643FD@netapp.com> In-Reply-To: <2E9440F5-8847-4A60-A608-64FDDAD643FD@netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" , "draft-ietf-tcpm-dctcp@tools.ietf.org" Subject: Re: [tcpm] Some comments on draft-ietf-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:05:15 -0000 > > Section 3.3: "The congestion estimator on the sender MUST process > acceptable ACKs as follows:" > > > > =3D> This is a sender-side algorithm that relies on internal TCP > state variables. I am not sure if an implementation really has to > implement the algorithm exactly in this way or if slight variations > could yield the same result. A "MUST" on the exact algorithm seems a > bit restrictive in that case. >=20 > But with "slight modifications" it isn't DCTCP as implemented in > Windows, Linux and FreeBSD anymore. Sure, if this was an IETF-designed > protocol we could have a discussion on whether we want to give > implementors leeway here. But if they want to implement what Windows, > Linux and FreeBSD are doing, there isn't leeway. Well, I don't know about Windows and FreeBSD and in general I have not look= ed at Linux TCP for quite some time. But since you mention that this is exactly what Linux does, let's check... >From https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/n= et/ipv4/tcp_dctcp.c?id=3Drefs/tags/v4.6-rc7 static void dctcp_update_alpha(struct sock *sk, u32 flags) { const struct tcp_sock *tp =3D tcp_sk(sk); struct dctcp *ca =3D inet_csk_ca(sk); u32 acked_bytes =3D tp->snd_una - ca->prior_snd_una; /* If ack did not advance snd_una, count dupack as MSS size. * If ack did update window, do not count it at all. */ if (acked_bytes =3D=3D 0 && !(flags & CA_ACK_WIN_UPDATE)) acked_bytes =3D inet_csk(sk)->icsk_ack.rcv_mss; if (acked_bytes) { ca->acked_bytes_total +=3D acked_bytes; ca->prior_snd_una =3D tp->snd_una; if (flags & CA_ACK_ECE) ca->acked_bytes_ecn +=3D acked_bytes; } ... So, formally, Linux violates the MUST, as far as I can see, since the two "= if" statements are not foreseen in the specification, as far as I can see. I personally believe that this sort of deviation makes sense, but at first = sight I fail to see this specific algorithm in the draft and it is not what= the MUST asks for. Also, looking further at the Linux code I believe Linux does not fully impl= ement the following MUST: Rather than always halving the congestion window as described in [RFC3168], when the sender receives an indication of congestion (ECE), the sender MUST update cwnd as follows: cwnd =3D cwnd * (1 - DCTCP.Alpha / 2) In this case it seems to me that Linux adds a lower bound of 2 (MSS) not fo= reseen in the specification. This is nit-picking and this sort of algorithm changes seem to me reasonabl= e implementation choices that will not affect any interoperability. But, at= least at first sight, the Linux code does not *exactly* what the specifica= tion describes. I believe we should be careful with specifying algorithms. Note that I neither want to say that the I-D nor that the Linux implementat= ion would have to change. I am just not sure what a RFC 2119 "MUST" should = really mean for a sender-side only TCP algorithm that can be implemented in= many ways more or less resulting in the same macroscopic behavior. Michael From nobody Wed May 18 16:09:25 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBD112D52C for ; Wed, 18 May 2016 16:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.335 X-Spam-Level: *** X-Spam-Status: No, score=3.335 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335] autolearn=no 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 N0MLEeHveOqM for ; Wed, 18 May 2016 16:09:23 -0700 (PDT) Received: from vmz34mtai-tvt-spo.fly.com.br (mx.zcs8ib.jetmailx.com.br [200.170.89.34]) by ietfa.amsl.com (Postfix) with ESMTP id C13C712D7A2 for ; Wed, 18 May 2016 16:09:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vmz34mtai-tvt-spo.fly.com.br (Postfix) with ESMTP id 160D91825B9; Wed, 18 May 2016 20:09:22 -0300 (BRT) X-Virus-Scanned: amavisd-new at vmz34mtai-tvt-spo.fly.com.br Received: from vmz34mtai-tvt-spo.fly.com.br ([127.0.0.1]) by localhost (vmz34mtai-tvt-spo.fly.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpYX4W9EPEAe; Wed, 18 May 2016 20:09:09 -0300 (BRT) Received: by vmz34mtai-tvt-spo.fly.com.br (Postfix, from userid 998) id 7EBEE1825E8; Wed, 18 May 2016 20:08:11 -0300 (BRT) Received: from ensyy.com (unknown [46.143.217.145]) by vmz34mtai-tvt-spo.fly.com.br (Postfix) with ESMTPSA id 56EC21825C5; Wed, 18 May 2016 20:08:06 -0300 (BRT) From: To: "tara.ali-yahiya" , "tb" , "tccc" , "tccc" , "tccn" , "tcpm" Date: Thu, 19 May 2016 02:08:04 +0300 Message-ID: <00008da621cf$eb09056b$2c63d131$@queuefull.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_773434AB.448DB75B" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdG4KdQZo2YlZunkDC2nPQfEMnbSrg== Content-Language: en-us Archived-At: Subject: [tcpm] gorgeous X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 23:09:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_773434AB.448DB75B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, That stuff is just gorgeous, you have to read about it more at Hope this helps, bensons@queuefull.net ------=_NextPart_000_0001_773434AB.448DB75B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hello, That stuff is just gorgeous, you have to read= about it more at http://ngycathese.krisbryan.com/theater.php

 

Hope this helps, bensons= @queuefull.net

------=_NextPart_000_0001_773434AB.448DB75B-- From nobody Thu May 19 11:33:45 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132B512DBB5; Thu, 19 May 2016 11:33:11 -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 r0v5msBloBe8; Thu, 19 May 2016 11:33: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 A89A212DB99; Thu, 19 May 2016 11:29:40 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:39946 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b3ShW-0005G6-JJ; Thu, 19 May 2016 19:29:38 +0100 To: tsv-area IETF list , AQM IETF list , tcpm IETF list , tsvwg IETF list , "rmcat@ietf.org" From: Bob Briscoe Message-ID: <573E0611.5070803@bobbriscoe.net> Date: Thu, 19 May 2016 19:29:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070606010507000205050305" 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: TCP Prague List Subject: [tcpm] L4S/DualQ BoF-forming on tcpprague list: pls air your concerns X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 18:33:11 -0000 This is a multi-part message in MIME format. --------------070606010507000205050305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Multiple IETF Transport mailing lists. This is to announce that discussions are proceeding on the tcpprague@ietf.org list [see archive ] about organising a BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the IETF-96 Berlin timeframe. The proposed L4S BoF will be about the full implications of L4S - on ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is not just about so-called "TCP Prague" and its implications solely on TCP. If you reply to this announcement, please cut all the mailing lists from the distr except tcpprague. Anyone who is sceptical of the L4S approach, or its safety for the public Internet, please air your concerns. Ideally now on the tcpprague list, but certainly at or preferably before the proposed BoF in Berlin. If you prefer to air your concerns on your favourite WG mailing list, pls at least ensure the tcpprague list is aware. You may know L4S as the DualQ Coupled AQM. Background info on L4S including I-Ds, code, videos, etc. can be found here: https://riteproject.eu/dctth/ Cheers Bob > > -------- Forwarded Message -------- > Subject: Volunteers pls: L4S non-WG-forming BoF proposal cut-off > approaching > Date: Wed, 18 May 2016 12:47:26 +0100 > From: Bob Briscoe > To: TCP Prague List > > > > Folks, > > At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in > Buenos Aires, there was support for a BoF about L4S, In the IETF-96 > (Berlin) time-frame. > It was decided to initially use this ML, even tho the scope of L4S is > wider than TCP Prague. > Consensus was to aim for a non-WG-forming BoF, to demonstrate > willingness to work on the pieces in existing IETF WGs, and to > co-ordinate approaches to each WG. > > The cut-off is now 2.5 weeks away. > *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area > Directors at UTC 23:59. > > To organise a successful BoF (referring to rfc5434 > ), we need volunteers for the > following tasks: > #/ Draft a statement of problem & scope > #/ List planned deliverables (incl. implementation, spec drafting), > milestones and target WG (also identify any critical interdependencies) > #/ Identify and draft any necessary changes to WG charters, to cover > the above deliverables > #/ Discuss with relevant WG chairs and ADs [see background below] > #/ Identify volunteers (pref before the BoF) planning to work on each > deliverable > > Some people have already volunteered in general to help with arranging > the BoF, but we now need to get specific. > > Let's get volunteers for the above priority tasks first, but for > completeness I'll also list the formalities we have to do: > #/ Decide on name of BoF (and mailing list) > #/ BoF facilitators - chairs, scribes, etc > #/ Draft the BoF agenda, incl. time constraints > #/ Decide on the BoF questions > #/ Estimate attendance, list conflicts, decide duration > #/ Submit a formal request for the BoF via > http://www.ietf.org/instructions/MTG-SLOTS.html and > http://www.ietf.org/ietf/1bof-procedures.txt > > I'll start off co-ordinating and chasing all the above, but contact me > if you would like to take on the co-ordinating task. > > *Background work so far** > * > The idea of this BoF has been floated with WG chairs and ADs for some > time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked > with the RMCAT chairs. > Also we have already done considerable work on defining the problem > while writing various drafts and papers about L4S. > > But, that was just a small group of co-authors (me, Koen, Inton, > Olga). There's still a lot to do to build wider consensus. > We can go ahead with a BoF scheduling request even if disagreements on > scope/problem remain. > But before the BoF itself, we need to have any such disagreements > ironed out. > > At the Buenos Aires Bar Bof, we put up a todo list of pieces that will > need to be worked on: > See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf > particularly slides 9 & 10 > and the target WGs for each were: > * TSVWG (the L4S identifier) > * AQM (the AQM - the name gives the clue ;) > * TCPM (the DCTCP-like congestion control, covering SCTP) > * RMCAT (L4S variants of real-time congestion controls, or at least > standardise existing controls using the identifier) > > I believe, formally, each WG has to decide to charter additional work > on its own ML. > > [Since then, Ingemar has pointed out on this list that we also need to > get AQM & ECN-marking in radio networks, and that will require working > with/through other SDOs and/or developer groups that deal with the MAC > layer . > V. important, but let's push that to a separate thread.] > > Many of the pieces have their own rationale, independent of L4S. The > idea of the BoF is to draw the bigger picture that motivates the work. > That doesn't preclude incremental work on the pieces for those who are > not motivated by a big picture. > > Cheers > > > > Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------070606010507000205050305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Multiple IETF Transport mailing lists.

This is to announce that discussions are proceeding on the tcpprague@ietf.org list [see archive] about organising a BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the IETF-96 Berlin timeframe.
The proposed L4S BoF will be about the full implications of L4S - on ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is not just about so-called "TCP Prague" and its implications solely on TCP.

If you reply to this announcement, please cut all the mailing lists from the distr except tcpprague.

Anyone who is sceptical of the L4S approach, or its safety for the public Internet, please air your concerns. Ideally now on the tcpprague list, but certainly at or preferably before the proposed BoF in Berlin.
If you prefer to air your concerns on your favourite WG mailing list, pls at least ensure the tcpprague list is aware.

You may know L4S as the DualQ Coupled AQM. Background info on L4S including I-Ds, code, videos, etc. can be found here:
https://riteproject.eu/dctth/

Cheers




Bob


-------- Forwarded Message --------
Subject: Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching
Date: Wed, 18 May 2016 12:47:26 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: TCP Prague List <tcpPrague@ietf.org>


Folks,

At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) time-frame.
It was decided to initially use this ML, even tho the scope of L4S is wider than TCP Prague.
Consensus was to aim for a non-WG-forming BoF, to demonstrate willingness to work on the pieces in existing IETF WGs, and to co-ordinate approaches to each WG.

The cut-off is now 2.5 weeks away.
*2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area Directors at UTC 23:59.

To organise a successful BoF (referring to rfc5434), we need volunteers for the following tasks:
#/ Draft a statement of problem & scope
#/ List planned deliverables (incl. implementation, spec drafting), milestones and target WG (also identify any critical interdependencies)
#/ Identify and draft any necessary changes to WG charters, to cover the above deliverables
#/ Discuss with relevant WG chairs and ADs [see background below]
#/ Identify volunteers (pref before the BoF) planning to work on each deliverable

Some people have already volunteered in general to help with arranging the BoF, but we now need to get specific.

Let's get volunteers for the above priority tasks first, but for completeness I'll also list the formalities we have to do:
#/ Decide on name of BoF (and mailing list)
#/ BoF facilitators - chairs, scribes, etc
#/ Draft the BoF agenda, incl. time constraints
#/ Decide on the BoF questions
#/ Estimate attendance, list conflicts, decide duration
#/ Submit a formal request for the BoF via
     http://www.ietf.org/instructions/MTG-SLOTS.html and
     http://www.ietf.org/ietf/1bof-procedures.txt

I'll start off co-ordinating and chasing all the above, but contact me if you would like to take on the co-ordinating task.

Background work so far

The idea of this BoF has been floated with WG chairs and ADs for some time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked with the RMCAT chairs.
Also we have already done considerable work on defining the problem while writing various drafts and papers about L4S.

But, that was just a small group of co-authors (me, Koen, Inton, Olga). There's still a lot to do to build wider consensus.
We can go ahead with a BoF scheduling request even if disagreements on scope/problem remain.
But before the BoF itself, we need to have any such disagreements ironed out.

At the Buenos Aires Bar Bof, we put up a todo list of pieces that will need to be worked on:
See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf particularly slides 9 & 10
and the target WGs for each were:
* TSVWG (the L4S identifier)
* AQM (the AQM - the name gives the clue ;)
* TCPM (the DCTCP-like congestion control, covering SCTP)
* RMCAT (L4S variants of real-time congestion controls, or at least standardise existing controls using the identifier)

I believe, formally, each WG has to decide to charter additional work on its own ML.

[Since then, Ingemar has pointed out on this list that we also need to get AQM & ECN-marking in radio networks, and that will require working with/through other SDOs and/or developer groups that deal with the MAC layer .
V. important, but let's push that to a separate thread.]

Many of the pieces have their own rationale, independent of L4S. The idea of the BoF is to draw the bigger picture that motivates the work.
That doesn't preclude incremental work on the pieces for those who are not motivated by a big picture.

Cheers



Bob




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------070606010507000205050305-- From nobody Wed May 25 03:55:50 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4291812B01D; Wed, 25 May 2016 03:55:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160525105548.18257.64842.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 03:55:48 -0700 Archived-At: Cc: tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org Subject: [tcpm] tcpm - Update to a Meeting Session Request for IETF 96 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 10:55:48 -0000 An update to a meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: tsvwg tsvarea taps mptcp tcpinc httpbis iccrg maprg accord Second Priority: rmcat rtcweb aqm dclcrg Third Priority: ippm teas Special Requests: Further conflicts: spud/plus BoF, quic BoF (if approved) --------------------------------------------------------- From nobody Tue May 31 05:53:11 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6B12D785 for ; Tue, 31 May 2016 05:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 PAYJxd-_OOPk for ; Tue, 31 May 2016 05:53:07 -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 450A012D77E for ; Tue, 31 May 2016 05:53:07 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b7jAP-00026I-1u for tcpm@ietf.org; Tue, 31 May 2016 14:53:05 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b7jAO-0007Yq-F0 for tcpm@ietf.org; Tue, 31 May 2016 14:53:05 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2016 14:53:04 +0200 References: <20160531124239.18741.45638.idtracker@ietfa.amsl.com> To: tcpm IETF list Message-Id: <6DD38B35-4E61-4AAF-A06F-36CA05F28126@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 5 sum rcpts/h 8 sum msgs/h 5 total rcpts 42382 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.646, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5F7002C080534CE5B6ADE995CA9B5231CBF013F2 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 10174 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-khademi-tcpm-alternativebackoff-ecn-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 12:53:10 -0000 Dear all, Following my presentation to, and the related discussion in TSVWG in BA: https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf we have split the ABE draft ( draft-khademi-alternativebackoff-ecn ) = into two documents: 1) a document that only makes the necessary update to RFC3168 to allow a = reaction to ECN that differs from the reaction to loss: This is draft-khademi-tsvwg-ecn-response, which I just posted. 2) a document that only contains the concrete change to TCP that we = suggest (the new multiplication factor): This is draft-khademi-tcpm-alternativebackoff-ecn, with details below. Please read and discuss item 2 here in TCPM - thanks!! :) Cheers, Michael (on behalf of the ABE authors) > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-khademi-tcpm-alternativebackoff-ecn-00.txt > Date: 31 May 2016 14:42:39 CEST > To: Gorry Fairhurst , Grenville Armitage = , Naeem Khademi , Godred = Fairhurst , Michael Welzl > Resent-From: >=20 >=20 > A new version of I-D, draft-khademi-tcpm-alternativebackoff-ecn-00.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-khademi-tcpm-alternativebackoff-ecn > Revision: 00 > Title: TCP Alternative Backoff with ECN (ABE) > Document date: 2016-05-31 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-khademi-tcpm-alternativebackoff= -ecn-00.txt > Status: = https://datatracker.ietf.org/doc/draft-khademi-tcpm-alternativebackoff-ecn= / > Htmlized: = https://tools.ietf.org/html/draft-khademi-tcpm-alternativebackoff-ecn-00 >=20 >=20 > Abstract: > This memo updates the TCP sender-side reaction to a congestion > notification received via Explicit Congestion Notification (ECN). > The updated method reduces FlightSize in Congestion Avoidance by a > smaller amount than the TCP reaction to loss. The intention is to > achieve good throughput when the queue at the bottleneck is smaller > than the bandwidth-delay-product of the connection. This is more > likely when an Active Queue Management (AQM) mechanism has used ECN > to CE-mark a packet, than when a packet was lost. Future versions = of > this document will also describe a corresponding method for SCTP. >=20 >=20 >=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 > The IETF Secretariat >=20 From nobody Tue May 31 13:34:48 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F212D653; Tue, 31 May 2016 13:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 BXLNRbz85I5P; Tue, 31 May 2016 13:34:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9D112D640; Tue, 31 May 2016 13:34:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 826C1C9420; Tue, 31 May 2016 16:34:36 -0400 (EDT) Date: Tue, 31 May 2016 16:34:36 -0400 From: John Leslie To: Michael Welzl Message-ID: <20160531203436.GB95392@verdi> References: <20160531124239.18741.45638.idtracker@ietfa.amsl.com> <6DD38B35-4E61-4AAF-A06F-36CA05F28126@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DD38B35-4E61-4AAF-A06F-36CA05F28126@ifi.uio.no> User-Agent: Mutt/1.4.1i Archived-At: Cc: tcpm IETF list , tsvwg@ietf.org Subject: Re: [tcpm] Fwd: New Version Notification for draft-khademi-tcpm-alternativebackoff-ecn-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:34:44 -0000 Michael Welzl wrote: > > Following my presentation to, and the related discussion in TSVWG in BA: > https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf > we have split the ABE draft ( draft-khademi-alternativebackoff-ecn ) > into two documents: > > 1) a document that only makes the necessary update to RFC3168 to allow a > reaction to ECN that differs from the reaction to loss: > This is draft-khademi-tsvwg-ecn-response, which I just posted. Three cheers!!! > 2) a document that only contains the concrete change to TCP that we > suggest (the new multiplication factor): > This is draft-khademi-tcpm-alternativebackoff-ecn, with details below. > > Please read and discuss item 2 here in TCPM - thanks!! :) You don't specify where to discuss item 1). IMHO, the actual reduction of sending-rate _must_ be Experimental (as it is); this implies that some other mechanism _might_ prove better. Thus, I would prefer that alternativebackoff-ecn not limit us to the scheme in ecn-response. There are various ways to manage this: I won't advocate strongly for any particular one yet (but I can certainly propose one or two if somebody questions whether it is "possible" to separate these). __ John Leslie From nobody Tue May 31 15:01:23 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C8A12B049; Tue, 31 May 2016 15:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 yg4UHxZfy_Nm; Tue, 31 May 2016 15:01:16 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 5DE7112B01B; Tue, 31 May 2016 15:01:16 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b7ris-0006P1-M7; Wed, 01 Jun 2016 00:01:14 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.100]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b7ris-0002Ym-3O; Wed, 01 Jun 2016 00:01:14 +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: <20160531203436.GB95392@verdi> Date: Wed, 1 Jun 2016 00:01:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03FC4BCE-5951-4F40-A7D9-84CCBB3C586D@ifi.uio.no> References: <20160531124239.18741.45638.idtracker@ietfa.amsl.com> <6DD38B35-4E61-4AAF-A06F-36CA05F28126@ifi.uio.no> <20160531203436.GB95392@verdi> To: John Leslie X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 4 total rcpts 42411 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 07C02D3DB756A7C8B6C40A554DBAABF889900EE1 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1169 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm IETF list , tsvwg@ietf.org Subject: Re: [tcpm] New Version Notification for draft-khademi-tcpm-alternativebackoff-ecn-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 22:01:19 -0000 > On 31. mai 2016, at 22.34, John Leslie wrote: >=20 > Michael Welzl wrote: >>=20 >> Following my presentation to, and the related discussion in TSVWG in = BA: >> https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf >> we have split the ABE draft ( draft-khademi-alternativebackoff-ecn ) >> into two documents: >>=20 >> 1) a document that only makes the necessary update to RFC3168 to = allow a >> reaction to ECN that differs from the reaction to loss: >> This is draft-khademi-tsvwg-ecn-response, which I just posted. >=20 > Three cheers!!! >=20 >> 2) a document that only contains the concrete change to TCP that we >> suggest (the new multiplication factor): >> This is draft-khademi-tcpm-alternativebackoff-ecn, with details = below. >>=20 >> Please read and discuss item 2 here in TCPM - thanks!! :) >=20 > You don't specify where to discuss item 1). Sorry - I did, but only in the corresponding email that went to TSVWG = only. =3D> TSVWG is the place for that. > IMHO, the actual reduction of sending-rate _must_ be Experimental > (as it is); this implies that some other mechanism _might_ prove = better. >=20 > Thus, I would prefer that alternativebackoff-ecn not limit us to the > scheme in ecn-response. You mean the other way round, right? If so, then that=E2=80=99s how it = is - draft-khademi-tsvwg-ecn-response just mentions = draft-khademi-tcpm-alternativebackoff-ecn as one example. > There are various ways to manage this: I won't advocate strongly for > any particular one yet (but I can certainly propose one or two if = somebody > questions whether it is "possible" to separate these). I=E2=80=99m not sure I get what you mean but I believe this is probably = already in line with what you wish=E2=80=A6 Cheers, Michael