From nobody Sat Sep 1 01:10:46 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6483D130EAC for ; Sat, 1 Sep 2018 01:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9hh2yxYJKlk for ; Sat, 1 Sep 2018 01:10:42 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546D3130DF4 for ; Sat, 1 Sep 2018 01:10:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B6D8425A95 for ; Sat, 1 Sep 2018 10:10:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1535789439; bh=Hqwqcvtv2oQEIkiWnEcOaoQPbv+RSe0Wnk1Q0tPnzaE=; h=From:To:Subject:Date:From; b=wEl4O3q1Gd3myvqictH5Hesw5l1U7Butz4iW9dZ6FjQGGxXp+lQKtXoyxOvalAB9J SrMZNreKORtNTsSZMvWN7+34yg1zOKVeXIKM/pkoEY8RJq+3D/13nxvs+kFIN/Z3oI 9/Ng9mCOe8R6RFlD9q9IDokxGpzZhwY2neOHRhEk= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtSE0Z7bGrQG for ; Sat, 1 Sep 2018 10:10:39 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.hs-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Sat, 1 Sep 2018 10:10:39 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.253]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Sat, 1 Sep 2018 10:10:39 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" Thread-Topic: Co-chair e-mail address change Thread-Index: AQHUQctEnKLZ1yLR/EydkpPf/5Z3Lw== Date: Sat, 1 Sep 2018 08:10:38 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E16BCD3EA@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E16BCD3EArznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] Co-chair e-mail address change X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.27 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, 01 Sep 2018 08:10:44 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E16BCD3EArznt8114rzntrzd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, My affiliation has changed to Hochschule Esslingen, which is a University o= f Applied Sciences close to Stuttgart. I will in future use the e-mail addr= ess michael.scharf@hs-esslingen.de in TCPM. The e-mail aliases (such as tcpm-chairs@ietf.org) have already bee= n updated. This may be a good opportunity to say thanks to Alcatel-Lucent and Nokia fo= r sponsoring my trips to IETF Meetings in the last years, even though TCPM = has been very far away from my day job. Thanks a lot Michael --_000_6EC6417807D9754DA64F3087E2E2E03E16BCD3EArznt8114rzntrzd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

My affiliation has changed to Hochschule Esslingen, which is a Univers= ity of Applied Sciences close to Stuttgart. I will in future use the e-mail= address

  michael.scharf@hs-esslingen.de

in TCPM. The e-mail aliases (such as tcpm-chairs@ietf.org) have alread= y been updated.

This may be a good opportunity to say thanks to Alcatel-Lucent and Nok= ia for sponsoring my trips to IETF Meetings in the last years, even though = TCPM has been very far away from my day job.

Thanks a lot

Michael
--_000_6EC6417807D9754DA64F3087E2E2E03E16BCD3EArznt8114rzntrzd_-- From nobody Wed Sep 5 08:53:07 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D58130E52 for ; Wed, 5 Sep 2018 07:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGltL-Djqxns for ; Wed, 5 Sep 2018 07:53:42 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1DD130E3C for ; Wed, 5 Sep 2018 07:53:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 4256CT0X25zMnjj; Wed, 5 Sep 2018 16:53:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCOuP46UuaBC; Wed, 5 Sep 2018 16:53:39 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.20] (nb-10688.ethz.ch [82.130.103.20]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 5 Sep 2018 16:53:39 +0200 (CEST) To: Joe Touch , Ignacio Goyret Cc: mankin@psg.com, rbonica@juniper.net, touch@isi.edu, tcpm@ietf.org, ietf@kuehlewind.net, spencerdawkins.ietf@gmail.com, tuexen@fh-muenster.de, RFC Errata System References: <20180503203252.D2005B82AA4@rfc-editor.org> <201805040027.w440R3ji011041@cliff.eng.ascend.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <518c945f-201d-3e20-4406-4135e182c6af@tik.ee.ethz.ch> Date: Wed, 5 Sep 2018 16:53:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------78E34ACC84D16EF045482813" Content-Language: en-US Archived-At: X-Mailman-Approved-At: Wed, 05 Sep 2018 08:53:06 -0700 Subject: Re: [tcpm] [Editorial Errata Reported] RFC5925 (5347) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Sep 2018 14:53:56 -0000 This is a multi-part message in MIME format. --------------78E34ACC84D16EF045482813 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Joe, hi Ignacio, is this something that I should set in the "Hold for Update" state? Mirja On 04.05.2018 03:54, Joe Touch wrote: > > > On 5/3/2018 5:20 PM, Ignacio Goyret wrote: >> The reason for the errata is because it happened: someone read >> that text and interpreted that the tcp checksum would only need >> to be cleared when only the TCP-AO option was included because the >> text stated "when included, only the TCP-AO MAC field is zeroed". >> Your suggested text addition does not address this incorrect >> interpretation. > It actually does directly, with this phrase: "within those options". > >> I also encountered someone that insisted that when only the TCP-AO >> option was included, that it was only the option data, not its header. > That is already addressed in the existing text directly here: > > "When TCP options are not included, all TCP options except for TCP- > AO are omitted from MAC processing." > > >> That's why a reference to section 2.2 sounds reasonable to me. > Adding the reference might be useful, but should not be strictly > necessary to interpret the existing text. > >> IMO, this is *exactly* the reason for an "editorial" errata. >> Technical details are not altered, just language clarifications >> to promote interoperability. I am not suggesting rewriting this or >> any other RFC. > There are many RFCs that have been misinterpreted. That doesn't always > warrant suggested alternate text. > > Joe > >> >> -Ignacio >> >> >> At 14:38 5/3/2018, Joe Touch wrote: >> >>> I do not agree that this is suggested text represents a clarification. >>> >>> At best, only the one sentence warrants clarification: >>> >>> From: When included, only the TCP-AO MAC field is zeroed. >>> >>> To: When TCP options are included, within those options only the TCP-AO MAC field is zeroed. >>> >>> >>> However, that context is implicit in the existing text. Yes, we could completely rewrite every RFC to be more clear, but that is not the purpose of errata nor is it productive, IMO. >>> >>> Joe >>> >>> On 2018-05-03 16:32, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC5925, >>>> "The TCP Authentication Option". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata/eid5347 >>>> >>>> -------------------------------------- >>>> Type: Editorial >>>> Reported by: Ignacio Goyret <ignacio.goyret@nokia.com> >>>> >>>> Section: 5.1 >>>> >>>> Original Text >>>> ------------- >>>> 3. The TCP header, by default including options, and where the TCP >>>> checksum and TCP-AO MAC fields are set to zero, all in network- >>>> byte order. >>>> >>>> The TCP option flag of the MKT indicates whether the TCP options >>>> are included in the MAC. When included, only the TCP-AO MAC field >>>> is zeroed. >>>> >>>> When TCP options are not included, all TCP options except for TCP- >>>> AO are omitted from MAC processing. Again, the TCP-AO MAC field >>>> is zeroed for the MAC processing. >>>> >>>> >>>> Corrected Text >>>> -------------- >>>> 3. The TCP header and TCP options, where the TCP checksum and TCP-AO >>>> MAC fields are always set to zero, all in network-byte order. >>>> >>>> The TCP option flag of the MKT indicates which TCP options are >>>> included in the MAC. When TCP options are not included, only the >>>> TCP option for TCP-AO (as described in Section 2.2) is included >>>> in the MAC. Otherwise, all the TCP options are included in the MAC. >>>> >>>> >>>> Notes >>>> ----- >>>> Rewording for clarity and simplification. >>>> The original text could lead to confusion re '...When included, only the TCP-AO MAC field is zeroed.' >>>> >>>> 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 >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) >>>> -------------------------------------- >>>> Title : The TCP Authentication Option >>>> Publication Date : June 2010 >>>> Author(s) : J. Touch, A. Mankin, R. Bonica >>>> Category : PROPOSED STANDARD >>>> Source : TCP Maintenance and Minor Extensions >>>> Area : Transport >>>> Stream : IETF >>>> Verifying Party : IESG > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --------------78E34ACC84D16EF045482813 Content-Type: text/x-vcard; name="mirja_kuehlewind.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mirja_kuehlewind.vcf" bnVsbA== --------------78E34ACC84D16EF045482813-- From nobody Wed Sep 5 12:45:18 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7996130DCF for ; Wed, 5 Sep 2018 12:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-SR1EUYRt-R for ; Wed, 5 Sep 2018 12:45:10 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E7A130DC7 for ; Wed, 5 Sep 2018 12:45:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 425Dgm5PmhzMnrW; Wed, 5 Sep 2018 21:45:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-OwpHI0wuud; Wed, 5 Sep 2018 21:45:07 +0200 (CEST) X-MtScore: NO score=0 Received: from vpn-global-dhcp2-51.ethz.ch (vpn-global-dhcp2-51.ethz.ch [129.132.209.51]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 5 Sep 2018 21:45:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <4c9ba64bef09362918acfb2d12a65eba@strayalpha.com> Date: Wed, 5 Sep 2018 21:45:06 +0200 Cc: Ignacio Goyret , "tcpm@ietf.org Extensions" , touch@isi.edu Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180503203252.D2005B82AA4@rfc-editor.org> <201805040027.w440R3ji011041@cliff.eng.ascend.com> <518c945f-201d-3e20-4406-4135e182c6af@tik.ee.ethz.ch> <4c9ba64bef09362918acfb2d12a65eba@strayalpha.com> To: Joe Touch X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [Editorial Errata Reported] RFC5925 (5347) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Sep 2018 19:45:16 -0000 If you could agree, I can update the errata. Thanks! > Am 05.09.2018 um 21:12 schrieb Joe Touch : >=20 >=20 >=20 > If we need an errata, we need to agree on the text, which we have not = yet. >=20 >=20 >=20 > Joe >=20 >=20 >=20 > On 2018-09-05 07:53, Mirja K=C3=BChlewind wrote: >=20 >> Hi Joe, hi Ignacio, >>=20 >> is this something that I should set in the "Hold for Update" state? >>=20 >> Mirja >>=20 >>=20 >>=20 >> On 04.05.2018 03:54, Joe Touch wrote: >>>=20 >>>=20 >>> On 5/3/2018 5:20 PM, Ignacio Goyret wrote: >>>> The reason for the errata is because it happened: someone read >>>> that text and interpreted that the tcp checksum would only need >>>> to be cleared when only the TCP-AO option was included because the >>>> text stated "when included, only the TCP-AO MAC field is zeroed". >>>> Your suggested text addition does not address this incorrect >>>> interpretation. >>> It actually does directly, with this phrase: "within those options". >>>=20 >>>> I also encountered someone that insisted that when only the TCP-AO >>>> option was included, that it was only the option data, not its = header. >>> That is already addressed in the existing text directly here: >>>=20 >>> "When TCP options are not included, all TCP options except for = TCP- >>> AO are omitted from MAC processing." >>>=20 >>>=20 >>>> That's why a reference to section 2.2 sounds reasonable to me. >>> Adding the reference might be useful, but should not be strictly >>> necessary to interpret the existing text. >>>=20 >>>> IMO, this is *exactly* the reason for an "editorial" errata. >>>> Technical details are not altered, just language clarifications >>>> to promote interoperability. I am not suggesting rewriting this or >>>> any other RFC. >>> There are many RFCs that have been misinterpreted. That doesn't = always >>> warrant suggested alternate text. >>>=20 >>> Joe >>>=20 >>>>=20 >>>> -Ignacio >>>>=20 >>>>=20 >>>> At 14:38 5/3/2018, Joe Touch wrote: >>>>=20 >>>>> I do not agree that this is suggested text represents a = clarification. >>>>>=20 >>>>> At best, only the one sentence warrants clarification: >>>>>=20 >>>>> From: When included, only the TCP-AO MAC field is zeroed. >>>>>=20 >>>>> To: When TCP options are included, within those options only the = TCP-AO MAC field is zeroed. >>>>>=20 >>>>>=20 >>>>> However, that context is implicit in the existing text. Yes, we = could completely rewrite every RFC to be more clear, but that is not the = purpose of errata nor is it productive, IMO. >>>>>=20 >>>>> Joe >>>>>=20 >>>>> On 2018-05-03 16:32, RFC Errata System wrote: >>>>>> The following errata report has been submitted for RFC5925, >>>>>> "The TCP Authentication Option". >>>>>>=20 >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> = http://www.rfc-editor.org/errata= /eid5347 >>>>>>=20 >>>>>> -------------------------------------- >>>>>> Type: Editorial >>>>>> Reported by: Ignacio Goyret = <ignacio.goyret@nokia.com> >>>>>>=20 >>>>>> Section: 5.1 >>>>>>=20 >>>>>> Original Text >>>>>> ------------- >>>>>> 3. The TCP header, by default including options, and where the = TCP >>>>>> checksum and TCP-AO MAC fields are set to zero, all in = network- >>>>>> byte order. >>>>>>=20 >>>>>> The TCP option flag of the MKT indicates whether the TCP = options >>>>>> are included in the MAC. When included, only the TCP-AO MAC = field >>>>>> is zeroed. >>>>>>=20 >>>>>> When TCP options are not included, all TCP options except for = TCP- >>>>>> AO are omitted from MAC processing. Again, the TCP-AO MAC = field >>>>>> is zeroed for the MAC processing. >>>>>>=20 >>>>>>=20 >>>>>> Corrected Text >>>>>> -------------- >>>>>> 3. The TCP header and TCP options, where the TCP checksum and = TCP-AO >>>>>> MAC fields are always set to zero, all in network-byte order. >>>>>>=20 >>>>>> The TCP option flag of the MKT indicates which TCP options are >>>>>> included in the MAC. When TCP options are not included, only = the >>>>>> TCP option for TCP-AO (as described in Section 2.2) is = included >>>>>> in the MAC. Otherwise, all the TCP options are included in the = MAC. >>>>>>=20 >>>>>>=20 >>>>>> Notes >>>>>> ----- >>>>>> Rewording for clarity and simplification. >>>>>> The original text could lead to confusion re '...When included, = only the TCP-AO MAC field is zeroed.' >>>>>>=20 >>>>>> 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 >>>>>> can log in to change the status and edit the report, if = necessary. >>>>>>=20 >>>>>> -------------------------------------- >>>>>> RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) >>>>>> -------------------------------------- >>>>>> Title : The TCP Authentication Option >>>>>> Publication Date : June 2010 >>>>>> Author(s) : J. Touch, A. Mankin, R. Bonica >>>>>> Category : PROPOSED STANDARD >>>>>> Source : TCP Maintenance and Minor Extensions >>>>>> Area : Transport >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Sep 5 13:29:00 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA592130DC9 for ; Wed, 5 Sep 2018 13:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM-RmGQfpTfn for ; Wed, 5 Sep 2018 13:28:54 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 20EC6130DC7 for ; Wed, 5 Sep 2018 13:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q/56gd9sqrTCAaxRJo66FovcnTchlOvHlPDnUZIPT2o=; b=BEKrCwabQPp4GbFSDQlIG+kWa KiP0Vh4rbuvojHpFwRwF50m9Nu9ITJ/fkpWvqrX0/lnWdD8Yql3lu/diYe2/etwHNCdtvaw9bgey7 Qvrsu1Lb64jPpAXvPa5Cfkf/8QCjO5uK2RlcjlyL+vK0UCaQraVRsu0cnz9mhiAUUQSmUJoj0CcUs XPAowp2sDiXNcum79It+gt+EUBV+FYLq6KqIbbh+C5tRjzCohpxrTgYPvAMHl4wd6VzOjM6FyFOMa 3FIuSCIXvPfcNixD6/2XeLD+0h7yVLNzwwgVaRvjlo82uVk9EySgqpc18dzT2O2ycVbS8vjEqwGgQ ZVO0ZjgVQ==; Received: from [204.140.240.55] (port=55519 helo=[172.26.62.97]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fxePr-0036rg-P8; Wed, 05 Sep 2018 16:28:52 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Wed, 5 Sep 2018 13:28:18 -0700 Cc: Ignacio Goyret , "tcpm@ietf.org Extensions" , touch@isi.edu Content-Transfer-Encoding: quoted-printable Message-Id: <9C4A5263-1653-42EE-B386-161AB97F880F@strayalpha.com> References: <20180503203252.D2005B82AA4@rfc-editor.org> <201805040027.w440R3ji011041@cliff.eng.ascend.com> <518c945f-201d-3e20-4406-4135e182c6af@tik.ee.ethz.ch> <4c9ba64bef09362918acfb2d12a65eba@strayalpha.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [Editorial Errata Reported] RFC5925 (5347) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Sep 2018 20:28:57 -0000 We can that that off list and converge and get back to you.=20 Joe > On Sep 5, 2018, at 12:45 PM, Mirja K=C3=BChlewind wrote: >=20 > If you could agree, I can update the errata. Thanks! >=20 >> Am 05.09.2018 um 21:12 schrieb Joe Touch : >>=20 >>=20 >>=20 >> If we need an errata, we need to agree on the text, which we have not yet= . >>=20 >>=20 >>=20 >> Joe >>=20 >>=20 >>=20 >>> On 2018-09-05 07:53, Mirja K=C3=BChlewind wrote: >>>=20 >>> Hi Joe, hi Ignacio, >>>=20 >>> is this something that I should set in the "Hold for Update" state? >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >>>> On 04.05.2018 03:54, Joe Touch wrote: >>>>=20 >>>>=20 >>>>> On 5/3/2018 5:20 PM, Ignacio Goyret wrote: >>>>> The reason for the errata is because it happened: someone read >>>>> that text and interpreted that the tcp checksum would only need >>>>> to be cleared when only the TCP-AO option was included because the >>>>> text stated "when included, only the TCP-AO MAC field is zeroed". >>>>> Your suggested text addition does not address this incorrect >>>>> interpretation. >>>> It actually does directly, with this phrase: "within those options". >>>>=20 >>>>> I also encountered someone that insisted that when only the TCP-AO >>>>> option was included, that it was only the option data, not its header.= >>>> That is already addressed in the existing text directly here: >>>>=20 >>>> "When TCP options are not included, all TCP options except for TCP- >>>> AO are omitted from MAC processing." >>>>=20 >>>>=20 >>>>> That's why a reference to section 2.2 sounds reasonable to me. >>>> Adding the reference might be useful, but should not be strictly >>>> necessary to interpret the existing text. >>>>=20 >>>>> IMO, this is *exactly* the reason for an "editorial" errata. >>>>> Technical details are not altered, just language clarifications >>>>> to promote interoperability. I am not suggesting rewriting this or >>>>> any other RFC. >>>> There are many RFCs that have been misinterpreted. That doesn't always >>>> warrant suggested alternate text. >>>>=20 >>>> Joe >>>>=20 >>>>>=20 >>>>> -Ignacio >>>>>=20 >>>>>=20 >>>>> At 14:38 5/3/2018, Joe Touch wrote: >>>>>=20 >>>>>> I do not agree that this is suggested text represents a clarification= . >>>>>>=20 >>>>>> At best, only the one sentence warrants clarification: >>>>>>=20 >>>>>> From: When included, only the TCP-AO MAC field is zeroed. >>>>>>=20 >>>>>> To: When TCP options are included, within those options only the TCP-= AO MAC field is zeroed. >>>>>>=20 >>>>>>=20 >>>>>> However, that context is implicit in the existing text. Yes, we could= completely rewrite every RFC to be more clear, but that is not the purpose o= f errata nor is it productive, IMO. >>>>>>=20 >>>>>> Joe >>>>>>=20 >>>>>>> On 2018-05-03 16:32, RFC Errata System wrote: >>>>>>> The following errata report has been submitted for RFC5925, >>>>>>> "The TCP Authentication Option". >>>>>>>=20 >>>>>>> -------------------------------------- >>>>>>> You may review the report below and at: >>>>>>> http://www.rfc-editor.org/= errata/eid5347 >>>>>>>=20 >>>>>>> -------------------------------------- >>>>>>> Type: Editorial >>>>>>> Reported by: Ignacio Goyret <ignaci= o.goyret@nokia.com> >>>>>>>=20 >>>>>>> Section: 5.1 >>>>>>>=20 >>>>>>> Original Text >>>>>>> ------------- >>>>>>> 3. The TCP header, by default including options, and where the TCP >>>>>>> checksum and TCP-AO MAC fields are set to zero, all in network- >>>>>>> byte order. >>>>>>>=20 >>>>>>> The TCP option flag of the MKT indicates whether the TCP options >>>>>>> are included in the MAC. When included, only the TCP-AO MAC field= >>>>>>> is zeroed. >>>>>>>=20 >>>>>>> When TCP options are not included, all TCP options except for TCP-= >>>>>>> AO are omitted from MAC processing. Again, the TCP-AO MAC field >>>>>>> is zeroed for the MAC processing. >>>>>>>=20 >>>>>>>=20 >>>>>>> Corrected Text >>>>>>> -------------- >>>>>>> 3. The TCP header and TCP options, where the TCP checksum and TCP-AO= >>>>>>> MAC fields are always set to zero, all in network-byte order. >>>>>>>=20 >>>>>>> The TCP option flag of the MKT indicates which TCP options are >>>>>>> included in the MAC. When TCP options are not included, only the >>>>>>> TCP option for TCP-AO (as described in Section 2.2) is included >>>>>>> in the MAC. Otherwise, all the TCP options are included in the MAC= . >>>>>>>=20 >>>>>>>=20 >>>>>>> Notes >>>>>>> ----- >>>>>>> Rewording for clarity and simplification. >>>>>>> The original text could lead to confusion re '...When included, only= the TCP-AO MAC field is zeroed.' >>>>>>>=20 >>>>>>> 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 >>>>>>> can log in to change the status and edit the report, if necessary. >>>>>>>=20 >>>>>>> -------------------------------------- >>>>>>> RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) >>>>>>> -------------------------------------- >>>>>>> Title : The TCP Authentication Option >>>>>>> Publication Date : June 2010 >>>>>>> Author(s) : J. Touch, A. Mankin, R. Bonica >>>>>>> Category : PROPOSED STANDARD >>>>>>> Source : TCP Maintenance and Minor Extensions >>>>>>> Area : Transport >>>>>>> Stream : IETF >>>>>>> Verifying Party : IESG >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Thu Sep 6 01:13:08 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE02C130E06 for ; Thu, 6 Sep 2018 01:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKlwSc5iUkpf for ; Thu, 6 Sep 2018 01:13:04 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505D91277D2 for ; Thu, 6 Sep 2018 01:13:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 425YGk4ZMBzMnsr; Thu, 6 Sep 2018 10:13:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plYX4fYhzpsm; Thu, 6 Sep 2018 10:13:00 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.20] (nb-10688.ethz.ch [82.130.103.20]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 6 Sep 2018 10:13:00 +0200 (CEST) To: Joe Touch Cc: Ignacio Goyret , "tcpm@ietf.org Extensions" , touch@isi.edu References: <20180503203252.D2005B82AA4@rfc-editor.org> <201805040027.w440R3ji011041@cliff.eng.ascend.com> <518c945f-201d-3e20-4406-4135e182c6af@tik.ee.ethz.ch> <4c9ba64bef09362918acfb2d12a65eba@strayalpha.com> <9C4A5263-1653-42EE-B386-161AB97F880F@strayalpha.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 6 Sep 2018 10:13:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9C4A5263-1653-42EE-B386-161AB97F880F@strayalpha.com> Content-Type: multipart/mixed; boundary="------------BA4D6828241A6DD49D9573B1" Content-Language: en-US Archived-At: Subject: Re: [tcpm] [Editorial Errata Reported] RFC5925 (5347) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 06 Sep 2018 08:13:07 -0000 This is a multi-part message in MIME format. --------------BA4D6828241A6DD49D9573B1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit That would be great! Thanks! On 05.09.2018 22:28, Joe Touch wrote: > We can that that off list and converge and get back to you. > > Joe > >> On Sep 5, 2018, at 12:45 PM, Mirja Kühlewind wrote: >> >> If you could agree, I can update the errata. Thanks! >> >>> Am 05.09.2018 um 21:12 schrieb Joe Touch : >>> >>> >>> >>> If we need an errata, we need to agree on the text, which we have not yet. >>> >>> >>> >>> Joe >>> >>> >>> >>>> On 2018-09-05 07:53, Mirja Kühlewind wrote: >>>> >>>> Hi Joe, hi Ignacio, >>>> >>>> is this something that I should set in the "Hold for Update" state? >>>> >>>> Mirja >>>> >>>> >>>> >>>>> On 04.05.2018 03:54, Joe Touch wrote: >>>>> >>>>> >>>>>> On 5/3/2018 5:20 PM, Ignacio Goyret wrote: >>>>>> The reason for the errata is because it happened: someone read >>>>>> that text and interpreted that the tcp checksum would only need >>>>>> to be cleared when only the TCP-AO option was included because the >>>>>> text stated "when included, only the TCP-AO MAC field is zeroed". >>>>>> Your suggested text addition does not address this incorrect >>>>>> interpretation. >>>>> It actually does directly, with this phrase: "within those options". >>>>> >>>>>> I also encountered someone that insisted that when only the TCP-AO >>>>>> option was included, that it was only the option data, not its header. >>>>> That is already addressed in the existing text directly here: >>>>> >>>>> "When TCP options are not included, all TCP options except for TCP- >>>>> AO are omitted from MAC processing." >>>>> >>>>> >>>>>> That's why a reference to section 2.2 sounds reasonable to me. >>>>> Adding the reference might be useful, but should not be strictly >>>>> necessary to interpret the existing text. >>>>> >>>>>> IMO, this is *exactly* the reason for an "editorial" errata. >>>>>> Technical details are not altered, just language clarifications >>>>>> to promote interoperability. I am not suggesting rewriting this or >>>>>> any other RFC. >>>>> There are many RFCs that have been misinterpreted. That doesn't always >>>>> warrant suggested alternate text. >>>>> >>>>> Joe >>>>> >>>>>> >>>>>> -Ignacio >>>>>> >>>>>> >>>>>> At 14:38 5/3/2018, Joe Touch wrote: >>>>>> >>>>>>> I do not agree that this is suggested text represents a clarification. >>>>>>> >>>>>>> At best, only the one sentence warrants clarification: >>>>>>> >>>>>>> From: When included, only the TCP-AO MAC field is zeroed. >>>>>>> >>>>>>> To: When TCP options are included, within those options only the TCP-AO MAC field is zeroed. >>>>>>> >>>>>>> >>>>>>> However, that context is implicit in the existing text. Yes, we could completely rewrite every RFC to be more clear, but that is not the purpose of errata nor is it productive, IMO. >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>>> On 2018-05-03 16:32, RFC Errata System wrote: >>>>>>>> The following errata report has been submitted for RFC5925, >>>>>>>> "The TCP Authentication Option". >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> You may review the report below and at: >>>>>>>> http://www.rfc-editor.org/errata/eid5347 >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> Type: Editorial >>>>>>>> Reported by: Ignacio Goyret <ignacio.goyret@nokia.com> >>>>>>>> >>>>>>>> Section: 5.1 >>>>>>>> >>>>>>>> Original Text >>>>>>>> ------------- >>>>>>>> 3. The TCP header, by default including options, and where the TCP >>>>>>>> checksum and TCP-AO MAC fields are set to zero, all in network- >>>>>>>> byte order. >>>>>>>> >>>>>>>> The TCP option flag of the MKT indicates whether the TCP options >>>>>>>> are included in the MAC. When included, only the TCP-AO MAC field >>>>>>>> is zeroed. >>>>>>>> >>>>>>>> When TCP options are not included, all TCP options except for TCP- >>>>>>>> AO are omitted from MAC processing. Again, the TCP-AO MAC field >>>>>>>> is zeroed for the MAC processing. >>>>>>>> >>>>>>>> >>>>>>>> Corrected Text >>>>>>>> -------------- >>>>>>>> 3. The TCP header and TCP options, where the TCP checksum and TCP-AO >>>>>>>> MAC fields are always set to zero, all in network-byte order. >>>>>>>> >>>>>>>> The TCP option flag of the MKT indicates which TCP options are >>>>>>>> included in the MAC. When TCP options are not included, only the >>>>>>>> TCP option for TCP-AO (as described in Section 2.2) is included >>>>>>>> in the MAC. Otherwise, all the TCP options are included in the MAC. >>>>>>>> >>>>>>>> >>>>>>>> Notes >>>>>>>> ----- >>>>>>>> Rewording for clarity and simplification. >>>>>>>> The original text could lead to confusion re '...When included, only the TCP-AO MAC field is zeroed.' >>>>>>>> >>>>>>>> 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 >>>>>>>> can log in to change the status and edit the report, if necessary. >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) >>>>>>>> -------------------------------------- >>>>>>>> Title : The TCP Authentication Option >>>>>>>> Publication Date : June 2010 >>>>>>>> Author(s) : J. Touch, A. Mankin, R. Bonica >>>>>>>> Category : PROPOSED STANDARD >>>>>>>> Source : TCP Maintenance and Minor Extensions >>>>>>>> Area : Transport >>>>>>>> Stream : IETF >>>>>>>> Verifying Party : IESG >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >> > --------------BA4D6828241A6DD49D9573B1 Content-Type: text/x-vcard; name="mirja_kuehlewind.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mirja_kuehlewind.vcf" bnVsbA== --------------BA4D6828241A6DD49D9573B1-- From nobody Thu Sep 6 11:10:37 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E101E12F1A5 for ; Wed, 5 Sep 2018 12:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzjfbXP0Ytv6 for ; Wed, 5 Sep 2018 12:12:55 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C13D41271FF for ; Wed, 5 Sep 2018 12:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ONecWPmvZe+2hODdP5lJrAxagUX8syqQjDqiBQuXxTU=; b=SbTsWzXADU2S5mbis2z8myW2r 3T8LcFnDY13d9rpMzXDWL9eK5u4p0PfecOLCVtkeYkJxO9oqswOF5G0mK3OpESUvCwNlMwXotF1yD eJgeBEkMH1cSnJsKYEk9k9jmUvnzc3098DFxNk2fQQh53c3zDZuE9OxhjdS9gIBYI39qAxxHcsmWT 8xPsCkPT0RCGNjFJKa3PDeMQzDxFn4G7R2YzNzVpVXW253XxXK9r7C03kIZ/t8lbsBQ+rObEuy9R5 Bv+HgAif+OnqcyuRb6wMv3LhbcktXDB9T5clB+egv5aM5cATn1ChCi5b2KYASHokEFCZAi7AU6W+m xn/b5FVPw==; Received: from [::1] (port=53684 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from ) id 1fxdEL-002HLW-3U; Wed, 05 Sep 2018 15:12:52 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b55991603a396f58671b0f1c1686fdf0" Date: Wed, 05 Sep 2018 12:12:44 -0700 From: Joe Touch To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Ignacio Goyret , tcpm@ietf.org, touch@isi.edu, rbonica@juniper.net, mankin@psg.com, ietf@kuehlewind.net, spencerdawkins.ietf@gmail.com, tuexen@fh-muenster.de, RFC Errata System In-Reply-To: <518c945f-201d-3e20-4406-4135e182c6af@tik.ee.ethz.ch> References: <20180503203252.D2005B82AA4@rfc-editor.org> <201805040027.w440R3ji011041@cliff.eng.ascend.com> <518c945f-201d-3e20-4406-4135e182c6af@tik.ee.ethz.ch> Message-ID: <4c9ba64bef09362918acfb2d12a65eba@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.3 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-Mailman-Approved-At: Thu, 06 Sep 2018 11:10:35 -0700 Subject: Re: [tcpm] [Editorial Errata Reported] RFC5925 (5347) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Sep 2018 19:12:59 -0000 --=_b55991603a396f58671b0f1c1686fdf0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 If we need an errata, we need to agree on the text, which we have not yet. Joe On 2018-09-05 07:53, Mirja Kühlewind wrote: > Hi Joe, hi Ignacio, > > is this something that I should set in the "Hold for Update" state? > > Mirja > > On 04.05.2018 03:54, Joe Touch wrote: > > On 5/3/2018 5:20 PM, Ignacio Goyret wrote: The reason for the errata is because it happened: someone read > that text and interpreted that the tcp checksum would only need > to be cleared when only the TCP-AO option was included because the > text stated "when included, only the TCP-AO MAC field is zeroed". > Your suggested text addition does not address this incorrect > interpretation. It actually does directly, with this phrase: "within those options". > > I also encountered someone that insisted that when only the TCP-AO > option was included, that it was only the option data, not its header. That is already addressed in the existing text directly here: > > "When TCP options are not included, all TCP options except for TCP- > AO are omitted from MAC processing." > > That's why a reference to section 2.2 sounds reasonable to me. Adding the reference might be useful, but should not be strictly > necessary to interpret the existing text. > > IMO, this is *exactly* the reason for an "editorial" errata. > Technical details are not altered, just language clarifications > to promote interoperability. I am not suggesting rewriting this or > any other RFC. There are many RFCs that have been misinterpreted. That doesn't always > warrant suggested alternate text. > > Joe > > -Ignacio > > At 14:38 5/3/2018, Joe Touch wrote: > > I do not agree that this is suggested text represents a clarification. > > At best, only the one sentence warrants clarification: > > From: When included, only the TCP-AO MAC field is zeroed. > > To: When TCP options are included, within those options only the TCP-AO MAC field is zeroed. > > However, that context is implicit in the existing text. Yes, we could completely rewrite every RFC to be more clear, but that is not the purpose of errata nor is it productive, IMO. > > Joe > > On 2018-05-03 16:32, RFC Errata System wrote: The following errata report has been submitted for RFC5925, > "The TCP Authentication Option". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5347 > > -------------------------------------- > Type: Editorial > Reported by: Ignacio Goyret <ignacio.goyret@nokia.com> > > Section: 5.1 > > Original Text > ------------- > 3. The TCP header, by default including options, and where the TCP > checksum and TCP-AO MAC fields are set to zero, all in network- > byte order. > > The TCP option flag of the MKT indicates whether the TCP options > are included in the MAC. When included, only the TCP-AO MAC field > is zeroed. > > When TCP options are not included, all TCP options except for TCP- > AO are omitted from MAC processing. Again, the TCP-AO MAC field > is zeroed for the MAC processing. > > Corrected Text > -------------- > 3. The TCP header and TCP options, where the TCP checksum and TCP-AO > MAC fields are always set to zero, all in network-byte order. > > The TCP option flag of the MKT indicates which TCP options are > included in the MAC. When TCP options are not included, only the > TCP option for TCP-AO (as described in Section 2.2) is included > in the MAC. Otherwise, all the TCP options are included in the MAC. > > Notes > ----- > Rewording for clarity and simplification. > The original text could lead to confusion re '...When included, only the TCP-AO MAC field is zeroed.' > > 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 > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) > -------------------------------------- > Title : The TCP Authentication Option > Publication Date : June 2010 > Author(s) : J. Touch, A. Mankin, R. Bonica > Category : PROPOSED STANDARD > Source : TCP Maintenance and Minor Extensions > Area : Transport > Stream : IETF > Verifying Party : IESG _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --=_b55991603a396f58671b0f1c1686fdf0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


If we need an errata, we need to agree on the text, which we have not ye= t.


Joe


On 2018-09-05 07:53, Mirja Kühlewind wrote:

= Hi Joe, hi Ignacio,

is this somet= hing that I should set in the "Hold = ;for Update" state?

Mirja


On 04.05.2018 03:54, = ;Joe Touch wrote:


On&nb= sp;5/3/2018 5:20 PM, Ignacio Goyret wrote:
The reason&n= bsp;for the errata is because it happened:&nb= sp;someone read
that&= nbsp;text and interpreted that the tcp checks= um would only need
to be cleared when only the TCP-AO&nb= sp;option was included because the
text stated "when included,&nbs= p;only the TCP-AO MAC field is zeroed".
Your suggested text&n= bsp;addition does not address this incorrect
interpretation. It actually does direct= ly, with this phrase: "within those options"= =2E

I also = encountered someone that insisted that when o= nly the TCP-AO
o= ption was included, that it was only the=  option data, not its header.
That is already address= ed in the existing text directly here:=

   "When&nb= sp;TCP options are not included, all TCP = ;options except for TCP-
   AO are omitted from MAC=  processing."


That's why&n= bsp;a reference to section 2.2 sounds reasona= ble to me.
Adding the reference mi= ght be useful, but should not be strictl= y
necessary to i= nterpret the existing text.

IMO, this&nb= sp;is *exactly* the reason for an "editorial"=  errata.
Technical&nb= sp;details are not altered, just language cla= rifications
to promot= e interoperability. I am not suggesting rewri= ting this or
any=  other RFC.
There are many RFCs&nbs= p;that have been misinterpreted. That doesn't = ;always
warrant sugge= sted alternate text.

Joe


-Ignacio


At 14:38&nb= sp;5/3/2018, Joe Touch wrote:

I do no= t agree that this is suggested text repr= esents a clarification.

At best, only the one sentence = warrants clarification:

From: When included, only the TCP-AO = ;MAC field is zeroed.

To: When TCP options are included= , within those options only the TCP-AO M= AC field is zeroed.


However, that context is implicit&= nbsp;in the existing text. Yes, we could = ;completely rewrite every RFC to be more = ;clear, but that is not the purpose of&n= bsp;errata nor is it productive, IMO.
=
Joe

On 2018-05-= 03 16:32, RFC Errata System wrote:
The followin= g errata report has been submitted for R= FC5925,
"The TCP = ;Authentication Option".

--------------------------------------
You may review the report b= elow and at:
<= ;http://www.rfc-editor.org/errata/eid5347>http://www.rfc-editor.org/errata/eid5347
----------------------------= ----------
Type: Edit= orial
Reported by:&nb= sp;Ignacio Goyret <<mailto:ignacio.goyret@nokia.com>ignacio.goyret@nokia.com>

Section: 5.1

Original Text
-------------
3. The TCP header, by default includin= g options, and where the TCP
   checksum and TCP-AO=  MAC fields are set to zero, all in=  network-
  = ; byte order.

   The TCP option flag of the&n= bsp;MKT indicates whether the TCP options   are include= d in the MAC.  When included, only = the TCP-AO MAC field
   is zeroed.

   When TCP options = ;are not included, all TCP options except&nbs= p;for TCP-
 &nbs= p; AO are omitted from MAC processing. &= nbsp;Again, the TCP-AO MAC field
   is zeroed for t= he MAC processing.


Corrected Text
--------------
3= =2E The TCP header and TCP options, wher= e the TCP checksum and TCP-AO
   MAC fields are&nbs= p;always set to zero, all in network-byte&nbs= p;order.

  = ; The TCP option flag of the MKT in= dicates which TCP options are
   included in the = MAC. When TCP options are not included, = only the
  =  TCP option for TCP-AO (as described in&= nbsp;Section 2.2) is included
   in the MAC. Otherwise,&= nbsp;all the TCP options are included in = ;the MAC.


Notes
-----
Rewordi= ng for clarity and simplification.
The original text could le= ad to confusion re '...When included, only&nb= sp;the TCP-AO MAC field is zeroed.'
Instructions:
-------------
This erratum is currently posted = as "Reported". If necessary, please
use "Reply All" to discus= s whether it should be verified or
rejected. When a deci= sion is reached, the verifying party
<= span style=3D"white-space: nowrap;">can log in to chang= e the status and edit the report, if&nbs= p;necessary.

-------= -------------------------------
RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11)
--------------------------------------Title     =           : The = ;TCP Authentication Option
Publication Date    : June 20= 10
Author(s)  &n= bsp;        : J. Touch,&n= bsp;A. Mankin, R. Bonica
Category         = ;   : PROPOSED STANDARD
Source       &nbs= p;      : TCP Maintenance and&= nbsp;Minor Extensions
Area           &nbs= p;    : Transport
Stream        &nbs= p;     : IETF
Verifying Party     : = IESG

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


= _______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--=_b55991603a396f58671b0f1c1686fdf0-- From nobody Mon Sep 10 01:05:58 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 050B612008A; Mon, 10 Sep 2018 01:05:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: nishida@sfc.wide.ad.jp, tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153656675698.26481.9045347310182494935.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2018 01:05:56 -0700 Archived-At: Subject: [tcpm] tcpm - New Meeting Session Request for IETF 103 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 08:05:57 -0000 A new meeting session request has just been submitted by Yoshifumi Nishida, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Yoshifumi Nishida Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas Third Priority: rtcweb maprg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Sep 11 03:16:57 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204D21310CA for ; Tue, 11 Sep 2018 03:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fifY81bqtjv for ; Tue, 11 Sep 2018 03:16:52 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B72127332 for ; Tue, 11 Sep 2018 03:16:52 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id q4-v6so3081453iob.8 for ; Tue, 11 Sep 2018 03:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mo4LnNx8PquPQ72bf7ihQz4/Ji0un3Ksuh4kj9VrTGQ=; b=O5Kxs8coO2PXhizRsVjczvQ/0tUv0HqU2wQHJuOPnp+EFW/X+JlpzTGce0/mnADyoC UZIt7a58a8GY0YCQbjORU1s7sGTx2xWjYYBiCNz4aZFxrN2YvgHjIi11EhcWEvaO9lOc QJfW9RY8L9Xcxoc7XQMjCT00eXpYt6dJ3WAZqNnVXxV6LNn9Y49I2xVOL6o63lJK1CuV b6xfhQmsG96tUjiZXLJVXsFDY0n7PvoT7PTgJ0WoYp539l//mx7Wm8FzTgQvJzeYTjAH Z99cUuuaD6+fN7Ni+35YtBNplvvphwVuMuAhG6J36E1XISvfZPb6ZMWs9kapKTt7+uRq 83tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mo4LnNx8PquPQ72bf7ihQz4/Ji0un3Ksuh4kj9VrTGQ=; b=RS3R5sAlzSNQDwiyToa6XUpMBla0pRCvVpl2MHYPL/he81587URQzvR8pxUTGlOISM ghTg/dXh5LMKP1HgXHpVS5xoGfPs38C29yyo/Wtk2v6ZVKQxBf82nnGi86UDMre3egWA Bn7PAvV5owPNQbM6y5QWFsktCxZ4VvH7TU397BX9bAA2rkedoI8S7hodi0EkWnDDcXLk FXygVnjkoTpU2JUCSbXAeAl9J3ueDp378VgsxJ0jhdzEdiWjWW36tvfQpl1aMo/Nv6B0 KO8WKL/f1juCYzLjgVMrlyCJeDSvEDxCb9WQAHMFzL53sDY78KeSEAKEl+clKQM0H04w uzyQ== X-Gm-Message-State: APzg51AanAO7D4So3zlFNNdvaWcwNHJnTAqv5sAq+fAh7wF9b5AlNVdZ dCyaNpBYnrPdrgGIZSxcdq9aQJ98uUK2+Gh7CxY= X-Google-Smtp-Source: ANB0Vda0KbJMms/a55HjkLAdZGOqJbeVp/s+UB983RzNbg7Uxmmt0t3IddAWGaue0joJ/i9RujG1+AHWXzlQv+0UiYo= X-Received: by 2002:a6b:c586:: with SMTP id v128-v6mr19875704iof.7.1536661011631; Tue, 11 Sep 2018 03:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:f741:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 03:16:51 -0700 (PDT) In-Reply-To: References: From: Loganaden Velvindron Date: Tue, 11 Sep 2018 14:16:51 +0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Sep 2018 10:16:55 -0000 On Fri, Aug 24, 2018 at 6:07 PM, Mirja K=C3=BChlewind wrote: > Hi, > > my personal opinion: > > I agree that documenting the problem and recommending the implementation = of per-socket limits would be a useful thing to do. > > I don=E2=80=99t think it is appropriated or needed to update or even depr= ecate/ RFC5961, therefore I would strongly support the changes to this draf= t as you described below. > > Mirja > Thank you Mirja. I have updated the I-D, and removed all texts which suggested updates or deprecation of RFC5961. Feedback/opinions welcomed: https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03 From nobody Tue Sep 11 19:05:29 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C3F130DC1; Tue, 11 Sep 2018 19:05:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tcpm-alternativebackoff-ecn@ietf.org, =?utf-8?q?Michael_T=C3=BCxen?= , tcpm-chairs@ietf.org, tuexen@fh-muenster.de, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153671792220.16917.2738782205833501417.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 19:05:22 -0700 Archived-At: Subject: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-alternativebackoff-ecn-11: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 02:05:22 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tcpm-alternativebackoff-ecn-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for section 8. Please expand PIE and CoDel on first mention. From nobody Wed Sep 12 19:13:01 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41050130F40; Wed, 12 Sep 2018 19:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=QSQEecKK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=s+idFcOr 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 aRyZQ7kb3Glt; Wed, 12 Sep 2018 19:12:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EFBF130F3F; Wed, 12 Sep 2018 19:12:50 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AF675219E6; Wed, 12 Sep 2018 22:12:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 12 Sep 2018 22:12:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=DfzN1YiiYuK+i3ZLoG5PqTOxGMDJF QCHEtX76nxx1Tk=; b=QSQEecKKprtP0DE5crHu2uHotCbRI32Ey2p3tmt6neWsD hhpQBX7UfhBvQV2QRM2n1mcgSdgI4p1tgsqTz6uSxCEa+0kycLyCptPFnsu9+uyJ oyuok2QYSqJi2DEdkPnZDz+DAtXVV/XzHx+e5Wb/9FAy8Y2sX+Ly7FDzYhA3SR69 OffxwkB7fOU1vbCyxy18SJpYYtM3PMkZFSriU7dCMsjCwrpGcveCQvtBdx703p0H 0g3EGQR7DAPc0PGHot6KJFmdBn+nBJSgK0h3Fqe6f1mYkrdsxbjQ9nFmURr6Kqcd 8ramEBBTNhb4g6PXjwlwsn0uuEs+VjpllaEvRJCYQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=DfzN1Y iiYuK+i3ZLoG5PqTOxGMDJFQCHEtX76nxx1Tk=; b=s+idFcOr7DhH1QLhNsfUHi c0KIgO68dwWMp/ypUcYk7pua1qpxjHojMQ/YykYMNkezm4DkfweVAU0nz/mEPnLa uSHzL7Bue+aN2hl6vV/tDQzrbZExxfH7LK2ju5tqnCb5z4vV3BXF+9fs9P9INqqy Dgu8HCztPCpqqYGDxKzJklByBwyNGqS/okWNtXaCeF0zh98yzI8/2Vc+Z6WoODtB Jbe7WmrQ/GkC25/gTnOIDNYtdvw0v3y64WZbankfKGttSwNcbImfZwQseVVbG2pv 5BGo8Ry7rpjUXHRyouFq6hiJDEtO7pYp1SpuHa0A+MdHiA8iGwwzUCsHXoEWerkg == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A6A9102E2; Wed, 12 Sep 2018 22:12:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <153452985801.18009.2900521078281198682@ietfa.amsl.com> Date: Wed, 12 Sep 2018 22:12:45 -0400 Cc: gen-art , tcpm@ietf.org, draft-ietf-tcpm-alternativebackoff-ecn.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <454E8E3D-F192-44FF-8DE7-19D3A1446942@cooperw.in> References: <153452985801.18009.2900521078281198682@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] [Gen-art] Genart last call review of draft-ietf-tcpm-alternativebackoff-ecn-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 02:12:54 -0000 Russ, thanks for your review. Gorry, thanks for your response. I have = entered a No Objection ballot. Alissa > On Aug 17, 2018, at 2:17 PM, Russ Housley = wrote: >=20 > Reviewer: Russ Housley > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-tcpm-alternativebackoff-ecn-09 > Reviewer: Russ Housley > Review Date: 2018-08-17 > IETF LC End Date: 2018-08-28 > IESG Telechat date: unknown >=20 > Summary: Ready >=20 >=20 > Major Concerns: >=20 > None >=20 >=20 > Minor Concerns: >=20 > Section 2: Please update the first paragraph to reference RFC 8174 > in addition to RFC 2119, as follows:=20 >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in = BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. >=20 > Section 12.1: Please add a normative reference to RFC 7926. >=20 >=20 > Nits: >=20 > Abstract: s/RFC3168/RFC 3168/ >=20 > Section 1: s/RFC8087 [RFC8087]/[RFC8087]/ >=20 > Section 1 says: >=20 > However, currently used loss-based congestion control mechanisms > cannot always utilise a bottleneck link well where there are short > queues. >=20 > I stumbled on this sentence. Maybe it would read better if you said > that current mechanisms sometimes provides poor link utilization when > queues are short. >=20 > Section 1: s/allow for short queues only/allow only for short queues/ >=20 > Section 6: s/RFC3168 states/[RFC3168] states/ and > s/dropped packet [RFC3168]./dropped packet./ >=20 > Section 6: s/the TCPM WG or IESG/the TCPM WG or the IESG/ >=20 > Section 7" s/TCPM working group/TCPM Working Group/ or /TCPM WG/ >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Sep 12 19:51:57 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CDA1271FF; Wed, 12 Sep 2018 19:51:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tcpm-alternativebackoff-ecn@ietf.org, =?utf-8?q?Michael_T=C3=BCxen?= , tcpm-chairs@ietf.org, tuexen@fh-muenster.de, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153680710893.9432.14024338054788704789.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2018 19:51:48 -0700 Archived-At: Subject: [tcpm] Adam Roach's Yes on draft-ietf-tcpm-alternativebackoff-ecn-11: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 02:51:50 -0000 Adam Roach has entered the following ballot position for draft-ietf-tcpm-alternativebackoff-ecn-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a well-written and easy-to-understand document. I find the proposed experiment quite interesting. I have a small number of editorial nits that you may want to address if you produce another version of the document. --------------------------------------------------------------------------- I-D Nits reports: == Unused Reference: 'RFC7713' is defined on line 538, but no explicit reference was found in the text --------------------------------------------------------------------------- General: When used as a compound adjective, "congestion control" should be hyphenated. e.g.: * congestion-control algorithm(s) * congestion-control mechanism(s) * congestion-control response * congestion-control behaviour --------------------------------------------------------------------------- §1: > Recognizing these changes in modern AQM practices, > the strict requirement that ECN CE signals be treated identically to > inferred packet loss have been relaxed [RFC8311]. This document Nit: "...has been..." --------------------------------------------------------------------------- §12.2: > [BUFFERBLOAT] > Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in > the Internet", November 2011. This seems incomplete. I would suggest something more like: [BUFFERBLOAT] Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the Internet", ACM Queue 9, 11, DOI 10.1145/2063166.2071893, November 2011, https://queue.acm.org/detail.cfm?id=2071893 From nobody Thu Sep 13 00:09:21 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E63112D7F8; Thu, 13 Sep 2018 00:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Q-0nvJgu7S; Thu, 13 Sep 2018 00:09:18 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97D130DD0; Thu, 13 Sep 2018 00:09:17 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3D27B1B00210; Thu, 13 Sep 2018 08:09:09 +0100 (BST) Message-ID: <5B9A0D13.7060103@erg.abdn.ac.uk> Date: Thu, 13 Sep 2018 08:09:07 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Adam Roach CC: The IESG , draft-ietf-tcpm-alternativebackoff-ecn@ietf.org, =?UTF-8?B?TWljaGFlbCBUw7w=?= =?UTF-8?B?eGVu?= , tcpm-chairs@ietf.org, tcpm@ietf.org References: <153680710893.9432.14024338054788704789.idtracker@ietfa.amsl.com> In-Reply-To: <153680710893.9432.14024338054788704789.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Adam Roach's Yes on draft-ietf-tcpm-alternativebackoff-ecn-11: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 07:09:21 -0000 Adam, Thanks for the comments. It would be very unusual to hyphenate "congestion control", so I'd suggest leaving this as-is to be consistent with other RFCs. I plan to incorporate the other corrections in the next edit. Gorry On 13/09/2018, 03:51, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-tcpm-alternativebackoff-ecn-11: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for a well-written and easy-to-understand document. I find the proposed > experiment quite interesting. > > I have a small number of editorial nits that you may want to address if you > produce another version of the document. > > --------------------------------------------------------------------------- > > I-D Nits reports: > > == Unused Reference: 'RFC7713' is defined on line 538, but no explicit > reference was found in the text > > --------------------------------------------------------------------------- > > General: > > When used as a compound adjective, "congestion control" should be hyphenated. > e.g.: > > * congestion-control algorithm(s) > * congestion-control mechanism(s) > * congestion-control response > * congestion-control behaviour > > --------------------------------------------------------------------------- > > §1: > >> Recognizing these changes in modern AQM practices, >> the strict requirement that ECN CE signals be treated identically to >> inferred packet loss have been relaxed [RFC8311]. This document > Nit: "...has been..." > > --------------------------------------------------------------------------- > > §12.2: > >> [BUFFERBLOAT] >> Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in >> the Internet", November 2011. > This seems incomplete. I would suggest something more like: > > [BUFFERBLOAT] > Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the > Internet", ACM Queue 9, 11, DOI 10.1145/2063166.2071893, > November 2011, https://queue.acm.org/detail.cfm?id=2071893 > From nobody Thu Sep 13 00:26:21 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C598130DDC; Thu, 13 Sep 2018 00:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe1rMH1GwTFk; Thu, 13 Sep 2018 00:26:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757E812D7F8; Thu, 13 Sep 2018 00:26:14 -0700 (PDT) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8D7PQU3021568 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 13 Sep 2018 02:25:27 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: gorry@erg.abdn.ac.uk Cc: tcpm@ietf.org, =?UTF-8?Q?Michael_T=c3=bcxen?= , The IESG , tcpm-chairs@ietf.org, draft-ietf-tcpm-alternativebackoff-ecn@ietf.org References: <153680710893.9432.14024338054788704789.idtracker@ietfa.amsl.com> <5B9A0D13.7060103@erg.abdn.ac.uk> From: Adam Roach Message-ID: Date: Thu, 13 Sep 2018 02:25:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <5B9A0D13.7060103@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------6F1385CE3B8C862BED11AC30" Content-Language: en-US Archived-At: Subject: Re: [tcpm] Adam Roach's Yes on draft-ietf-tcpm-alternativebackoff-ecn-11: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 07:26:16 -0000 This is a multi-part message in MIME format. --------------6F1385CE3B8C862BED11AC30 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/13/18 2:09 AM, Gorry Fairhurst wrote: > Adam, > > Thanks for the comments. > It would be very unusual to hyphenate "congestion control", > so I'd suggest leaving this as-is to be consistent with other RFCs. You can, of course, do what you want here, but I'll note that RFC 7233 is pretty clear about the guidelines used for editorial matters: > The world of technical publishing has generally accepted rules for > grammar, punctuation, capitalization, sentence length and complexity, > parallelism, etc. The RFC Editor generally follows these accepted > rules as defined by the Chicago Manual of Style (CMOS) [CMOS], with a > few important exceptions to avoid ambiguity in complex technical > prose and to handle mixtures of text and computer languages, or to > preserve historical formatting rules. And CMOS §7.85 indicates that hyphenation is called for in these circumstances. /a --------------6F1385CE3B8C862BED11AC30 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/13/18 2:09 AM, Gorry Fairhurst wrote:
Adam,

Thanks for the comments.
It would be very unusual to hyphenate "congestion control",
so I'd suggest leaving this as-is to be consistent with other RFCs.


You can, of course, do what you want here, but I'll note that RFC 7233 is pretty clear about the guidelines used for editorial matters:

   The world of technical publishing has generally accepted rules for
   grammar, punctuation, capitalization, sentence length and complexity,
   parallelism, etc.  The RFC Editor generally follows these accepted
   rules as defined by the Chicago Manual of Style (CMOS) [CMOS], with a
   few important exceptions to avoid ambiguity in complex technical
   prose and to handle mixtures of text and computer languages, or to
   preserve historical formatting rules.


And CMOS §7.85 indicates that hyphenation is called for in these circumstances.

/a

--------------6F1385CE3B8C862BED11AC30-- From nobody Thu Sep 13 00:33:09 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8422D130DD9; Thu, 13 Sep 2018 00:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KaghU1jc6Da; Thu, 13 Sep 2018 00:33:00 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7DD12D7F8; Thu, 13 Sep 2018 00:32:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7A0FA25A2A; Thu, 13 Sep 2018 09:32:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1536823977; bh=9B63zBabbaGbopmPWtSBF4OTdPQZDPE9QQ7InYOUZMA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LWtub52ohJ8P9/vWO4LJBjNSLxteaDCm9brussgJOXsYIZWO67AK48qNaFJGpU0s7 TJMLinrjL1TwFTYTephSaJ9+Pa/uH9WoBuvXw8l2jnkiELazEZQJsiSzQiZoYHVdUc N7EDmNpgS86U6uMMBBwx78HAg+BR5km/LOFh4c/Y= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xD4asR7oJ06; Thu, 13 Sep 2018 09:32:57 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.hs-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 13 Sep 2018 09:32:57 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.253]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Thu, 13 Sep 2018 09:32:56 +0200 From: "Scharf, Michael" To: Adam Roach , "gorry@erg.abdn.ac.uk" CC: "tcpm@ietf.org" , =?iso-8859-1?Q?Michael_T=FCxen?= , The IESG , "tcpm-chairs@ietf.org" , "draft-ietf-tcpm-alternativebackoff-ecn@ietf.org" Thread-Topic: Adam Roach's Yes on draft-ietf-tcpm-alternativebackoff-ecn-11: (with COMMENT) Thread-Index: AQHUSwy7IaxtqP6MZkeR2eudo7HvW6TtqbGAgAAEfACAACMCYQ== Date: Thu, 13 Sep 2018 07:32:56 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E16BD37AF@rznt8114.rznt.rzdir.fht-esslingen.de> References: <153680710893.9432.14024338054788704789.idtracker@ietfa.amsl.com> <5B9A0D13.7060103@erg.abdn.ac.uk>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E16BD37AFrznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Adam Roach's Yes on draft-ietf-tcpm-alternativebackoff-ecn-11: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Sep 2018 07:33:03 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E16BD37AFrznt8114rzntrzd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For what it is worth, RFC 5681 uses the term "congestion control algorithm"= . IMHO we should not change the term. Michael ________________________________ Von: Adam Roach [adam@nostrum.com] Gesendet: Donnerstag, 13. September 2018 09:25 An: gorry@erg.abdn.ac.uk Cc: tcpm@ietf.org; Michael T=FCxen; The IESG; tcpm-chairs@ietf.org; draft-i= etf-tcpm-alternativebackoff-ecn@ietf.org Betreff: Re: Adam Roach's Yes on draft-ietf-tcpm-alternativebackoff-ecn-11:= (with COMMENT) On 9/13/18 2:09 AM, Gorry Fairhurst wrote: Adam, Thanks for the comments. It would be very unusual to hyphenate "congestion control", so I'd suggest leaving this as-is to be consistent with other RFCs. You can, of course, do what you want here, but I'll note that RFC 7233 is p= retty clear about the guidelines used for editorial matters: The world of technical publishing has generally accepted rules for grammar, punctuation, capitalization, sentence length and complexity, parallelism, etc. The RFC Editor generally follows these accepted rules as defined by the Chicago Manual of Style (CMOS) [CMOS], with a few important exceptions to avoid ambiguity in complex technical prose and to handle mixtures of text and computer languages, or to preserve historical formatting rules. And CMOS =A77.85 indicates that hyphenation is called for in these circumst= ances. /a --_000_6EC6417807D9754DA64F3087E2E2E03E16BD37AFrznt8114rzntrzd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For what it is worth, RFC 5681 uses the term "congestion control = algorithm". IMHO we should not change the term.

Michael 


Von: Adam Roach [adam@nostrum.com]
Gesendet: Donnerstag, 13. September 2018 09:25
An: gorry@erg.abdn.ac.uk
Cc: tcpm@ietf.org; Michael T=FCxen; The IESG; tcpm-chairs@ietf.org; = draft-ietf-tcpm-alternativebackoff-ecn@ietf.org
Betreff: Re: Adam Roach's Yes on draft-ietf-tcpm-alternativebackoff-= ecn-11: (with COMMENT)

On 9/13/18 2:09 AM, Gorry Fairhurst wrote:
Adam,

Thanks for the comments.
It would be very unusual to hyphenate "congestion control",
so I'd suggest leaving this as-is to be consistent with other RFCs.


You can, of course, do what you want here, but I'll note that RFC 7233 i= s pretty clear about the guidelines used for editorial matters:

   The world of technical publishing has generally accepted rules for=
=0A=
   grammar, punctuation, capitalization, sentence length and complexity,=0A=
   parallelism, etc.  The RFC Editor generally follows these accepted=0A=
   rules as defined by the Chicago Manual of Style (CMOS) [CMOS], with a=0A=
   few important exceptions to avoid ambiguity in complex technical=0A=
   prose and to handle mixtures of text and computer languages, or to=0A=
   preserve historical formatting rules.


And CMOS =A77.85 indicates that hyphenation is called for in these circu= mstances.

/a

--_000_6EC6417807D9754DA64F3087E2E2E03E16BD37AFrznt8114rzntrzd_-- From nobody Thu Sep 13 07:16:54 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 494431252B7; Thu, 13 Sep 2018 07:16:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tcpm-alternativebackoff-ecn@ietf.org, =?utf-8?q?Michael_T=C3=BCxen?= , tcpm-chairs@ietf.org, tuexen@fh-muenster.de, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153684820529.8276.13231353600836286208.idtracker@ietfa.amsl.com> Date: Thu, 13 Sep 2018 07:16:45 -0700 Archived-At: Subject: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-alternativebackoff-ecn-11: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 14:16:46 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tcpm-alternativebackoff-ecn-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update: Adam pointed out I thanked the authors for an empty IANA section. I meant section _6_, the Experiment Goals section. Thank you for section 8. Please expand PIE and CoDel on first mention. From nobody Thu Sep 13 23:34:51 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F317B1271FF; Thu, 13 Sep 2018 23:34:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <153690688490.29541.3689925883363352859@ietfa.amsl.com> Date: Thu, 13 Sep 2018 23:34:44 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-alternativebackoff-ecn-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 06:34:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : TCP Alternative Backoff with ECN (ABE) Authors : Naeem Khademi Michael Welzl Grenville Armitage Godred Fairhurst Filename : draft-ietf-tcpm-alternativebackoff-ecn-12.txt Pages : 13 Date : 2018-09-13 Abstract: Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay- product is large. The reception of a Congestion Experienced (CE) ECN mark indicates that an AQM mechanism is used at the bottleneck, and therefore the bottleneck network queue is likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. This specification therefore defines an experimental change to the TCP reaction specified in RFC3168, as permitted by RFC 8311. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-12 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-alternativebackoff-ecn-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-alternativebackoff-ecn-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 26 10:49:13 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6626A130DD7 for ; Wed, 26 Sep 2018 10:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ7RXYj_aoLx for ; Wed, 26 Sep 2018 10:49:09 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193E9128766 for ; Wed, 26 Sep 2018 10:49:08 -0700 (PDT) Received: from mail-it1-f181.google.com (mail-it1-f181.google.com [209.85.166.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1E90829C00F for ; Thu, 27 Sep 2018 02:49:06 +0900 (JST) Received: by mail-it1-f181.google.com with SMTP id 74-v6so2432595itw.1 for ; Wed, 26 Sep 2018 10:49:06 -0700 (PDT) X-Gm-Message-State: ABuFfohUPi8rGXPx5yYzHJQOU1Lc0jvR/rABWuwTaTW3565n+x3LQvuF lhvqcEza+9SwMOuJCq17xlMbj7Cfb6VLVdGkDKw= X-Google-Smtp-Source: ACcGV620j0MEPfTJap3Qqd8vp2jFHKnxUKkMnvkqKRLzvdImo4cG/zyKZJjj1jYjr3L6ffy/XATXlzC66zK9rw5i0kE= X-Received: by 2002:a24:f605:: with SMTP id u5-v6mr6295911ith.17.1537984144357; Wed, 26 Sep 2018 10:49:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:930e:0:0:0:0:0 with HTTP; Wed, 26 Sep 2018 10:49:03 -0700 (PDT) From: Yoshifumi Nishida Date: Wed, 26 Sep 2018 10:49:03 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000983eb80576c9d678" Archived-At: Subject: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Sep 2018 17:49:12 -0000 --000000000000983eb80576c9d678 Content-Type: text/plain; charset="UTF-8" Hello, this is just out of my curiosity. I've checked traffic archives in CAIDA (https://data.caida.org/datasets/) and WIDE (http://mawi.wide.ad.jp/mawi/) on a whim and tried to see how many connections utilize timestamps. As far as I've checked some archives recently captured, it seems that around 60-70% TCP connections use timestamp option. But, this ratio seems to be a bit lower as I thought most of implementations these days support TS option and activate it by default. Does anyone have some ideas about it? Am I looking at uncommon data? Or there are still many old implementations around? Or, many users have disabled the option for some reasons? -- Yoshi --000000000000983eb80576c9d678 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
this is just = out of my curiosity.
I've checked traffic archives in CAIDA (= https://data.caida.org/dataset= s/) and WIDE (http://mawi.wide= .ad.jp/mawi/) on a whim and tried to see how many connections utilize t= imestamps.

As far as I've checked some arc= hives recently captured, it seems that around 60-70% TCP connections use ti= mestamp option. But, this ratio seems to be a bit lower as I thought most o= f implementations these days support TS option and activate it by default.<= /div>
Does anyone have some ideas about it? Am I looking at uncommon da= ta? Or there are still many old implementations around? Or, many users have= disabled the option for some reasons?=C2=A0
--
Yos= hi


--000000000000983eb80576c9d678-- From nobody Wed Sep 26 11:21:25 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D9130E3B for ; Wed, 26 Sep 2018 11:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYNsp_kcOBaL for ; Wed, 26 Sep 2018 11:21:18 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710102.outbound.protection.outlook.com [40.107.71.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1724F130E41 for ; Wed, 26 Sep 2018 11:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jAYIJYXqhN2Q9ob9u5mUtE8o56liVKlyYoKK2aGffWA=; b=nM4OeV9WOXszaY2hkSFTIh9Fh73v5EzscdqtcYPh7aToQgyxt8u2SwFrvu+uCc9GICpDIc6vgst66S5HhaA1vjo9+eZ4rTNbBVKIb40dUvCeoaCJ0tPYyMkuI51lNSfwgYXcBIofodQVfltQ6UlAfi/YsdUNnDdbXe10i2Kb5F4= Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0768.namprd21.prod.outlook.com (10.173.51.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1207.9; Wed, 26 Sep 2018 18:21:15 +0000 Received: from MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::5443:2f41:bcd:634f]) by MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::5443:2f41:bcd:634f%5]) with mapi id 15.20.1207.006; Wed, 26 Sep 2018 18:21:15 +0000 From: Praveen Balasubramanian To: Yoshifumi Nishida , "tcpm@ietf.org" Thread-Topic: [tcpm] usage for timestamp options in the wild Thread-Index: AQHUVcFDBUenX6MW2Ui5madIUzPkvaUC3v1A Date: Wed, 26 Sep 2018 18:21:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:3:8e1c:417:2114:339b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0768; 6:AwmI/PNnTkRMVJT3HjETT7s8B7aPkvw+hNc3ZXN9++k1fSZfXlhOjtGiPT6TcfQyGQiB/Uc0uTRpPEcIX7Bh0sC6YHai8GT2q1njyoUfW9A+CkapryurmWH2xPPLlktjgVlUXvgt3K/n/Kix/SrNSWAoJx5C7qntNxszUsCnoeQ17w++OXv+fvM1H9WEyMvn5jGP0viqsrrKSg3zGr2dpKxP9Fx/20wql+ZWs3eeYzAtsnfYXuKLRhEZJwI0mQ1Sdl68DZVinMfT5cqVcGA03F9edkfyls9ItkCGEVC2tM89TiA/n/AvS8TIo9k7PyFCMtd4KW0rWU6w53tlP5C7W65+nnyogRPX8Dw83u025y6aNCvae48y7WzZWbwblpDDgUs+91Q4B5AgOpKR3laYbJ0w3DphzQTAd3JZNNNNhpu9/kGXQZCHa0wzNq7ZQWIh6vcCH0sZrjQXkPFdIKWZSA==; 5:dsLVgxUlhsIZycI7KBtx2IHg8ZJAbt/zi3oJYQUeztzpAhubCCztRZSvQTzOms6cUCHI6xsAY5BffTZ0f6CMXtO8617CJWeB1Uy2yVez/1iOFkF/OOLokmZRsgm3FzpEbPGk+eVIwYan8ZqfZ6rwa2FTMvBf1faS1GB0smJ+jBg=; 7:iyvbKKK7irXD/UK4tayC/gg3aQeK4Xz8CEaQ7nrRIa0fPuMk2IlLRvNt2HISXFyyvZpIzwfmynGPxE5+P6dr3nkSkgimbSjgI7UIMe1xjtNvCKsXf6gTI14M8gY9PKSLBDhLOPXJNpboejU1HkaaymiI0jlfGlaiwWRqAfplAVck64HGbFBjR57i/pbFANRfJ1+BJ94VotIuhy2Fl9tujYQ7+VN/n4QSn3yHJb4Bev2O2s0wvfhdD/T/jQ1WMRjY x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 56d77270-7ff2-4492-de98-08d623dcd8ae x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MWHPR21MB0768; x-ms-traffictypediagnostic: MWHPR21MB0768: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510)(219752817060721)(189930954265078); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(2018427008)(6055026)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991041); SRVR:MWHPR21MB0768; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0768; x-forefront-prvs: 08076ABC99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(39860400002)(376002)(366004)(199004)(189003)(186003)(25786009)(6506007)(476003)(10090500001)(86362001)(7736002)(34290500001)(5660300001)(11346002)(19609705001)(97736004)(110136005)(71200400001)(71190400001)(6246003)(46003)(33656002)(102836004)(316002)(86612001)(446003)(6346003)(486006)(7696005)(8990500004)(22452003)(53546011)(99286004)(76176011)(74316002)(5250100002)(6306002)(478600001)(9686003)(54896002)(236005)(106356001)(10290500003)(105586002)(606006)(2501003)(229853002)(55016002)(6436002)(2906002)(6116002)(53936002)(68736007)(2900100001)(14444005)(256004)(8936002)(790700001)(8676002)(81166006)(81156014)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0768; H:MWHPR21MB0191.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: Gle6WQ2RndMvxXZ8+lZ5MGSlzSlwpDo0GPf0Z8CUF7Xp8rQ64tvxBN4ADWfNXl1wVOdUN26UOFpdFkjWZMR76XRqT1VBhBrn1O+ccUlL6Rl31m6/G3a+aq3cgYLvW6GTD/fg3nkV1knq2RVlk8w/qORDUMTTZoj3qDIxjnI/4jmv76GttLHo+QP8kN0CjZ0Ey82dshNUn9QNTjFaITMfKhNDIFUjYasZdh5VjnzSNo7QvKKcPWySAo6wP5p9CLQ69ytHTqj3CW4E/hXqbblG3z4Uw4H/iPm2cMoLcdstDAmALthg5H/TXhFfdSU0uMjo0a4BEypSmNcQScyldG7IJ94QIKpXc0Xnnzqwz6ofGI8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB019123F8820BE88FEAA2A9FBB6150MWHPR21MB0191namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56d77270-7ff2-4492-de98-08d623dcd8ae X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2018 18:21:15.3526 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0768 Archived-At: Subject: Re: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Sep 2018 18:21:22 -0000 --_000_MWHPR21MB019123F8820BE88FEAA2A9FBB6150MWHPR21MB0191namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2luZG93cyBkb2VzbuKAmXQgZG8gdGltZXN0YW1wIG9wdGlvbiBieSBkZWZhdWx0LiBJdOKAmXMg MTAgYnl0ZSBwZXIgcGFja2V0IG92ZXJoZWFkIGZvciBtYXJnaW5hbCBiZW5lZml0cy4NCg0KRnJv bTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgWW9zaGlmdW1pIE5p c2hpZGENClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI2LCAyMDE4IDEwOjQ5IEFNDQpUbzog dGNwbUBpZXRmLm9yZw0KU3ViamVjdDogW3RjcG1dIHVzYWdlIGZvciB0aW1lc3RhbXAgb3B0aW9u cyBpbiB0aGUgd2lsZA0KDQpIZWxsbywNCnRoaXMgaXMganVzdCBvdXQgb2YgbXkgY3VyaW9zaXR5 Lg0KSSd2ZSBjaGVja2VkIHRyYWZmaWMgYXJjaGl2ZXMgaW4gQ0FJREEgKGh0dHBzOi8vZGF0YS5j YWlkYS5vcmcvZGF0YXNldHMvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YS5jYWlkYS5vcmclMkZkYXRhc2V0cyUyRiZk YXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NjYmEzNTZhZmE3ZTM0Nzc5YmFi ZjA4ZDYyM2Q4NjQ4MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY3MzU4MDk2NDQ3NDk2OTUmc2RhdGE9d1V6MEhFeEoybTNSZVBZeE0wYWJ3WXdQaGwyVWVB TmFWOE5BZyUyQnlLazljJTNEJnJlc2VydmVkPTA+KSBhbmQgV0lERSAoaHR0cDovL21hd2kud2lk ZS4uYWQuanAvbWF3aS88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cCUzQSUyRiUyRm1hd2kud2lkZS5hZC5qcCUyRm1hd2klMkYmZGF0YT0wMiU3 QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDY2JhMzU2YWZhN2UzNDc3OWJhYmYwOGQ2MjNk ODY0ODElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NzM1 ODA5NjQ0NzU5NzA3JnNkYXRhPVhnU2pDemlDQyUyQnVvSkF5blhpeEJRT2JkcW1BayUyRmxCeFol MkZUUjJDTUYzR2slM0QmcmVzZXJ2ZWQ9MD4pIG9uIGEgd2hpbSBhbmQgdHJpZWQgdG8gc2VlIGhv dyBtYW55IGNvbm5lY3Rpb25zIHV0aWxpemUgdGltZXN0YW1wcy4NCg0KQXMgZmFyIGFzIEkndmUg Y2hlY2tlZCBzb21lIGFyY2hpdmVzIHJlY2VudGx5IGNhcHR1cmVkLCBpdCBzZWVtcyB0aGF0IGFy b3VuZCA2MC03MCUgVENQIGNvbm5lY3Rpb25zIHVzZSB0aW1lc3RhbXAgb3B0aW9uLiBCdXQsIHRo aXMgcmF0aW8gc2VlbXMgdG8gYmUgYSBiaXQgbG93ZXIgYXMgSSB0aG91Z2h0IG1vc3Qgb2YgaW1w bGVtZW50YXRpb25zIHRoZXNlIGRheXMgc3VwcG9ydCBUUyBvcHRpb24gYW5kIGFjdGl2YXRlIGl0 IGJ5IGRlZmF1bHQuDQpEb2VzIGFueW9uZSBoYXZlIHNvbWUgaWRlYXMgYWJvdXQgaXQ/IEFtIEkg bG9va2luZyBhdCB1bmNvbW1vbiBkYXRhPyBPciB0aGVyZSBhcmUgc3RpbGwgbWFueSBvbGQgaW1w bGVtZW50YXRpb25zIGFyb3VuZD8gT3IsIG1hbnkgdXNlcnMgaGF2ZSBkaXNhYmxlZCB0aGUgb3B0 aW9uIGZvciBzb21lIHJlYXNvbnM/DQotLQ0KWW9zaGkNCg0KDQo= --_000_MWHPR21MB019123F8820BE88FEAA2A9FBB6150MWHPR21MB0191namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aW5kb3dzIGRvZXNu4oCZdCBkbyB0aW1lc3RhbXAgb3B0aW9uIGJ5IGRlZmF1bHQuIEl04oCZcyAx MCBieXRlIHBlciBwYWNrZXQgb3ZlcmhlYWQgZm9yIG1hcmdpbmFsIGJlbmVmaXRzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gdGNwbSAmbHQ7dGNwbS1ib3VuY2VzQGlldGYu b3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KWW9zaGlmdW1pIE5pc2hpZGE8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTggMTA6NDkgQU08YnI+DQo8Yj5U bzo8L2I+IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3RjcG1dIHVzYWdlIGZv ciB0aW1lc3RhbXAgb3B0aW9ucyBpbiB0aGUgd2lsZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj50aGlzIGlzIGp1c3Qgb3V0IG9mIG15IGN1cmlvc2l0eS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkndmUgY2hlY2tlZCB0 cmFmZmljIGFyY2hpdmVzIGluIENBSURBICg8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGEuY2FpZGEub3Jn JTJGZGF0YXNldHMlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3 Q2NiYTM1NmFmYTdlMzQ3NzliYWJmMDhkNjIzZDg2NDgxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjczNTgwOTY0NDc0OTY5NSZhbXA7c2RhdGE9d1V6MEhF eEoybTNSZVBZeE0wYWJ3WXdQaGwyVWVBTmFWOE5BZyUyQnlLazljJTNEJmFtcDtyZXNlcnZlZD0w Ij5odHRwczovL2RhdGEuY2FpZGEub3JnL2RhdGFzZXRzLzwvYT4pDQogYW5kIFdJREUgKDxhIGhy ZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHAlM0ElMkYlMkZtYXdpLndpZGUuYWQuanAlMkZtYXdpJTJGJmFtcDtkYXRhPTAyJTdDMDElN0Nw cmF2YiU0MG1pY3Jvc29mdC5jb20lN0NjYmEzNTZhZmE3ZTM0Nzc5YmFiZjA4ZDYyM2Q4NjQ4MSU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3MzU4MDk2NDQ3 NTk3MDcmYW1wO3NkYXRhPVhnU2pDemlDQyUyQnVvSkF5blhpeEJRT2JkcW1BayUyRmxCeFolMkZU UjJDTUYzR2slM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHA6Ly9tYXdpLndpZGUuLmFkLmpwL21hd2kv PC9hPikNCiBvbiBhIHdoaW0gYW5kIHRyaWVkIHRvIHNlZSBob3cgbWFueSBjb25uZWN0aW9ucyB1 dGlsaXplIHRpbWVzdGFtcHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFzIGZhciBhcyBJJ3ZlIGNoZWNrZWQgc29tZSBhcmNoaXZlcyByZWNl bnRseSBjYXB0dXJlZCwgaXQgc2VlbXMgdGhhdCBhcm91bmQgNjAtNzAlIFRDUCBjb25uZWN0aW9u cyB1c2UgdGltZXN0YW1wIG9wdGlvbi4gQnV0LCB0aGlzIHJhdGlvIHNlZW1zIHRvIGJlIGEgYml0 IGxvd2VyIGFzIEkgdGhvdWdodCBtb3N0IG9mIGltcGxlbWVudGF0aW9ucyB0aGVzZSBkYXlzIHN1 cHBvcnQgVFMgb3B0aW9uIGFuZCBhY3RpdmF0ZQ0KIGl0IGJ5IGRlZmF1bHQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIGFueW9uZSBoYXZl IHNvbWUgaWRlYXMgYWJvdXQgaXQ/IEFtIEkgbG9va2luZyBhdCB1bmNvbW1vbiBkYXRhPyBPciB0 aGVyZSBhcmUgc3RpbGwgbWFueSBvbGQgaW1wbGVtZW50YXRpb25zIGFyb3VuZD8gT3IsIG1hbnkg dXNlcnMgaGF2ZSBkaXNhYmxlZCB0aGUgb3B0aW9uIGZvciBzb21lIHJlYXNvbnM/Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9zaGk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB019123F8820BE88FEAA2A9FBB6150MWHPR21MB0191namp_-- From nobody Wed Sep 26 11:37:55 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F39E127332 for ; Wed, 26 Sep 2018 11:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.502 X-Spam-Level: X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbKlZCGkoCzv for ; Wed, 26 Sep 2018 11:37:51 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CED130E07 for ; Wed, 26 Sep 2018 11:37:51 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id q70-v6so4376561itb.3 for ; Wed, 26 Sep 2018 11:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=djnYxPZOZF3gcBFW5mSJ/iRiLArE5/YCkSS7q5QO+Nk=; b=nQmsnFe+eBgrnbZnNVtGfIrV8CrXCuyX4/7Ya/9w/ELs+Goe14hLd8ynsAyp8/kpeF mgpchWcBHOH5RGubPTo8QeV8cYxp3YPnfiXHrxrqeifJLzvKGMAdp45GN2JUNOZSQGPt NDmzKe/fXi+6nnxZ2b543RymJpeKBA75g7yzEhrEarj6holrUVo11ShFHru9wKDdW44o oMyy7oYcgAct6K/WOdLXLMwPanSVEZjGOC+6oAHoM5QmX9v/8JGQn/+oMy7FyPlygXhe bEjz3aTXacyqYOjtrUhAxT0QraRkwU9Q5VtW5DwzEBW9OcSDMjhPlu9EilqMA2WzcxIr V55Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=djnYxPZOZF3gcBFW5mSJ/iRiLArE5/YCkSS7q5QO+Nk=; b=gpPzRLnwR6GgUl/jHlSNHoLH0hcR/fSF5eawpTyQM2rXAgpLanjHYQuQYYbrSSYnGO LL9ddJQHdhIcppNL5PW0zpcF37iM11kw10+URf3+ScF6RPEAcgyj5tUh6i8yql7jdTzf HNzZ3PDILRW8SJYNLNF3NJa9sYs7WPeUfJAWWrLhqqamX4EMO0f6saqcClgCU6p2o2Dg zlCbEN5gPWymTP4FnpCakK4sgtFUpIw/bNY55CPnBFH82o8SDGDVNmpdlF6lGjYzB3RO H+mzwbXighTPn47hJ8JoruStdOq1d3JAW76GhyLZuM1CPlQh4Yh3hsgsDWZH5tB3bvov Ws2w== X-Gm-Message-State: ABuFfoi4slXFWfMklRpb1E1jDsB3dBmPnAN89e3RbmulteIEjmL1+sy2 j0Au7IhvUNkfac1MdvqObY40Pv1bW7mdhJoc3X1YJg== X-Google-Smtp-Source: ACcGV636iKL6RaHjTZBP33x0IUCHqkXaKSggwSPNeaxCmkLjV6NOl0S1O9tL6DvaJzYYHjy/IkTLdcM2xg4UjtMGVzo= X-Received: by 2002:a02:3f11:: with SMTP id d17-v6mr6787907jaa.36.1537987070490; Wed, 26 Sep 2018 11:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:f715:0:0:0:0:0 with HTTP; Wed, 26 Sep 2018 11:37:09 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Wed, 26 Sep 2018 11:37:09 -0700 Message-ID: To: Praveen Balasubramanian Cc: Yoshifumi Nishida , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Sep 2018 18:37:54 -0000 On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian wrote: > > Windows doesn=E2=80=99t do timestamp option by default. It=E2=80=99s 10 b= yte per packet overhead for marginal benefits. > > > > From: tcpm On Behalf Of Yoshifumi Nishida > Sent: Wednesday, September 26, 2018 10:49 AM > To: tcpm@ietf.org > Subject: [tcpm] usage for timestamp options in the wild > > > > Hello, > > this is just out of my curiosity. > > I've checked traffic archives in CAIDA (https://data.caida.org/datasets/)= and WIDE (http://mawi.wide..ad.jp/mawi/) on a whim and tried to see how ma= ny connections utilize timestamps. > > > > As far as I've checked some archives recently captured, it seems that aro= und 60-70% TCP connections use timestamp option. But, this ratio seems to b= e a bit lower as I thought most of implementations these days support TS op= tion and activate it by default. how recent are the archives? AFAIK TS is enabled by default on Linux, FreeBSD, and iOS. Linux has that by default more than a decade > > Does anyone have some ideas about it? Am I looking at uncommon data? Or t= here are still many old implementations around? Or, many users have disable= d the option for some reasons? > > -- > > Yoshi > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Sep 26 12:44:06 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6362C126CC7 for ; Wed, 26 Sep 2018 12:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez4p3tWS-yVh for ; Wed, 26 Sep 2018 12:44:01 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380AD1274D0 for ; Wed, 26 Sep 2018 12:44:00 -0700 (PDT) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D3B3D29C026 for ; Thu, 27 Sep 2018 04:43:57 +0900 (JST) Received: by mail-it1-f177.google.com with SMTP id c85-v6so4556357itd.1 for ; Wed, 26 Sep 2018 12:43:57 -0700 (PDT) X-Gm-Message-State: ABuFfog5M3HnkNZ0TK2ROcM5J96IAMr5OEbgVTOqNCCzwx/oO0TDza0o FP5J0V/BQLu4b2TRb2I6yVvRamsBKbL4OLuNSDk= X-Google-Smtp-Source: ACcGV62LdOZH+Kxbm8wRNlU7jQNQvv7xFmyQqkUHYixY5v0wfi5VmouCIrO4+PjeExAEWjAlVu4qktadtu4PQEL9hSM= X-Received: by 2002:a24:f605:: with SMTP id u5-v6mr6715557ith.17.1537991036628; Wed, 26 Sep 2018 12:43:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:930e:0:0:0:0:0 with HTTP; Wed, 26 Sep 2018 12:43:55 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Wed, 26 Sep 2018 12:43:55 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Yuchung Cheng Cc: Praveen Balasubramanian , Yoshifumi Nishida , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000067f5420576cb717c" Archived-At: Subject: Re: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Sep 2018 19:44:05 -0000 --00000000000067f5420576cb717c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 26, 2018 at 11:37 AM, Yuchung Cheng wrote: > On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian > wrote: > > > > Windows doesn=E2=80=99t do timestamp option by default. It=E2=80=99s 10= byte per packet > overhead for marginal benefits. > > > > > > > > From: tcpm On Behalf Of Yoshifumi Nishida > > Sent: Wednesday, September 26, 2018 10:49 AM > > To: tcpm@ietf.org > > Subject: [tcpm] usage for timestamp options in the wild > > > > > > > > Hello, > > > > this is just out of my curiosity. > > > > I've checked traffic archives in CAIDA (https://data.caida.org/datasets= /) > and WIDE (http://mawi.wide..ad.jp/mawi/) on a whim and tried to see how > many connections utilize timestamps. > > > > > > > > As far as I've checked some archives recently captured, it seems that > around 60-70% TCP connections use timestamp option. But, this ratio seems > to be a bit lower as I thought most of implementations these days support > TS option and activate it by default. > how recent are the archives? > They are 2018 data. > > AFAIK TS is enabled by default on Linux, FreeBSD, and iOS. Linux has > that by default more than a decade > that's why I was wondering. -- Yoshi --00000000000067f5420576cb717c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 26, 2018 at 11:37 AM, Yuchung Cheng <yche= ng@google.com> wrote:
On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramani= an
<pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
>
> Windows doesn=E2=80=99t do timestamp option by default. It=E2=80=99s 1= 0 byte per packet overhead for marginal benefits.
>
>
>
> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yoshifumi Nishida
> Sent: Wednesday, September 26, 2018 10:49 AM
> To: tcpm@ietf.org
> Subject: [tcpm] usage for timestamp options in the wild
>
>
>
> Hello,
>
> this is just out of my curiosity.
>
> I've checked traffic archives in CAIDA (https://data.caida.= org/datasets/) and WIDE (http://mawi.wide..ad.jp/mawi/) on a whim an= d tried to see how many connections utilize timestamps.
>
>
>
> As far as I've checked some archives recently captured, it seems t= hat around 60-70% TCP connections use timestamp option. But, this ratio see= ms to be a bit lower as I thought most of implementations these days suppor= t TS option and activate it by default.
how recent are the archives?

The= y are 2018 data.=C2=A0

AFAIK TS is enabled by default on Linux, FreeBSD, and iOS. Linux has
that by default more than a decade

that= 's why I was wondering.
--
Yoshi=C2=A0
= =C2=A0
--00000000000067f5420576cb717c-- From nobody Wed Sep 26 12:48:20 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A225A130F61 for ; Wed, 26 Sep 2018 12:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iw9FTRf_pOG for ; Wed, 26 Sep 2018 12:48:11 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163C4130F66 for ; Wed, 26 Sep 2018 12:48:10 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 579D829C030 for ; Thu, 27 Sep 2018 04:48:09 +0900 (JST) Received: by mail-io1-f50.google.com with SMTP id q5-v6so158139iop.3 for ; Wed, 26 Sep 2018 12:48:09 -0700 (PDT) X-Gm-Message-State: ABuFfoh3Q24YRJWDcpHj/ag0DyZe6ceSKPiLwA52P3+2m1LbtuwO+kn6 pD4px7L5wfUL515Tge1Nf463h2UUguLRSraRDbY= X-Google-Smtp-Source: ACcGV61sodXtoB3HIiw2p75DQF5yf4yYrdvmux6PpldCnqTP7Awx40ujH5GnoDdSTMG5XnEF5T9R83XchKQHSa2m9lc= X-Received: by 2002:a6b:c586:: with SMTP id v128-v6mr6328676iof.7.1537991287969; Wed, 26 Sep 2018 12:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:930e:0:0:0:0:0 with HTTP; Wed, 26 Sep 2018 12:48:07 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Wed, 26 Sep 2018 12:48:07 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Praveen Balasubramanian Cc: Yoshifumi Nishida , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006321e70576cb8047" Archived-At: Subject: Re: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Sep 2018 19:48:19 -0000 --0000000000006321e70576cb8047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Praveen, On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian < pravb@microsoft.com> wrote: > Windows doesn=E2=80=99t do timestamp option by default. It=E2=80=99s 10 b= yte per packet > overhead for marginal benefits. > Interesting. So, windows derives RTO only from ACK arrival time? -- Yoshi > > > *From:* tcpm *On Behalf Of * Yoshifumi Nishida > *Sent:* Wednesday, September 26, 2018 10:49 AM > *To:* tcpm@ietf.org > *Subject:* [tcpm] usage for timestamp options in the wild > > > > Hello, > > this is just out of my curiosity. > > I've checked traffic archives in CAIDA (https://data.caida.org/datasets/ > ) > and WIDE (http://mawi.wide..ad.jp/mawi/ > ) > on a whim and tried to see how many connections utilize timestamps. > > > > As far as I've checked some archives recently captured, it seems that > around 60-70% TCP connections use timestamp option. But, this ratio seems > to be a bit lower as I thought most of implementations these days support > TS option and activate it by default. > > Does anyone have some ideas about it? Am I looking at uncommon data? Or > there are still many old implementations around? Or, many users have > disabled the option for some reasons? > > -- > > Yoshi > > > > > --0000000000006321e70576cb8047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Praveen,

On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian = <pravb@microsoft.com> wrote:

Windows doesn=E2=80=99t do timestamp option by defau= lt. It=E2=80=99s 10 byte per packet overhead for marginal benefits.


Interesting. So, windows derives R= TO only from ACK arrival time?=C2=A0
--
Yoshi
=C2=A0

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Yoshifumi Nishida
Sent: Wednesday, September 26, 2018 10:49 AM
To: tcpm@ietf.org=
Subject: [tcpm] usage for timestamp options in the wild

=C2=A0

Hello,

this is just out of my curiosity.

I've checked traffic archives in CAIDA (https://data.caida.org/datasets= /) and WIDE (http://mawi.wide..= ad.jp/mawi/) on a whim and tried to see how many connections utilize timestamps.=

=C2=A0

As far as I've checked some archives recently ca= ptured, it seems that around 60-70% TCP connections use timestamp option. B= ut, this ratio seems to be a bit lower as I thought most of implementations= these days support TS option and activate it by default.

Does anyone have some ideas about it? Am I looking a= t uncommon data? Or there are still many old implementations around? Or, ma= ny users have disabled the option for some reasons?=C2=A0

--

Yoshi

=C2=A0

=C2=A0


--0000000000006321e70576cb8047-- From nobody Wed Sep 26 13:37:04 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7DC129385 for ; Wed, 26 Sep 2018 13:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHFj0HLUHJMl for ; Wed, 26 Sep 2018 13:37:00 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710131.outbound.protection.outlook.com [40.107.71.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6F6126CC7 for ; Wed, 26 Sep 2018 13:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WKBOqnVcz3pMOhptU+anJPriU5O+AZ+P0X7sLYFeams=; b=o0yqtJ9rolFbpQz6lbpZJUzFljFQSpTMHv8jWsjwq4qDq/VZmFaQO5cz2X3T7yBKKcTyikwNer2oJ4+41nsHbSybY4tOzVoEP/VFERfKOIM3f4iqzYhrKuG/mjrYJUiXjYFa4yXsiZ3/Z1PtUTEQT+TNzDs03+wudqMi63nqPO4= Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0510.namprd21.prod.outlook.com (10.172.95.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.2; Wed, 26 Sep 2018 20:36:58 +0000 Received: from MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::5443:2f41:bcd:634f]) by MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::5443:2f41:bcd:634f%5]) with mapi id 15.20.1207.006; Wed, 26 Sep 2018 20:36:58 +0000 From: Praveen Balasubramanian To: Yoshifumi Nishida CC: "tcpm@ietf.org" Thread-Topic: [tcpm] usage for timestamp options in the wild Thread-Index: AQHUVcFDBUenX6MW2Ui5madIUzPkvaUC3v1AgAAZMYCAAAwkYA== Date: Wed, 26 Sep 2018 20:36:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:3:8e1c:417:2114:339b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0510; 6:iEMovL2sqKavzXgHAsOffvpzcDoOnkabwS5J5emwe0AXP6Qii760sTujchwosmIW47SccbV2dSKvzpMZDFbY13p6fycOcRJu6/VXvKqv7KoqjhcKhmjZIip2Dmr+sc7TBbrKdToU6FwAJHj/GTB2h8dKSrblQ2rEeAuANYhYGW65/UJCKt8b0Z4Rxapf5H/ims3zwSl+kBRFIlLYkBu5Rj2lAVdac/nHpX/1AV+/OjCX2LGsSlwO0HVYLnwWKaMeLCwnJOzlT8SEOCeZTs73DGY72b4Z+jTCgpi29Nv6t9LYhCBmWYJ87jx/aFJPCfMI5t2gdOGzOtMjRryzEGihsQnPFR4Fy0IHU2FDrlHFd1VU9HTP8HlVLYzmH/6swuqj+rXhAoJspOTpD52R3bQOfMN9EDLGlAnQWyrFbB6aQkKZBvJRagJV5CS77HyNJrc+shPxHz9pDUZNODGbLKKiFg==; 5:HCTLvd4th0CpHl0vn2OkLvBSaimxzwbynGNd6AKRjEX1RGHJ548DhBDg4cKTpqsspyTjBhl+83FGmlDc3KWHXwbrY5Wq+ZSaBk09eJLjeDZh6tDFcyCLxtsP0uuyI38Ay9+TR3JWTW12WVKpdiQzQ3iLRPuLaF/5Oddcn/hggfk=; 7:f3VDTAejOcVSRZwRSnEDa5EFrM3QtDOEQlPKjGmXmfM113nWty2eSDfmcdg4vziUwOA3vAcr33c61VURLp0czyWJeMpQA0nKejIDf/gxIzQmRPYlYflxzm6K9Q97xkDQayKSz723ag1JXffsfXm/IkEUi8cH4jp53ykrlA8gavvuUCU3JZ/eVAFltRPI0EjzW2H+oRysx8VNxudqvzzLvaJ/S8Fsz5j1A6URSfvyTddHucfSyKD+ZLmQR0vzbEiq x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 789d5f8c-e6bf-4aa7-746b-08d623efce61 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MWHPR21MB0510; x-ms-traffictypediagnostic: MWHPR21MB0510: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155)(190501279198761)(227612066756510)(219752817060721)(189930954265078); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231355)(944501410)(52105095)(2018427008)(3002001)(10201501046)(6055026)(149066)(150057)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991041); SRVR:MWHPR21MB0510; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0510; x-forefront-prvs: 08076ABC99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(366004)(396003)(136003)(189003)(199004)(71200400001)(71190400001)(7696005)(53936002)(6306002)(34290500001)(9686003)(229853002)(2906002)(55016002)(236005)(46003)(22452003)(99286004)(25786009)(478600001)(10290500003)(5660300001)(7736002)(74316002)(33656002)(54896002)(6436002)(10090500001)(81166006)(11346002)(81156014)(76176011)(446003)(97736004)(19609705001)(105586002)(8990500004)(6116002)(790700001)(4326008)(106356001)(14454004)(6246003)(2900100001)(86612001)(606006)(186003)(476003)(86362001)(8936002)(6916009)(316002)(8676002)(14444005)(53546011)(256004)(68736007)(6506007)(5250100002)(102836004)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0510; H:MWHPR21MB0191.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: n7PNVRIzV2ouupfxP+PccLLK6xvWWc7ZeN/y5JaRr2szpE9MSra7FWb+EVhipgGr4W3wMUev8l71WEkY00NhYqDN8HXYcN0tpbhgQKrPYdghxKybVVtaTNLvmGy8IUSF17YkDQQnE6tjI/qmnzeAetemG6OGt3bfp+JTMH7LFlgygACSL6sg4NopLoDjrf/q2WP6mIOF4XSzRRBIzRtJOv9VFcjYgqjL4m5/DQsrFsbW4/kBTg0gVH/l2hDgDhOYvVW9J2gk/QQsPahy6Yk0Q90xjI6jH17jxfsWZcOxpIxwA2HH7mhiLrONM0/ht1/AFbtMXJLTgsdoo0xvZGWShLotxRmeFnVLgea+EUNznEg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01913A2B05C037E594F78CBAB6150MWHPR21MB0191namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 789d5f8c-e6bf-4aa7-746b-08d623efce61 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2018 20:36:58.4590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0510 Archived-At: Subject: Re: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Sep 2018 20:37:02 -0000 --_000_MWHPR21MB01913A2B05C037E594F78CBAB6150MWHPR21MB0191namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgZm9sbG93cyBSRkMgNjI5OCBhbmQgUlRPIGlzIGJhc2VkIG9uIFNSdHQgYW5kIFJ0dFZhci4g UlRUIHNhbXBsZSBtZWFzdXJlbWVudCB3aWxsIG1ha2UgdXNlIG9mIHRpbWVzdGFtcHMgd2hlbiBw cmVzZW50IG9yIGp1c3QgdXNlIEFDSyBhcnJpdmFsIHRpbWUuIEFzIGEgc2lkZSByZXN1bHQgb2Yg UkFDSyBpbXBsZW1lbnRhdGlvbiwgdGhlIG51bWJlciBvZiBSVFQgc2FtcGxlcyB0YWtlbiBwZXIg UlRUIHdhcyBpbmNyZWFzZWQuIFNlZSBTZWN0aW9uIDIgYW5kIDMgaW4gUkZDIDYyOTguDQoNCkZy b206IFlvc2hpZnVtaSBOaXNoaWRhIDxuaXNoaWRhQHNmYy53aWRlLmFkLmpwPg0KU2VudDogV2Vk bmVzZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTggMTI6NDggUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJy YW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCkNjOiBZb3NoaWZ1bWkgTmlzaGlkYSA8bmlz aGlkYUBzZmMud2lkZS5hZC5qcD47IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0g dXNhZ2UgZm9yIHRpbWVzdGFtcCBvcHRpb25zIGluIHRoZSB3aWxkDQoNCkhpIFByYXZlZW4sDQoN Ck9uIFdlZCwgU2VwIDI2LCAyMDE4IGF0IDExOjIxIEFNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+IHdyb3Rl Og0KV2luZG93cyBkb2VzbuKAmXQgZG8gdGltZXN0YW1wIG9wdGlvbiBieSBkZWZhdWx0LiBJdOKA mXMgMTAgYnl0ZSBwZXIgcGFja2V0IG92ZXJoZWFkIGZvciBtYXJnaW5hbCBiZW5lZml0cy4NCg0K SW50ZXJlc3RpbmcuIFNvLCB3aW5kb3dzIGRlcml2ZXMgUlRPIG9ubHkgZnJvbSBBQ0sgYXJyaXZh bCB0aW1lPw0KLS0NCllvc2hpDQoNCg0KRnJvbTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgWW9zaGlmdW1pIE5p c2hpZGENClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI2LCAyMDE4IDEwOjQ5IEFNDQpUbzog dGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFt0Y3BtXSB1c2Fn ZSBmb3IgdGltZXN0YW1wIG9wdGlvbnMgaW4gdGhlIHdpbGQNCg0KSGVsbG8sDQp0aGlzIGlzIGp1 c3Qgb3V0IG9mIG15IGN1cmlvc2l0eS4NCkkndmUgY2hlY2tlZCB0cmFmZmljIGFyY2hpdmVzIGlu IENBSURBIChodHRwczovL2RhdGEuY2FpZGEub3JnL2RhdGFzZXRzLzxodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGEuY2Fp ZGEub3JnJTJGZGF0YXNldHMlMkYmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29t JTdDMjdjY2E2Y2FjOGZkNDlkOThmNjkwOGQ2MjNlZTI3ZmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NzM1OTAzMTUyODg0Mjk5JnNkYXRhPWxNUGozbnVN JTJGaU5VOEhCaXJ4SlE2TCUyQmc1TjVBQlQzTWNWT3BWcTVaT1cwJTNEJnJlc2VydmVkPTA+KSBh bmQgV0lERSAoaHR0cDovL21hd2kud2lkZS4uYWQuanAvbWF3aS88aHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRm1hd2kud2lkZS5h ZC5qcCUyRm1hd2klMkYmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMjdj Y2E2Y2FjOGZkNDlkOThmNjkwOGQ2MjNlZTI3ZmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3QzElN0MwJTdDNjM2NzM1OTAzMTUyODk0MzA4JnNkYXRhPUpFJTJCYTZtN0VsYVM2 YlU0SVR1b0xiNDhhY2slMkZOZlFUak9Za0hKcDdBeDZBJTNEJnJlc2VydmVkPTA+KSBvbiBhIHdo aW0gYW5kIHRyaWVkIHRvIHNlZSBob3cgbWFueSBjb25uZWN0aW9ucyB1dGlsaXplIHRpbWVzdGFt cHMuDQoNCkFzIGZhciBhcyBJJ3ZlIGNoZWNrZWQgc29tZSBhcmNoaXZlcyByZWNlbnRseSBjYXB0 dXJlZCwgaXQgc2VlbXMgdGhhdCBhcm91bmQgNjAtNzAlIFRDUCBjb25uZWN0aW9ucyB1c2UgdGlt ZXN0YW1wIG9wdGlvbi4gQnV0LCB0aGlzIHJhdGlvIHNlZW1zIHRvIGJlIGEgYml0IGxvd2VyIGFz IEkgdGhvdWdodCBtb3N0IG9mIGltcGxlbWVudGF0aW9ucyB0aGVzZSBkYXlzIHN1cHBvcnQgVFMg b3B0aW9uIGFuZCBhY3RpdmF0ZSBpdCBieSBkZWZhdWx0Lg0KRG9lcyBhbnlvbmUgaGF2ZSBzb21l IGlkZWFzIGFib3V0IGl0PyBBbSBJIGxvb2tpbmcgYXQgdW5jb21tb24gZGF0YT8gT3IgdGhlcmUg YXJlIHN0aWxsIG1hbnkgb2xkIGltcGxlbWVudGF0aW9ucyBhcm91bmQ/IE9yLCBtYW55IHVzZXJz IGhhdmUgZGlzYWJsZWQgdGhlIG9wdGlvbiBmb3Igc29tZSByZWFzb25zPw0KLS0NCllvc2hpDQoN Cg0KDQo= --_000_MWHPR21MB01913A2B05C037E594F78CBAB6150MWHPR21MB0191namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dCBmb2xsb3dzIFJGQyA2Mjk4IGFuZCBSVE8gaXMgYmFzZWQgb24gU1J0dCBhbmQgUnR0VmFyLiBS VFQgc2FtcGxlIG1lYXN1cmVtZW50IHdpbGwgbWFrZSB1c2Ugb2YgdGltZXN0YW1wcyB3aGVuIHBy ZXNlbnQgb3IganVzdCB1c2UgQUNLIGFycml2YWwgdGltZS4gQXMgYSBzaWRlIHJlc3VsdCBvZiBS QUNLIGltcGxlbWVudGF0aW9uLCB0aGUgbnVtYmVyIG9mIFJUVCBzYW1wbGVzIHRha2VuIHBlciBS VFQgd2FzDQogaW5jcmVhc2VkLiBTZWUgU2VjdGlvbiAyIGFuZCAzIGluIFJGQyA2Mjk4LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gWW9zaGlmdW1pIE5pc2hpZGEgJmx0O25p c2hpZGFAc2ZjLndpZGUuYWQuanAmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIFNl cHRlbWJlciAyNiwgMjAxOCAxMjo0OCBQTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBZb3No aWZ1bWkgTmlzaGlkYSAmbHQ7bmlzaGlkYUBzZmMud2lkZS5hZC5qcCZndDs7IHRjcG1AaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSB1c2FnZSBmb3IgdGltZXN0YW1wIG9w dGlvbnMgaW4gdGhlIHdpbGQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFByYXZl ZW4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg U2VwIDI2LCAyMDE4IGF0IDExOjIxIEFNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2YkBt aWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldpbmRvd3MgZG9lc27igJl0IGRv IHRpbWVzdGFtcCBvcHRpb24gYnkgZGVmYXVsdC4gSXTigJlzIDEwIGJ5dGUgcGVyIHBhY2tldCBv dmVyaGVhZCBmb3IgbWFyZ2luYWwgYmVuZWZpdHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZXJl c3RpbmcuIFNvLCB3aW5kb3dzIGRlcml2ZXMgUlRPIG9ubHkgZnJvbSBBQ0sgYXJyaXZhbCB0aW1l PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pllvc2hpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IHRjcG0gJmx0OzxhIGhyZWY9Im1haWx0bzp0Y3Bt LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3BtLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Zb3NoaWZ1bWkgTmlzaGlkYTxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxOCAxMDo0OSBBTTxicj4NCjxiPlRv OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3Bt QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbdGNwbV0gdXNhZ2UgZm9yIHRpbWVz dGFtcCBvcHRpb25zIGluIHRoZSB3aWxkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPnRoaXMgaXMganVzdCBvdXQgb2YgbXkgY3VyaW9zaXR5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ3ZlIGNoZWNrZWQg dHJhZmZpYyBhcmNoaXZlcyBpbiBDQUlEQSAoPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhLmNhaWRhLm9y ZyUyRmRhdGFzZXRzJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20l N0MyN2NjYTZjYWM4ZmQ0OWQ5OGY2OTA4ZDYyM2VlMjdmYiU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3MzU5MDMxNTI4ODQyOTkmYW1wO3NkYXRhPWxNUGoz bnVNJTJGaU5VOEhCaXJ4SlE2TCUyQmc1TjVBQlQzTWNWT3BWcTVaT1cwJTNEJmFtcDtyZXNlcnZl ZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhLmNhaWRhLm9yZy9kYXRhc2V0cy88L2E+ KQ0KIGFuZCBXSURFICg8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGbWF3aS53aWRlLmFkLmpwJTJGbWF3aSUyRiZh bXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMjdjY2E2Y2FjOGZkNDlk OThmNjkwOGQ2MjNlZTI3ZmIlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM2NzM1OTAzMTUyODk0MzA4JmFtcDtzZGF0YT1KRSUyQmE2bTdFbGFTNmJVNElUdW9M YjQ4YWNrJTJGTmZRVGpPWWtISnA3QXg2QSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9tYXdpLndpZGUuLmFkLmpwL21hd2kvPC9hPikNCiBvbiBhIHdoaW0gYW5kIHRy aWVkIHRvIHNlZSBob3cgbWFueSBjb25uZWN0aW9ucyB1dGlsaXplIHRpbWVzdGFtcHMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBm YXIgYXMgSSd2ZSBjaGVja2VkIHNvbWUgYXJjaGl2ZXMgcmVjZW50bHkgY2FwdHVyZWQsIGl0IHNl ZW1zIHRoYXQgYXJvdW5kIDYwLTcwJSBUQ1AgY29ubmVjdGlvbnMgdXNlIHRpbWVzdGFtcCBvcHRp b24uIEJ1dCwgdGhpcyByYXRpbyBzZWVtcyB0byBiZSBhIGJpdCBsb3dlciBhcyBJIHRob3VnaHQg bW9zdA0KIG9mIGltcGxlbWVudGF0aW9ucyB0aGVzZSBkYXlzIHN1cHBvcnQgVFMgb3B0aW9uIGFu ZCBhY3RpdmF0ZSBpdCBieSBkZWZhdWx0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Eb2VzIGFueW9uZSBoYXZlIHNvbWUgaWRlYXMgYWJvdXQg aXQ/IEFtIEkgbG9va2luZyBhdCB1bmNvbW1vbiBkYXRhPyBPciB0aGVyZSBhcmUgc3RpbGwgbWFu eSBvbGQgaW1wbGVtZW50YXRpb25zIGFyb3VuZD8gT3IsIG1hbnkgdXNlcnMgaGF2ZSBkaXNhYmxl ZCB0aGUgb3B0aW9uIGZvciBzb21lIHJlYXNvbnM/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvc2hpPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_MWHPR21MB01913A2B05C037E594F78CBAB6150MWHPR21MB0191namp_-- From nobody Wed Sep 26 20:43:58 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF02130DE0 for ; Wed, 26 Sep 2018 20:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZrw5pUfPId1 for ; Wed, 26 Sep 2018 20:43:53 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3578A124C04 for ; Wed, 26 Sep 2018 20:43:52 -0700 (PDT) Received: from mail-it1-f180.google.com (mail-it1-f180.google.com [209.85.166.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5999529C037 for ; Thu, 27 Sep 2018 12:43:50 +0900 (JST) Received: by mail-it1-f180.google.com with SMTP id p129-v6so5886451ite.3 for ; Wed, 26 Sep 2018 20:43:50 -0700 (PDT) X-Gm-Message-State: ABuFfogWywV6s9on06NTOuhUv6Q9UdW5tvjfDylW53YN27thJ+oAeIXc 5p+e/w9Bq0+UXYVhwSXswoXXGlwA+ktYtZMdROg= X-Google-Smtp-Source: ACcGV61r/37q7CtkkwRm+rivzAJCTmPTc3xFh5J2yb0LyXcTRe1RhJc3SFKAq48oSNxFjFW5WZdjK4L6j5f4kaosFL4= X-Received: by 2002:a02:90cf:: with SMTP id c15-v6mr8699038jag.130.1538019828208; Wed, 26 Sep 2018 20:43:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:930e:0:0:0:0:0 with HTTP; Wed, 26 Sep 2018 20:43:47 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Wed, 26 Sep 2018 20:43:47 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Praveen Balasubramanian Cc: Yoshifumi Nishida , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000849ba50576d225ee" Archived-At: Subject: Re: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 03:43:57 -0000 --000000000000849ba50576d225ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Praveen, Sorry, I was not clear enough... I was interested in how windows samples RTT. I mean, I am interesting in knowing if the conventional once per RTT samplings can archive sufficient results or recording the transmission time of sending packets like RACK can compensate the lack of TS options. -- Yoshi On Wed, Sep 26, 2018 at 1:36 PM, Praveen Balasubramanian < pravb@microsoft.com> wrote: > It follows RFC 6298 and RTO is based on SRtt and RttVar. RTT sample > measurement will make use of timestamps when present or just use ACK > arrival time. As a side result of RACK implementation, the number of RTT > samples taken per RTT was increased. See Section 2 and 3 in RFC 6298. > > > > *From:* Yoshifumi Nishida > *Sent:* Wednesday, September 26, 2018 12:48 PM > *To:* Praveen Balasubramanian > *Cc:* Yoshifumi Nishida ; tcpm@ietf.org > *Subject:* Re: [tcpm] usage for timestamp options in the wild > > > > Hi Praveen, > > > > On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > Windows doesn=E2=80=99t do timestamp option by default. It=E2=80=99s 10 b= yte per packet > overhead for marginal benefits. > > > > Interesting. So, windows derives RTO only from ACK arrival time? > > -- > > Yoshi > > > > > > *From:* tcpm *On Behalf Of *Yoshifumi Nishida > *Sent:* Wednesday, September 26, 2018 10:49 AM > *To:* tcpm@ietf.org > *Subject:* [tcpm] usage for timestamp options in the wild > > > > Hello, > > this is just out of my curiosity. > > I've checked traffic archives in CAIDA (https://data.caida.org/datasets/ > ) > and WIDE (http://mawi.wide..ad.jp/mawi/ > ) > on a whim and tried to see how many connections utilize timestamps. > > > > As far as I've checked some archives recently captured, it seems that > around 60-70% TCP connections use timestamp option. But, this ratio seems > to be a bit lower as I thought most of implementations these days support > TS option and activate it by default. > > Does anyone have some ideas about it? Am I looking at uncommon data? Or > there are still many old implementations around? Or, many users have > disabled the option for some reasons? > > -- > > Yoshi > > > > > > > --000000000000849ba50576d225ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Praveen,
Sorry, I was not cl= ear enough... I was interested in how windows samples RTT.

I mean, I am interesting in knowing if the conventional= once per RTT samplings can archive sufficient results
or recordi= ng the transmission time of sending packets like RACK can compensate the la= ck of TS options.
--
Yoshi

On Wed, Sep 26, 2018 at 1:36 PM, Pr= aveen Balasubramanian <pravb@microsoft.com> wrote:

It follows RFC 6298 and RTO is based on SRtt and Rtt= Var. RTT sample measurement will make use of timestamps when present or jus= t use ACK arrival time. As a side result of RACK implementation, the number= of RTT samples taken per RTT was increased. See Section 2 and 3 in RFC 6298.

=C2=A0

From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp> <= br> Sent: Wednesday, September 26, 2018 12:48 PM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>; tcpm@ietf.org
Subject: Re: [tcpm] usage for timestamp options in the wild

=C2=A0

Hi Praveen,

=C2=A0

On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubram= anian <pravb@mi= crosoft.com> wrote:

Windows doesn=E2=80=99t do timestamp option by defau= lt. It=E2=80=99s 10 byte per packet overhead for marginal benefits.<= u>

=C2=A0

Interesting. So, windows derives RTO only from ACK a= rrival time?=C2=A0

--

Yoshi

=C2=A0

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yoshifumi Nishida
Sent: Wednesday, September 26, 2018 10:49 AM
To: tcpm@ietf.org=
Subject: [tcpm] usage for timestamp options in the wild

=C2=A0

Hello,

this is just out of my curiosity.

I've checked traffic archives in CAIDA (https://data.caida.org/datase= ts/) and WIDE (http://mawi.wide..ad= .jp/mawi/) on a whim and tried to see how many connections utilize timestamps.=

=C2=A0

As far as I've checked some archives recently ca= ptured, it seems that around 60-70% TCP connections use timestamp option. B= ut, this ratio seems to be a bit lower as I thought most of implementations these days support TS option and activate it by default= .

Does anyone have some ideas about it? Am I looking a= t uncommon data? Or there are still many old implementations around? Or, ma= ny users have disabled the option for some reasons?=C2=A0

--

Yoshi

=C2=A0

=C2=A0

=C2=A0


--000000000000849ba50576d225ee-- From nobody Thu Sep 27 09:35:28 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AED130EBC for ; Thu, 27 Sep 2018 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGS6oI6TG14A for ; Thu, 27 Sep 2018 09:35:23 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe40::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59546130EB5 for ; Thu, 27 Sep 2018 09:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=48RmyuPsblGg1IGueIdMzpCOED28BVaADGoDVaaDvpI=; b=bWjMe/jN1o4GjvnLe+lgw7EWHbXsqqzA9SQN0dolUGcnZ2KPcicwvGnxfjivSqDqh67V5+1QPb7NYrEjp9CY7Lsw4BFUWXqwhIhAc4h0Y/MAyROZR6u3IlOBNK1YzchtWE2Dtn7ewB+PKxaLiiu7x9nfBR5t24AnldWXzgQpxVI= Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0702.namprd21.prod.outlook.com (10.175.142.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.2; Thu, 27 Sep 2018 16:35:20 +0000 Received: from MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::5443:2f41:bcd:634f]) by MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::5443:2f41:bcd:634f%5]) with mapi id 15.20.1207.011; Thu, 27 Sep 2018 16:35:20 +0000 From: Praveen Balasubramanian To: Yoshifumi Nishida CC: "tcpm@ietf.org" Thread-Topic: [tcpm] usage for timestamp options in the wild Thread-Index: AQHUVcFDBUenX6MW2Ui5madIUzPkvaUC3v1AgAAZMYCAAAwkYIAAeMKAgADUONA= Date: Thu, 27 Sep 2018 16:35:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:9:51a5:baf2:9712:df79] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0702; 6:S+JCIvq8+1U0qoC83jAb2qdFG+YccB+vOofNGKz1uCSVaJEp+EPi8CDhF5LepbzyAhhfv+6QYfK9MZm7yBEjVme1/Rj2RIwjXgGpUMMa6NYXPPyjo1ITiXyBMQEaRFJLgc9AeMC9Uzkmiw8RiSJlTBfKlPBh6OULWllVI5i6AXLvOP3W4BLTCKEx62T3slRNkOoni2lspj3D3J8Xe8OX5pAhQObmJaA3mtAgWYGMva6q4FoG/3suMDbq5FJBDrym/JTfuNMwogmcqNk0GV2GKzm5EkiG7HkZXIaFgr+j8+sHE8zPHyeqUiHt+Vf4EunqtVfZRnhHvDSERb26Pm4pn/23sXSyJ5q90XnrJ70Y9OISguidRL6AL/GJVNxD31C/gUziwZzsqVZCzD81i+t2E5kWuN3eA4DG+7ZXgDgVGlcRO88TjR5FxylsTDBSpjFD61maEfNkv8STA5GV0h2RYw==; 5:64UAhDSGGwDUioAiKawiJyEQCPkj9LgbI0zAVuQxGpeh7X0r5/fvOL6CB19LPnuYK8HJwSYCWFrR+2R1T+p4SapRy7cbnnGhZLrTZcT4LNPc9lgTS0crH4/6xyCrHfgYactcOsAXajNY2+pwwEh7z6LL399XnNC3pnT7mXjNMOE=; 7:wehTylgkZwno69xV/e2+h3TbIHpMasTSjjKBWeuwlrMZxOxLbNcba4FUN6mDk1vOmZIHrbpg0E2N+2cfXD3CEKZDDFkzsFwe4bVOL0domAtYsDYQDRLjPvuKZbQ8rKYItgfdvS/egBLnlKOaMhuaCATSAe9XC/mO+9ybk1HaMQ2gpE/6q1F391D+U++v6MLTZ7UE7pW+DduhBZu7URHiZe+WBTANlb6b/kQjvOBzJBSSRc6ysJJm7N2jsu1afNHf x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e4783c8d-bd84-44d5-2a85-08d62497370f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MWHPR21MB0702; x-ms-traffictypediagnostic: MWHPR21MB0702: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155)(190501279198761)(227612066756510)(219752817060721)(189930954265078); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(2018427008)(93006095)(93001095)(10201501046)(3002001)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123562045)(201708071742011)(7699051)(76991041); SRVR:MWHPR21MB0702; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0702; x-forefront-prvs: 0808323E97 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(346002)(396003)(366004)(199004)(189003)(53936002)(46003)(186003)(8936002)(8676002)(81166006)(81156014)(68736007)(486006)(11346002)(446003)(476003)(86362001)(86612001)(8990500004)(4326008)(6246003)(19609705001)(55016002)(9686003)(54896002)(33656002)(236005)(7736002)(790700001)(6116002)(74316002)(6436002)(229853002)(2906002)(6306002)(97736004)(93886005)(316002)(2900100001)(22452003)(71190400001)(71200400001)(102836004)(25786009)(606006)(10290500003)(7696005)(105586002)(76176011)(5660300001)(106356001)(53546011)(14454004)(10090500001)(99286004)(256004)(14444005)(6916009)(6506007)(34290500001)(5250100002)(508600001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0702; H:MWHPR21MB0191.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: P+IPpza1qjcRX0/nfgwokaQCYXJBnMzuyaCGWVgBwbZHkHOGjsncy9mEJcasXdLqdQ+3pPnYgQ0n9Pdg8YmQ80V0yLNZI9bmCFm+nXBM/RXTBEDjHSw2yakG/jFMe5Y4CFtsoMQkw4K85C50mnCJqDmYb6eUWsakPfL4SUpWyJFmM4IwBCA7iTjnVwHXiH2VdChlGPF1vJU3xyrZHNEd3FwAPJF7k7Si2tKryaUMTczZnB+6uKJHRNP1I5Q8oQQN2X6P8G4myVwoqqsJaJy+PIE/LLE+ajkQ7qPitGGsJ3VIWUDULnHz3+B9IPcz/OMcboRzmSDAHWC/FRhPUcKEVOJ77QxGyWdTQjppujJPUn4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0191F84789FF05409B43CE24B6140MWHPR21MB0191namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e4783c8d-bd84-44d5-2a85-08d62497370f X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2018 16:35:20.0656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0702 Archived-At: Subject: Re: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 16:35:27 -0000 --_000_MWHPR21MB0191F84789FF05409B43CE24B6140MWHPR21MB0191namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIGp1c3QgY29tcHV0aW5nIFJUTywgb25jZSBwZXIgUlRUIGlzIHN1ZmZpY2llbnQuIEJhc2Vk IG9uIGxhYiBtZWFzdXJlbWVudHMsIGFueSBkZWxheSBiYXNlZCBhbGdvcml0aG1zIGxpa2UgSHlT dGFydCBvciBkZWxheSBiYXNlZCBjb25nZXN0aW9uIGNvbnRyb2wgYWxsIHdvcmsgYmV0dGVyIGlm IG1vcmUgUlRUIHNhbXBsZXMgYXJlIHRha2VuIHRocm91Z2hvdXQgdGhlIFJUVC4gUkFDSyByZXF1 aXJlcyBzZW5kIHRpbWVzdGFtcHMgYW5kIHdpdGggdGhhdCBpbmZyYXN0cnVjdHVyZSBpbiBwbGFj ZSBpdCBpcyBlYXNpZXIgdG8gY29tcHV0ZSBtb3JlIFJUVCBzYW1wbGVzIHBlciBSVFQuDQoNCkl0 J3MgY2VydGFpbmx5IGEgd29ydGh3aGlsZSBBL0IvQyBleHBlcmltZW50IHRvIGNvbXBhcmUgYWNj dXJhY3kgb2YgUlRUIHVzaW5nIHRpbWVzdGFtcHMsIG9uZSBzYW1wbGUgcGVyIFJUVCwgYW5kIG11 bHRpcGxlIHNhbXBsZXMgKE4pIHNwcmVhZCBhY3Jvc3MgdGhlIFJUVC4gV2luZG93cyBoYXMgYSBj b25zdGFudCBOIHRvZGF5IHRvIG1pbmltaXplIG1lbW9yeSBhbmQgQ1BVIHVzYWdlLiBJZiBhbnlv bmUgaGFzIGFueSBkYXRhIG9uIHRoaXMsIHBsZWFzZSBzaGFyZS4NCg0KRnJvbTogWW9zaGlmdW1p IE5pc2hpZGEgPG5pc2hpZGFAc2ZjLndpZGUuYWQuanA+DQpTZW50OiBXZWRuZXNkYXksIFNlcHRl bWJlciAyNiwgMjAxOCA4OjQ0IFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi QG1pY3Jvc29mdC5jb20+DQpDYzogWW9zaGlmdW1pIE5pc2hpZGEgPG5pc2hpZGFAc2ZjLndpZGUu YWQuanA+OyB0Y3BtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RjcG1dIHVzYWdlIGZvciB0aW1l c3RhbXAgb3B0aW9ucyBpbiB0aGUgd2lsZA0KDQpIaSBQcmF2ZWVuLA0KU29ycnksIEkgd2FzIG5v dCBjbGVhciBlbm91Z2guLi4gSSB3YXMgaW50ZXJlc3RlZCBpbiBob3cgd2luZG93cyBzYW1wbGVz IFJUVC4NCg0KSSBtZWFuLCBJIGFtIGludGVyZXN0aW5nIGluIGtub3dpbmcgaWYgdGhlIGNvbnZl bnRpb25hbCBvbmNlIHBlciBSVFQgc2FtcGxpbmdzIGNhbiBhcmNoaXZlIHN1ZmZpY2llbnQgcmVz dWx0cw0Kb3IgcmVjb3JkaW5nIHRoZSB0cmFuc21pc3Npb24gdGltZSBvZiBzZW5kaW5nIHBhY2tl dHMgbGlrZSBSQUNLIGNhbiBjb21wZW5zYXRlIHRoZSBsYWNrIG9mIFRTIG9wdGlvbnMuDQotLQ0K WW9zaGkNCg0KT24gV2VkLCBTZXAgMjYsIDIwMTggYXQgMTozNiBQTSwgUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+ PiB3cm90ZToNCkl0IGZvbGxvd3MgUkZDIDYyOTggYW5kIFJUTyBpcyBiYXNlZCBvbiBTUnR0IGFu ZCBSdHRWYXIuIFJUVCBzYW1wbGUgbWVhc3VyZW1lbnQgd2lsbCBtYWtlIHVzZSBvZiB0aW1lc3Rh bXBzIHdoZW4gcHJlc2VudCBvciBqdXN0IHVzZSBBQ0sgYXJyaXZhbCB0aW1lLiBBcyBhIHNpZGUg cmVzdWx0IG9mIFJBQ0sgaW1wbGVtZW50YXRpb24sIHRoZSBudW1iZXIgb2YgUlRUIHNhbXBsZXMg dGFrZW4gcGVyIFJUVCB3YXMgaW5jcmVhc2VkLiBTZWUgU2VjdGlvbiAyIGFuZCAzIGluIFJGQyA2 Mjk4Lg0KDQpGcm9tOiBZb3NoaWZ1bWkgTmlzaGlkYSA8bmlzaGlkYUBzZmMud2lkZS5hZC5qcDxt YWlsdG86bmlzaGlkYUBzZmMud2lkZS5hZC5qcD4+DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJl ciAyNiwgMjAxOCAxMjo0OCBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt aWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4NCkNjOiBZb3NoaWZ1bWkg TmlzaGlkYSA8bmlzaGlkYUBzZmMud2lkZS5hZC5qcDxtYWlsdG86bmlzaGlkYUBzZmMud2lkZS5h ZC5qcD4+OyB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt0Y3BtXSB1c2FnZSBmb3IgdGltZXN0YW1wIG9wdGlvbnMgaW4gdGhlIHdpbGQNCg0KSGkgUHJh dmVlbiwNCg0KT24gV2VkLCBTZXAgMjYsIDIwMTggYXQgMTE6MjEgQU0sIFByYXZlZW4gQmFsYXN1 YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29t Pj4gd3JvdGU6DQpXaW5kb3dzIGRvZXNu4oCZdCBkbyB0aW1lc3RhbXAgb3B0aW9uIGJ5IGRlZmF1 bHQuIEl04oCZcyAxMCBieXRlIHBlciBwYWNrZXQgb3ZlcmhlYWQgZm9yIG1hcmdpbmFsIGJlbmVm aXRzLg0KDQpJbnRlcmVzdGluZy4gU28sIHdpbmRvd3MgZGVyaXZlcyBSVE8gb25seSBmcm9tIEFD SyBhcnJpdmFsIHRpbWU/DQotLQ0KWW9zaGkNCg0KDQpGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBZb3No aWZ1bWkgTmlzaGlkYQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTggMTA6NDkg QU0NClRvOiB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogW3Rj cG1dIHVzYWdlIGZvciB0aW1lc3RhbXAgb3B0aW9ucyBpbiB0aGUgd2lsZA0KDQpIZWxsbywNCnRo aXMgaXMganVzdCBvdXQgb2YgbXkgY3VyaW9zaXR5Lg0KSSd2ZSBjaGVja2VkIHRyYWZmaWMgYXJj aGl2ZXMgaW4gQ0FJREEgKGh0dHBzOi8vZGF0YS5jYWlkYS5vcmcvZGF0YXNldHMvPGh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG ZGF0YS5jYWlkYS5vcmclMkZkYXRhc2V0cyUyRiZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jv c29mdC5jb20lN0NlY2Y4ODdiMWU4OTA0MWRhMzBlMDA4ZDYyNDcwM2QwZCU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3MzY0NjE4NDgyOTY3NTEmc2RhdGE9 T2ZmR3dZRmhqJTJGd3FUYnNUN1A3JTJCYVlpODhXdFQ1bmUxTUk2azc5dW54VFElM0QmcmVzZXJ2 ZWQ9MD4pIGFuZCBXSURFIChodHRwOi8vbWF3aS53aWRlLi5hZC5qcC9tYXdpLzxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGbWF3 aS53aWRlLmFkLmpwJTJGbWF3aSUyRiZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5j b20lN0NlY2Y4ODdiMWU4OTA0MWRhMzBlMDA4ZDYyNDcwM2QwZCU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3MzY0NjE4NDgyOTY3NTEmc2RhdGE9UTFNMHFW ZTd1JTJCJTJGNDBzcG4yJTJCNzQ2SXI3V1VHbGx5TGlJcjJ0QnRORndoVSUzRCZyZXNlcnZlZD0w Pikgb24gYSB3aGltIGFuZCB0cmllZCB0byBzZWUgaG93IG1hbnkgY29ubmVjdGlvbnMgdXRpbGl6 ZSB0aW1lc3RhbXBzLg0KDQpBcyBmYXIgYXMgSSd2ZSBjaGVja2VkIHNvbWUgYXJjaGl2ZXMgcmVj ZW50bHkgY2FwdHVyZWQsIGl0IHNlZW1zIHRoYXQgYXJvdW5kIDYwLTcwJSBUQ1AgY29ubmVjdGlv bnMgdXNlIHRpbWVzdGFtcCBvcHRpb24uIEJ1dCwgdGhpcyByYXRpbyBzZWVtcyB0byBiZSBhIGJp dCBsb3dlciBhcyBJIHRob3VnaHQgbW9zdCBvZiBpbXBsZW1lbnRhdGlvbnMgdGhlc2UgZGF5cyBz dXBwb3J0IFRTIG9wdGlvbiBhbmQgYWN0aXZhdGUgaXQgYnkgZGVmYXVsdC4NCkRvZXMgYW55b25l IGhhdmUgc29tZSBpZGVhcyBhYm91dCBpdD8gQW0gSSBsb29raW5nIGF0IHVuY29tbW9uIGRhdGE/ IE9yIHRoZXJlIGFyZSBzdGlsbCBtYW55IG9sZCBpbXBsZW1lbnRhdGlvbnMgYXJvdW5kPyBPciwg bWFueSB1c2VycyBoYXZlIGRpc2FibGVkIHRoZSBvcHRpb24gZm9yIHNvbWUgcmVhc29ucz8NCi0t DQpZb3NoaQ0KDQoNCg0KDQo= --_000_MWHPR21MB0191F84789FF05409B43CE24B6140MWHPR21MB0191namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G b3IganVzdCBjb21wdXRpbmcgUlRPLCBvbmNlIHBlciBSVFQgaXMgc3VmZmljaWVudC4gQmFzZWQg b24gbGFiIG1lYXN1cmVtZW50cywgYW55IGRlbGF5IGJhc2VkIGFsZ29yaXRobXMgbGlrZSBIeVN0 YXJ0IG9yIGRlbGF5IGJhc2VkIGNvbmdlc3Rpb24gY29udHJvbCBhbGwgd29yayBiZXR0ZXIgaWYg bW9yZSBSVFQgc2FtcGxlcyBhcmUgdGFrZW4gdGhyb3VnaG91dCB0aGUgUlRULiBSQUNLIHJlcXVp cmVzIHNlbmQNCiB0aW1lc3RhbXBzIGFuZCB3aXRoIHRoYXQgaW5mcmFzdHJ1Y3R1cmUgaW4gcGxh Y2UgaXQgaXMgZWFzaWVyIHRvIGNvbXB1dGUgbW9yZSBSVFQgc2FtcGxlcyBwZXIgUlRULg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0J3MgY2VydGFpbmx5IGEgd29ydGh3aGlsZSBBL0IvQyBl eHBlcmltZW50IHRvIGNvbXBhcmUgYWNjdXJhY3kgb2YgUlRUIHVzaW5nIHRpbWVzdGFtcHMsIG9u ZSBzYW1wbGUgcGVyIFJUVCwgYW5kIG11bHRpcGxlIHNhbXBsZXMgKE4pIHNwcmVhZCBhY3Jvc3Mg dGhlIFJUVC4gV2luZG93cyBoYXMgYSBjb25zdGFudCBOIHRvZGF5IHRvIG1pbmltaXplIG1lbW9y eSBhbmQgQ1BVIHVzYWdlLiBJZiBhbnlvbmUgaGFzDQogYW55IGRhdGEgb24gdGhpcywgcGxlYXNl IHNoYXJlLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFlvc2hpZnVtaSBO aXNoaWRhICZsdDtuaXNoaWRhQHNmYy53aWRlLmFkLmpwJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTggODo0NCBQTTxicj4NCjxiPlRvOjwvYj4gUHJh dmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBZb3NoaWZ1bWkgTmlzaGlkYSAmbHQ7bmlzaGlkYUBzZmMud2lkZS5hZC5qcCZndDs7 IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSB1c2FnZSBmb3Ig dGltZXN0YW1wIG9wdGlvbnMgaW4gdGhlIHdpbGQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGkgUHJhdmVlbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U29ycnksIEkgd2FzIG5vdCBjbGVhciBlbm91Z2guLi4gSSB3YXMg aW50ZXJlc3RlZCBpbiBob3cgd2luZG93cyBzYW1wbGVzIFJUVC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1lYW4sIEkgYW0gaW50ZXJlc3Rp bmcgaW4ga25vd2luZyBpZiB0aGUgY29udmVudGlvbmFsIG9uY2UgcGVyIFJUVCBzYW1wbGluZ3Mg Y2FuIGFyY2hpdmUgc3VmZmljaWVudCByZXN1bHRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vciByZWNvcmRpbmcgdGhlIHRyYW5zbWlzc2lvbiB0 aW1lIG9mIHNlbmRpbmcgcGFja2V0cyBsaWtlIFJBQ0sgY2FuIGNvbXBlbnNhdGUgdGhlIGxhY2sg b2YgVFMgb3B0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Zb3NoaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFdlZCwgU2VwIDI2LCAyMDE4IGF0IDE6MzYgUE0sIFByYXZlZW4gQmFsYXN1 YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQg Zm9sbG93cyBSRkMgNjI5OCBhbmQgUlRPIGlzIGJhc2VkIG9uIFNSdHQgYW5kIFJ0dFZhci4gUlRU IHNhbXBsZSBtZWFzdXJlbWVudCB3aWxsIG1ha2UgdXNlIG9mIHRpbWVzdGFtcHMgd2hlbiBwcmVz ZW50IG9yIGp1c3QgdXNlIEFDSyBhcnJpdmFsIHRpbWUuIEFzIGEgc2lkZSByZXN1bHQgb2YgUkFD SyBpbXBsZW1lbnRhdGlvbiwNCiB0aGUgbnVtYmVyIG9mIFJUVCBzYW1wbGVzIHRha2VuIHBlciBS VFQgd2FzIGluY3JlYXNlZC4gU2VlIFNlY3Rpb24gMiBhbmQgMyBpbiBSRkMgNjI5OC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBZb3NoaWZ1bWkgTmlzaGlkYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj5u aXNoaWRhQHNmYy53aWRlLmFkLmpwPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIFNlcHRlbWJlciAyNiwgMjAxOCAxMjo0OCBQTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBC YWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBZb3NoaWZ1bWkgTmlzaGlkYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pc2hpZGFAc2ZjLndpZGUu YWQuanAiIHRhcmdldD0iX2JsYW5rIj5uaXNoaWRhQHNmYy53aWRlLmFkLmpwPC9hPiZndDs7DQo8 YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gdXNhZ2UgZm9yIHRpbWVzdGFt cCBvcHRpb25zIGluIHRoZSB3aWxkPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IaSBQcmF2ZWVuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBTZXAgMjYsIDIwMTggYXQgMTE6MjEgQU0sIFByYXZl ZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldpbmRvd3MgZG9lc27i gJl0IGRvIHRpbWVzdGFtcCBvcHRpb24gYnkgZGVmYXVsdC4gSXTigJlzIDEwIGJ5dGUgcGVyIHBh Y2tldCBvdmVyaGVhZCBmb3IgbWFyZ2luYWwgYmVuZWZpdHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkludGVyZXN0aW5nLiBTbywgd2luZG93cyBkZXJpdmVzIFJUTyBvbmx5IGZyb20gQUNLIGFy cml2YWwgdGltZT8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+WW9zaGk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gdGNwbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRjcG0tYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG0tYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPllvc2hpZnVtaSBOaXNoaWRhPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI2LCAyMDE4IDEwOjQ5IEFNPGJyPg0KPGI+VG86PC9i PiA8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt0Y3BtXSB1c2FnZSBmb3IgdGltZXN0YW1w IG9wdGlvbnMgaW4gdGhlIHdpbGQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+dGhpcyBpcyBqdXN0IG91dCBvZiBteSBjdXJpb3NpdHkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkndmUgY2hlY2tlZCB0cmFm ZmljIGFyY2hpdmVzIGluIENBSURBICg8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGEuY2FpZGEub3JnJTJG ZGF0YXNldHMlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2Vj Zjg4N2IxZTg5MDQxZGEzMGUwMDhkNjI0NzAzZDBkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjczNjQ2MTg0ODI5Njc1MSZhbXA7c2RhdGE9T2ZmR3dZRmhq JTJGd3FUYnNUN1A3JTJCYVlpODhXdFQ1bmUxTUk2azc5dW54VFElM0QmYW1wO3Jlc2VydmVkPTAi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGEuY2FpZGEub3JnL2RhdGFzZXRzLzwvYT4pDQog YW5kIFdJREUgKDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZtYXdpLndpZGUuYWQuanAlMkZtYXdpJTJGJmFtcDtk YXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NlY2Y4ODdiMWU4OTA0MWRhMzBl MDA4ZDYyNDcwM2QwZCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY3MzY0NjE4NDgyOTY3NTEmYW1wO3NkYXRhPVExTTBxVmU3dSUyQiUyRjQwc3BuMiUyQjc0 NklyN1dVR2xseUxpSXIydEJ0TkZ3aFUlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vbWF3aS53aWRlLi5hZC5qcC9tYXdpLzwvYT4pDQogb24gYSB3aGltIGFuZCB0cmll ZCB0byBzZWUgaG93IG1hbnkgY29ubmVjdGlvbnMgdXRpbGl6ZSB0aW1lc3RhbXBzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgZmFy IGFzIEkndmUgY2hlY2tlZCBzb21lIGFyY2hpdmVzIHJlY2VudGx5IGNhcHR1cmVkLCBpdCBzZWVt cyB0aGF0IGFyb3VuZCA2MC03MCUgVENQIGNvbm5lY3Rpb25zIHVzZSB0aW1lc3RhbXAgb3B0aW9u LiBCdXQsIHRoaXMgcmF0aW8gc2VlbXMgdG8gYmUgYSBiaXQgbG93ZXIgYXMgSSB0aG91Z2h0IG1v c3QNCiBvZiBpbXBsZW1lbnRhdGlvbnMgdGhlc2UgZGF5cyBzdXBwb3J0IFRTIG9wdGlvbiBhbmQg YWN0aXZhdGUgaXQgYnkgZGVmYXVsdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+RG9lcyBhbnlvbmUgaGF2ZSBzb21lIGlkZWFzIGFib3V0IGl0 PyBBbSBJIGxvb2tpbmcgYXQgdW5jb21tb24gZGF0YT8gT3IgdGhlcmUgYXJlIHN0aWxsIG1hbnkg b2xkIGltcGxlbWVudGF0aW9ucyBhcm91bmQ/IE9yLCBtYW55IHVzZXJzIGhhdmUgZGlzYWJsZWQg dGhlIG9wdGlvbiBmb3Igc29tZSByZWFzb25zPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Zb3NoaTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR21MB0191F84789FF05409B43CE24B6140MWHPR21MB0191namp_-- From nobody Thu Sep 27 16:56:28 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B31E128A6E for ; Thu, 27 Sep 2018 16:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3nJrcAtHptN for ; Thu, 27 Sep 2018 16:56:25 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B60B128CB7 for ; Thu, 27 Sep 2018 16:56:24 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id m9-v6so666830ita.2 for ; Thu, 27 Sep 2018 16:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QFMUevKApwbfIAp64yTovha1FTw0+KV0kzcaS8wUgNg=; b=ZVkGOya9OqyXQ9qh8DXAXRgCEx3/R9tGgSX48pw2EY6Bg57kKEeOh6IQ+o8JySsBP+ 9PCKStAu+Qv8ByShJn2LPDdLeBqET/s1ggeHHmfjyDA4Vqh5sjoI5DEdXWMwe/yvGXRK WBx2fAyZ7MHx0cQINwv9MLe/LVkSID91V8oNVoycCTJnO0vrAtkYvOOQt5/CmmIrw2AG 96UqedgfjhX3QXIqgA1dP/i01vni/gAKRykF2LEQ886iHI6OdCTSdwEODvQKJqck/dC3 SVYp9wDWX2U1AB1MH+9gWMiU5euYMn77rUUXunbA59EAPK0RpJOK12Hq1TAFMhfIUmW9 7kfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QFMUevKApwbfIAp64yTovha1FTw0+KV0kzcaS8wUgNg=; b=kwbvnn+UUhFNxVSFq5ZKIp4FRauy9bC71zO8Zp2o94iFLbHfVILae6hu0/AqqsyTW5 ipl9wlAZaPGPxT2SEfvIrg+L6tq1GZLU9rkD/MeaTiT825WsjVWnL0d/GIRItrZ0aOG/ qZkZNsvMA4OH7H7pyjXA85HbldYqFlAfwlAPiINPkNSN4C7TJfsvLaS0m7ljuld38Gss Sg5mFhTRz6Or4KC8/XpKrDm/5V41ZU8pYDpLPPAP96qevf1JHvKORuRhVjKRkK+FvDyF yE/SRsM5XFIlW4GfXeEJXWMrHl2UPlurAlQs7Hs5gWZpf1pqyGIX3+T4+f6WHybzaZIE qC+A== X-Gm-Message-State: ABuFfojctug0hcYWknvmUSy5zxNtEPBvAwglOlO5rmma3hIo2s/GTma9 4lHk+Rq0g8/J/GyKS3iZFU0jFC8yg+36cDpYCjjOmTYo X-Google-Smtp-Source: ACcGV635fegZQf2orYGE8MiLAe7yPSDkjz9M9zsGUeKpp83cffmHRLxZt+aLW2KUZBM9sCEYE4As332FsjPtZjtqd9g= X-Received: by 2002:a24:5d4a:: with SMTP id w71-v6mr655620ita.118.1538092583289; Thu, 27 Sep 2018 16:56:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:f715:0:0:0:0:0 with HTTP; Thu, 27 Sep 2018 16:55:42 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Thu, 27 Sep 2018 16:55:42 -0700 Message-ID: To: Yoshifumi Nishida Cc: Praveen Balasubramanian , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] usage for timestamp options in the wild X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Sep 2018 23:56:28 -0000 On Wed, Sep 26, 2018 at 12:43 PM, Yoshifumi Nishida wrote: > > > > On Wed, Sep 26, 2018 at 11:37 AM, Yuchung Cheng wrote= : >> >> On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian >> wrote: >> > >> > Windows doesn=E2=80=99t do timestamp option by default. It=E2=80=99s 1= 0 byte per packet overhead for marginal benefits. >> > >> > >> > >> > From: tcpm On Behalf Of Yoshifumi Nishida >> > Sent: Wednesday, September 26, 2018 10:49 AM >> > To: tcpm@ietf.org >> > Subject: [tcpm] usage for timestamp options in the wild >> > >> > >> > >> > Hello, >> > >> > this is just out of my curiosity. >> > >> > I've checked traffic archives in CAIDA (https://data.caida.org/dataset= s/) and WIDE (http://mawi.wide..ad.jp/mawi/) on a whim and tried to see how= many connections utilize timestamps. >> > >> > >> > >> > As far as I've checked some archives recently captured, it seems that = around 60-70% TCP connections use timestamp option. But, this ratio seems t= o be a bit lower as I thought most of implementations these days support TS= option and activate it by default. >> how recent are the archives? > > > They are 2018 data. There's some number dated in 2011 "2. GOOGLE MEASUREMENTS We sampled TCP statistics on unmodified Google Web servers world-wide for one week in May 2011. The servers use a recent version of Linux 2.6 with settings listed in Table 4. The servers do not include the changes proposed in this paper. The global statistics for interactive Web services are summarized in Table 1. Among the billions of connections sampled, 96% of the connections negotiated SACK but only 12% of the connections negotiated Timestamps. The majority of clients are Microsoft Windows which by default do not use TCP Timestamps." https://storage.googleapis.com/pub-tools-public-publication-data/pdf/37486.= pdf While this is comparing apple (google) to oranges (caida), I would say 70% is already a significant jump. However I am sensing that the value of TCP timestamp options is under-valued - Linux for example uses TS for many things: 1. RTT estimation on retransmission - this is crucial when a TCP is in constant recovery mode such as encountering a traffic policer. Note that the standard ACK time approach no longer works if any sequence acked has been transmitted, thus RTO may stale during extended recovery period. 2. Undo operations (i.e. TCP Eifel RFC4015) requires TCP timestamps - being able to detect false reactions to losses is particularly key for "loss-based" congestion control. Such false positives are common in wireless or even wired networks due to all sorts of dark queues and L2 optimizations. While DSACK and F-RTO can also be used to detect false recoveries - both of them take at least one more round-trip and/or require new application data, while timestamp can detect false retransmission instantly on the original ACK 3. Receiver buffer auto-tuning uses TCP ACKs' TS value to echo to measure RTT from the receiver to tune the buffer size. 4. Potentially TCP timestamps being generated with known units, can be used to gauge the data arrival rate. The measurement can be valuable for congestion control b/c it's not subject to hectic ACK delays in modern networks. I know folks at NetFlix is doing some deep research into this aspect. QUIC has emphasized the importance of unique packet identifier - TCP TS provides a close equivalent and is super useful, especially w/ more precision / unit vs an opaque value. >> >> >> AFAIK TS is enabled by default on Linux, FreeBSD, and iOS. Linux has >> that by default more than a decade > > > that's why I was wondering. > -- > Yoshi >