From nobody Fri Jan 9 00:21:22 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE041A86F5 for ; Fri, 9 Jan 2015 00:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 gXtylNhdXpdv for ; Fri, 9 Jan 2015 00:21:18 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5641A86F0 for ; Fri, 9 Jan 2015 00:21:17 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-14-54af8f7b21c4 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.BE.04076.B7F8FA45; Fri, 9 Jan 2015 09:21:16 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.13]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 09:21:15 +0100 From: Ingemar Johansson S To: "tcpm@ietf.org" Thread-Topic: TCP RACK implementation status Thread-Index: AdAr5K/R08F/kj9aRmeWafvPjgPmdA== Date: Fri, 9 Jan 2015 08:21:14 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA32057971@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA32057971ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW5N//oQg4OzmSy2nZzP5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN4td1kKnjhUHHz1m7mB8ad1FyMHh4SAicSzZ1xdjJxAppjE hXvr2boYuTiEBI4wSsz/t40ZwlnEKLHr+QFWkCo2ARuJlYe+M4LYIgLKEqvvfwCzhQXUJZav ncUKEdeRuDbhLDvIAhEBPYkFs5NBwiwCKhLN/bOZQGxeAV+JA31fwFoZBWQl7n+/xwJiMwuI S9x6Mp8J4iABiSV7zjND2KISLx//Y4WwFSWuTl/OBFGfL7FyVRcrxExBiZMzn7BMYBSahWTU LCRls5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYyixanFxbnpRkZ6qUWZycXF +Xl6eaklmxiBEXFwy2+rHYwHnzseYhTgYFTi4TVwWR8ixJpYVlyZe4hRmoNFSZz3tjBQSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OR1aoHLW1sHKFma5NbVp4qqml9oLqV/cjdPPY/n5Q3 Zs8Lvdi1b+mOjHfhd88HMcQrMsp4ZUyOs545rVGK26XlgJKmb8GrTdz3lF8VZWkJro68/1r0 Y2hJqmlHitNec3Fr8YP7dgZP/HogxnBVyL5bazvz2r5d9BW5vW2fa/bD/8rZ6tOiTiuxFGck GmoxFxUnAgB4UYjFaQIAAA== Archived-At: Subject: [tcpm] TCP RACK implementation status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 09 Jan 2015 08:21:21 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA32057971ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Is TCP RACK implemented in e.g. the latest Linux TCP kernel ?. Are there plans to do this or is more research needed ? /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "The Earth is a very small stage in a vast cosmic arena" Carl Sagan "Pale Blue Dot" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA32057971ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Is TCP RACK implemented in e.g.= the latest Linux TCP kernel ?.

Are there plans to do this or i= s more research needed ?

 

/Ingemar

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

Ingemar Johansson  M.Sc.

Senior Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com= =

www.ericsson.com

 

“The Earth is a very small stage in a

 vast cosmic arena”<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Arial"= ,"sans-serif";color:black;mso-fareast-language:SV">
Carl Sagan “= Pale Blue Dot”
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA32057971ESESSMB205erics_-- From nobody Fri Jan 9 10:11:21 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DB71A87E4 for ; Fri, 9 Jan 2015 10:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 gJczR6vHk4M8 for ; Fri, 9 Jan 2015 10:11:18 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFA81A2119 for ; Fri, 9 Jan 2015 10:11:17 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id z20so2891552igj.4 for ; Fri, 09 Jan 2015 10:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cac5sb0ndNHNZbSrIUrWaWCD2VLJpcySctzBzjauW1k=; b=J2AItvl771hW0Di4gPoUoM7LiH+iQOUvY4dWAz0nlf719GuvDYMk74MqiZWGMzQNGu Vb69Lag0CsWXGke37As2pSBKLVEV1WFzp7G1hEH307yt/+k5erR+Ojwii67CVNSfJRw2 ACtI+PC1ZiE7k24UWVC2i8lFNjQyQV1/JS3fZCJbV3s8JI5j667HtWHoQUo/SZ1zldRy qw3Iw1F2XP8YjSN9jmUZZojz1vuabByr4cIkUpOZSl+wwTjo4iw+QjS6UQCYFu9bRJc9 BWd2CI4NxqzbUxBNO1ohdQ4dDi/F9Nu8Rgfnwq0qRYQslggVwESHINl5IQKdGL1VGH34 3Tiw== 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:content-type; bh=cac5sb0ndNHNZbSrIUrWaWCD2VLJpcySctzBzjauW1k=; b=mbzlTS7OACg7v0iYoKmTaMwKYNdezYBVLVvVHvQrN/1/h/HaBGPqiEcU9q27AvNFxC CoWfzdzw7G9718dTtLBuas2W7fjWvoBCf1mqxLUSJL+ZvjdS9XIqwisnj9BbMqkL+TQh vXTfT64mfP8/JhTkpePa5DLKBxGt08jxKQMCUIK5Qxz9s1HgqAs+nXSAKaqAN/sn/1UE GwKRdyVoYOhgAOqovi93ss/xtltxKe6CJqpFNd2990RTsZf2itBmhApUanN6xmCqOnLt LAhdNG6ynXEB9IGnfSiiJXGI1JXxMHtBxYpmmbqjQMmsYBr3/B4yftBE9ShgVLmM3jmD niOg== X-Gm-Message-State: ALoCoQnItUcQkm0XGLhrmyvBjXV7CTpqYa2zli/HGjuTE+Z2zl3RRlXhqJ5Xp7K+VqVYckRL3E7A X-Received: by 10.107.12.10 with SMTP id w10mr16482682ioi.71.1420827076820; Fri, 09 Jan 2015 10:11:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.62.49 with HTTP; Fri, 9 Jan 2015 10:10:36 -0800 (PST) In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA32057971@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA32057971@ESESSMB205.ericsson.se> From: Yuchung Cheng Date: Fri, 9 Jan 2015 10:10:36 -0800 Message-ID: To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=001a113ed6f233d91e050c3c15cd Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP RACK implementation status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 09 Jan 2015 18:11:19 -0000 --001a113ed6f233d91e050c3c15cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 9, 2015 at 12:21 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > Is TCP RACK implemented in e.g. the latest Linux TCP kernel ?. > > Are there plans to do this or is more research needed ? > It is not in Linux (yet). We are still doing research and testing our implementations on Google servers. > > /Ingemar > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Senior Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > =E2=80=9CThe Earth is a very small stage in a > > vast cosmic arena=E2=80=9D > Carl Sagan =E2=80=9CPale Blue Dot=E2=80=9D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a113ed6f233d91e050c3c15cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 9, 2015 at 12:21 AM, Ingemar Johansson S = <i= ngemar.s.johansson@ericsson.com> wrote:

Hi

=C2=A0

Is TCP RACK implemented in e.g.= the latest Linux TCP kernel ?.

Are there plans to do this or i= s more research needed ?

It is not = in Linux (yet). We are still doing research and testing our implementations= on Google servers.

=C2=A0

/Ingemar

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

Ingemar Johansson=C2=A0 M.Sc.

Senior Researcher

=C2=A0

Ericsson AB

Wireless Access Networks

Labratoriegr=C3=A4nd 11

971 28, Lule=C3=A5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

=C2=A0

=E2=80=9CThe Earth is a very small stage in a

=C2=A0vast cosmic arena=E2=80=9D
Carl Sagan =E2=80=9CPale Blue Dot=E2=80=9D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm


--001a113ed6f233d91e050c3c15cd-- From nobody Wed Jan 21 07:58:13 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C151A1AE7 for ; Wed, 21 Jan 2015 07:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 REzLhDjVGlTn for ; Wed, 21 Jan 2015 07:58:06 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F571A1AE3 for ; Wed, 21 Jan 2015 07:58:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,442,1418112000"; d="asc'?scan'208";a="15074231" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx142-out.netapp.com with ESMTP; 21 Jan 2015 07:53:02 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 21 Jan 2015 07:53:01 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d8c:be2b:9e16:f915%21]) with mapi id 15.00.0995.031; Wed, 21 Jan 2015 07:53:01 -0800 From: "Eggert, Lars" To: "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-bensley-tcpm-dctcp-02.txt Thread-Index: AQHQNZH1uSwZrtqC60+yRPESjS6AhA== Date: Wed, 21 Jan 2015 15:53:01 +0000 Message-ID: <1270E165-3D14-4B14-8EA8-EE8C77571F2D@netapp.com> References: <20150121154952.7049.62632.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.1) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_0AF9BF8C-9668-470A-94D2-481AECD7860A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-bensley-tcpm-dctcp-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jan 2015 15:58:09 -0000 --Apple-Mail=_0AF9BF8C-9668-470A-94D2-481AECD7860A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This revision includes pointers to the Linux and FreeBSD = implementations, which are believed to also follow this spec. Begin forwarded message: >=20 > From: > To: Lars Eggert , Dave Thaler = , "Lars Eggert" , Dave Thaler = , "sbens@microsoft.com" , = Stephen Bensley > Subject: New Version Notification for draft-bensley-tcpm-dctcp-02.txt > Date: January 21, 2015 at 16:49:52 GMT+1 >=20 >=20 > A new version of I-D, draft-bensley-tcpm-dctcp-02.txt > has been successfully submitted by Lars Eggert and posted to the > IETF repository. >=20 > Name: draft-bensley-tcpm-dctcp > Revision: 02 > Title: Microsoft's Datacenter TCP (DCTCP): TCP = Congestion Control for Datacenters > Document date: 2015-01-21 > Group: Individual Submission > Pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-bensley-tcpm-dctcp-02.txt > Status: = https://datatracker.ietf.org/doc/draft-bensley-tcpm-dctcp/ > Htmlized: http://tools.ietf.org/html/draft-bensley-tcpm-dctcp-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bensley-tcpm-dctcp-02 >=20 > Abstract: > This memo describes Datacenter TCP (DCTCP), an improvement to TCP > congestion control for datacenter traffic, as implemented in Windows > Server 2012. DCTCP enhances Explicit Congestion Notification (ECN) > processing to estimate the fraction of bytes that encounter > congestion, rather than simply detecting that some congestion has > occurred. DCTCP then scales the TCP congestion window based on this > estimate. This method achieves high burst tolerance, low latency, > and high throughput with shallow-buffered switches. >=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 --Apple-Mail=_0AF9BF8C-9668-470A-94D2-481AECD7860A 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----- iQCVAwUBVL/LXdZcnpRveo1xAQJhgQP6A098aGrcUwKs+EcBeIW1j+P4ctpf9nn4 sQt6MkzXy36oCyu4wcehtkOLp7TA5GNeiJ77PVmgsDZW1mFyMVJ14qRRwwEiyZEG Xpg9z0j+mauM80Gx9DQMNqtdMhnyJVxLnIXkihEswlz68ki6ksrwkXmiEorX7ePQ reozKv8G5tc= =BVEZ -----END PGP SIGNATURE----- --Apple-Mail=_0AF9BF8C-9668-470A-94D2-481AECD7860A-- From nobody Fri Jan 23 08:01:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AEC1A00A8 for ; Thu, 22 Jan 2015 15:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.512 X-Spam-Level: X-Spam-Status: No, score=-105.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 S_ySKWxBGuD5 for ; Thu, 22 Jan 2015 15:22:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0C91A0076 for ; Thu, 22 Jan 2015 15:22:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 202691832BB; Thu, 22 Jan 2015 15:22:28 -0800 (PST) To: ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, michael.scharf@alcatel-lucent.com, nishida@sfc.wide.ad.jp, pasi.sarolahti@iki.fi X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150122232228.202691832BB@rfc-editor.org> Date: Thu, 22 Jan 2015 15:22:28 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 23 Jan 2015 08:01:22 -0800 Cc: mjl@caida.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Technical Errata Reported] RFC7413 (4238) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2015 23:22:53 -0000 The following errata report has been submitted for RFC7413, "TCP Fast Open". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7413&eid=4238 -------------------------------------- Type: Technical Reported by: Matthew Luckie Section: 4.1.1 Original Text ------------- Kind 1 byte: value = 34 Length 1 byte: range 6 to 18 (bytes); limited by remaining space in the options field. The number MUST be even. Cookie 0, or 4 to 16 bytes (Length - 2) Corrected Text -------------- Kind 1 byte: value = 34 Length 1 byte: range 2 to 18 (bytes); limited by remaining space in the options field. The number MUST be even. Cookie 0, or 4 to 16 bytes in length (Length - 2) Notes ----- A Nil cookie is a fast open option with no cookie value. A length range of 6 to 18 bytes excludes a Nil cookie. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7413 (draft-ietf-tcpm-fastopen-10) -------------------------------------- Title : TCP Fast Open Publication Date : December 2014 Author(s) : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Category : EXPERIMENTAL Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Fri Jan 23 08:01:27 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532051A891B for ; Thu, 22 Jan 2015 15:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 FyIHt8cKjmT3 for ; Thu, 22 Jan 2015 15:24:44 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 28F7A1A891A for ; Thu, 22 Jan 2015 15:24:44 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 282F5187A98; Thu, 22 Jan 2015 15:24:20 -0800 (PST) To: ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, michael.scharf@alcatel-lucent.com, nishida@sfc.wide.ad.jp, pasi.sarolahti@iki.fi X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150122232420.282F5187A98@rfc-editor.org> Date: Thu, 22 Jan 2015 15:24:20 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 23 Jan 2015 08:01:23 -0800 Cc: mjl@caida.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Technical Errata Reported] RFC7413 (4239) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2015 23:24:51 -0000 The following errata report has been submitted for RFC7413, "TCP Fast Open". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7413&eid=4239 -------------------------------------- Type: Technical Reported by: Matthew Luckie Section: 4.2.1 Original Text ------------- 1. The client sends a SYN packet with a Fast Open option with a Length field of 0 (empty cookie field). Corrected Text -------------- 1. The client sends a SYN packet with a Fast Open option with a Length field of 2 (empty cookie field). Notes ----- A Nil fast-open option has an option length of 2. A length field of zero would mean an invalid TCP option. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7413 (draft-ietf-tcpm-fastopen-10) -------------------------------------- Title : TCP Fast Open Publication Date : December 2014 Author(s) : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Category : EXPERIMENTAL Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Sun Jan 25 10:41:34 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A525B1A88FA for ; Fri, 23 Jan 2015 15:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mkZFjE8mhWF9 for ; Fri, 23 Jan 2015 15:51:44 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7E41A88F5 for ; Fri, 23 Jan 2015 15:51:41 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t0NNpANn016724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 Jan 2015 15:51:10 -0800 (PST) Message-ID: <54C2DE6E.2010505@isi.edu> Date: Fri, 23 Jan 2015 15:51:10 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: RFC Errata System , ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, michael.scharf@alcatel-lucent.com, nishida@sfc.wide.ad.jp, pasi.sarolahti@iki.fi References: <20150122232420.282F5187A98@rfc-editor.org> In-Reply-To: <20150122232420.282F5187A98@rfc-editor.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-Mailman-Approved-At: Sun, 25 Jan 2015 10:41:31 -0800 Cc: tcpm@ietf.org Subject: Re: [tcpm] [Technical Errata Reported] RFC7413 (4239) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 23 Jan 2015 23:51:45 -0000 Hi, all, On 1/22/2015 3:24 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC7413, > "TCP Fast Open". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7413&eid=4239 > > -------------------------------------- > Type: Technical > Reported by: Matthew Luckie > > Section: 4.2.1 > > Original Text > ------------- > 1. The client sends a SYN packet with a Fast Open option with a > Length field of 0 (empty cookie field). > > Corrected Text > -------------- > 1. The client sends a SYN packet with a Fast Open option with a > Length field of 2 (empty cookie field). > > Notes > ----- > A Nil fast-open option has an option length of 2. Agreed. > A length field of zero would mean an invalid TCP option. Disagree. The correct reason is, IMO: The Nil option has no bytes beyond the Kind and Length fields required in all TCP options, and the Length field includes the space used for Kind and Length. The interpretation of an option with a 0 length should not be discussed in the errata or future updates to this doc; it is out of scope. (AFAICT, if it were observed, the entire segment would have to be deemed invalid, not just that individual option. But that's not germane to this errata). I suggest the errata be updated accordingly. Joe From nobody Sun Jan 25 10:41:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7DA1A00DC for ; Fri, 23 Jan 2015 19:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 OXLry8vLHXNe for ; Fri, 23 Jan 2015 19:57:56 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by ietfa.amsl.com (Postfix) with ESMTP id 317141A00D1 for ; Fri, 23 Jan 2015 19:57:55 -0800 (PST) Received: from [76.167.133.166] ([76.167.133.166:16915] helo=spandex.luckie.org.nz) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 86/40-29014-04813C45; Sat, 24 Jan 2015 03:57:55 +0000 Received: from mjl by spandex.luckie.org.nz with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YErr5-0008TG-Gi; Fri, 23 Jan 2015 19:57:51 -0800 Date: Fri, 23 Jan 2015 19:57:51 -0800 From: Matthew Luckie To: Joe Touch Message-ID: <20150124035751.GA32450@spandex.luckie.org.nz> References: <20150122232420.282F5187A98@rfc-editor.org> <54C2DE6E.2010505@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <54C2DE6E.2010505@isi.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Matthew Luckie X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: X-Mailman-Approved-At: Sun, 25 Jan 2015 10:41:54 -0800 Cc: tcpm@ietf.org, arvind@google.com, mls.ietf@gmail.com, RFC Errata System Subject: Re: [tcpm] [Technical Errata Reported] RFC7413 (4239) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 24 Jan 2015 03:57:58 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Notes > > ----- > > A Nil fast-open option has an option length of 2.=20 >=20 > Agreed. >=20 > > A length field of zero would mean an invalid TCP option. >=20 > Disagree. The correct reason is, IMO: >=20 > The Nil option has no bytes beyond the Kind and Length > fields required in all TCP options, and the Length field > includes the space used for Kind and Length. >=20 > The interpretation of an option with a 0 length should not be discussed > in the errata or future updates to this doc; it is out of scope. >=20 > (AFAICT, if it were observed, the entire segment would have to be deemed > invalid, not just that individual option. But that's not germane to this > errata). I do not think that the reasoning behind this errata needs to be discussed in future updates to the RFC (I put my reasoning in the Notes field of the errata form) but I absolutely believe that a TCP option defined after RFC793 with a length of zero is an invalid option that will cause a TCP receiver to stop processing the options. https://tools.ietf.org/html/rfc793 <-- page 17 Options: variable Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option: Case 1: A single octet of option-kind. Case 2: An octet of option-kind, an octet of option-length, and the actual option-data octets. The option-length counts the two octets of option-kind and option-length as well as the option-data octets. https://tools.ietf.org/html/rfc5925 <-- page 8 (discussing a different option type, but all options post 793 are TLVs, and this RFC specifically says that the segment should be discarded. granted that it is a different TCP option) o Length: An unsigned 1-byte field indicating the length of the option in bytes, including the Kind, Length, KeyID, RNextKeyID, and MAC fields. >> The Length value MUST be greater than or equal to 4. When the Length value is less than 4, TCP MUST discard the segment. =3D=3D=3D Matthew --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlTDGDwACgkQKyuDKSEQAGCq3wCcDVjovsmruWL3wo8i0JmVyZ4J NYcAnjN2Z0u9Ka+5ggaZq2b3ytsA5DHu =lZ/u -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From nobody Sun Jan 25 10:42:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BFB1A3B9D for ; Sat, 24 Jan 2015 10:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 vB5MdUbgcE20 for ; Sat, 24 Jan 2015 10:42:45 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 80A031A1F00 for ; Sat, 24 Jan 2015 10:42:45 -0800 (PST) Received: from [76.167.133.166] ([76.167.133.166:28288] helo=spandex.luckie.org.nz) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 42/D3-08653-1A7E3C45; Sat, 24 Jan 2015 18:42:44 +0000 Received: from mjl by spandex.luckie.org.nz with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YF5fN-0006HH-3j; Sat, 24 Jan 2015 10:42:41 -0800 Date: Sat, 24 Jan 2015 10:42:41 -0800 From: Matthew Luckie To: Joe Touch Message-ID: <20150124184240.GA23985@spandex.luckie.org.nz> References: <20150122232420.282F5187A98@rfc-editor.org> <54C2DE6E.2010505@isi.edu> <20150124035751.GA32450@spandex.luckie.org.nz> <54C3D063.5000500@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <54C3D063.5000500@isi.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Matthew Luckie X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: X-Mailman-Approved-At: Sun, 25 Jan 2015 10:42:24 -0800 Cc: tcpm@ietf.org, mls.ietf@gmail.com, RFC Errata System Subject: Re: [tcpm] [Technical Errata Reported] RFC7413 (4239) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 24 Jan 2015 18:42:47 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >>>A length field of zero would mean an invalid TCP option. > >> > >>Disagree. The correct reason is, IMO: > >> > >> The Nil option has no bytes beyond the Kind and Length > >> fields required in all TCP options, and the Length field > >> includes the space used for Kind and Length. > >> > >>The interpretation of an option with a 0 length should not be discussed > >>in the errata or future updates to this doc; it is out of scope. > >> > >>(AFAICT, if it were observed, the entire segment would have to be deemed > >>invalid, not just that individual option. But that's not germane to this > >>errata). > > > >I do not think that the reasoning behind this errata needs to be > >discussed in future updates to the RFC (I put my reasoning in the > >Notes field of the errata form) but I absolutely believe that a TCP > >option defined after RFC793 with a length of zero is an invalid option > >that will cause a TCP receiver to stop processing the options. >=20 > It should be interpreted as a malformed segment, not simply stop the > processing of the options. OK. I took a more careful read of your responses and I think we are somewhat in agreement, about L<2 being malformed. But, the source of two TCP stacks (Linux tcp_parse_options() and FreeBSD tcp_doptions()) show that they just stop processing the options when they get a TLV option with a L < 2, rather than discard the segment. --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlTD550ACgkQKyuDKSEQAGA0mACfbiUwojaCQPxCbB1F/wbh+O4a faUAoKLCAHzWVrmeM0k6TX+JeJJeOr4N =p6ql -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From nobody Sun Jan 25 10:42:43 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E0E1A89C4 for ; Sat, 24 Jan 2015 09:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MQh11FgO2TiL for ; Sat, 24 Jan 2015 09:04:03 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CF51A7032 for ; Sat, 24 Jan 2015 09:04:03 -0800 (PST) Received: from [192.168.1.11] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t0OH3Wwg003115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 24 Jan 2015 09:03:35 -0800 (PST) Message-ID: <54C3D063.5000500@isi.edu> Date: Sat, 24 Jan 2015 09:03:31 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Matthew Luckie References: <20150122232420.282F5187A98@rfc-editor.org> <54C2DE6E.2010505@isi.edu> <20150124035751.GA32450@spandex.luckie.org.nz> In-Reply-To: <20150124035751.GA32450@spandex.luckie.org.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-Mailman-Approved-At: Sun, 25 Jan 2015 10:42:42 -0800 Cc: tcpm@ietf.org, arvind@google.com, mls.ietf@gmail.com, RFC Errata System Subject: Re: [tcpm] [Technical Errata Reported] RFC7413 (4239) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 24 Jan 2015 17:04:04 -0000 On 1/23/2015 7:57 PM, Matthew Luckie wrote: >>> Notes >>> ----- >>> A Nil fast-open option has an option length of 2. >> >> Agreed. >> >>> A length field of zero would mean an invalid TCP option. >> >> Disagree. The correct reason is, IMO: >> >> The Nil option has no bytes beyond the Kind and Length >> fields required in all TCP options, and the Length field >> includes the space used for Kind and Length. >> >> The interpretation of an option with a 0 length should not be discussed >> in the errata or future updates to this doc; it is out of scope. >> >> (AFAICT, if it were observed, the entire segment would have to be deemed >> invalid, not just that individual option. But that's not germane to this >> errata). > > I do not think that the reasoning behind this errata needs to be > discussed in future updates to the RFC (I put my reasoning in the > Notes field of the errata form) but I absolutely believe that a TCP > option defined after RFC793 with a length of zero is an invalid option > that will cause a TCP receiver to stop processing the options. It should be interpreted as a malformed segment, not simply stop the processing of the options. Joe From nobody Sun Jan 25 10:42:44 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C68C1A005C for ; Sat, 24 Jan 2015 12:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 O7sBTVL9QYOA for ; Sat, 24 Jan 2015 12:46:25 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB261A0037 for ; Sat, 24 Jan 2015 12:46:25 -0800 (PST) Received: from [192.168.1.11] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t0OKcOjP001060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 24 Jan 2015 12:38:33 -0800 (PST) Message-ID: <54C402C0.6050609@isi.edu> Date: Sat, 24 Jan 2015 12:38:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Matthew Luckie References: <20150122232420.282F5187A98@rfc-editor.org> <54C2DE6E.2010505@isi.edu> <20150124035751.GA32450@spandex.luckie.org.nz> <54C3D063.5000500@isi.edu> <20150124184240.GA23985@spandex.luckie.org.nz> In-Reply-To: <20150124184240.GA23985@spandex.luckie.org.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-Mailman-Approved-At: Sun, 25 Jan 2015 10:42:42 -0800 Cc: tcpm@ietf.org, mls.ietf@gmail.com, RFC Errata System Subject: Re: [tcpm] [Technical Errata Reported] RFC7413 (4239) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 24 Jan 2015 20:46:26 -0000 On 1/24/2015 10:42 AM, Matthew Luckie wrote: >>>>> A length field of zero would mean an invalid TCP option. >>>> >>>> Disagree. The correct reason is, IMO: >>>> >>>> The Nil option has no bytes beyond the Kind and Length >>>> fields required in all TCP options, and the Length field >>>> includes the space used for Kind and Length. >>>> >>>> The interpretation of an option with a 0 length should not be discussed >>>> in the errata or future updates to this doc; it is out of scope. >>>> >>>> (AFAICT, if it were observed, the entire segment would have to be deemed >>>> invalid, not just that individual option. But that's not germane to this >>>> errata). >>> >>> I do not think that the reasoning behind this errata needs to be >>> discussed in future updates to the RFC (I put my reasoning in the >>> Notes field of the errata form) but I absolutely believe that a TCP >>> option defined after RFC793 with a length of zero is an invalid option >>> that will cause a TCP receiver to stop processing the options. >> >> It should be interpreted as a malformed segment, not simply stop the >> processing of the options. > > OK. I took a more careful read of your responses and I think we are > somewhat in agreement, about L<2 being malformed. But, the source of > two TCP stacks (Linux tcp_parse_options() and FreeBSD tcp_doptions()) > show that they just stop processing the options when they get a TLV > option with a L < 2, rather than discard the segment. I think that is a mistake in both implementations. Once something nonsensical occurs in a TCP header, the segment should be discarded. Logging it (with rate limiting) would be nice too. But the rest of the message clearly should not be acted upon. Joe From nobody Mon Jan 26 06:13:56 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3323C1A8839 for ; Mon, 26 Jan 2015 06:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 LLul9jQLQOOB for ; Mon, 26 Jan 2015 06:13:52 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405511A8835 for ; Mon, 26 Jan 2015 06:13:52 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id p9so7754932lbv.4 for ; Mon, 26 Jan 2015 06:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oIkIoDQl8Fpo/H1A6BOiInLHt9TirbsFyJkIwEJ1V2Q=; b=hfzjUtfgk7ALqKt2viLv9/jWyRrWNT00PgpChX9FJoD+q0CvSR1JHi6W3J/r/a26ej zefN4yYFQ5qc90BQlgE1c/m0fSH7gQEKshtJpvgG1dZcQg7FQGbJ/C3qKOw/lM+/mrqy kIy69id9yuE+tQLWwrfAOBC/N5ZOvBAs07lVZ7sszis+wJUNbLqdvRpfFP3EIw1YicZO I708H5LvLVUO0P+ZgJBGaA+X2wUG4ZMCvzDmQo+cxii/2awSnesh/0V4UWwIpdpveLry wiuc4ZEuf4Wh9K4TmszFRNY4kGsWDXaXtAqKanANXJfTHGgQVJ3zLuAHhqmtKW53sZTN 4rbA== MIME-Version: 1.0 X-Received: by 10.112.78.39 with SMTP id y7mr21889457lbw.42.1422281630672; Mon, 26 Jan 2015 06:13:50 -0800 (PST) Received: by 10.112.173.102 with HTTP; Mon, 26 Jan 2015 06:13:50 -0800 (PST) Date: Mon, 26 Jan 2015 15:13:50 +0100 Message-ID: From: renaud sallantin To: "tcpm@ietf.org" , cedric baudoin Content-Type: multipart/mixed; boundary=001a11c3da2e5e04ba050d8ebf86 Archived-At: Subject: [tcpm] Initial Spreading patch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jan 2015 14:13:55 -0000 --001a11c3da2e5e04ba050d8ebf86 Content-Type: multipart/alternative; boundary=001a11c3da2e5e04b4050d8ebf84 --001a11c3da2e5e04b4050d8ebf84 Content-Type: text/plain; charset=UTF-8 Dear all, Following our last email, some of you asked for our Initial Spreading implementation. Attached to this email, you can find our patch tested with Linux 3.13.8. As you can see, we used a slightly modified version of the FQ scheduler developed by Eric Dumazet. We introduced two sysctl parameters to ease your tests: - tcp_initial_spreading_rate_min (integer): It corresponds to the minimal rate value computed by Initial Spreading. Considering draft-sallantin-tcpm-initial-spreading-00, tcp_initial_spreading_rate_min= MTU / T_Spreading - tcp_initial_spreading_rate_debug (boolean): When non-zero, a kernel log message will print the rate used by Initial Spreading each time a TCP connection is initialized We hope that you will be able to try Initial Spreading and that you will confirm the good results we obtained. Your comments on the patch but also on the draft are more than welcome, https://tools.ietf.org/html/draft-sallantin-tcpm-initial-spreading-00 Regards, Renaud Sallantin --001a11c3da2e5e04b4050d8ebf84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

Following our last e= mail,
some of you asked for our Initial Spreading implementation. =

Attached to this email, you can find our patch tested wi= th Linux 3.13.8.
As you can see, we used a slightly modified vers= ion of the FQ scheduler developed by Eric Dumazet.

=
We introduced two sysctl parameters to ease your tests:
- tcp_initi= al_spreading_rate_min (integer):
It corresponds to the minima= l rate value computed by Initial Spreading.
Considering draft= -sallantin-tcpm-initial-spreading-00,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tcp_initial_spreading_rate_min=3D MTU / T_Sp= reading

- tcp_initial_spreading_rate_debug (boolean):
=
When non-zero, a kernel log=C2=A0 message will print the rate used by Initial Spreading each time a TCP conne= ction is initialized


We hope that you will be able t= o try Initial Spreading and that you will confirm the good results we obtai= ned.

Your comments on the patch but also on the draft ar= e more than welcome,
https://tools.ietf.org/html/draft-sallantin-= tcpm-initial-spreading-00

Regards,
Renaud Sallantin
--001a11c3da2e5e04b4050d8ebf84-- --001a11c3da2e5e04ba050d8ebf86 Content-Type: text/x-patch; charset=US-ASCII; name="0001-implementing-initial-spreading-using-fq-sched.patch" Content-Disposition: attachment; filename="0001-implementing-initial-spreading-using-fq-sched.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i5dxqrcl0 RnJvbSA2NTFmOGMwN2JhNGZiOGUxY2NkZmFhOWNjMmViOTRiNTFjOTAyNTQ0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQ0KRnJvbTogRWxpZSBCb3V0dGllciA8ZWxpZS5ib3V0dGllckBlbnNlZWlo dC5mcj4NCkRhdGU6IFRodSwgMTEgRGVjIDIwMTQgMTk6MDI6MTcgKzAxMDANClN1YmplY3Q6IFtQ QVRDSF0gaW1wbGVtZW50aW5nIGluaXRpYWwgc3ByZWFkaW5nIHVzaW5nIGZxIHNjaGVkDQoNCi0t LQ0KIERvY3VtZW50YXRpb24vbmV0d29ya2luZy9pcC1zeXNjdGwudHh0IHwgMTMgKysrKysrKysr KysrKw0KIGluY2x1ZGUvbmV0L3RjcC5oICAgICAgICAgICAgICAgICAgICAgIHwgIDIgKysNCiBp bmNsdWRlL3VhcGkvbGludXgvc3lzY3RsLmggICAgICAgICAgICB8ICAyICsrDQogbmV0L2lwdjQv c3lzY3RsX25ldF9pcHY0LmMgICAgICAgICAgICAgfCAxNSArKysrKysrKysrKysrKysNCiBuZXQv aXB2NC90Y3BfaW5wdXQuYyAgICAgICAgICAgICAgICAgICB8IDMzICsrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrLQ0KIG5ldC9zY2hlZC9zY2hfZnEuYyAgICAgICAgICAgICAgICAgICAg IHwgIDUgKysrLS0NCiA2IGZpbGVzIGNoYW5nZWQsIDY3IGluc2VydGlvbnMoKyksIDMgZGVsZXRp b25zKC0pDQoNCmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL25ldHdvcmtpbmcvaXAtc3lzY3Rs LnR4dCBiL0RvY3VtZW50YXRpb24vbmV0d29ya2luZy9pcC1zeXNjdGwudHh0DQppbmRleCA4YTk4 NGU5Li5jYmUxYzM5IDEwMDY0NA0KLS0tIGEvRG9jdW1lbnRhdGlvbi9uZXR3b3JraW5nL2lwLXN5 c2N0bC50eHQNCisrKyBiL0RvY3VtZW50YXRpb24vbmV0d29ya2luZy9pcC1zeXNjdGwudHh0DQpA QCAtNTg4LDYgKzU4OCwxOSBAQCB0Y3BfY2hhbGxlbmdlX2Fja19saW1pdCAtIElOVEVHRVINCiAJ aW4gUkZDIDU5NjEgKEltcHJvdmluZyBUQ1AncyBSb2J1c3RuZXNzIHRvIEJsaW5kIEluLVdpbmRv dyBBdHRhY2tzKQ0KIAlEZWZhdWx0OiAxMDANCiANCit0Y3BfaW5pdGlhbF9zcHJlYWRpbmdfbWlu X3JhdGUgLSBJTlRFR0VSDQorICAgIE1pbmltYWwgcmF0ZSB2YWx1ZSBjb21wdXRlZCBieSBpbml0 aWFsIHNwcmVhZGluZyBhbGdvcml0aG0uDQorICAgIERpc2FibGVkIGlmIHNldCB0byB6ZXJvLg0K KyAgICBTZWUNCisgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhbGxhbnRp bi10Y3BtLWluaXRpYWwtc3ByZWFkaW5nLTAwLg0KKyAgICBXZSBoYXZlIHRoZSByZWxhdGlvbiBy YXRlX21pbiA9IE1UVSAvIFRfc3ByZWFkaW5nLg0KKyAgICBEZWZhdWx0OiAwDQorDQordGNwX2lu aXRpYWxfc3ByZWFkaW5nX2RlYnVnIC0gQk9PTEVBTg0KKyAgICBXaGVuIG5vbi16ZXJvLCBhIGtl cm5lbCBsb2cgbWVzc2FnZSB3aWxsIHByaW50IHRoZSByYXRlIGNvbXB1dGVkIGJ5IEluaXRpYWwN CisgICAgU3ByZWFkaW5nIGVhY2ggdGltZSBhIFRDUCBjb25uZWN0aW9uIGlzIGluaXRpYWxpemVk Lg0KKyAgICBEZWZhdWx0OiAwDQorDQogVURQIHZhcmlhYmxlczoNCiANCiB1ZHBfbWVtIC0gdmVj dG9yIG9mIDMgSU5URUdFUnM6IG1pbiwgcHJlc3N1cmUsIG1heA0KZGlmZiAtLWdpdCBhL2luY2x1 ZGUvbmV0L3RjcC5oIGIvaW5jbHVkZS9uZXQvdGNwLmgNCmluZGV4IDcwZTU1ZDIuLjY2YzYzMDUg MTAwNjQ0DQotLS0gYS9pbmNsdWRlL25ldC90Y3AuaA0KKysrIGIvaW5jbHVkZS9uZXQvdGNwLmgN CkBAIC0yODIsNiArMjgyLDggQEAgZXh0ZXJuIGludCBzeXNjdGxfdGNwX2xpbWl0X291dHB1dF9i eXRlczsNCiBleHRlcm4gaW50IHN5c2N0bF90Y3BfY2hhbGxlbmdlX2Fja19saW1pdDsNCiBleHRl cm4gdW5zaWduZWQgaW50IHN5c2N0bF90Y3Bfbm90c2VudF9sb3dhdDsNCiBleHRlcm4gaW50IHN5 c2N0bF90Y3BfbWluX3Rzb19zZWdzOw0KK2V4dGVybiBpbnQgc3lzY3RsX3RjcF9pbml0aWFsX3Nw cmVhZGluZ19yYXRlX21pbjsNCitleHRlcm4gaW50IHN5c2N0bF90Y3BfaW5pdGlhbF9zcHJlYWRp bmdfZGVidWc7DQogDQogZXh0ZXJuIGF0b21pY19sb25nX3QgdGNwX21lbW9yeV9hbGxvY2F0ZWQ7 DQogZXh0ZXJuIHN0cnVjdCBwZXJjcHVfY291bnRlciB0Y3Bfc29ja2V0c19hbGxvY2F0ZWQ7DQpk aWZmIC0tZ2l0IGEvaW5jbHVkZS91YXBpL2xpbnV4L3N5c2N0bC5oIGIvaW5jbHVkZS91YXBpL2xp bnV4L3N5c2N0bC5oDQppbmRleCA2ZDY3MjEzLi4zNTVlNzQxIDEwMDY0NA0KLS0tIGEvaW5jbHVk ZS91YXBpL2xpbnV4L3N5c2N0bC5oDQorKysgYi9pbmNsdWRlL3VhcGkvbGludXgvc3lzY3RsLmgN CkBAIC00MjUsNiArNDI1LDggQEAgZW51bQ0KIAlORVRfVENQX0FMTE9XRURfQ09OR19DT05UUk9M PTEyMywNCiAJTkVUX1RDUF9NQVhfU1NUSFJFU0g9MTI0LA0KIAlORVRfVENQX0ZSVE9fUkVTUE9O U0U9MTI1LA0KKwlORVRfVENQX0lOSVRJQUxfU1BSRUFESU5HX1JBVEVfTUlOPTEyNiwNCisJTkVU X1RDUF9JTklUSUFMX1NQUkVBRElOR19ERUJVRz0xMjcsDQogfTsNCiANCiBlbnVtIHsNCmRpZmYg LS1naXQgYS9uZXQvaXB2NC9zeXNjdGxfbmV0X2lwdjQuYyBiL25ldC9pcHY0L3N5c2N0bF9uZXRf aXB2NC5jDQppbmRleCAzZDY5ZWM4Li40NzgyN2E0IDEwMDY0NA0KLS0tIGEvbmV0L2lwdjQvc3lz Y3RsX25ldF9pcHY0LmMNCisrKyBiL25ldC9pcHY0L3N5c2N0bF9uZXRfaXB2NC5jDQpAQCAtNzMz LDYgKzczMywyMSBAQCBzdGF0aWMgc3RydWN0IGN0bF90YWJsZSBpcHY0X3RhYmxlW10gPSB7DQog CQkuZXh0cmEyCQk9ICZnc29fbWF4X3NlZ3MsDQogCX0sDQogCXsNCisJCS5wcm9jbmFtZQk9ICJ0 Y3BfaW5pdGlhbF9zcHJlYWRpbmdfcmF0ZV9taW4iLA0KKwkJLmRhdGEJCT0gJnN5c2N0bF90Y3Bf aW5pdGlhbF9zcHJlYWRpbmdfcmF0ZV9taW4sDQorCQkubWF4bGVuCQk9IHNpemVvZihpbnQpLA0K KwkJLm1vZGUJCT0gMDY0NCwNCisJCS5wcm9jX2hhbmRsZXIJPSBwcm9jX2RvaW50dmVjLA0KKwl9 LA0KKwl7DQorCQkucHJvY25hbWUJPSAidGNwX2luaXRpYWxfc3ByZWFkaW5nX2RlYnVnIiwNCisJ CS5kYXRhCQk9ICZzeXNjdGxfdGNwX2luaXRpYWxfc3ByZWFkaW5nX2RlYnVnLA0KKwkJLm1heGxl bgkJPSBzaXplb2YoaW50KSwNCisJCS5tb2RlCQk9IDA2NDQsDQorCQkucHJvY19oYW5kbGVyCT0g cHJvY19kb2ludHZlYywNCisJfSwNCisJew0KKw0KIAkJLnByb2NuYW1lCT0gInVkcF9tZW0iLA0K IAkJLmRhdGEJCT0gJnN5c2N0bF91ZHBfbWVtLA0KIAkJLm1heGxlbgkJPSBzaXplb2Yoc3lzY3Rs X3VkcF9tZW0pLA0KZGlmZiAtLWdpdCBhL25ldC9pcHY0L3RjcF9pbnB1dC5jIGIvbmV0L2lwdjQv dGNwX2lucHV0LmMNCmluZGV4IGM1M2I3ZjMuLmYwMmYzODkgMTAwNjQ0DQotLS0gYS9uZXQvaXB2 NC90Y3BfaW5wdXQuYw0KKysrIGIvbmV0L2lwdjQvdGNwX2lucHV0LmMNCkBAIC05OSw2ICs5OSw5 IEBAIGludCBzeXNjdGxfdGNwX3RoaW5fZHVwYWNrIF9fcmVhZF9tb3N0bHk7DQogaW50IHN5c2N0 bF90Y3BfbW9kZXJhdGVfcmN2YnVmIF9fcmVhZF9tb3N0bHkgPSAxOw0KIGludCBzeXNjdGxfdGNw X2Vhcmx5X3JldHJhbnMgX19yZWFkX21vc3RseSA9IDM7DQogDQoraW50IHN5c2N0bF90Y3BfaW5p dGlhbF9zcHJlYWRpbmdfcmF0ZV9taW4gX19yZWFkX21vc3RseSA9IDA7DQoraW50IHN5c2N0bF90 Y3BfaW5pdGlhbF9zcHJlYWRpbmdfZGVidWcgX19yZWFkX21vc3RseSA9IDA7DQorDQogI2RlZmlu ZSBGTEFHX0RBVEEJCTB4MDEgLyogSW5jb21pbmcgZnJhbWUgY29udGFpbmVkIGRhdGEuCQkqLw0K ICNkZWZpbmUgRkxBR19XSU5fVVBEQVRFCQkweDAyIC8qIEluY29taW5nIEFDSyB3YXMgYSB3aW5k b3cgdXBkYXRlLgkqLw0KICNkZWZpbmUgRkxBR19EQVRBX0FDS0VECQkweDA0IC8qIFRoaXMgQUNL IGFja25vd2xlZGdlZCBuZXcgZGF0YS4JCSovDQpAQCAtNzYzLDYgKzc2NiwzNCBAQCBzdGF0aWMg dm9pZCB0Y3BfdXBkYXRlX3BhY2luZ19yYXRlKHN0cnVjdCBzb2NrICpzaykNCiAJCQkJCQlzay0+ c2tfbWF4X3BhY2luZ19yYXRlKTsNCiB9DQogDQorLyogU2V0IHRoZSBza19wYWNpbmdfcmF0ZSB0 byBhbGxvdyBGUSBwYWNrZXQgc2NoZWR1bGVyIGRvaW5nIFRDUCBpbml0aWFsDQorICogc3ByZWFk aW5nLg0KKyAqIFNlZQ0KKyAqIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWxs YW50aW4tdGNwbS1pbml0aWFsLXNwcmVhZGluZy0wMA0KKyAqLw0KK3N0YXRpYyB2b2lkIHRjcF9z ZXRfaW5pdGlhbF9wYWNpbmdfcmF0ZShzdHJ1Y3Qgc29jayAqc2spDQorew0KKwljb25zdCBzdHJ1 Y3QgdGNwX3NvY2sgKnRwID0gdGNwX3NrKHNrKTsNCisJdTY0IHJhdGU7DQorDQorCS8qIHNldCBz a19wYWNpbmdfcmF0ZSB0byAxMDAgJSBvZiBjdXJyZW50IHJhdGUgKG1zcyAqIGN3bmQgLyBzcnR0 KSAqLw0KKwlyYXRlID0gKHU2NCl0cC0+bXNzX2NhY2hlICogKEhaIDw8IDMpICogdHAtPnNuZF9j d25kOw0KKw0KKwlpZiAodHAtPnNydHQgPiA4ICsgMikNCisJCWRvX2RpdihyYXRlLCB0cC0+c3J0 dCk7DQorDQorICAgIC8qIHJhdGVfbWluID0gbXR1IC8gVF9zcHJlYWRpbmcgKHNlZSBkcmFmdCkg Ki8NCisJaWYgKHN5c2N0bF90Y3BfaW5pdGlhbF9zcHJlYWRpbmdfcmF0ZV9taW4pDQorCQlyYXRl ID0gbWF4X3QodTY0LCByYXRlLAlzeXNjdGxfdGNwX2luaXRpYWxfc3ByZWFkaW5nX3JhdGVfbWlu KTsNCisNCisJcmF0ZSA9IG1pbl90KHU2NCwgcmF0ZSwJc2stPnNrX21heF9wYWNpbmdfcmF0ZSk7 DQorDQorCWlmIChzeXNjdGxfdGNwX2luaXRpYWxfc3ByZWFkaW5nX2RlYnVnKQ0KKwkJcHJpbnRr KEtFUk5fSU5GTyAidGNwX3BhY2luZ19yYXRlOiAlbGx1XG4iLCByYXRlKTsNCisNCisJQUNDRVNT X09OQ0Uoc2stPnNrX3BhY2luZ19yYXRlKSA9IHJhdGU7DQorfQ0KKw0KIC8qIENhbGN1bGF0ZSBy dG8gd2l0aG91dCBiYWNrb2ZmLiAgVGhpcyBpcyB0aGUgc2Vjb25kIGhhbGYgb2YgVmFuIEphY29i c29uJ3MNCiAgKiByb3V0aW5lIHJlZmVycmVkIHRvIGFib3ZlLg0KICAqLw0KQEAgLTU3NjcsNyAr NTc5OCw3IEBAIGludCB0Y3BfcmN2X3N0YXRlX3Byb2Nlc3Moc3RydWN0IHNvY2sgKnNrLCBzdHJ1 Y3Qgc2tfYnVmZiAqc2tiLA0KIAkJfSBlbHNlDQogCQkJdGNwX2luaXRfbWV0cmljcyhzayk7DQog DQotCQl0Y3BfdXBkYXRlX3BhY2luZ19yYXRlKHNrKTsNCisJCXRjcF9zZXRfaW5pdGlhbF9wYWNp bmdfcmF0ZShzayk7DQogDQogCQkvKiBQcmV2ZW50IHNwdXJpb3VzIHRjcF9jd25kX3Jlc3RhcnQo KSBvbiBmaXJzdCBkYXRhIHBhY2tldCAqLw0KIAkJdHAtPmxzbmR0aW1lID0gdGNwX3RpbWVfc3Rh bXA7DQpkaWZmIC0tZ2l0IGEvbmV0L3NjaGVkL3NjaF9mcS5jIGIvbmV0L3NjaGVkL3NjaF9mcS5j DQppbmRleCA5NWQ4NDM5Li5iNDA2M2E1IDEwMDY0NA0KLS0tIGEvbmV0L3NjaGVkL3NjaF9mcS5j DQorKysgYi9uZXQvc2NoZWQvc2NoX2ZxLmMNCkBAIC03MDgsOCArNzA4LDkgQEAgc3RhdGljIGlu dCBmcV9pbml0KHN0cnVjdCBRZGlzYyAqc2NoLCBzdHJ1Y3QgbmxhdHRyICpvcHQpDQogDQogCXNj aC0+bGltaXQJCT0gMTAwMDA7DQogCXEtPmZsb3dfcGxpbWl0CQk9IDEwMDsNCi0JcS0+cXVhbnR1 bQkJPSAyICogcHNjaGVkX210dShxZGlzY19kZXYoc2NoKSk7DQotCXEtPmluaXRpYWxfcXVhbnR1 bQk9IDEwICogcHNjaGVkX210dShxZGlzY19kZXYoc2NoKSk7DQorICAgIC8qIFdlIGNoYW5nZSBk ZWZhdWx0IHZhbHVlcyBmb3IgaW5pdGlhbCBzcHJlYWRpbmcgdXNlLWNhc2UgKi8NCisJcS0+cXVh bnR1bQkJPSAxICogcHNjaGVkX210dShxZGlzY19kZXYoc2NoKSk7DQorCXEtPmluaXRpYWxfcXVh bnR1bQk9IDEgKiBwc2NoZWRfbXR1KHFkaXNjX2RldihzY2gpKTsNCiAJcS0+Zmxvd19yZWZpbGxf ZGVsYXkJPSBtc2Vjc190b19qaWZmaWVzKDQwKTsNCiAJcS0+Zmxvd19tYXhfcmF0ZQk9IH4wVTsN CiAJcS0+cmF0ZV9lbmFibGUJCT0gMTsNCi0tIA0KMi4yLjINCg0K --001a11c3da2e5e04ba050d8ebf86-- From nobody Tue Jan 27 02:22:08 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF34D1A8789 for ; Tue, 27 Jan 2015 02:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 26OmrnQQlyqU for ; Tue, 27 Jan 2015 02:22:04 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 9AB9C1A8783 for ; Tue, 27 Jan 2015 02:22:04 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 042674A41ED6B; Tue, 27 Jan 2015 10:22:01 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t0RALwTd015955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Jan 2015 11:22:02 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.165]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 11:21:47 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: Rechartering TCPM for alternative congestion control algorithms Thread-Index: AdA6Gw2/aMIpCeKlQZ6aha0AlCWw1g== Date: Tue, 27 Jan 2015 10:21:47 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 10:22:06 -0000 Hi, This e-mails asks for community feedback on a suggested small addon to the = TCPM charter [1]. In the last TCPM meeting [2] there was strong support for adopting a docume= nt describing the CUBIC congestion control algorithm [3]. To the chairs, it= is not entirely obvious whether this document, or possibly other similar d= ocuments, would indeed be in scope of the current TCPM charter. Given the i= mportance of the TCP congestion control, we prefer a community consensus ex= plicitly documented in the charter instead of ambiguity. The current charter limits the scope of TCPM to "modest changes to the prot= ocol, algorithms, and interfaces". It allows "incremental enhancements of T= CP's standard congestion control" but explicitly mandates rechartering for = fundamental changes [1]:=20 OLD: TCPM also provides a venue for standardization of incremental enhancements of TCP's standard congestion control, but such changes may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will be handled by other working groups or will require rechartering. We suggest to update this paragraph in the TCPM charter by an explicit stat= ement that "TCPM may document alternative congestion control algorithms tha= t are known to be widely deployed, and that are considered safe for large-s= cale deployment in the Internet": NEW: TCPM also provides a venue for standardization of incremental enhancements of TCP's standard congestion control. In addition, TCPM may document alternative congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet. Changes of algorithms may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will be handled by other working groups or will require rechartering. In our reading, "TCP's standard congestion control" is currently defined by= RFC 5681. This e-mail and the suggested rechartering does not imply any adoption of o= ne or more alternative congestion control algorithms. Any feedback regarding this suggested rechartering would be very welcome. I= n particular, please let us know if there are any concerns with this propos= al or if you have suggestions for a different wording. Please let us know a= ny thoughts until Feb. 15, 2015. Thanks a lot! Michael, Pasi, Yoshifumi [1] https://datatracker.ietf.org/wg/tcpm/charter/ [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm [3] https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ From nobody Tue Jan 27 02:31:53 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ECD1A876B for ; Tue, 27 Jan 2015 02:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 cZj1ZSCiw77p for ; Tue, 27 Jan 2015 02:31:49 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA23A1A6FF8 for ; Tue, 27 Jan 2015 02:31:48 -0800 (PST) Received: from [192.168.1.200] (p508F02F3.dip0.t-ipconnect.de [80.143.2.243]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F41141C0B4606; Tue, 27 Jan 2015 11:31:46 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> Date: Tue, 27 Jan 2015 11:31:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <67E21286-0DC0-45C1-A9D4-FBDDE7038F21@lurchi.franken.de> References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 10:31:51 -0000 > On 27 Jan 2015, at 11:21, Scharf, Michael (Michael) = wrote: >=20 > Hi, >=20 > This e-mails asks for community feedback on a suggested small addon to = the TCPM charter [1]. >=20 > In the last TCPM meeting [2] there was strong support for adopting a = document describing the CUBIC congestion control algorithm [3]. To the = chairs, it is not entirely obvious whether this document, or possibly = other similar documents, would indeed be in scope of the current TCPM = charter. Given the importance of the TCP congestion control, we prefer a = community consensus explicitly documented in the charter instead of = ambiguity. >=20 > The current charter limits the scope of TCPM to "modest changes to the = protocol, algorithms, and interfaces". It allows "incremental = enhancements of TCP's standard congestion control" but explicitly = mandates rechartering for fundamental changes [1]:=20 >=20 > OLD: >=20 > TCPM also provides a venue for standardization of incremental > enhancements of TCP's standard congestion control, but such changes > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will be handled by other working groups or will require > rechartering. >=20 > We suggest to update this paragraph in the TCPM charter by an explicit = statement that "TCPM may document alternative congestion control = algorithms that are known to be widely deployed, and that are considered = safe for large-scale deployment in the Internet": >=20 > NEW: >=20 > TCPM also provides a venue for standardization of incremental > enhancements of TCP's standard congestion control. In addition, > TCPM may document alternative congestion control algorithms > that are known to be widely deployed, and that are considered > safe for large-scale deployment in the Internet. Changes of algorithms > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will be handled by other working groups or will require > rechartering. >=20 > In our reading, "TCP's standard congestion control" is currently = defined by RFC 5681. >=20 > This e-mail and the suggested rechartering does not imply any adoption = of one or more alternative congestion control algorithms. >=20 > Any feedback regarding this suggested rechartering would be very = welcome. In particular, please let us know if there are any concerns = with this proposal or if you have suggestions for a different wording. = Please let us know any thoughts until Feb. 15, 2015. How would the usage of TCP based CCs in SCTP be handled? Would it be = covered in the documents in TCPM? Would there additional documents be needed? If = yes, would they go also to TCPM or to TSVWG? Just wondering... Best regards Michael >=20 > Thanks a lot! >=20 > Michael, Pasi, Yoshifumi >=20 >=20 > [1] https://datatracker.ietf.org/wg/tcpm/charter/ >=20 > [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >=20 > [3] https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Tue Jan 27 04:08:31 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE63D1A8765 for ; Tue, 27 Jan 2015 04:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 s4JcbbHc6efH for ; Tue, 27 Jan 2015 04:08:23 -0800 (PST) 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 70BB71A876C for ; Tue, 27 Jan 2015 04:08:13 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1217B8EA3B848; Tue, 27 Jan 2015 12:08:08 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t0RC88w3031947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Jan 2015 13:08:09 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.165]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 13:08:08 +0100 From: "Scharf, Michael (Michael)" To: Michael Tuexen Thread-Topic: [tcpm] Rechartering TCPM for alternative congestion control algorithms Thread-Index: AdA6Gw2/aMIpCeKlQZ6aha0AlCWw1v//8gcA///kMzA= Date: Tue, 27 Jan 2015 12:08:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16BCCFDD@FR711WXCHMBA05.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> <67E21286-0DC0-45C1-A9D4-FBDDE7038F21@lurchi.franken.de> In-Reply-To: <67E21286-0DC0-45C1-A9D4-FBDDE7038F21@lurchi.franken.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 12:08:27 -0000 > How would the usage of TCP based CCs in SCTP be handled? Would it be > covered in > the documents in TCPM? Would there additional documents be needed? If > yes, would > they go also to TCPM or to TSVWG? Just wondering... Good question. I can only respond as far as TCPM is concerned. The current = TCPM charter states in two other paragraphs [1]: The focus of the working group is TCP. In cases where small changes are directly applicable to other transports (e.g., SCTP or DCCP), the mappings to other transports may be specified alongside that for TCP, but other significant additions and changes to other transports are not in scope. [...] TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP or DCCP), which are standardized in other working groups, such as the Transport Area WG (tsvwg). In the past, the IETF has worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents will be determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. My current thinking is to leave these two paragraphs in the TCPM charter un= changed. As far as I recall, in the past TCPM has handled basically all doc= uments specifying algorithms both for TCP and for SCTP. In contrast, SCTP-o= nly documents are explicitly outside of the current charter of TCPM (i.e., = they probably have to go to TSVWG). Thus, it would depend whether a CC algo= rithm would be specified for TCP and SCTP in the same document, or not. I c= ould also think of TCPM documents describing the usage in SCTP in a non-nor= mative section or an appendix. The proposed TCPM charter is very explicitly limited to CC algorithms "know= n to be widely deployed". Adoption in TCPM would probably require that said= algorithm has been tested very extensively in TCP stacks (e.g., experiment= s in which the algorithm has been enabled by default). I don't know whether= there is a way to ensure comprehensive testing of an algorithm both for TC= P and SCTP. Therefore, I don't think we should mandate that all CC algorith= ms submitted to TCPM have to be specified both for TCP and SCTP in the same= document. The congestion control in RFC 5681 is also specified for TCP onl= y. Are there any suggestion for an alternative handling? Thanks Michael [1] https://datatracker.ietf.org/wg/tcpm/charter/ From nobody Tue Jan 27 04:26:33 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE811A6FFF for ; Tue, 27 Jan 2015 04:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 j2ctiQ2bx5Mb for ; Tue, 27 Jan 2015 04:26:28 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEDA1A02F1 for ; Tue, 27 Jan 2015 04:26:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,474,1418112000"; d="scan'208";a="17950158" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 27 Jan 2015 04:21:27 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 27 Jan 2015 04:21:26 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::8140:62e8:294b:51f4%21]) with mapi id 15.00.0995.031; Tue, 27 Jan 2015 04:21:26 -0800 From: "Scheffenegger, Richard" To: Michael Tuexen , "Scharf, Michael (Michael)" Thread-Topic: [tcpm] Rechartering TCPM for alternative congestion control algorithms Thread-Index: AQHQOhx5WwubREY3ZE2jPMF7qGpwi5zT4IqQ Date: Tue, 27 Jan 2015 12:21:25 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> <67E21286-0DC0-45C1-A9D4-FBDDE7038F21@lurchi.franken.de> In-Reply-To: <67E21286-0DC0-45C1-A9D4-FBDDE7038F21@lurchi.franken.de> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 12:26:31 -0000 Hi Michael, Chairs, First, I think the proposed change to the charter is a good one - especiall= y in the light that there is a recent push to try and document what is curr= ently deployed. Second, for Cubic specifically there is a single reference to SCTP which in= dicates that cubic can also be applied to SCTP. However, other than this in= troductory mentioning, nothing specific is there. But if one builds a CC sp= ecific to either TCP or SCTP - which does NOT apply to the other protocol, = a document should clearly state so and treated in the respective WG. In the generic case - that is, CC which applies equally to SCTP and TCP, I = think the current provision of having TCPM and ICCRG denting the algorithm = out, and then when the time comes, having it in TCPM seems natural, not? Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Michael Tuexen > Sent: Dienstag, 27. J=E4nner 2015 11:32 > To: Scharf, Michael (Michael) > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org > Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control > algorithms >=20 > > On 27 Jan 2015, at 11:21, Scharf, Michael (Michael) > wrote: > > > > Hi, > > > > This e-mails asks for community feedback on a suggested small addon to > the TCPM charter [1]. > > > > In the last TCPM meeting [2] there was strong support for adopting a > document describing the CUBIC congestion control algorithm [3]. To the > chairs, it is not entirely obvious whether this document, or possibly > other similar documents, would indeed be in scope of the current TCPM > charter. Given the importance of the TCP congestion control, we prefer a > community consensus explicitly documented in the charter instead of > ambiguity. > > > > The current charter limits the scope of TCPM to "modest changes to the > protocol, algorithms, and interfaces". It allows "incremental enhancement= s > of TCP's standard congestion control" but explicitly mandates recharterin= g > for fundamental changes [1]: > > > > OLD: > > > > TCPM also provides a venue for standardization of incremental > > enhancements of TCP's standard congestion control, but such changes > > may require additional review by the IRTF Congestion Control Research > > Group (ICCRG). Fundamental changes to TCP or its congestion control > > algorithms (e.g., departure from loss-based congestion > > control) will be handled by other working groups or will require > > rechartering. > > > > We suggest to update this paragraph in the TCPM charter by an explicit > statement that "TCPM may document alternative congestion control > algorithms that are known to be widely deployed, and that are considered > safe for large-scale deployment in the Internet": > > > > NEW: > > > > TCPM also provides a venue for standardization of incremental > > enhancements of TCP's standard congestion control. In addition, TCPM > > may document alternative congestion control algorithms that are known > > to be widely deployed, and that are considered safe for large-scale > > deployment in the Internet. Changes of algorithms may require > > additional review by the IRTF Congestion Control Research Group > > (ICCRG). Fundamental changes to TCP or its congestion control > > algorithms (e.g., departure from loss-based congestion > > control) will be handled by other working groups or will require > > rechartering. > > > > In our reading, "TCP's standard congestion control" is currently define= d > > by RFC 5681. > > > > This e-mail and the suggested rechartering does not imply any adoption > > of one or more alternative congestion control algorithms. > > > > Any feedback regarding this suggested rechartering would be very > > welcome. In particular, please let us know if there are any concerns wi= th > > this proposal or if you have suggestions for a different wording. Pleas= e > > let us know any thoughts until Feb. 15, 2015. > > > How would the usage of TCP based CCs in SCTP be handled? Would it be > covered in the documents in TCPM? Would there additional documents be > needed? If yes, would they go also to TCPM or to TSVWG? Just wondering... >=20 > Best regards > Michael > > > > Thanks a lot! > > > > Michael, Pasi, Yoshifumi > > > > > > [1] https://datatracker.ietf.org/wg/tcpm/charter/ > > > > [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm > > > > [3] https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jan 27 04:49:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C017D1A8746 for ; Tue, 27 Jan 2015 04:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 p2r49r9mKJ4A for ; Tue, 27 Jan 2015 04:49:19 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861621A87B0 for ; Tue, 27 Jan 2015 04:49:00 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t0RCms2X001972; Tue, 27 Jan 2015 04:48:54 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 022665E94F8; Tue, 27 Jan 2015 07:48:50 -0500 (EST) To: "Scharf, Michael (Michael)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Freeze-Frame X-URL-0: http://www.icir.org/mallman-files/Document13677.jpg X-URL-1: http://www.icir.org/mallman-files/Document28690.docx X-URL-2: http://www.icir.org/mallman-files/Document38659.pdf X-URL-3: http://www.icir.org/mallman-files/Document25158.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma35122-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 27 Jan 2015 07:48:50 -0500 Sender: mallman@icir.org Message-Id: <20150127124851.022665E94F8@lawyers.icir.org> Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 12:49:20 -0000 ----------ma35122-1 Content-Type: text/plain Content-Disposition: inline > We suggest to update this paragraph in the TCPM charter by an explicit > statement that "TCPM may document alternative congestion control > algorithms that are known to be widely deployed, and that are > considered safe for large-scale deployment in the Internet": Seems fine to me. No need to make easy things difficult; make the change! allman ----------ma35122-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTHiTIACgkQWyrrWs4yIs6+iwCfSGKhrdc1dojtWII0lMFin9z2 iGYAn3cjoOysYPIuJo51Y36MUnJiUwim =cKDc -----END PGP SIGNATURE----- ----------ma35122-1-- From nobody Tue Jan 27 05:06:35 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90781A8739 for ; Tue, 27 Jan 2015 05:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 eoFV_2EXb6GF for ; Tue, 27 Jan 2015 05:06:23 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FD71A8745 for ; Tue, 27 Jan 2015 05:06:22 -0800 (PST) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E5B321C10437E; Tue, 27 Jan 2015 14:06:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <655C07320163294895BBADA28372AF5D16BCCFDD@FR711WXCHMBA05.zeu.alcatel-lucent.com> Date: Tue, 27 Jan 2015 14:06:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58424AFA-4A54-4DD7-A839-D7AC8BFFB14A@lurchi.franken.de> References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> <67E21286-0DC0-45C1-A9D4-FBDDE7038F21@lurchi.franken.de> <655C07320163294895BBADA28372AF5D16BCCFDD@FR711WXCHMBA05.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 13:06:30 -0000 > On 27 Jan 2015, at 13:08, Scharf, Michael (Michael) = wrote: >=20 >> How would the usage of TCP based CCs in SCTP be handled? Would it be >> covered in >> the documents in TCPM? Would there additional documents be needed? If >> yes, would >> they go also to TCPM or to TSVWG? Just wondering... >=20 > Good question. I can only respond as far as TCPM is concerned. The = current TCPM charter states in two other paragraphs [1]: >=20 > The focus of the working group is TCP. In cases where small > changes are directly applicable to other transports (e.g., SCTP or > DCCP), the mappings to other transports may be specified alongside > that for TCP, but other significant additions and changes to other > transports are not in scope. >=20 > [...] >=20 > TCP's congestion control algorithms are the model followed by > alternate transports (e.g., SCTP or DCCP), which are standardized in > other working groups, such as the Transport Area WG (tsvwg). In the > past, the IETF has worked on several documents about algorithms that > are specified for multiple protocols (e.g., TCP and SCTP) in the > same document. Which WG shepherds such documents will be determined > on a case-by-case basis. In any case, the TCPM WG will remain in > close contact with other relevant WGs working on these protocols to > ensure openness and stringent review from all angles. >=20 >=20 > My current thinking is to leave these two paragraphs in the TCPM = charter unchanged. As far as I recall, in the past TCPM has handled = basically all documents specifying algorithms both for TCP and for SCTP. = In contrast, SCTP-only documents are explicitly outside of the current = charter of TCPM (i.e., they probably have to go to TSVWG). Thus, it = would depend whether a CC algorithm would be specified for TCP and SCTP = in the same document, or not. I could also think of TCPM documents = describing the usage in SCTP in a non-normative section or an appendix. >=20 > The proposed TCPM charter is very explicitly limited to CC algorithms = "known to be widely deployed". Adoption in TCPM would probably require = that said algorithm has been tested very extensively in TCP stacks = (e.g., experiments in which the algorithm has been enabled by default). = I don't know whether there is a way to ensure comprehensive testing of = an algorithm both for TCP and SCTP. Therefore, I don't think we should = mandate that all CC algorithms submitted to TCPM have to be specified = both for TCP and SCTP in the same document. The congestion control in = RFC 5681 is also specified for TCP only. >=20 > Are there any suggestion for an alternative handling? OK. Makes sense. If we need modifications for SCTP we can go through = TSVWG... Best regards Michael >=20 > Thanks >=20 > Michael >=20 >=20 > [1] https://datatracker.ietf.org/wg/tcpm/charter/ >=20 From nobody Tue Jan 27 07:34:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73601A8825 for ; Tue, 27 Jan 2015 07:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 46p5Tuh93Y4J for ; Tue, 27 Jan 2015 07:34:21 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133DC1A8771 for ; Tue, 27 Jan 2015 07:34:21 -0800 (PST) Received: from [192.168.1.5] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t0RFXoKA004707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 Jan 2015 07:33:59 -0800 (PST) Message-ID: <54C7AFDD.5040502@isi.edu> Date: Tue, 27 Jan 2015 07:33:49 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 15:34:22 -0000 Hi, all, I disagree; TCP congestion control algorithms are also deployed in other transports, and thus this seems more appropriate for TSVWG. Joe On 1/27/2015 2:21 AM, Scharf, Michael (Michael) wrote: > Hi, > > This e-mails asks for community feedback on a suggested small addon to the TCPM charter [1]. > > In the last TCPM meeting [2] there was strong support for adopting a document describing the CUBIC congestion control algorithm [3]. To the chairs, it is not entirely obvious whether this document, or possibly other similar documents, would indeed be in scope of the current TCPM charter. Given the importance of the TCP congestion control, we prefer a community consensus explicitly documented in the charter instead of ambiguity. > > The current charter limits the scope of TCPM to "modest changes to the protocol, algorithms, and interfaces". It allows "incremental enhancements of TCP's standard congestion control" but explicitly mandates rechartering for fundamental changes [1]: > > OLD: > > TCPM also provides a venue for standardization of incremental > enhancements of TCP's standard congestion control, but such changes > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will be handled by other working groups or will require > rechartering. > > We suggest to update this paragraph in the TCPM charter by an explicit statement that "TCPM may document alternative congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet": > > NEW: > > TCPM also provides a venue for standardization of incremental > enhancements of TCP's standard congestion control. In addition, > TCPM may document alternative congestion control algorithms > that are known to be widely deployed, and that are considered > safe for large-scale deployment in the Internet. Changes of algorithms > may require additional review by the IRTF Congestion Control > Research Group (ICCRG). Fundamental changes to TCP or its congestion > control algorithms (e.g., departure from loss-based congestion > control) will be handled by other working groups or will require > rechartering. > > In our reading, "TCP's standard congestion control" is currently defined by RFC 5681. > > This e-mail and the suggested rechartering does not imply any adoption of one or more alternative congestion control algorithms. > > Any feedback regarding this suggested rechartering would be very welcome. In particular, please let us know if there are any concerns with this proposal or if you have suggestions for a different wording. Please let us know any thoughts until Feb. 15, 2015. > > Thanks a lot! > > Michael, Pasi, Yoshifumi > > > [1] https://datatracker.ietf.org/wg/tcpm/charter/ > > [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm > > [3] https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Jan 27 07:59:29 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336C01A88A7 for ; Tue, 27 Jan 2015 07:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pMnxwWbH9HUc for ; Tue, 27 Jan 2015 07:59:17 -0800 (PST) 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 9C0971A8849 for ; Tue, 27 Jan 2015 07:56:27 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 62593BFBC95A0; Tue, 27 Jan 2015 15:56:22 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t0RFuPej019734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Jan 2015 16:56:25 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.165]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 16:56:26 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch , "tcpm@ietf.org" Thread-Topic: [tcpm] Rechartering TCPM for alternative congestion control algorithms Thread-Index: AdA6Gw2/aMIpCeKlQZ6aha0AlCWw1gAIzXWAAAI6RtA= Date: Tue, 27 Jan 2015 15:56:24 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16BCD3B5@FR711WXCHMBA05.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> <54C7AFDD.5040502@isi.edu> In-Reply-To: <54C7AFDD.5040502@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 15:59:26 -0000 Hi Joe, The current TCPM charter very explicitly includes "incremental enhancements= of TCP's standard congestion control". RFC 5681 is a TCPM document. Are you suggesting that *all* documents dealing with TCP congestion control= should be moved from TCPM to TSVWG, including e.g. potential future update= s of RFC 5681? I guess this would result in a major re-chartering both of TCPM and TSVWG. = And it could be a slippery road. A lot of TCPM documents affect congestion = control at least partly. Thanks Michael > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, January 27, 2015 4:34 PM > To: Scharf, Michael (Michael); tcpm@ietf.org > Cc: tcpm-chairs@tools.ietf.org > Subject: Re: [tcpm] Rechartering TCPM for alternative congestion > control algorithms >=20 > Hi, all, >=20 > I disagree; TCP congestion control algorithms are also deployed in > other > transports, and thus this seems more appropriate for TSVWG. >=20 > Joe >=20 > On 1/27/2015 2:21 AM, Scharf, Michael (Michael) wrote: > > Hi, > > > > This e-mails asks for community feedback on a suggested small addon > to the TCPM charter [1]. > > > > In the last TCPM meeting [2] there was strong support for adopting a > document describing the CUBIC congestion control algorithm [3]. To the > chairs, it is not entirely obvious whether this document, or possibly > other similar documents, would indeed be in scope of the current TCPM > charter. Given the importance of the TCP congestion control, we prefer > a community consensus explicitly documented in the charter instead of > ambiguity. > > > > The current charter limits the scope of TCPM to "modest changes to > the protocol, algorithms, and interfaces". It allows "incremental > enhancements of TCP's standard congestion control" but explicitly > mandates rechartering for fundamental changes [1]: > > > > OLD: > > > > TCPM also provides a venue for standardization of incremental > > enhancements of TCP's standard congestion control, but such changes > > may require additional review by the IRTF Congestion Control > > Research Group (ICCRG). Fundamental changes to TCP or its congestion > > control algorithms (e.g., departure from loss-based congestion > > control) will be handled by other working groups or will require > > rechartering. > > > > We suggest to update this paragraph in the TCPM charter by an > explicit statement that "TCPM may document alternative congestion > control algorithms that are known to be widely deployed, and that are > considered safe for large-scale deployment in the Internet": > > > > NEW: > > > > TCPM also provides a venue for standardization of incremental > > enhancements of TCP's standard congestion control. In addition, > > TCPM may document alternative congestion control algorithms > > that are known to be widely deployed, and that are considered > > safe for large-scale deployment in the Internet. Changes of > algorithms > > may require additional review by the IRTF Congestion Control > > Research Group (ICCRG). Fundamental changes to TCP or its congestion > > control algorithms (e.g., departure from loss-based congestion > > control) will be handled by other working groups or will require > > rechartering. > > > > In our reading, "TCP's standard congestion control" is currently > defined by RFC 5681. > > > > This e-mail and the suggested rechartering does not imply any > adoption of one or more alternative congestion control algorithms. > > > > Any feedback regarding this suggested rechartering would be very > welcome. In particular, please let us know if there are any concerns > with this proposal or if you have suggestions for a different wording. > Please let us know any thoughts until Feb. 15, 2015. > > > > Thanks a lot! > > > > Michael, Pasi, Yoshifumi > > > > > > [1] https://datatracker.ietf.org/wg/tcpm/charter/ > > > > [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm > > > > [3] https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > From nobody Tue Jan 27 08:04:56 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488541A8771 for ; Tue, 27 Jan 2015 08:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GUrUg7irJTcc for ; Tue, 27 Jan 2015 08:04:49 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179371A1AA6 for ; Tue, 27 Jan 2015 08:04:49 -0800 (PST) Received: from [192.168.1.5] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t0RG4CxH010110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 Jan 2015 08:04:21 -0800 (PST) Message-ID: <54C7B6FB.20806@isi.edu> Date: Tue, 27 Jan 2015 08:04:11 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> <54C7AFDD.5040502@isi.edu> <655C07320163294895BBADA28372AF5D16BCD3B5@FR711WXCHMBA05.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16BCD3B5@FR711WXCHMBA05.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 16:04:54 -0000 On 1/27/2015 7:56 AM, Scharf, Michael (Michael) wrote: > Hi Joe, > > The current TCPM charter very explicitly includes "incremental > enhancements of TCP's standard congestion control". RFC 5681 is a TCPM > document. Yes, where incremental would include things like tweaking RTO or ACK counts. > Are you suggesting that *all* documents dealing with TCP congestion > control should be moved from TCPM to TSVWG, including e.g. potential > future updates of RFC 5681? Major changes that aren't specific to TCP, IMO yes, and yes, that would definitely IMO include updates to RFC5681. The community affected and interested in such changes is far beyond that of just TCPM. IMO, this is better for TCMP, TSVWG, and the development of overarching mechanisms. > I guess this would result in a major re-chartering both of TCPM and > TSVWG. And it could be a slippery road. A lot of TCPM documents affect > congestion control at least partly. We already have that sort of slippery slope issue. The general rule, AFAICT, is "minor" stays in TCPM and major goes to TSVWG. Major always includes changes that affect other transports as much as they affect TCP. (we could even say that adopting CUBIC should happen in TSVWG, but that later minor tweaks could happen in TCPM) Joe >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, January 27, 2015 4:34 PM >> To: Scharf, Michael (Michael); tcpm@ietf.org >> Cc: tcpm-chairs@tools.ietf.org >> Subject: Re: [tcpm] Rechartering TCPM for alternative congestion >> control algorithms >> >> Hi, all, >> >> I disagree; TCP congestion control algorithms are also deployed in >> other >> transports, and thus this seems more appropriate for TSVWG. >> >> Joe >> >> On 1/27/2015 2:21 AM, Scharf, Michael (Michael) wrote: >>> Hi, >>> >>> This e-mails asks for community feedback on a suggested small addon >> to the TCPM charter [1]. >>> >>> In the last TCPM meeting [2] there was strong support for adopting a >> document describing the CUBIC congestion control algorithm [3]. To the >> chairs, it is not entirely obvious whether this document, or possibly >> other similar documents, would indeed be in scope of the current TCPM >> charter. Given the importance of the TCP congestion control, we prefer >> a community consensus explicitly documented in the charter instead of >> ambiguity. >>> >>> The current charter limits the scope of TCPM to "modest changes to >> the protocol, algorithms, and interfaces". It allows "incremental >> enhancements of TCP's standard congestion control" but explicitly >> mandates rechartering for fundamental changes [1]: >>> >>> OLD: >>> >>> TCPM also provides a venue for standardization of incremental >>> enhancements of TCP's standard congestion control, but such changes >>> may require additional review by the IRTF Congestion Control >>> Research Group (ICCRG). Fundamental changes to TCP or its congestion >>> control algorithms (e.g., departure from loss-based congestion >>> control) will be handled by other working groups or will require >>> rechartering. >>> >>> We suggest to update this paragraph in the TCPM charter by an >> explicit statement that "TCPM may document alternative congestion >> control algorithms that are known to be widely deployed, and that are >> considered safe for large-scale deployment in the Internet": >>> >>> NEW: >>> >>> TCPM also provides a venue for standardization of incremental >>> enhancements of TCP's standard congestion control. In addition, >>> TCPM may document alternative congestion control algorithms >>> that are known to be widely deployed, and that are considered >>> safe for large-scale deployment in the Internet. Changes of >> algorithms >>> may require additional review by the IRTF Congestion Control >>> Research Group (ICCRG). Fundamental changes to TCP or its congestion >>> control algorithms (e.g., departure from loss-based congestion >>> control) will be handled by other working groups or will require >>> rechartering. >>> >>> In our reading, "TCP's standard congestion control" is currently >> defined by RFC 5681. >>> >>> This e-mail and the suggested rechartering does not imply any >> adoption of one or more alternative congestion control algorithms. >>> >>> Any feedback regarding this suggested rechartering would be very >> welcome. In particular, please let us know if there are any concerns >> with this proposal or if you have suggestions for a different wording. >> Please let us know any thoughts until Feb. 15, 2015. >>> >>> Thanks a lot! >>> >>> Michael, Pasi, Yoshifumi >>> >>> >>> [1] https://datatracker.ietf.org/wg/tcpm/charter/ >>> >>> [2] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >>> >>> [3] https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/ >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> From nobody Tue Jan 27 08:42:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04241A8872 for ; Tue, 27 Jan 2015 08:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 ARo4oPeoGu0r for ; Tue, 27 Jan 2015 08:42:49 -0800 (PST) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5FD1A8862 for ; Tue, 27 Jan 2015 08:40:10 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t0RGe8qB004426 for ; Tue, 27 Jan 2015 11:40:08 -0500 Received: (qmail 21699 invoked by uid 0); 27 Jan 2015 16:40:08 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 27 Jan 2015 16:40:08 -0000 Message-ID: <54C7BF65.7030104@mti-systems.com> Date: Tue, 27 Jan 2015 11:40:05 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , Joe Touch , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D16BCCD3D@FR711WXCHMBA05.zeu.alcatel-lucent.com> <54C7AFDD.5040502@isi.edu> <655C07320163294895BBADA28372AF5D16BCD3B5@FR711WXCHMBA05.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16BCD3B5@FR711WXCHMBA05.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 16:42:50 -0000 On 1/27/2015 10:56 AM, Scharf, Michael (Michael) wrote: > The current TCPM charter very explicitly includes "incremental enhancements of TCP's standard congestion control". RFC 5681 is a TCPM document. > > Are you suggesting that *all* documents dealing with TCP congestion control should be moved from TCPM to TSVWG, including e.g. potential future updates of RFC 5681? > > I guess this would result in a major re-chartering both of TCPM and TSVWG. And it could be a slippery road. A lot of TCPM documents affect congestion control at least partly. When you read the TSVWG or TCPM mailing lists or go to the meetings, it's a heavily overlapping set of names and faces, so this is really about which mailing list to use and which set of chairs will run the process, IMHO. In the past, when CTCP, CUBIC, and HTCP were being proposed, TCPM was the group that would have taken them, as mentioned in the IESG statement from back then: https://www.ietf.org/iesg/statement/congestion-control.html TCPM should definitely be the home for this, and TSVWG can be copied on the adoption call in case some folks there who aren't following TCPM want to participate. Either way, reviewing the draft is more important than which list's name it happens under, so there's no need to have a constitutional crisis over it. -- Wes Eddy MTI Systems From nobody Tue Jan 27 09:04:04 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0903C1A8847 for ; Tue, 27 Jan 2015 09:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YSIxe7nLLzly for ; Tue, 27 Jan 2015 09:03:53 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AACC1A8843 for ; Tue, 27 Jan 2015 09:03:52 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t0RH3mJG020351; Tue, 27 Jan 2015 09:03:48 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C09285ECB65; Tue, 27 Jan 2015 12:03:47 -0500 (EST) To: Wesley Eddy From: Mark Allman In-Reply-To: <54C7BF65.7030104@mti-systems.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Freeze-Frame X-URL-0: http://www.icir.org/mallman-files/Document38318.doc X-URL-1: http://www.icir.org/mallman-files/Document94581.html X-URL-2: http://www.icir.org/mallman-files/Document93527.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma50419-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 27 Jan 2015 12:03:47 -0500 Sender: mallman@icir.org Message-Id: <20150127170347.C09285ECB65@lawyers.icir.org> Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 17:03:59 -0000 ----------ma50419-1 Content-Type: text/plain Content-Disposition: inline > Either way, reviewing the draft is more important than which > list's name it happens under, so there's no need to have a > constitutional crisis over it. Don't make easy things difficult. Both directions have valid arguments. Someone should decide and we should work on difficult things. Sheesh. allman ----------ma50419-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTHxPMACgkQWyrrWs4yIs5FwACeLEPoi9eJwg6pAYE8jSxSdwUi B3cAnArGP+dJBj56sjoq71cEUPtaARls =7AGb -----END PGP SIGNATURE----- ----------ma50419-1-- From nobody Tue Jan 27 09:10:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E4B1A88A9 for ; Tue, 27 Jan 2015 09:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MK7QOPcGrF0m for ; Tue, 27 Jan 2015 09:09:59 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E64C1A887E for ; Tue, 27 Jan 2015 09:09:39 -0800 (PST) Received: from [192.168.1.5] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t0RH8BED021239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 Jan 2015 09:08:20 -0800 (PST) Message-ID: <54C7C5FA.8070601@isi.edu> Date: Tue, 27 Jan 2015 09:08:10 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mallman@icir.org, Wesley Eddy References: <20150127170347.C09285ECB65@lawyers.icir.org> In-Reply-To: <20150127170347.C09285ECB65@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 17:10:01 -0000 +1. I was making the point that this should be moved to TSVWG instead of TCPM, *especially* because of past presentations on new algorithms. I've made my point. This isn't a "crisis", it's a viewpoint. The IESG needs to make a decision after others weigh in too. Joe On 1/27/2015 9:03 AM, Mark Allman wrote: > >> Either way, reviewing the draft is more important than which >> list's name it happens under, so there's no need to have a >> constitutional crisis over it. > > Don't make easy things difficult. Both directions have valid > arguments. Someone should decide and we should work on difficult > things. > > Sheesh. > > allman > > > From nobody Tue Jan 27 09:23:47 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A841A1A7D for ; Tue, 27 Jan 2015 09:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Lx4Pni1wCe14 for ; Tue, 27 Jan 2015 09:23:41 -0800 (PST) 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 C76071A1A30 for ; Tue, 27 Jan 2015 09:23:40 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 884D7C5A4C035; Tue, 27 Jan 2015 17:23:33 +0000 (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 t0RHNalR022616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Jan 2015 18:23:36 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.165]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 18:23:37 +0100 From: "Scharf, Michael (Michael)" To: "mallman@icir.org" , Wesley Eddy Thread-Topic: [tcpm] Rechartering TCPM for alternative congestion control algorithms Thread-Index: AQHQOlM2Gqm9ZQ2Vt0yESAJ0K253GZzUMwwQ Date: Tue, 27 Jan 2015 17:23:35 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16BCD62F@FR711WXCHMBA05.zeu.alcatel-lucent.com> References: <54C7BF65.7030104@mti-systems.com> <20150127170347.C09285ECB65@lawyers.icir.org> In-Reply-To: <20150127170347.C09285ECB65@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 17:23:45 -0000 > > Either way, reviewing the draft is more important than which > > list's name it happens under, so there's no need to have a > > constitutional crisis over it. >=20 > Don't make easy things difficult. Both directions have valid > arguments. Someone should decide and we should work on difficult > things. The proposed addon to the TCPM charter is explicitly limited to documenting= TCP algorithms "known to be widely deployed". Getting feedback and reviews= from TCP implementers is indeed the actual challenge in this case. I believe (well, actually I hope) that implementers of major stacks indeed = follow the TCPM list. In my opinion, we should not make it too complex for = them to figure out what is done where in the IETF. Michael From nobody Tue Jan 27 14:41:32 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F75D1A90A1 for ; Tue, 27 Jan 2015 14:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9vXqsiabmUjC for ; Tue, 27 Jan 2015 14:41:29 -0800 (PST) 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 C513E1A909C for ; Tue, 27 Jan 2015 14:41:28 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YGEoz-00078H-Dd; Tue, 27 Jan 2015 23:41:21 +0100 Received: from [109.236.130.11] (helo=surfer-172-29-15-13-hotspot.s-bit.nl) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YGEoy-0000lI-Ty; Tue, 27 Jan 2015 23:41:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: <655C07320163294895BBADA28372AF5D16BCD62F@FR711WXCHMBA05.zeu.alcatel-lucent.com> Date: Tue, 27 Jan 2015 23:41:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <870745F5-397F-460B-AB57-16DE5D5AE5CA@ifi.uio.no> References: <54C7BF65.7030104@mti-systems.com> <20150127170347.C09285ECB65@lawyers.icir.org> <655C07320163294895BBADA28372AF5D16BCD62F@FR711WXCHMBA05.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 22 sum msgs/h 9 total rcpts 25174 max rcpts/h 44 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: E85C79E760390ECF09B313DE6157099DE168A3A6 X-UiO-SPAM-Test: remote_host: 109.236.130.11 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 23 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" , Joe Touch , "mallman@icir.org" Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control algorithms X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 22:41:31 -0000 +1 for TCPM > On 27. jan. 2015, at 18.23, Scharf, Michael (Michael) = wrote: >=20 >>> Either way, reviewing the draft is more important than which >>> list's name it happens under, so there's no need to have a >>> constitutional crisis over it. >>=20 >> Don't make easy things difficult. Both directions have valid >> arguments. Someone should decide and we should work on difficult >> things. >=20 > The proposed addon to the TCPM charter is explicitly limited to = documenting TCP algorithms "known to be widely deployed". Getting = feedback and reviews from TCP implementers is indeed the actual = challenge in this case. >=20 > I believe (well, actually I hope) that implementers of major stacks = indeed follow the TCPM list. In my opinion, we should not make it too = complex for them to figure out what is done where in the IETF. >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jan 29 02:55:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129DE1A019B for ; Thu, 29 Jan 2015 02:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 nXwtfHd_dbU3 for ; Thu, 29 Jan 2015 02:55:50 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60A21A0151 for ; Thu, 29 Jan 2015 02:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4986; q=dns/txt; s=iport; t=1422528949; x=1423738549; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/sZOvthGU7HMDQimgqAQRfZFbFfdm3oVPVJEBGlLr/w=; b=SflCZerdJ9UJw+2/zf51ZFy4BP8NeV/hkqDo6EXXYxq1VJRqGoh7JRbl VM5UGZzqEZW0HOVoeCP8Qqw+c8hCErKWxkIYAFXMK9eda3hhzpKM1zNDe bxfZn9meVJc7GsdeHHb9KoT+i3djbI4dFkJhWlzpj4cTDldmBCsvxC8ca A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CbBwAgEcpU/4kNJK1agkNDUlkEwm+BaYVxAoEeQwEBAQEBfYQMAQEBBHkQAgEIBA0DAQIoBzIUCQgCBA4FiCwN1XkBAQEBAQEBAQIBAQEBAQEBAQEBARePZw0EB4QpBY50g0uFV4EXNoJLh3iCeYM9IoNub4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,485,1418083200"; d="scan'208,217";a="118619164" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 29 Jan 2015 10:55:49 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t0TAtno9008697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Jan 2015 10:55:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.3]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 04:55:48 -0600 From: "Sujeet Nayak A (sua)" To: "tcpm@ietf.org" Thread-Topic: Updated SHA-2 AO draft Thread-Index: AQHP8nYrPM6bJff4oUqZ0Bc1WuqHwZzYQB4A Date: Thu, 29 Jan 2015 10:55:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.142.108.96] Content-Type: multipart/alternative; boundary="_000_D0F00E397EE64suaciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Updated SHA-2 AO draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 10:55:52 -0000 --_000_D0F00E397EE64suaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks again for all the valuable comments so far. Brian and myself have up= loaded the next version (version 2)of the draft: http://tools.ietf.org/html/draft-nayak-tcp-sha2-02 The change that has been made (wrt version 1): * Last parah in section 4 has been added to accommodate the review comm= ent on explicitly calling out options packing. Please let me know if there are any more comments. Regards, Sujeet From: sua > Date: Tuesday, 28 October 2014 11:42 AM To: "tcpm@ietf.org" > Cc: "Brian Weis (bew)" > Subject: Updated SHA-2 AO draft Hi, Thanks everyone for your valuable review comments so far. Brian and myself = have updated the draft to produce the next version. https://tools.ietf.org/html/draft-nayak-tcp-sha2-01 Some of the high level changes made are: * Because of TCP option space issue, SHA512 has been moved out of the d= raft (a note added in the "Security Consideration" for future support, when= needed). * Moved the motivation contents into the introduction section. * Taken care of some of the RFC language related comments. Pl. review and let me know your feedback. On the other hand, if there is a = consensus that, the contents need to update RFC5926, and if that RFC allows= such an update, then we are happy to work with Greg on it. Regards, Sujeet --_000_D0F00E397EE64suaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <275A639F96B9B54BAA6120287929100E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,
Thanks again for all the valuable comments so far. Brian and myself ha= ve uploaded the next version (version 2)of the draft:

The change that has been made (wrt version 1):
  • Last parah in section 4 has been added to accommodate the review commen= t on explicitly calling out options packing.
Please let me know if there are any more comments.

Regards,

Sujeet

From: sua <sua@cisco.com>
Date: Tuesday, 28 October 2014 11:4= 2 AM
To: "tcpm@ietf.org" <tcpm@i= etf.org>
Cc: "Brian Weis (bew)" &l= t;bew@cisco.com>
Subject: Updated SHA-2 AO draft

Hi,
Thanks everyone for your valuable review comments so far. Brian and my= self have updated the draft to produce the next version. 

Some of the high level changes made are:
  • Because of TCP option space issue, SHA512 has been moved out of the dra= ft (a note added in the "Security Consideration" for future suppo= rt, when needed).
  • Moved the motivation contents into the introducti= on section.
  • Taken care of some of the RFC language related comments= .
Pl. review and let me know your feedback. On the other hand, if there = is a consensus that, the contents need to update RFC5926, and if that RFC a= llows such an update, then we are happy to work with Greg on it.

Regards,

Sujeet
 --_000_D0F00E397EE64suaciscocom_--