From nobody Mon Apr 1 00:58:17 2019 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 62DB012009E; Mon, 1 Apr 2019 00:58:15 -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, 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 BbevfKoctYdA; Mon, 1 Apr 2019 00:58:13 -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 E3B0512008C; Mon, 1 Apr 2019 00:58:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id A8EAD25A13; Mon, 1 Apr 2019 09:58:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1554105490; bh=QaJmPqdKRcmTJgkLHckCywdrO+zoS4bhFblp3Gul2ug=; h=From:To:CC:Subject:Date:From; b=uhPAB8HAUd1qg54h4/9LkqsaArHkRiy9Fg9B3H9j91F8A6+dbcN+lY5j+bilm0911 zBe72G46IJgH+U6p1yphZ59eOLef8k4gC42oW3H+LfXZkKn+QkPG/XDUcaE8rHSLHb TAxy272Gum5hQefN3LemL09eNl/K494+81qaXPIE= 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 ZLq4ojj1RsxC; Mon, 1 Apr 2019 09:58:09 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-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; Mon, 1 Apr 2019 09:58:09 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.111]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Mon, 1 Apr 2019 09:58:09 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Draft minutes for Prague TCPM meeting Thread-Index: AdToYKV2QlxjWYPmQI2HpF7xpUcLhg== Date: Mon, 1 Apr 2019 07:58:09 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D290618@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Draft minutes for Prague TCPM meeting 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: Mon, 01 Apr 2019 07:58:16 -0000 Draft minutes for the Prague meeting can be found at: https://datatracker.i= etf.org/meeting/104/materials/minutes-104-tcpm-00 If there is any need to correct the minutes, please reach out to the chairs= . Thanks a lot to the notetaker Colin Bookham for his excellent minutes! Michael From nobody Mon Apr 1 23:28:38 2019 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 789E3120090 for ; Mon, 1 Apr 2019 23:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Rkk4GiKOS16Y for ; Mon, 1 Apr 2019 23:28:35 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4763012001E for ; Mon, 1 Apr 2019 23:28:35 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 44YK6914ZBz2xZh; Tue, 2 Apr 2019 08:28:33 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 44YK6902zSz1xpl; Tue, 2 Apr 2019 08:28:33 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([fe80::2c53:f99a:e2a9:19c6%21]) with mapi id 14.03.0439.000; Tue, 2 Apr 2019 08:28:32 +0200 From: To: "tcpm@ietf.org" , "pravb@microsoft.com" Thread-Topic: draft-ietf-tcpm-converter: Praveen's Comment Thread-Index: AdTpHUjyJVzjtSnASnuB/GHn+JiZWg== Date: Tue, 2 Apr 2019 06:28:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA50E39@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA50E39OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] draft-ietf-tcpm-converter: Praveen's 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: Tue, 02 Apr 2019 06:28:38 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA50E39OPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Praveen, all, During the Prague meeting, you raised a comment about the inability of your= implementation to send data in a SYN without enabling TFO. I suggest to following change to the draft to take into account your commen= t: OLD: Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry data inside its payload but forbids the receiver from delivering it to the application until completion of the three-way-handshake. This restriction was motivated by two concerns. First, duplicate SYNs can cause problems for some applications that rely on TCP [RFC7413]. Second, TCP suffers from SYN flooding attacks [RFC4987]. TCP Fast Open [RFC7413] solves these two pro= blems for applications that can tolerate replays by using the TCP Fast Open option that includes a cookie. However, the utilization of this option consumes space in the limited TCP extended header. Furthermore, there are situations, as noted in Section 7.3 of [RFC7413] where it is possible to accept the payload of SYN packets without creating additional security risks such as a network where addresses cannot be spoofed and the Transport Converter only serves a set of hosts that are identified by these addresses. For these reasons, this specification does not mandate the use of the TCP Fast Open option when the Client sends a connection establishment packet towards a Transport Converter. The Convert protocol includes an optional Cookie TLV that provides similar protection as the TCP Fast Open option without consuming space in the extended TCP header. NEW: Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry data inside its payload but forbids the receiver from delivering it to the application until completion of the three-way-handshake. This restriction was motivated by two concerns. First, duplicate SYNs can cause problems for some applications that rely on TCP [RFC7413]. Second, TCP suffers from SYN flooding attacks [RFC4987]. TCP Fast Open [RFC7413] solves these two pro= blems for applications that can tolerate replays by using the TCP Fast Open option that includes a cookie. However, the utilization of this option consumes space in the limited TCP extended header. Furthermore, there are situations, as noted in Section 7.3 of [RFC7413] where it is possible to accept the payload of SYN packets without creating additional security risks such as a network where addresses cannot be spoofed and the Transport Converter only serves a set of hosts that are identified by these addresses. For these reasons, this specification does not mandate the use of the TCP Fast Open option when the Client sends a connection establishment packet towards a Transport Converter. The Convert protocol includes an optional Cookie TLV that provides similar protection as the TCP Fast Open option without consuming space in the extended TCP header. o Implementation Note: For implementations which do not allow to insert data in the payload of a SYN without making use of TFO option, a cookie-less TFO mode is used. Considerations related to the use of the Cookie TLV apply also for such cookie-less TFO mode. Please let us know if this change addresses your concern. Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93302EA50E39OPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Praveen, all,

 

During the Prague meeting, you raised a com= ment about the inability of your implementation to send data in a SYN witho= ut enabling TFO.

I suggest to following change to the draft = to take into account your comment:

 

OLD:

 

   Standard TCP ([RFC0793]=
, Section 3.4) allows a SYN packet to =
carry
   data inside its payload but forbids =
the receiver from delivering it
   to the application until completion =
of the three-way-handshake.  This
   restriction was motivated by two con=
cerns.  First, duplicate SYNs can
   cause problems for some applications=
 that rely on TCP [RFC7413<=
span lang=3D"EN-US">].
   Second, TCP suffers from SYN floodin=
g attacks [RFC4987].  TCP Fast<=
/span>
   Open [RFC7413] solves these two problems f=
or applications that can
   tolerate replays by using the TCP Fa=
st Open option that includes a
   cookie.  However, the utilizati=
on of this option consumes space in
   the limited TCP extended header.&nbs=
p; Furthermore, there are situations,
   as noted in Section&nbs=
p;7.3 of [RFC7413] where it is possible to =
accept
   the payload of SYN packets without c=
reating additional security risks
   such as a network where addresses ca=
nnot be spoofed and the Transport
   Converter only serves a set of hosts=
 that are identified by these
   addresses.  For these reasons, =
this specification does not mandate
   the use of the TCP Fast Open option =
when the Client sends a
   connection establishment packet towa=
rds a Transport Converter.  The
   Convert protocol includes an optiona=
l Cookie TLV that provides
   similar protection as the TCP Fast O=
pen option without consuming
   space in the extended TCP header.

 

 

NEW:

 

   Standard TCP ([RFC0793]=
, Section 3.4) allows a SYN packet to =
carry
   data inside its payload but forbids =
the receiver from delivering it
   to the application until completion =
of the three-way-handshake.  This
   restriction was motivated by two con=
cerns.  First, duplicate SYNs can
   cause problems for some applications=
 that rely on TCP [RFC7413<=
span lang=3D"EN-US">].
   Second, TCP suffers from SYN floodin=
g attacks [RFC4987].  TCP Fast<=
/span>
   Open [RFC7413] solves these two problems f=
or applications that can
   tolerate replays by using the TCP Fa=
st Open option that includes a
   cookie.  However, the utilizati=
on of this option consumes space in
   the limited TCP extended header.&nbs=
p; Furthermore, there are situations,
   as noted in Section&nbs=
p;7.3 of [RFC7413] where it is possible to =
accept
   the payload of SYN packets without c=
reating additional security risks
   such as a network where addresses ca=
nnot be spoofed and the Transport
   Converter only serves a set of hosts=
 that are identified by these
   addresses.  For these reasons, =
this specification does not mandate
   the use of the TCP Fast Open option =
when the Client sends a
   connection establishment packet towa=
rds a Transport Converter.  The
   Convert protocol includes an optiona=
l Cookie TLV that provides
   similar protection as the TCP Fast O=
pen option without consuming
   space in the extended TCP header.
 
   o  Implementation Note: For imp=
lementations which do not allow to
      insert data in the=
 payload of a SYN without making use of TFO
      option, a cookie-l=
ess TFO mode is used.  Considerations related to

      the use of the Coo=
kie TLV apply also for such cookie-less TFO


      mode.<=
/o:p>


 


Please let us know if this change addresses=
 your concern.



 


Thank you.



 


Cheers,


Med
--_000_787AE7BB302AE849A7480A190F8B93302EA50E39OPEXCAUBMA2corp_-- From nobody Thu Apr 4 04:27:42 2019 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 0DBB012009A for ; Thu, 4 Apr 2019 04:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZmo24bAdb5q for ; Thu, 4 Apr 2019 04:27:38 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573EC120092 for ; Thu, 4 Apr 2019 04:27:38 -0700 (PDT) Received: from [10.0.1.118] (unknown [212.201.121.94]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 9B2E872106C37 for ; Thu, 4 Apr 2019 13:27:19 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <3244A43C-C3FF-4CA8-9D4A-4AD2D650C0D0@lurchi.franken.de> References: <7a6e508d-9a78-ac57-1cb9-4da663eaddfd@ericsson.com> To: "tcpm@ietf.org Extensions" Date: Thu, 4 Apr 2019 13:27:18 +0200 X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [tcpm] Fwd: WGLC for draft-ietf-lwig-tcp-constrained-node-networks 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, 04 Apr 2019 11:27:41 -0000 Dear all, as discussed in the last WG meeting, we are running this WGLC also on = the TCPM mailing list. If you have comments, please also include lwip@ietf.org in = your response. Best regards Michael >=20 > -------- Forwarded Message -------- > Subject: WGLC for draft-ietf-lwig-tcp-constrained-node-networks > Date: Tue, 2 Apr 2019 09:58:43 +0300 > From: Mohit Sethi M > To: lwip@ietf.org >=20 >=20 > Dear all, >=20 > This email starts the WGLC for = draft-ietf-lwig-tcp-constrained-node-networks > = https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-= 07 >=20 > Many of you have already provided useful feedback that has helped us = improve this document. If you have any remaining concerns or issues, = please comment on the mailing list before the WGLC expires. The WGLC = will end in four weeks on 30th April 2019. >=20 > If you have previously reviewed the document and feel that it is ready = for IESG review, please express support on the mailing list. It helps = the document shepherd to move the document forward. >=20 > This WGLC will also be forwarded to the TCMP mailing list. Thank you = authors for your hard work. >=20 > Zhen and Mohit >=20 >=20 >=20 From nobody Thu Apr 4 09:42:28 2019 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 BEC8512014E; Thu, 4 Apr 2019 09:42: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 h_RCaKA0nhoS; Thu, 4 Apr 2019 09:42:18 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0442C12010E; Thu, 4 Apr 2019 09:42:18 -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 B7D981B0010F; Thu, 4 Apr 2019 17:42:12 +0100 (BST) Message-ID: <5CA633E4.5090306@erg.abdn.ac.uk> Date: Thu, 04 Apr 2019 17:42:12 +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: Carles Gomez Montenegro CC: lwip@ietf.org, tcpm@ietf.org, jon.crowcroft@cl.cam.ac.uk References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-07.txt] 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, 04 Apr 2019 16:42:21 -0000 I have looked at the diff. Thanks for responding to my comments. Gorry On 29/03/2019, 19:28, Carles Gomez Montenegro wrote: > Dear all, > > Please find below a new revision (-07) of the draft entitled "TCP Usage > Guidance in the Internet of Things (IoT)". > > The updates in this revision are intended to address the comments and > incorporate the suggestions kindly provided by Gorry Fairhurst. > > @Gorry: thank you very much for taking the time to review the draft. > > Cheers, > > Carles (on behalf of all authors) > > > > ---------------------------- Original Message ---------------------------- > Subject: [Lwip] I-D Action: > draft-ietf-lwig-tcp-constrained-node-networks-07.txt > From: internet-drafts@ietf.org > Date: Fri, March 29, 2019 8:17 pm > To: i-d-announce@ietf.org > Cc: lwip@ietf.org > -------------------------------------------------------------------------- > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Light-Weight Implementation Guidance WG > of the IETF. > > Title : TCP Usage Guidance in the Internet of Things (IoT) > Authors : Carles Gomez > Jon Crowcroft > Michael Scharf > Filename : draft-ietf-lwig-tcp-constrained-node-networks-07.txt > Pages : 27 > Date : 2019-03-29 > > Abstract: > This document provides guidance on how to implement and use the > Transmission Control Protocol (TCP) in Constrained-Node Networks > (CNNs), which are a characterstic of the Internet of Things (IoT). > Such environments require a lightweight TCP implementation and may > not make use of optional functionality. This document explains a > number of known and deployed techniques to simplify a TCP stack as > well as corresponding tradeoffs. The objective is to help embedded > developers with decisions on which TCP features to use. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-07 > https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-07 > > > 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/ > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > From nobody Mon Apr 15 06:39:26 2019 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 348D51201A9; Mon, 15 Apr 2019 06:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 5r7Wf_xMiiNM; Mon, 15 Apr 2019 06:39:21 -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 5A8E91201A1; Mon, 15 Apr 2019 06:39:21 -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=BUat4ybNL1+3dXoiMt50ik7wfN1oAY+hb9u+kpwjjO4=; b=rP07y/WichjnVoxVYHAcougwE vXIxUJD4/hBUJYrhDq7OCBYUmlISlXHAWqgkKl7SzDtjq+i3HKIwq4ky8NXPrQ5mjhUxFZfHrFln0 NGtTXnUsfuJQ0kYHRpKdGhnG/acOOaJ2UQ3IkA4gtXTqyPm53Sl+57tfEhikS2ATUwZRjOXQZxr+F x/sM4HE9IrYArn7j8WZccwyhbkN7dN9TR7T2fIWmdB/U/aesDI5fWOFTqyhzIvD3anYrt2KIMDiyO XYNpVYXNr33vVkAe6wWmnzuewGBj7CkwDces6BV9kPmFC9Wrmxo+sjeJX6gIUZRZ2AXheyl6si5x+ 8cIQpBNDQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52302 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hG1pK-003eF3-Ot; Mon, 15 Apr 2019 09:39:19 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-3FAD1B30-5B3B-4DF5-A7AE-34431AE8C089 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) X-Apple-Base-Url: x-msg://2/ X-Universally-Unique-Identifier: 8BE81A72-A10F-407D-824F-EEDEB9790FD6 X-Apple-Mail-Remote-Attachments: YES From: Joe Touch X-Mailer: iPad Mail (16E227) In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D256A45@rznt8114.rznt.rzdir.fht-esslingen.de> X-Apple-Windows-Friendly: 1 Date: Mon, 15 Apr 2019 06:39:14 -0700 Cc: "tcpm@ietf.org" , "draft-touch-tcpm-2140bis@ietf.org" Content-Transfer-Encoding: 7bit X-Apple-Mail-Signature: Message-Id: <21D858F0-CA71-49C8-AC3C-9122DEBA17CA@strayalpha.com> References: <6EC6417807D9754DA64F3087E2E2E03E2D24EEA4@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D256A45@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" 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: Subject: Re: [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06 targeting informational status 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: Mon, 15 Apr 2019 13:39:24 -0000 --Apple-Mail-3FAD1B30-5B3B-4DF5-A7AE-34431AE8C089 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, Michael, I am in the process of posting the new draft-ietf-tcp-2140bis-00 version, wh= ich addresses your comments as indicated below. Joe > On Mar 11, 2019, at 2:56 PM, Scharf, Michael wrote: >=20 > Disclaimer: Chair hat off >=20 > I have read draft-touch-tcpm-2140bis-06. I believe that this document is a= good starting point for a new TCPM working group item targeting an informat= ional RFC. >=20 > Below are some initial comments that are hopefully not difficult to sort o= ut in a follow-up version. >=20 > Comments: >=20 > - The abstract and/or the introduction could better explain the purpose of= the document and why it is informational. For instance, a sentence such as "= this document provides informational guidance to TCP implementers..." or the= like could be useful. Done. > - While this may be somewhat obvious to most of us, the document could als= o mention more explicitly that the content does not affect TCP interoperabil= ity. Done in the abstract and intro. > - Section 2 may not be required given that the document does not use RFC 2= 119 language, except in a quote from RFC 7413 and in the appendix that will b= e removed prior to publication. If section 2 stays in the document, it shoul= d be reworded according to RFC 8174. The section is revised to explain that those keywords do not have special me= aning, which I think is needed to be clear. > - In Section 6, I find the sentence and references "RTT values are updated= by a more complicated mechanism [RFC1644][Ja86]" somewhat confusing. First,= I don't know what [Ja86] actually refers to; without a public archive such a= reference has only very limited value to (younger) readers. That also appli= es to a later use of [Ja86]. Agreed and removed throughout. > Second, RFC 1644 is now obsolete and I think T/TCP belongs better into App= endix A. Agreed; we thought we removed all but the one pointer to the appendix, and n= ow have. > I wonder if this section could be reworded with references to RFC 6298? Th= e same comment may also apply to later discussions of the RTT. In some cases in some places, but I think you mean RFC6928. > Editorial nits: >=20 > - The abstract may be more useful on the first page We have no control over this; the boilerplate for drafts is included as requ= ired. This would be corrected upon final publication by the RFC Editor as po= ssible anyway. > - Section 8: "TCP is sometimes used in situations where packets of the sam= e host-pair always take the same path." This sentence seems broken, no? Yes, and reversed. It has been revised for clarity. > - Section 8: "some Virtual Private Networks (VPNs) are known to use propri= etary UDP encapsulation methods". I don't understand why "proprietary" is us= ed in this context; actually I even don't even understand why "UDP encapsula= tion" matters. Doesn't this paragraph apply to all tunnel encaps? Yes; also revised for clarity. The issue, FWIW, is to differentiate encapsul= ation from encryption; the former remains problematic if the encapsulation u= ses non-standard mechanisms that cannot be readily determined in advance usi= ng known protocols. > - Section 9: "One such problem is determining the associated prior outgoin= g packet for an incoming packet, to infer RTT from the exchange." Well, as a= non-native speaker, I had to read this sentence at least three times to und= erstand what is probably meant by that. Also revised for clarity as well. >=20 >=20 > Thanks >=20 > Michael >=20 >=20 >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael >> Sent: Wednesday, March 6, 2019 11:48 PM >> To: tcpm@ietf.org >> Subject: [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06 >> targeting informational status >>=20 >> Hi all, >>=20 >> The document draft-touch-tcpm-2140bis has been discussed quite a bit in >> TCPM. One question has been the status (BCP or INFO). The version >> draft-touch-tcpm-2140bis-06 explicitly targets informational status and >> plans to obsolete RFC 2140 (which is informational, too). >>=20 >> The intention of this e-mail is to confirm that draft-touch-tcpm- >> 2140bis-06 should be adopted as informational TCPM working group item, >> i.e., that a new item should be added to the TCPM charter: >>=20 >> Nov. 2019 Submit document on TCP Control Block Interdependence to >> the IESG for publication as Informational RFC >>=20 >> The adoption call runs on the TCPM mailing list until March 22. Please >> let us know if you support adoption of the document, or if there are >> any concerns. >>=20 >> Best regards >>=20 >> Michael >> (TCPM co-chair) >>=20 >>=20 >> -------- Forwarded Message -------- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Friday, January 4, 2019 5:52 PM >> To: tcpm@ietf.org >> Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm- >> 2140bis-06.txt >>=20 >> FYI - >> This version: >> - obsoletes 2140 >> - says so in the abstract and intro >> - includes a "changes from 2140" section summarizing the >> differences >> Note that the earlier versions did cite 2140, but did not as directly >> indicate that this is intended as its replacement. >> Joe >>=20 >> -------- Forwarded Message -------- >> Subject: >> New Version Notification for draft-touch-tcpm-2140bis-06.txt >> Date: >> Fri, 04 Jan 2019 08:49:25 -0800 >> From: >> internet-drafts@ietf.org >> To: >> Safiqul Islam , Michael Welzl >> , Joseph Touch , Joe Touch >> >>=20 >>=20 >>=20 >> A new version of I-D, draft-touch-tcpm-2140bis-06.txt >> has been successfully submitted by Joe Touch and posted to the >> IETF repository. >>=20 >> Name: draft-touch-tcpm-2140bis >> Revision: 06 >> Title: TCP Control Block Interdependence >> Document date: 2019-01-04 >> Group: Individual Submission >> Pages: 22 >> URL: https://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis- >> 06.txt >> Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-2140bis/ >> Htmlized: https://tools.ietf.org/html/draft-touch-tcpm-2140bis-06 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tcpm- >> 2140bis >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tcpm-2140bis-06 >>=20 >> Abstract: >> This memo updates and replaces RFC 2140's description of >> interdependent TCP control blocks, in which part of the TCP state is >> shared among similar concurrent or consecutive connections. TCP >> state includes a combination of parameters, such as connection >> state, current round-trip time estimates, congestion control >> information, and process information. Most of this state is >> maintained on a per-connection basis in the TCP Control Block (TCB), >> but implementations can (and do) share certain TCB information >> across connections to the same host. Such sharing is intended to >> improve overall transient transport performance, while maintaining >> backward-compatibility with existing implementations. The sharing >> described herein is limited to only the TCB initialization and so >> has no effect on the long-term behavior of TCP after a connection >> has been established. >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >> _______________________________________________ >> 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 --Apple-Mail-3FAD1B30-5B3B-4DF5-A7AE-34431AE8C089 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi, Michael,

I am in the process of posting the= new draft-ietf-tcp-2140bis-00 version, which addresses your comments as ind= icated below.

Joe

On Mar 1= 1, 2019, at 2:56 PM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

Disclaimer: Chair hat off

I have read draft-touch-tcpm-2140bis-06. I believe that thi= s document is a good starting point for a new TCPM working group item target= ing an informational RFC.

Below are some initia= l comments that are hopefully not difficult to sort out in a follow-up versi= on.

Comments:

- Th= e abstract and/or the introduction could better explain the purpose of the d= ocument and why it is informational. For instance, a sentence such as "this d= ocument provides informational guidance to TCP implementers..." or the like c= ould be useful.

Done.

- While this may be somewhat obvious to most of us, the docume= nt could also mention more explicitly that the content does not affect TCP i= nteroperability.

Done in the abstract an= d intro.

- Section 2 may not be required giv= en that the document does not use RFC 2119 language, except in a quote from R= FC 7413 and in the appendix that will be removed prior to publication. If se= ction 2 stays in the document, it should be reworded according to RFC 8174.<= br class=3D"">

The section is revised to explain that those keywords d= o not have special meaning, which I think is needed to be clear.

- In Section 6, I find the sentence and re= ferences "RTT values are updated by a more complicated mechanism [RFC1644][J= a86]" somewhat confusing. First, I don't know what [Ja86] actually refers to= ; without a public archive such a reference has only very limited value to (= younger) readers. That also applies to a later use of [Ja86].
Agreed= and removed throughout.

Secon= d, RFC 1644 is now obsolete and I think T/TCP belongs better into Appendix A= .

Agreed; we thought we removed all but the one pointer to the appen= dix, and now have.

I wonder if t= his section could be reworded with references to RFC 6298? The same comment m= ay also apply to later discussions of the RTT.
In som= e cases in some places, but I think you mean RFC6928.

Editorial nits:

- The ab= stract may be more useful on the first page

We have n= o control over this; the boilerplate for drafts is included as required. Thi= s would be corrected upon final publication by the RFC Editor as possible an= yway.

- Section 8: "TCP is some= times used in situations where packets of the same host-pair always take the= same path." This sentence seems broken, no?

<= /div>
Yes, and= reversed. It has been revised for clarity.

- Section 8: "some Virtual Private Networks (VPNs) are known to= use proprietary UDP encapsulation methods". I don't understand why "proprie= tary" is used in this context; actually I even don't even understand why "UD= P encapsulation" matters. Doesn't this paragraph apply to all tunnel encaps?=

Yes; also revised for clarity. The issue, FWIW, is t= o differentiate encapsulation from encryption; the former remains problemati= c if the encapsulation uses non-standard mechanisms that cannot be readily d= etermined in advance using known protocols.

- Section 9: "One such problem is determining the associated pr= ior outgoing packet for an incoming packet, to infer RTT from the exchange."= Well, as a non-native speaker, I had to read this sentence at least three t= imes to understand what is probably meant by that.

Al= so revised for clarity as well.



Thanks

Michael

-----Original Message-----
From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, M= ichael
Sent: Wednesday, March 6, 2019 11:48 PM
T= o: tcpm@ietf.org
Subject:= [tcpm] Working group acceptance of draft-touch-tcpm-2140bis-06
targeting informational status

Hi all,

The document draft-touch-tcpm-2140bis has been discus= sed quite a bit in
TCPM. One question has been the status (BCP= or INFO). The version
draft-touch-tcpm-2140bis-06 explicitly t= argets informational status and
plans to obsolete RFC 2140 (wh= ich is informational, too).

The intention of th= is e-mail is to confirm that draft-touch-tcpm-
2140bis-06 shou= ld be adopted as informational TCPM working group item,
i.e., t= hat a new item should be added to the TCPM charter:

 Nov. 2019  Submit document on TCP Control Block Interdependen= ce to
the IESG for publication as Informational RFC

The adoption call runs on the TCPM mailing list until Marc= h 22. Please
let us know if you support adoption of the docume= nt, or if there are
any concerns.

Best regards

Michael
(TCPM co-ch= air)


-------- Forwarded Message -= -------
From: tcpm [m= ailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch
Sent: = Friday, January 4, 2019 5:52 PM
To: tcpm@ietf.org
Subject: [tcpm] Fwd: New Version Noti= fication for draft-touch-tcpm-
2140bis-06.txt
FYI -
This version:
  &nb= sp; - obsoletes 2140
    - says so in the abstr= act and intro
    - includes a "changes from 21= 40" section summarizing the
differences
Note tha= t the earlier versions did cite 2140, but did not as directly
= indicate that this is intended as its replacement.
Joe

-------- Forwarded Message --------
Subj= ect:
New Version Notification for draft-touch-tcpm-2140bis-06.= txt
Date:
Fri, 04 Jan 2019 08:49:25 -0800
From:
inte= rnet-drafts@ietf.org
To:
Safiqul Islam <<= a href=3D"mailto:safiquli@ifi.uio.no">safiquli@ifi.uio.no>, Michael W= elzl
<michawe@ifi.uio= .no>, Joseph Touch <touch@= strayalpha.com>, Joe Touch
<touch@strayalpha.com>


A new version of I-D, draft-touch-tcpm-2140bis-0= 6.txt
has been successfully submitted by Joe Touch and posted t= o the
IETF repository.

Name: draf= t-touch-tcpm-2140bis
Revision: 06
Title: TCP Con= trol Block Interdependence
Document date: 2019-01-04
Group: Individual Submission
Pages: 22
URL: <= a href=3D"https://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis-">ht= tps://www.ietf.org/internet-drafts/draft-touch-tcpm-2140bis-
06.txt
Status: https://datatracker.ietf.org/doc/draft-touch-tcpm= -2140bis/
Htmlized: https://tools.ietf.org/html/draft-touch-tcpm-2= 140bis-06
Htmlized: https://datatracker.ietf.org/doc/html/draft-to= uch-tcpm-
2140bis
Diff: https://www.ietf.org= /rfcdiff?url2=3Ddraft-touch-tcpm-2140bis-06

Abstract:
This memo updates and replaces RFC 2140's descripti= on of
interdependent TCP control blocks, in which part of the T= CP state is
shared among similar concurrent or consecutive con= nections. TCP
state includes a combination of parameters, such= as connection
state, current round-trip time estimates, conge= stion control
information, and process information. Most of th= is state is
maintained on a per-connection basis in the TCP Co= ntrol Block (TCB),
but implementations can (and do) share cert= ain TCB information
across connections to the same host. Such s= haring is intended to
improve overall transient transport perf= ormance, while maintaining
backward-compatibility with existin= g implementations. The sharing
described herein is limited to o= nly the TCB initialization and so
has no effect on the long-te= rm behavior of TCP after a connection
has been established.


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.

The IE= TF Secretariat
_______________________________________________=
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
=
_______________________________________________
t= cpm mailing list
tcpm@ietf.or= g
h= ttps://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail-3FAD1B30-5B3B-4DF5-A7AE-34431AE8C089-- From nobody Mon Apr 15 15:50:42 2019 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 32D1712027C; Mon, 15 Apr 2019 15:50:34 -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.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <155536863410.10872.7527024445472065423@ietfa.amsl.com> Date: Mon, 15 Apr 2019 15:50:34 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-00.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: Mon, 15 Apr 2019 22:50:34 -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 Control Block Interdependence Authors : Joe Touch Michael Welzl Safiqul Islam Filename : draft-ietf-tcpm-2140bis-00.txt Pages : 23 Date : 2019-04-15 Abstract: This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 15 15:51:23 2019 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 C73D012027A for ; Mon, 15 Apr 2019 15:51:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155536868181.10769.15943534650322017151.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2019 15:51:21 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG 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, 15 Apr 2019 22:51:22 -0000 Changed milestone "Submit document on TCP Control Block Interdependence to the IESG for publication as Informational RFC", added draft-ietf-tcpm-2140bis to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Tue Apr 16 18:48:09 2019 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 658961201A1 for ; Tue, 16 Apr 2019 18:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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] 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 viT5zFkFC5RQ for ; Tue, 16 Apr 2019 18:48:05 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690116.outbound.protection.outlook.com [40.107.69.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71C412015A for ; Tue, 16 Apr 2019 18:48:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=We1p6ISzXXqsBSNqHt6dqTUH4vJHCOqzdfot6SBIB6yL3uLGUqsHJAOvvOpSwbgIc+3ufUzMdcWqOQGmWUgRzknPhZHZgSI56h07gC8LTHoy4D6T71xoFeflHm0V6vE8g9uO+yNVaTQQsXNY8wP8GcpzjAD5VDjmaTf3OU8f2RPweRADzka8EFkpSEP0vmdsc7HaTsc8AE0H3B03QNq6p1UhPfyflHUYgBCJQrZgdioO3Y5WijqCwMawn1yfQvuh7DzulTM2ESNEhHAHhWVwS/JaNTAclMDi49OBZjLqDjwG02l7HkEiNJQm8vD8q3juocLeWIPT29skXKzcnmcsNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Buf7kAyQU7bvNp18Qs1vx0AyTOJ+reMNtcPPbMo0OI=; b=qXfKGcG7KRyDp+2XTkJGvI5N5adtwlAo3b75zJcoP7txuyekwwBoHgK+QEsdwElUwdgp61yxdxVWCAvlTrW8L9F/mHwK8NnRUWuhoLTPEgyXQXYfvnEpG3d7ZlRNsgHHMJ3F+641l4iZsQfEMpNgWmvUEMn8VMAwKFfv49m6Ci7STzi2V7tw+87QplAn+7vuxDW1Y+G7Gh6R1RLKwwCscF7xDdw/0+dyyC5cXcCYIUIuMcEkUTuhQdp4/tCECn9H88NKg+tyPnoPp2PkwPx3rlz2Z88wWe+ngEbI57Cakk4yzbwJ/VK/ODwSc11QYJZDOccmM9iywEnIWhH7xn/eLA== ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none 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=9Buf7kAyQU7bvNp18Qs1vx0AyTOJ+reMNtcPPbMo0OI=; b=oowqq2xA1rqaUge/QoCRhJAvrV9z+JvFAjulsr0h4RAvH6rAJC9oanB2Ct/Iecy+Y5lTVI0M5lfjG3wKM7Nj9ib75PswruxlJRzZsWHKOOjFq4gw3x9CdO6s4WbgFlCLwAWIKVVRgwUeRdJOFis+BrNcVsZefy6/FbFRghnDTzc= Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (52.132.24.13) by BL0PR2101MB1042.namprd21.prod.outlook.com (52.132.24.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.1; Wed, 17 Apr 2019 01:48:03 +0000 Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9%8]) with mapi id 15.20.1835.000; Wed, 17 Apr 2019 01:48:03 +0000 From: Yi Huang To: "tcpm@ietf.org" CC: Praveen Balasubramanian , Matt Olson Thread-Topic: A question about PTO/RTO rescheduling in RACK draft Thread-Index: AdT0v450DAV7LlJPShaJ9NxD6aYmRA== Date: Wed, 17 Apr 2019 01:48:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-04-17T01:48:01.5391021Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=00d3cf94-4d32-4f59-82ee-607320319143; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2001:4898:80e8:a:90dd:d90c:8727:9001] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b24bacbd-ef04-4826-3a91-08d6c2d6bae2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB1042; x-ms-traffictypediagnostic: BL0PR2101MB1042: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(376002)(136003)(396003)(189003)(199004)(25786009)(8990500004)(81166006)(86362001)(74316002)(86612001)(71200400001)(71190400001)(10090500001)(2351001)(9686003)(22452003)(81156014)(1730700003)(106356001)(478600001)(8936002)(256004)(14444005)(14454004)(7736002)(4326008)(8676002)(10290500003)(52536014)(5660300002)(68736007)(9326002)(6116002)(790700001)(33656002)(55016002)(6436002)(2501003)(5640700003)(6916009)(107886003)(6506007)(476003)(54896002)(6306002)(97736004)(2906002)(105586002)(54906003)(316002)(486006)(53936002)(99286004)(7696005)(186003)(102836004)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1042; H:BL0PR2101MB1043.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QED+EWv3p4aTCn/1ibZGoqsK4RwHEiu/hTDQyaK09+dKoIvuxsfvCG8GIgpwRskeYZpSC0u9uZyNVcIhnknwDYnZNbMurwcFXl5nyh0CFlg1A5ZM+EWS0ac7pomU/UC1lHGGN+3j9d0OhdvRRvKczSezeEW0yXmUexpRXS0B3RzMfW7ztHeMA9qStAGQ+DKZNGMXm01L1oacEEM6axIU84sSle+b0snka3LcmJvigDM2geyvtY8hqLxOsjyYTRd5Ko6KaNPnKI3oZe/JzCBR6gaKyq0UbKxksQXzQqCd9lRFByE1yk3PmTmw1/+FTsFJ1wAuBtvbvkxaoVcissUfi0nzvmltI08Qj1HnSdGTM9EY1kyEfMq2niL10TkBeo/YgKzRO78rH7M2uIr4j4aKkS6miakAVpgmD2h8juFKaN4= Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB104347EF7FC7CD5C86DF08B7C3250BL0PR2101MB1043_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b24bacbd-ef04-4826-3a91-08d6c2d6bae2 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 01:48:03.2053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1042 Archived-At: Subject: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 17 Apr 2019 01:48:07 -0000 --_000_BL0PR2101MB104347EF7FC7CD5C86DF08B7C3250BL0PR2101MB1043_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a question about PTO/RTO rescheduling logic in RACK draft. The draft= states, in Section 6.5.1, "If there was a previously scheduled PTO or RTO = pending, then that pending PTO or RTO should first be cancelled, and then t= he new PTO should be scheduled". So if an app keeps posting data in an inte= rval less than PTO and RTO (say one byte each time and Cwnd is large enough= ) and no acks are coming back due to network failures or a receiver that ju= st does not send anything back, the app will never fires RTO since the time= r is pushed out each time we send this one byte data. Is this a problem? Wh= at is the intention of pushing out the timer for each send? I think in this= case the sender should disconnect the connection because, without TLP, the= sender would have had several RTOs and closed the connection. Also, RFC 6298 Section 5 (5.1) states "Every time a packet containing data = is sent (including a retransmission), if the timer is not running, start it= running so that it will expire after RTO seconds (for the current value of= RTO).", which says TCP should schedule timer only when it is not schedule = yet and this kind of conflicts with (or is overridden by) what is in RACK/T= LP draft. Thanks, Yi Huang --_000_BL0PR2101MB104347EF7FC7CD5C86DF08B7C3250BL0PR2101MB1043_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a question about PTO/RTO rescheduling logic i= n RACK draft. The draft states, in Section 6.5.1, “If there was a pre= viously scheduled PTO or RTO pending, then that pending PTO or RTO should f= irst be cancelled, and then the new PTO should be scheduled”. So if an app keeps posting data in an interval= less than PTO and RTO (say one byte each time and Cwnd is large enough) an= d no acks are coming back due to network failures or a receiver that just d= oes not send anything back, the app will never fires RTO since the timer is pushed out each time we send this one b= yte data. Is this a problem? What is the intention of pushing out the timer= for each send? I think in this case the sender should disconnect the conne= ction because, without TLP, the sender would have had several RTOs and closed the connection.

 

Also, RFC 6298 Section 5 (5.1) states “Every t= ime a packet containing data is sent (including a retransmission), if the t= imer is not running, start it running so that it will expire after RTO seco= nds (for the current value of RTO).”, which says TCP should schedule timer only when it is not schedule yet and this k= ind of conflicts with (or is overridden by) what is in RACK/TLP draft.=

 

Thanks,

 

Yi Huang

--_000_BL0PR2101MB104347EF7FC7CD5C86DF08B7C3250BL0PR2101MB1043_-- From nobody Wed Apr 17 07:05:25 2019 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 BAC25120104 for ; Wed, 17 Apr 2019 07:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0YQZ4lBha7i9 for ; Wed, 17 Apr 2019 07:05:22 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C600E12008D for ; Wed, 17 Apr 2019 07:05:21 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 44kkXH6Yqsz2y7n; Wed, 17 Apr 2019 16:05:19 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 44kkXH5jStz5vN2; Wed, 17 Apr 2019 16:05:19 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup ([fe80::193b:bc32:1ad3:362d%21]) with mapi id 14.03.0439.000; Wed, 17 Apr 2019 16:05:17 +0200 From: To: "tcpm@ietf.org" CC: "Konda, Tirumaleswar Reddy (TirumaleswarReddy_Konda@McAfee.com)" , JACQUENET Christian TGI/OLN Thread-Topic: Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-converter) Thread-Index: AdT1JpTl6PWd1LxoQCSpHCkyMXtjvw== Date: Wed, 17 Apr 2019 14:05:16 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_f700a7d21aad4f9690c644e77b0525e2OPEXCAUBM5Fcorporateadr_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-converter) 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, 17 Apr 2019 14:05:24 -0000 --_000_f700a7d21aad4f9690c644e77b0525e2OPEXCAUBM5Fcorporateadr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Now that the 0-RTT Converter spec is about to be LCed, we would like to ask= the WG to consider this draft https://datatracker.ietf.org/doc/draft-boucadair-tcpm-dhc-converter/ which = is useful for the dynamic provisioning of the Converters to CPEs, in partic= ular. The converters discovery options cannot be defined in the dhc WG because it= s charter says the following: "Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are generally outside of scope for the DHC WG. Such options should be defined within their respective WGs" We hope that tcpm can host this work. Cheers, Med --_000_f700a7d21aad4f9690c644e77b0525e2OPEXCAUBM5Fcorporateadr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Now that the 0-RTT Converter spec is about = to be LCed, we would like to ask the WG to consider this draft

https://datatracker.ietf.org/doc/draf= t-boucadair-tcpm-dhc-converter/ which is useful for the dynamic provisioning of the Converters to CPEs, in particular.

 

The converters discovery options cannot be = defined in the dhc WG because its charter says the following:

 

“Definitions of new DHCP options that= are delivered using standard

mechanisms with documented semantics are no= t considered a protocol

extension and thus are generally outside of= scope for the DHC WG. Such

options should be defined with= in their respective WGs”

 

We hope that tcpm can host this work.

 

Cheers,

Med

--_000_f700a7d21aad4f9690c644e77b0525e2OPEXCAUBM5Fcorporateadr_-- From nobody Wed Apr 17 11:13:47 2019 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 8A3F1120006 for ; Wed, 17 Apr 2019 11:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0n7Mncy_DbT for ; Wed, 17 Apr 2019 11:13:44 -0700 (PDT) Received: from mail.strugglingcoder.info (unknown [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id B98691200B1 for ; Wed, 17 Apr 2019 11:13:44 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 66CAF17F67; Wed, 17 Apr 2019 11:13:44 -0700 (PDT) Date: Wed, 17 Apr 2019 11:13:44 -0700 From: hiren panchasara To: Yi Huang Cc: "tcpm@ietf.org" , Matt Olson Message-ID: <20190417181344.GM31257@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="m46qSNjkc66Ye11q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 17 Apr 2019 18:13:46 -0000 --m46qSNjkc66Ye11q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/17/19 at 01:48P, Yi Huang wrote: > Hi, Hi! I don't see anything inherently wrong in how this works or I am missing something. >=20 > I have a question about PTO/RTO rescheduling logic in RACK draft. The dra= ft states, in Section 6.5.1, "If there was a previously scheduled PTO or RT= O pending, then that pending PTO or RTO should first be cancelled, and then= the new PTO should be scheduled". So if an app keeps posting data in an in= terval less than PTO and RTO (say one byte each time and Cwnd is large enou= gh) and no acks are coming back due to network failures or a receiver that = just does not send anything back, the app will never fires RTO since the ti= mer is pushed out each time we send this one byte data. Is this a problem? By growing CWND, TCP has decided that it is okay to send that much without needing an ACK. I think something along the lines of detecting that connection is app-limited OR doing newcwv like validation may help to keep CWND in check? > What is the intention of pushing out the timer for each send? 6.5.1 (Step 1) indicated a few conditions for scheduling PTO (i.e. pushing out the timer) so its not blindly doing for each send. But it would do that for the case you described as app *is* handing new data to be sent to TCP. >I think in this case the sender should disconnect the connection because, = without TLP, the sender would have had several RTOs and closed the connecti= on. I am probably not understanding something. I think you are saying TLP is causing RTO to be pushed out unnecessarily. One cannot schedule PTO when a TLP is out. So, on first timeout i.e. PTO as we prefer that over RTO, you send a TLP out. And if you don't get an ACK back for that, next timeout would be an RTO as 6.5.1. Phase 1 condition 1 suggests. But if there is new data to be sent, RTO would also gets pushed out, no? >=20 > Also, RFC 6298 Section 5 (5.1) states "Every time a packet containing dat= a is sent (including a retransmission), if the timer is not running, start = it running so that it will expire after RTO seconds (for the current value = of RTO).", which says TCP should schedule timer only when it is not schedul= e yet and this kind of conflicts with (or is overridden by) what is in RACK= /TLP draft. I am not sure I follow. For the connection, you need a timeout mechanism. And RACK draft suggests keeping PTO aligned with RTO as the former is less expensive. Try PTO and if it doesn't work, do RTO. I believe the wordings around "first cancel the pending one and then only schedule new one" are for clarity around implementation details. Gist is to not keep 2 sets of timers running for the same timeout mechanism.=20 Someone with more clue on the list would probably correct me. :-) Cheers, Hiren --m46qSNjkc66Ye11q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJct2zUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lmOYH/1zZsR+VomAd7u4ia/8JG0ze dfspL3vFowyf2sl0IBcMZhvxMQxoYWL4jDvtOc9b7kT8Yv1cuiMvV0U3dxtaS1+F 1w8PJxR9wVgQ78JOGN/WkzmLgj+IV7YB5Q9pebtdXf+ScvDRZtE6O44qwZSvj6rS +pffI6yfawjSWsLdy0qY9mfVweFnUBF/au9ixyWIw+lkcOJFz/U2C4YWJ5ogvCnK AMXUn45eGE2JiboI6AH/2Gl1c0FNyxQ+Hc4rJh00XYdWoIyIBG2ApQFzFrzQ1J4U 5y6fFMW2PqRGOIx/FmKx+ap8y2oVF/b0BmxzJd7eBJu5958Mn+n23RF9oWJGoxA= =hwIO -----END PGP SIGNATURE----- --m46qSNjkc66Ye11q-- From nobody Wed Apr 17 12:22:06 2019 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 7E96C120392 for ; Wed, 17 Apr 2019 12:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNbMZiSBKW5U for ; Wed, 17 Apr 2019 12:22:03 -0700 (PDT) Received: from mail.strugglingcoder.info (unknown [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 38E94120363 for ; Wed, 17 Apr 2019 12:22:03 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id C649117018; Wed, 17 Apr 2019 12:22:02 -0700 (PDT) Date: Wed, 17 Apr 2019 12:22:02 -0700 From: hiren panchasara To: Matt Olson , draft-cheng-tcpm-rack@ietf.org Cc: Yi Huang , "tcpm@ietf.org" Message-ID: <20190417192202.GN31257@strugglingcoder.info> References: <20190417181344.GM31257@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EkxpYdHiqGHPYbUt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 17 Apr 2019 19:22:05 -0000 --EkxpYdHiqGHPYbUt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/17/19 at 06:52P, Matt Olson wrote: > Previously, you'd start the RTO timer on the first packet, and the timer = would run until an ACK was received. Now, the timer is reset on each new pa= cket. So the concern is that there exist cases where previously TCP would r= educe the CWnd and retransmit, but not anymore. I see your point. I guess in this particular case, RACK (which is the smallest/first timer to fire) is also not useful as there are no acks coming back. >=20 > If all such cases are app-limited cases, then I like Hiren's point about = this being a "keep CWnd in check while app-limited" problem.=20 iirc, there was some guidance around this in previous version(s) of the draft. I don't find that in -04. May be authors (CC'd) can chime in. Cheers, Hiren >=20 > -----Original Message----- > From: hiren panchasara =20 > Sent: Wednesday, April 17, 2019 11:14 AM > To: Yi Huang > Cc: tcpm@ietf.org; Matt Olson > Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft >=20 > On 04/17/19 at 01:48P, Yi Huang wrote: > > Hi, >=20 > Hi! > I don't see anything inherently wrong in how this works or I am missing s= omething. > >=20 > > I have a question about PTO/RTO rescheduling logic in RACK draft. The d= raft states, in Section 6.5.1, "If there was a previously scheduled PTO or = RTO pending, then that pending PTO or RTO should first be cancelled, and th= en the new PTO should be scheduled". So if an app keeps posting data in an = interval less than PTO and RTO (say one byte each time and Cwnd is large en= ough) and no acks are coming back due to network failures or a receiver tha= t just does not send anything back, the app will never fires RTO since the = timer is pushed out each time we send this one byte data. Is this a problem? > By growing CWND, TCP has decided that it is okay to send that much withou= t needing an ACK. > I think something along the lines of detecting that connection is app-lim= ited OR doing newcwv like validation may help to keep CWND in check? >=20 > > What is the intention of pushing out the timer for each send? > 6.5.1 (Step 1) indicated a few conditions for scheduling PTO (i.e. > pushing out the timer) so its not blindly doing for each send. But it wou= ld do that for the case you described as app *is* handing new data to be se= nt to TCP. >=20 > >I think in this case the sender should disconnect the connection because= , without TLP, the sender would have had several RTOs and closed the connec= tion. > I am probably not understanding something. I think you are saying TLP is = causing RTO to be pushed out unnecessarily. >=20 > One cannot schedule PTO when a TLP is out. So, on first timeout i.e. PTO = as we prefer that over RTO, you send a TLP out. And if you don't get an ACK= back for that, next timeout would be an RTO as 6.5.1. Phase 1 condition 1= suggests. >=20 > But if there is new data to be sent, RTO would also gets pushed out, no? > >=20 > > Also, RFC 6298 Section 5 (5.1) states "Every time a packet containing d= ata is sent (including a retransmission), if the timer is not running, star= t it running so that it will expire after RTO seconds (for the current valu= e of RTO).", which says TCP should schedule timer only when it is not sched= ule yet and this kind of conflicts with (or is overridden by) what is in RA= CK/TLP draft. >=20 > I am not sure I follow. For the connection, you need a timeout mechanism.= And RACK draft suggests keeping PTO aligned with RTO as the former is less= expensive. Try PTO and if it doesn't work, do RTO. >=20 > I believe the wordings around "first cancel the pending one and then only= schedule new one" are for clarity around implementation details. > Gist is to not keep 2 sets of timers running for the same timeout mechani= sm.=20 >=20 > Someone with more clue on the list would probably correct me. :-) Cheers,= Hiren --EkxpYdHiqGHPYbUt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJct3zXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l2wgIAICA/Vrl9l3Z5k1vooaejk/X EeYWqTBLqEhXM8SNYp0Ly/lODQzmd3YZsLq1nWbhHaX7reJxTcoTXcXlnTM7J2Q/ JPEqQyIwQ0OuJfuzybItf7eKr4Ux9BL3sK4Z6kO7os74dkLNYX4ybKB1KaHW9Vqh AIfLrWJSlPih+T43Nh4Xs+gI/CsDsGa6PA1h6pPuolxAxTmMKC/7LpAxwzEjCvQj X56OszkZ7yf6QdVV+Twa8VaS042Z/k/Nu7BKKto7bqVwvCNNrcnfIR8hpacdTOUs 9BwZrA3k/Fz2dSzHAcZOXooVBnIxg9GSwBs/29uhvUwwfvbYL545LBt4IEfSS10= =DfJN -----END PGP SIGNATURE----- --EkxpYdHiqGHPYbUt-- From nobody Wed Apr 17 13:30:03 2019 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 EF13612016C for ; Wed, 17 Apr 2019 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, HTML_MESSAGE=0.001, 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 6APFIFKzcrxm for ; Wed, 17 Apr 2019 13:29:59 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 98B86120163 for ; Wed, 17 Apr 2019 13:29:57 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id f10so21903329otb.6 for ; Wed, 17 Apr 2019 13:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vv9W7//mBzaykFZEaBdtO97v6kb7WizCHVP4WXMFbnY=; b=SCzP56IfibUTpQkoOYZLcdynQARJhNPKSX9reioXVAhgyBKmq4PNURuEQFqofG6FhD uD7JaWS7+ybNZ2KpibxC3mXqJw4G27acSOiMdFjF7IfocEbgjEFY7/pvJ4crss6na1z/ 2jDEH0w3dK0zPocw+sCYbIuVYAo4kMoye9j4HiozEJgjUfXNLkoDKFAZhDJBNBeeLxg7 FXx09AeIu8HfN/E0wngIuAYEr+DCJseV3N+M+cSOTy6KoIO53xxHWv14Mjm7+zgMlgaN 1NOoTNrVvovGDGtHmoNv+ktcr1iSlELavYuK0A9VrC28QJukYL5A/r1OKdOCD0XkFH/j EVpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vv9W7//mBzaykFZEaBdtO97v6kb7WizCHVP4WXMFbnY=; b=UfXteAVTksn1aNmoa5bzyfE7V27dTS6lEeUwB9hS1XMnvy3iQ56XYJkb8XMYjLt84W ocFzQzMmgNaFSDhFMNGFsb0zUk5E4CtfSSIaaopoJPxmQiDUZUlhjvju5A1cbOLwrEFg S4wO+zDhO0NATxJyEGli24ySOD9h8UezQoAy7SV3yDztHSgdJ7KAtZU/g+r724eSffUt vCTDvMJhOLVRvJ9ZCkW3l1xARJaAzJBGr59re7+8Y+pI2T+j0y3fltNaoL6y4Ix0igCh BvuM++ekJuqP0oWAQtOB3qZZdLdRrazCg/yVNp4gh6jwXgQI3Z8dqmQ/+x8n4/liYPaJ DXTA== X-Gm-Message-State: APjAAAVZWjBNxCsgJDefFGdrgR1wltXIOBYA4P9FHBOzWRa9cVNc7N/X q1MVTdyASCoAjxC0fqiJiSK3MzjbeC15dAfPZ7m4PA== X-Google-Smtp-Source: APXvYqxhPUiT77l/FT8tCAZNGF3ido1HsN5zR6OZrQ4ojLXIxdi1aflEmYdrN10GBz702Pf/0Fc+Cgfmtb1UcMq2N1c= X-Received: by 2002:a05:6830:1398:: with SMTP id d24mr57683373otq.104.1555532996457; Wed, 17 Apr 2019 13:29:56 -0700 (PDT) MIME-Version: 1.0 References: <20190417181344.GM31257@strugglingcoder.info> <20190417192202.GN31257@strugglingcoder.info> In-Reply-To: <20190417192202.GN31257@strugglingcoder.info> From: Neal Cardwell Date: Wed, 17 Apr 2019 16:29:40 -0400 Message-ID: To: hiren panchasara Cc: Matt Olson , draft-cheng-tcpm-rack@ietf.org, "tcpm@ietf.org" , Yi Huang , Yuchung Cheng , Nandita Dukkipati , Priyaranjan Jha Content-Type: multipart/alternative; boundary="000000000000b13b1c0586bfbfca" Archived-At: Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 17 Apr 2019 20:30:01 -0000 --000000000000b13b1c0586bfbfca Content-Type: text/plain; charset="UTF-8" Hi Yi and Hiren, Thank you for raising this question and the continued discussion. I think there are a few concrete mechanisms that kick into play in the kind of scenario Yi lays out. (1) The TLP is scheduled at the min of the "native" TLP time and the "native" RTO time, as laid out in section 6.5.1 .: TLP_timeout(): ... If Now() + PTO > TCP_RTO_expire(): PTO = TCP_RTO_expire() - Now() This keeps the TLP (PTO) from being pushed past the time at which an RTO previously would have fired. (2) After the TLP probe is sent, an RTO timer is scheduled and fires. The intent is to not get stuck in cycles of repeated TLPs. To illustrate more concretely, below is a (passing) packetdrill script illustrating/documenting the Linux TCP behavior in this kind of scenario, showing the points at which a loss probe and timeout happen. We will need to update the draft to make these aspects more clear. Thank you for raising this! neal ------------------ // Test for TLP with an app that makes periodic small writes. `nstat > /dev/null` // Establish a connection. 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 < S 0:0(0) win 32792 +0 > S. 0:0(0) ack 1 +.1 < . 1:1(0) ack 1 win 257 +0 accept(3, ..., ...) = 4 // Small write of 2*MSS. +0 write(4, ..., 2000) = 2000 +0 > P. 1:2001(2000) ack 1 +0 %{ assert tcpi_ca_state == TCP_CA_Open }% // TLP is scheduled 200ms later, but app writes again before that. // Small write of 2*MSS, which pushes back TLP timer. +.150 write(4, ..., 2000) = 2000 +0 > P. 2001:4001(2000) ack 1 +0 %{ assert tcpi_ca_state == TCP_CA_Open }% // Loss probe is a retransmission, scheduled at a time // calculated by the RTO formula, 300ms after the // first packet we sent. +.150 > P. 3001:4001(1000) ack 1 +0 %{ assert tcpi_ca_state == TCP_CA_Open }% +0 `nstat -a -z | grep LossProbes` // Small write of 2*MSS. +.150 write(4, ..., 2000) = 2000 +0 > P. 4001:6001(2000) ack 1 +0 %{ assert tcpi_ca_state == TCP_CA_Open }% // RTO timer fires. +.210 > . 1:1001(1000) ack 1 +0 %{ assert tcpi_ca_state == TCP_CA_Loss }% +0 `nstat -a -z | grep TCPTimeouts` --000000000000b13b1c0586bfbfca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yi and Hiren,

Thank you for raising this question and the continued discussion.

I think there are a few concrete mechanisms that kick= into play in the kind of scenario Yi lays out.

(1= ) The TLP is scheduled at the min of the "native" TLP time and th= e "native" RTO time, as laid out in section=C2=A06.5.1.:
= 
   TLP_timeout():
  ...
       If No=
w() + PTO > TCP_RTO_expire():
           PTO =3D TCP_RTO_expire() - Now()

= =C2=A0 =C2=A0This keeps the TLP (PTO) from being pushed past the time at wh= ich an RTO previously would have fired.

(2) After = the TLP probe is sent, an RTO timer is scheduled and fires. The intent is t= o not get stuck in cycles of repeated TLPs.

To ill= ustrate more concretely, below is a (passing) packetdrill script illustrati= ng/documenting the Linux TCP behavior in this kind of scenario, showing the= points at which a loss probe and timeout happen.

=
We will need to update the draft to make these aspects more clear. Tha= nk you for raising this!

neal

------------------
// Test for TLP with an app that makes periodic small writes.
`n= stat > /dev/null`

// Establish a connection= .
=C2=A0 =C2=A0 0 socket(..., SOCK_STREAM, IPPROTO_TCP) =3D 3
=C2=A0 =C2=A0+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) =3D = 0
=C2=A0 =C2=A0+0 bind(3, ..., ...) =3D 0
=C2=A0 =C2=A0= +0 listen(3, 1) =3D 0

=C2=A0 =C2=A0+0 < S 0:0(0= ) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
=C2=A0 = =C2=A0+0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8><= /div>
=C2=A0 +.1 < . 1:1(0) ack 1 win 257
=C2=A0 =C2=A0+0 = accept(3, ..., ...) =3D 4

// Small write of 2*MSS.=
=C2=A0 =C2=A0+0 write(4, ..., 2000) =3D 2000
=C2=A0 = =C2=A0+0 > P. 1:2001(2000) ack 1
=C2=A0 =C2=A0+0 %{ assert tcp= i_ca_state =3D=3D TCP_CA_Open }%
// TLP is scheduled 200ms later,= but app writes again before that.

// Small write = of 2*MSS, which pushes back TLP timer.
+.150 write(4, ..., 2000) = =3D 2000
=C2=A0 =C2=A0+0 > P. 2001:4001(2000) ack 1
= =C2=A0 =C2=A0+0 %{ assert tcpi_ca_state =3D=3D TCP_CA_Open }%
// Loss probe is a retransmission, scheduled at a time
// calculated by the RTO formula, 300ms after the
// first pack= et we sent.
+.150 > P. 3001:4001(1000) ack 1
=C2=A0 = =C2=A0+0 %{ assert tcpi_ca_state =3D=3D TCP_CA_Open }%
=C2=A0 =C2= =A0+0 `nstat -a -z | grep LossProbes`

// Small wri= te of 2*MSS.
+.150 write(4, ..., 2000) =3D 2000
=C2=A0 = =C2=A0+0 > P. 4001:6001(2000) ack 1
=C2=A0 =C2=A0+0 %{ assert = tcpi_ca_state =3D=3D TCP_CA_Open }%

// RTO timer f= ires.
+.210 > . 1:1001(1000) ack 1
=C2=A0 =C2=A0+0 %= { assert tcpi_ca_state =3D=3D TCP_CA_Loss }%
=C2=A0 =C2=A0+0 `nst= at -a -z | grep TCPTimeouts`

--000000000000b13b1c0586bfbfca-- From nobody Wed Apr 17 14:15:25 2019 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 382951200D8 for ; Wed, 17 Apr 2019 14:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzco9sGr5T6e for ; Wed, 17 Apr 2019 14:15:22 -0700 (PDT) Received: from mail.strugglingcoder.info (unknown [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id EA2B8120075 for ; Wed, 17 Apr 2019 14:15:21 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 5EF301715B; Wed, 17 Apr 2019 14:15:21 -0700 (PDT) Date: Wed, 17 Apr 2019 14:15:21 -0700 From: hiren panchasara To: Neal Cardwell Cc: Matt Olson , draft-cheng-tcpm-rack@ietf.org, "tcpm@ietf.org" , Yi Huang , Yuchung Cheng , Nandita Dukkipati , Priyaranjan Jha Message-ID: <20190417211521.GA45038@strugglingcoder.info> References: <20190417181344.GM31257@strugglingcoder.info> <20190417192202.GN31257@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 17 Apr 2019 21:15:23 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/17/19 at 04:29P, Neal Cardwell wrote: > Hi Yi and Hiren, >=20 > Thank you for raising this question and the continued discussion. Thanks for a quick response as always. :) [skip] > We will need to update the draft to make these aspects more clear. Thank > you for raising this! I'll keep this to the point I thought got missed. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-04.txt Is where we can see `Scheduling a loss probe` getting changed. Specifically, following condition has been removed from -04: 3. The connection is either limited by congestion window (the data in flight matches or exceeds the cwnd) or application-limited (there is no unsent data that the receiver window allows to be sent). And afaict, Linux code still has this condition in. If you can provide some rationale behind this change, it'd be great. Thanks a ton, Hiren --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJct5dmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lR5oH/0K/04Ms8esPo+Q/WWKzJFu9 RnVvy68+1JNE6X6yH+nc5adgHDSt9rF0BMlgzCImxWcym390CSqNDu/QiyF3Xmv7 qkcrqSC8I0IbKsKK3M5+SzFPA0hXz9o33dyqd+qhZx1HUy1ykOAw11UZeuaec8EV aGMPJd8MaX2TKtQXUQZijbPx57o1kUKFELW7J+QNZaPkmAPH/hWafI03vj+TdKNR FKSeTql5ObAj67Pl0lNoUwS+Y/HqOcYodAAfcHdcbxTKEMW1iFUzXY3B2OYL0G3p jZEg+1wANbwE7NKP5C9FK+D19TbZG2C4yxglFGcmHQLGR+vnSRtR7enNwG86pxI= =pUW3 -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From nobody Wed Apr 17 15:09:15 2019 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 B1D331201B1 for ; Wed, 17 Apr 2019 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 S3kMU1pouBBV for ; Wed, 17 Apr 2019 15:09:09 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740125.outbound.protection.outlook.com [40.107.74.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C2B120112 for ; Wed, 17 Apr 2019 15:09:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=Avl5HE1XsM7E8Q4dsd2bwuAXucqwOL63tOU/Tw1SieOehYcVdTn0qYhbESchz7S3uXSS7xhSjtuye3cwhXywy4j86KrwS71fJYSEPHuyGjCYAgJlmcScZI+aHr9LsdlQ3sqCOZT8R+QStVnPspEuEzDxQZ5v+ie+s7wp0QjAYwf++8lN728zdkKt3qDfa9QYIU0d4JpIAW8YtBTxaaLyUfWbIXF18+HZ7peVGB3c9Un9ThBMxo+5zaXYXyoYLvNhHkOgjbheGdY2yn3c6vkZHnlzTHKiQAn76iH3TfICbPufczp+zpfJFwmi010q507P6oFu4qzhPcy44AxuFWRGOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tYoFJCY5h3kvQGS8tjl+bCI3lIOJrkTHzUE8RMp9Uh8=; b=YFhiEqkAKpENxVGNxT9izD8LTpn3Gj/1GwX3JUS7NKhmgTpvVooP6mA6zSI+fUYJHDUO6zxfdR8PLlfEczez8a2lEC4e5TF+RueBt1nNPHegUamv2J7dA1fXnJqhkrJ50OGBHIkKT4EX7FwLM0xdjBWCAEEsCed66SOPlOBsakL27lQFVSe3yb1haZIhRf25KPmtMhTix6Zp7onQgan0OCs/cqVmxe5UgP0lQFgz1+CeAHXpMACHZr4yyQVVIqTknyCeE4dB2vMhpHx4kUjqUtx7Q4/J5juorItjETK7UfCEhgeVj4wSks0fG87/wSqhIzdDzDEMftwoyw5dKZc5Uw== ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none 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=tYoFJCY5h3kvQGS8tjl+bCI3lIOJrkTHzUE8RMp9Uh8=; b=Wj2UjaX3Wd7/iC82bHFZdGtiulJR14kelYuaHYQKHWDz84Zq0KZwFqNAbQzSRrVgqKWGj8tJfnPg7JlP0f3ygubRiUi0/VQbNIVCBaaEvpyrk9L2t3p28cf6Mk0n5T9BJa2H8IksLnkInJYffanhSVGbTi/lVNwBzDUVXs0G7K4= Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (52.132.24.13) by BL0PR2101MB1012.namprd21.prod.outlook.com (52.132.24.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.6; Wed, 17 Apr 2019 22:09:03 +0000 Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9%8]) with mapi id 15.20.1835.000; Wed, 17 Apr 2019 22:09:03 +0000 From: Yi Huang To: Neal Cardwell , hiren panchasara CC: "tcpm@ietf.org" , Matt Olson , "draft-cheng-tcpm-rack@ietf.org" , Priyaranjan Jha , Yi Huang Thread-Topic: [tcpm] A question about PTO/RTO rescheduling in RACK draft Thread-Index: AdT0v450DAV7LlJPShaJ9NxD6aYmRAAibyEAAADFGxAAAZ2MAAACXLAAAAMODIA= Date: Wed, 17 Apr 2019 22:09:03 +0000 Message-ID: References: <20190417181344.GM31257@strugglingcoder.info> <20190417192202.GN31257@strugglingcoder.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-04-17T22:09:02.2131489Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=339615d5-ed45-455b-ad6f-e9230ed65cec; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2001:4898:80e8:a:90dd:d90c:8727:9001] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 73a0d452-f96d-4e41-8bcd-08d6c3814d87 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR2101MB1012; x-ms-traffictypediagnostic: BL0PR2101MB1012: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(366004)(39860400002)(199004)(189003)(14444005)(25786009)(256004)(97736004)(55016002)(316002)(110136005)(22452003)(71200400001)(54906003)(8990500004)(6116002)(74316002)(790700001)(102836004)(186003)(10290500003)(71190400001)(7736002)(14454004)(2906002)(53546011)(6506007)(10090500001)(478600001)(33656002)(93886005)(9686003)(5660300002)(6246003)(4326008)(7696005)(11346002)(236005)(446003)(46003)(76176011)(81166006)(68736007)(86612001)(81156014)(6306002)(476003)(606006)(486006)(8676002)(54896002)(6436002)(99286004)(53936002)(9326002)(86362001)(229853002)(52536014)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1012; H:BL0PR2101MB1043.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DcifIVfihVcpu4L52ePgCl5panZyHj7EWf2U7JOFeZfPz6ddyB0ZhKNhrvI3200DWMOlxhf9EhaZO8ulnTPRQ0PJUtHYbUFRgGkG6qdNKG9lQnntSIsKo2hIr5ldKdAoySc7LLV3pysYWjbcX8LGo2adz3PYtGGYJbzmdw2BrRAar8belGtkaBA3Eq6Zp8ocy4Q3r2zpzHGsIO98ogv9sTB82NoIDGzxL3g/+Ax9g0KvHuZEIUZVwxjM1Havrb43k2/mld+c+1kedJLboKI3V9p0Nx/llozYchQgPKZM94MQBU4qSnQ0UnP3mBWoj4eysCtx58eZdEBGHuex+IrKCE1q/9lQpc5IoayTfqf9lMYHk1v18l2A+ou/7nmjgl9DM9nWTrwmuwx/2YXPaxHRYKXdHYcMsNPzPZZriF9WTJ0= Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1043291C3F10700EA22B778BC3250BL0PR2101MB1043_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73a0d452-f96d-4e41-8bcd-08d6c3814d87 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 22:09:03.6661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1012 Archived-At: Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 17 Apr 2019 22:09:13 -0000 --_000_BL0PR2101MB1043291C3F10700EA22B778BC3250BL0PR2101MB1043_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmVhbCwNCg0KVGhhbmtzIGZvciB5b3VyIHF1aWNrIHJlc3BvbnNlIGFuZCBhbHNvIHRoYW5r cyBIaXJlbiBmb3IgdGhlIGhlbHAuIEl04oCZcyB2ZXJ5IGNsZWFyIHRvIG1lIG5vdy4NCg0KWWkN Cg0KRnJvbTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTmVhbCBD YXJkd2VsbA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxNywgMjAxOSAxOjMwIFBNDQpUbzogaGly ZW4gcGFuY2hhc2FyYSA8aGlyZW5Ac3RydWdnbGluZ2NvZGVyLmluZm8+DQpDYzogdGNwbUBpZXRm Lm9yZzsgTWF0dCBPbHNvbiA8bWFvbHNvbkBtaWNyb3NvZnQuY29tPjsgZHJhZnQtY2hlbmctdGNw bS1yYWNrQGlldGYub3JnOyBQcml5YXJhbmphbiBKaGEgPHByaXlhcmpoYUBnb29nbGUuY29tPjsg WWkgSHVhbmcgPGh1YW55aT00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3RjcG1dIEEgcXVlc3Rpb24gYWJvdXQgUFRPL1JUTyByZXNjaGVkdWxpbmcgaW4gUkFD SyBkcmFmdA0KDQpIaSBZaSBhbmQgSGlyZW4sDQoNClRoYW5rIHlvdSBmb3IgcmFpc2luZyB0aGlz IHF1ZXN0aW9uIGFuZCB0aGUgY29udGludWVkIGRpc2N1c3Npb24uDQoNCkkgdGhpbmsgdGhlcmUg YXJlIGEgZmV3IGNvbmNyZXRlIG1lY2hhbmlzbXMgdGhhdCBraWNrIGludG8gcGxheSBpbiB0aGUg a2luZCBvZiBzY2VuYXJpbyBZaSBsYXlzIG91dC4NCg0KKDEpIFRoZSBUTFAgaXMgc2NoZWR1bGVk IGF0IHRoZSBtaW4gb2YgdGhlICJuYXRpdmUiIFRMUCB0aW1lIGFuZCB0aGUgIm5hdGl2ZSIgUlRP IHRpbWUsIGFzIGxhaWQgb3V0IGluIHNlY3Rpb24gNi41LjE8aHR0cHM6Ly9uYW0wNi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5v cmclMkZodG1sJTJGZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDQlMjNzZWN0aW9uLTYuNS4xJmRhdGE9 MDIlN0MwMSU3Q2h1YW55aSU0MG1pY3Jvc29mdC5jb20lN0NkMzZhMjM5NTY4Nzg0ZDUyMzNkOTA4 ZDZjMzczN2NiMiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzY5MTEyOTgxMTc3NTI5ODcmc2RhdGE9cWxQcSUyRkR0bVpZcDR6dW1CSlpQRHElMkZOWDN2RnVt SkIzcXpUNFp6SFltaU0lM0QmcmVzZXJ2ZWQ9MD4uOg0KDQoNCiAgIFRMUF90aW1lb3V0KCk6DQoN CiAgLi4uDQoNCiAgICAgICBJZiBOb3coKSArIFBUTyA+IFRDUF9SVE9fZXhwaXJlKCk6DQoNCiAg ICAgICAgICAgUFRPID0gVENQX1JUT19leHBpcmUoKSAtIE5vdygpDQoNCiAgIFRoaXMga2VlcHMg dGhlIFRMUCAoUFRPKSBmcm9tIGJlaW5nIHB1c2hlZCBwYXN0IHRoZSB0aW1lIGF0IHdoaWNoIGFu IFJUTyBwcmV2aW91c2x5IHdvdWxkIGhhdmUgZmlyZWQuDQoNCigyKSBBZnRlciB0aGUgVExQIHBy b2JlIGlzIHNlbnQsIGFuIFJUTyB0aW1lciBpcyBzY2hlZHVsZWQgYW5kIGZpcmVzLiBUaGUgaW50 ZW50IGlzIHRvIG5vdCBnZXQgc3R1Y2sgaW4gY3ljbGVzIG9mIHJlcGVhdGVkIFRMUHMuDQoNClRv IGlsbHVzdHJhdGUgbW9yZSBjb25jcmV0ZWx5LCBiZWxvdyBpcyBhIChwYXNzaW5nKSBwYWNrZXRk cmlsbCBzY3JpcHQgaWxsdXN0cmF0aW5nL2RvY3VtZW50aW5nIHRoZSBMaW51eCBUQ1AgYmVoYXZp b3IgaW4gdGhpcyBraW5kIG9mIHNjZW5hcmlvLCBzaG93aW5nIHRoZSBwb2ludHMgYXQgd2hpY2gg YSBsb3NzIHByb2JlIGFuZCB0aW1lb3V0IGhhcHBlbi4NCg0KV2Ugd2lsbCBuZWVkIHRvIHVwZGF0 ZSB0aGUgZHJhZnQgdG8gbWFrZSB0aGVzZSBhc3BlY3RzIG1vcmUgY2xlYXIuIFRoYW5rIHlvdSBm b3IgcmFpc2luZyB0aGlzIQ0KDQpuZWFsDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KLy8gVGVzdCBm b3IgVExQIHdpdGggYW4gYXBwIHRoYXQgbWFrZXMgcGVyaW9kaWMgc21hbGwgd3JpdGVzLg0KYG5z dGF0ID4gL2Rldi9udWxsYA0KDQovLyBFc3RhYmxpc2ggYSBjb25uZWN0aW9uLi4NCiAgICAwIHNv Y2tldCguLi4sIFNPQ0tfU1RSRUFNLCBJUFBST1RPX1RDUCkgPSAzDQogICArMCBzZXRzb2Nrb3B0 KDMsIFNPTF9TT0NLRVQsIFNPX1JFVVNFQUREUiwgWzFdLCA0KSA9IDANCiAgICswIGJpbmQoMywg Li4uLCAuLi4pID0gMA0KICAgKzAgbGlzdGVuKDMsIDEpID0gMA0KDQogICArMCA8IFMgMDowKDAp IHdpbiAzMjc5MiA8bXNzIDEwMDAsc2Fja09LLG5vcCxub3Asbm9wLHdzY2FsZSA3Pg0KICAgKzAg PiBTLiAwOjAoMCkgYWNrIDEgPG1zcyAxNDYwLG5vcCxub3Asc2Fja09LLG5vcCx3c2NhbGUgOD4N CiAgKy4xIDwgLiAxOjEoMCkgYWNrIDEgd2luIDI1Nw0KICAgKzAgYWNjZXB0KDMsIC4uLiwgLi4u KSA9IDQNCg0KLy8gU21hbGwgd3JpdGUgb2YgMipNU1MuDQogICArMCB3cml0ZSg0LCAuLi4sIDIw MDApID0gMjAwMA0KICAgKzAgPiBQLiAxOjIwMDEoMjAwMCkgYWNrIDENCiAgICswICV7IGFzc2Vy dCB0Y3BpX2NhX3N0YXRlID09IFRDUF9DQV9PcGVuIH0lDQovLyBUTFAgaXMgc2NoZWR1bGVkIDIw MG1zIGxhdGVyLCBidXQgYXBwIHdyaXRlcyBhZ2FpbiBiZWZvcmUgdGhhdC4NCg0KLy8gU21hbGwg d3JpdGUgb2YgMipNU1MsIHdoaWNoIHB1c2hlcyBiYWNrIFRMUCB0aW1lci4NCisuMTUwIHdyaXRl KDQsIC4uLiwgMjAwMCkgPSAyMDAwDQogICArMCA+IFAuIDIwMDE6NDAwMSgyMDAwKSBhY2sgMQ0K ICAgKzAgJXsgYXNzZXJ0IHRjcGlfY2Ffc3RhdGUgPT0gVENQX0NBX09wZW4gfSUNCg0KLy8gTG9z cyBwcm9iZSBpcyBhIHJldHJhbnNtaXNzaW9uLCBzY2hlZHVsZWQgYXQgYSB0aW1lDQovLyBjYWxj dWxhdGVkIGJ5IHRoZSBSVE8gZm9ybXVsYSwgMzAwbXMgYWZ0ZXIgdGhlDQovLyBmaXJzdCBwYWNr ZXQgd2Ugc2VudC4NCisuMTUwID4gUC4gMzAwMTo0MDAxKDEwMDApIGFjayAxDQogICArMCAleyBh c3NlcnQgdGNwaV9jYV9zdGF0ZSA9PSBUQ1BfQ0FfT3BlbiB9JQ0KICAgKzAgYG5zdGF0IC1hIC16 IHwgZ3JlcCBMb3NzUHJvYmVzYA0KDQovLyBTbWFsbCB3cml0ZSBvZiAyKk1TUy4NCisuMTUwIHdy aXRlKDQsIC4uLiwgMjAwMCkgPSAyMDAwDQogICArMCA+IFAuIDQwMDE6NjAwMSgyMDAwKSBhY2sg MQ0KICAgKzAgJXsgYXNzZXJ0IHRjcGlfY2Ffc3RhdGUgPT0gVENQX0NBX09wZW4gfSUNCg0KLy8g UlRPIHRpbWVyIGZpcmVzLg0KKy4yMTAgPiAuIDE6MTAwMSgxMDAwKSBhY2sgMQ0KICAgKzAgJXsg YXNzZXJ0IHRjcGlfY2Ffc3RhdGUgPT0gVENQX0NBX0xvc3MgfSUNCiAgICswIGBuc3RhdCAtYSAt eiB8IGdyZXAgVENQVGltZW91dHNgDQoNCg== --_000_BL0PR2101MB1043291C3F10700EA22B778BC3250BL0PR2101MB1043_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6MTAyODcyNjExNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MTM4NjkxMjc1NCAxMTI2OTczMzcwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdY aWFuOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBOZWFsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2UgYW5kIGFsc28gdGhhbmtzIEhpcmVuIGZvciB0 aGUgaGVscC4gSXTigJlzIHZlcnkgY2xlYXIgdG8gbWUgbm93LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ZaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gdGNwbSAmbHQ7dGNw bS1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTmVhbCBDYXJkd2Vs bDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDE3LCAyMDE5IDE6MzAgUE08YnI+ DQo8Yj5Ubzo8L2I+IGhpcmVuIHBhbmNoYXNhcmEgJmx0O2hpcmVuQHN0cnVnZ2xpbmdjb2Rlci5p bmZvJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGNwbUBpZXRmLm9yZzsgTWF0dCBPbHNvbiAmbHQ7bWFv bHNvbkBtaWNyb3NvZnQuY29tJmd0OzsgZHJhZnQtY2hlbmctdGNwbS1yYWNrQGlldGYub3JnOyBQ cml5YXJhbmphbiBKaGEgJmx0O3ByaXlhcmpoYUBnb29nbGUuY29tJmd0OzsgWWkgSHVhbmcgJmx0 O2h1YW55aT00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdGNwbV0gQSBxdWVzdGlvbiBhYm91dCBQVE8vUlRPIHJlc2NoZWR1bGluZyBp biBSQUNLIGRyYWZ0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIFlpIGFuZCBIaXJlbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciByYWlzaW5nIHRoaXMgcXVlc3Rpb24gYW5kIHRo ZSBjb250aW51ZWQgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGVyZSBhcmUgYSBmZXcgY29uY3JldGUgbWVj aGFuaXNtcyB0aGF0IGtpY2sgaW50byBwbGF5IGluIHRoZSBraW5kIG9mIHNjZW5hcmlvIFlpIGxh eXMgb3V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4oMSkgVGhlIFRMUCBpcyBzY2hlZHVsZWQgYXQgdGhlIG1pbiBvZiB0aGUgJnF1b3Q7bmF0 aXZlJnF1b3Q7IFRMUCB0aW1lIGFuZCB0aGUgJnF1b3Q7bmF0aXZlJnF1b3Q7IFJUTyB0aW1lLCBh cyBsYWlkIG91dCBpbiBzZWN0aW9uJm5ic3A7PGEgbmFtZT0ic2VjdGlvbi02LjUuMSI+PC9hPjxh IGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtdGNwbS1y YWNrLTA0JTIzc2VjdGlvbi02LjUuMSZhbXA7ZGF0YT0wMiU3QzAxJTdDaHVhbnlpJTQwbWljcm9z b2Z0LmNvbSU3Q2QzNmEyMzk1Njg3ODRkNTIzM2Q5MDhkNmMzNzM3Y2IyJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjkxMTI5ODExNzc1Mjk4NyZhbXA7c2Rh dGE9cWxQcSUyRkR0bVpZcDR6dW1CSlpQRHElMkZOWDN2RnVtSkIzcXpUNFp6SFltaU0lM0QmYW1w O3Jlc2VydmVkPTAiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6JnF1b3Q7c2VjdGlvbi02XC41 XC4xJnF1b3Q7Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjYuNS4xPC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOiZxdW90O3NlY3Rpb24tNlwuNVwuMSZxdW90OyI+PC9z cGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOiZxdW90O3NlY3Rpb24tNlwuNVwuMSZx dW90OyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ljo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUTFBfdGltZW91dCgpOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpw YWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBJZiBOb3coKSAmIzQzOyBQVE8gJmd0OyBUQ1BfUlRPX2V4cGlyZSgpOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQ VE8gPSBUQ1BfUlRPX2V4cGlyZSgpIC0gTm93KCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1RoaXMga2Vl cHMgdGhlIFRMUCAoUFRPKSBmcm9tIGJlaW5nIHB1c2hlZCBwYXN0IHRoZSB0aW1lIGF0IHdoaWNo IGFuIFJUTyBwcmV2aW91c2x5IHdvdWxkIGhhdmUgZmlyZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigyKSBBZnRlciB0aGUgVExQIHByb2Jl IGlzIHNlbnQsIGFuIFJUTyB0aW1lciBpcyBzY2hlZHVsZWQgYW5kIGZpcmVzLiBUaGUgaW50ZW50 IGlzIHRvIG5vdCBnZXQgc3R1Y2sgaW4gY3ljbGVzIG9mIHJlcGVhdGVkIFRMUHMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGlsbHVzdHJh dGUgbW9yZSBjb25jcmV0ZWx5LCBiZWxvdyBpcyBhIChwYXNzaW5nKSBwYWNrZXRkcmlsbCBzY3Jp cHQgaWxsdXN0cmF0aW5nL2RvY3VtZW50aW5nIHRoZSBMaW51eCBUQ1AgYmVoYXZpb3IgaW4gdGhp cyBraW5kIG9mIHNjZW5hcmlvLCBzaG93aW5nIHRoZSBwb2ludHMgYXQgd2hpY2ggYSBsb3NzIHBy b2JlIGFuZCB0aW1lb3V0IGhhcHBlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdpbGwgbmVlZCB0byB1cGRhdGUgdGhlIGRy YWZ0IHRvIG1ha2UgdGhlc2UgYXNwZWN0cyBtb3JlIGNsZWFyLiBUaGFuayB5b3UgZm9yIHJhaXNp bmcgdGhpcyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5u ZWFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi8vIFRlc3QgZm9yIFRMUCB3aXRoIGFuIGFwcCB0aGF0IG1h a2VzIHBlcmlvZGljIHNtYWxsIHdyaXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmBuc3RhdCAmZ3Q7IC9kZXYvbnVsbGA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ly8gRXN0YWJsaXNoIGEg Y29ubmVjdGlvbi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7IDAgc29ja2V0KC4uLiwgU09DS19TVFJFQU0sIElQUFJPVE9f VENQKSA9IDM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsmIzQzOzAgc2V0c29ja29wdCgzLCBTT0xfU09DS0VULCBTT19SRVVT RUFERFIsIFsxXSwgNCkgPSAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzswIGJpbmQoMywgLi4uLCAuLi4pID0gMDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyYjNDM7MCBsaXN0ZW4oMywgMSkgPSAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOzAgJmx0OyBTIDA6 MCgwKSB3aW4gMzI3OTIgJmx0O21zcyAxMDAwLHNhY2tPSyxub3Asbm9wLG5vcCx3c2NhbGUgNyZn dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDsmIzQzOzAgJmd0OyBTLiAwOjAoMCkgYWNrIDEgJmx0O21zcyAxNDYwLG5vcCxu b3Asc2Fja09LLG5vcCx3c2NhbGUgOCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmIzQzOy4xICZsdDsgLiAxOjEoMCkgYWNrIDEg d2luIDI1NzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyYjNDM7MCBhY2NlcHQoMywgLi4uLCAuLi4pID0gNDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vLyBTbWFsbCB3cml0 ZSBvZiAyKk1TUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOzAgd3JpdGUoNCwgLi4uLCAyMDAwKSA9IDIwMDA8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsmIzQzOzAgJmd0OyBQLiAxOjIwMDEoMjAwMCkgYWNrIDE8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOzAgJXsg YXNzZXJ0IHRjcGlfY2Ffc3RhdGUgPT0gVENQX0NBX09wZW4gfSU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi8vIFRMUCBpcyBzY2hlZHVsZWQgMjAw bXMgbGF0ZXIsIGJ1dCBhcHAgd3JpdGVzIGFnYWluIGJlZm9yZSB0aGF0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vLyBTbWFsbCB3cml0ZSBv ZiAyKk1TUywgd2hpY2ggcHVzaGVzIGJhY2sgVExQIHRpbWVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsuMTUwIHdyaXRlKDQsIC4uLiwg MjAwMCkgPSAyMDAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzswICZndDsgUC4gMjAwMTo0MDAxKDIwMDApIGFjayAx PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7JiM0MzswICV7IGFzc2VydCB0Y3BpX2NhX3N0YXRlID09IFRDUF9DQV9PcGVuIH0l PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi8v IExvc3MgcHJvYmUgaXMgYSByZXRyYW5zbWlzc2lvbiwgc2NoZWR1bGVkIGF0IGEgdGltZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ly8gY2FsY3Vs YXRlZCBieSB0aGUgUlRPIGZvcm11bGEsIDMwMG1zIGFmdGVyIHRoZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ly8gZmlyc3QgcGFja2V0IHdlIHNl bnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m IzQzOy4xNTAgJmd0OyBQLiAzMDAxOjQwMDEoMTAwMCkgYWNrIDE8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOzAgJXsg YXNzZXJ0IHRjcGlfY2Ffc3RhdGUgPT0gVENQX0NBX09wZW4gfSU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOzAgYG5z dGF0IC1hIC16IHwgZ3JlcCBMb3NzUHJvYmVzYDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vLyBTbWFsbCB3cml0ZSBvZiAyKk1TUy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7LjE1MCB3 cml0ZSg0LCAuLi4sIDIwMDApID0gMjAwMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7MCAmZ3Q7IFAuIDQwMDE6NjAw MSgyMDAwKSBhY2sgMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7MCAleyBhc3NlcnQgdGNwaV9jYV9zdGF0ZSA9PSBU Q1BfQ0FfT3BlbiB9JTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4vLyBSVE8gdGltZXIgZmlyZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOy4yMTAgJmd0OyAuIDE6MTAwMSgxMDAwKSBh Y2sgMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyYjNDM7MCAleyBhc3NlcnQgdGNwaV9jYV9zdGF0ZSA9PSBUQ1BfQ0FfTG9z cyB9JTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyYjNDM7MCBgbnN0YXQgLWEgLXogfCBncmVwIFRDUFRpbWVvdXRzYDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BL0PR2101MB1043291C3F10700EA22B778BC3250BL0PR2101MB1043_-- From nobody Thu Apr 18 06:19:20 2019 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 54BC512008A for ; Thu, 18 Apr 2019 06:19:19 -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=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 MnMPjgOq8uBn for ; Thu, 18 Apr 2019 06:19:17 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A26120077 for ; Thu, 18 Apr 2019 06:19:16 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id n187so1565390oih.6 for ; Thu, 18 Apr 2019 06:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=svEd+0FS7yObtCUV9MmbG8YjqkNbbdiezBSi2uRj6RM=; b=IBM/CL9nA4vnBtPSKOUPabD549nmfxUz3ekHNQgcdXIcgL1ayyNCfeuBs+jFt5mlAV BUjlKGniuBc0ll7Z2iSVNozIacjRVKnxtxzEcgmg6xzhtQhJ70RWXlW3N0wer+BNXTkY mSNLVbX+ASB7s+qb2DXwaNZ0LO8DpoyeW4zBO8Lqieuhm3NtkStZT0fK2uVBv38Py5Zq XAppRiXJ4JUoBdVXWIpBiKWGl5obUmkajzCnqR54wNAP1UjxPutO+fPO08udWKi81UzG vRpuZps6Nfl9dcML0d1zG4r7myJeZ7ULY8JSZxluCYDnaiNso8FZgfN/Z2hoBwEknbSo iVqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=svEd+0FS7yObtCUV9MmbG8YjqkNbbdiezBSi2uRj6RM=; b=M9ma82i0/msS+YdEf3355ZVrgwVN5QEBVtLK5qqkH1QupCrvDaTsl/rRCrq/RiYa4i g6qy0zOFX0OOgjvk2YJQPmJDQOKDNBAbIfjqV6cgVQbb2otZ9qWY71HeO5KNaqf9J2lg P8GEac+AVVnbtovIBT099fsDptaXxlwGV/3dxAYqoWjsEwOFmOmUoheLzjEBWk2OyyP0 b3ATgoa5XhTdePxrQxu7vFeVkTmjxZI+M3hqMsMum5Vfqgx8OMXs0ts6tOh4FjbDRamD 9eoHUiR1MTIneu1FDgpfwBHXbw91hnodpyBzspVTY2RtKTHnndB6vCGUa9qRbYnOnmDb MeMQ== X-Gm-Message-State: APjAAAUgaUXHVf/jkdomrPUvq4xLnPlpTnZNDcA/Ia4hGPdwdbgUFXWW 9gEcGVfEjyRWWLnAKoxlhRHowSaaVUIXW48Pm8FTGA== X-Google-Smtp-Source: APXvYqxULIYdpBZ9JiIJF9WXEg5Hb+UnypNcMRwnjkBg7EzeFu0tcZY1Y4hik4cp0UlzixIAbgToxZLNN6I//avYAIs= X-Received: by 2002:aca:6086:: with SMTP id u128mr1781014oib.79.1555593554992; Thu, 18 Apr 2019 06:19:14 -0700 (PDT) MIME-Version: 1.0 References: <20190417181344.GM31257@strugglingcoder.info> <20190417192202.GN31257@strugglingcoder.info> <20190417211521.GA45038@strugglingcoder.info> In-Reply-To: <20190417211521.GA45038@strugglingcoder.info> From: Neal Cardwell Date: Thu, 18 Apr 2019 09:18:57 -0400 Message-ID: To: hiren panchasara , draft-ietf-tcpm-rack@ietf.org Cc: Matt Olson , "tcpm@ietf.org" , Yi Huang , Yuchung Cheng , Nandita Dukkipati , Priyaranjan Jha Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 18 Apr 2019 13:19:19 -0000 On Wed, Apr 17, 2019 at 5:15 PM hiren panchasara wrote: > I'll keep this to the point I thought got missed. > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-04.txt > > Is where we can see `Scheduling a loss probe` getting changed. > Specifically, following condition has been removed from -04: > > 3. The connection is either limited by congestion window (the data > in flight matches or exceeds the cwnd) or application-limited > (there is no unsent data that the receiver window allows to be > sent). > > And afaict, Linux code still has this condition in. If you can provide > some rationale behind this change, it'd be great. We removed the code for that condition from Linux around 2017-12-13, in this commit (GPLv2 patch in this link): https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/net/ipv4/tcp_output.c?id=b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd The commit description explains the rationale for removing that condition, but here is a paraphrased description of the rationale for removing that code and that condition in the draft: --- Disallowing TLP when there is unused cwnd had the primary effect of disallowing TLP when there is TSO deferral, Nagle deferral, or we hit the receiver window limit. Why? Because basically every application write() or incoming ACK will cause us to run the TCP transmit loop to see if we can send more. And then if we sent something we then see if we should schedule a TLP. At that point, there are a few common reasons why some cwnd budget could still be unused: (a) receiver window limits (b) Nagle deferral (c) TSO deferral (deferring with the hope of sending a bigger TSO offload burst later) (d) intra-send-host flow control (in Linux, TCP small queues, aka TSQ) For (d), after the next packet tx completion the TSQ mechanism will allow us to send more packets, so we don't really need a TLP (in practice it shouldn't matter whether we schedule one or not). But for (a), (b), or (c) the sender won't send any more packets until it receives another ACK. But if the whole flight of data was lost, or all the ACKs for the flight were lost, then the sender won't get any more ACKs, and so in this case ideally we should schedule and send a TLP to get more feedback. --- best, neal From nobody Thu Apr 18 09:46:13 2019 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 D861412037D for ; Wed, 17 Apr 2019 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 QvCOEpY9IzoW for ; Wed, 17 Apr 2019 11:52:16 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690116.outbound.protection.outlook.com [40.107.69.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6AB1200A3 for ; Wed, 17 Apr 2019 11:52:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=mMuCgXVbqzFQg15MZcBEkyhDDKXQlV/2vKF1sa/4zsA6BZ5Tbhc932T4VKNN7pJdBYRnQ0G9Q9uTRS+ZwmOIJ1ieztrcbSM+YE2ksM0J2z2l8GI5tLlcLvDzmLoz9hJV30kcWFC+akSXisndyd6TipT5Yfn0u4tJzotDk590V9yN9r7azLJYzRaIinB8MCtHVa++IKC5DuHqfI3upAd4L7a3mhsYDr+u0rdiNzuYZgUlcXphgDvEIXwmrASsaIJqxOlXz9OF4V9PUtKTrGiIKLl+N3RLRSZj1mWEzWE8KvYP/Mqodf5xaohFhJ0X2QccoY5IRATh93a9EQivSeWBzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l1FIqbahlHvjT8uvIlKO1cyeVeYVy6QDZ33GC56C8ww=; b=nduv4ERVCFyqBAK+6bbhfztsg7czCEvblbeCTcAKDY2/WCyZD0+TcRWNDUtws5NWWTY6+UcE0cAOoEv3Hp0Dvw0oiARiPf4VtI3WS5w0IK+eKUExOA70jR6ReCA8EwZNds65SkTBP24ZEr5OfI9od8CosCpgeejs5i21x5YntGmrRZaoP5K7IgWNSKn5/XAgjVMnq4VvK2MPsE/2EFzlvjOemNGILwJGdZyi+lJWnlrxWQ+Gl11kT0WjUX7CrO4PGVuUfIZeLBP69nOcqqzHYE/XH8bT6jZYDgGbC9n/v7LmjZK7o5JHtzR+8JyCohX1otIVu9xv5ipXktwYra1iCA== ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none 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=l1FIqbahlHvjT8uvIlKO1cyeVeYVy6QDZ33GC56C8ww=; b=ZixImEyYTTC82hcaS1BtPhug2MoE/gEkjPRzUrjXUadl01F8Y7xO4gn1aN2bJhMjSkycfwZ2mUtDDky4ARVGtJ93JIw0A/47j/xDMEqKC37iFAFKREsNe6cD1FzFeuecc4ZWkhDReziD3tscoNbLr4WYXkBOhjfh/zdH82Lx3s8= Received: from BYAPR21MB1256.namprd21.prod.outlook.com (20.179.57.160) by BYAPR21MB1334.namprd21.prod.outlook.com (20.179.60.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.2; Wed, 17 Apr 2019 18:52:15 +0000 Received: from BYAPR21MB1256.namprd21.prod.outlook.com ([fe80::a4a4:9084:90b3:f89d]) by BYAPR21MB1256.namprd21.prod.outlook.com ([fe80::a4a4:9084:90b3:f89d%9]) with mapi id 15.20.1835.003; Wed, 17 Apr 2019 18:52:15 +0000 From: Matt Olson To: hiren panchasara , Yi Huang CC: "tcpm@ietf.org" Thread-Topic: [tcpm] A question about PTO/RTO rescheduling in RACK draft Thread-Index: AdT0v450DAV7LlJPShaJ9NxD6aYmRAAibyEAAADFGxA= Date: Wed, 17 Apr 2019 18:52:14 +0000 Message-ID: References: <20190417181344.GM31257@strugglingcoder.info> In-Reply-To: <20190417181344.GM31257@strugglingcoder.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=maolson@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-04-17T18:52:13.6932571Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f017d8d7-0615-48d3-909a-0b8cfa969d3a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=maolson@microsoft.com; x-originating-ip: [2001:4898:80e8:1:a0b8:a831:97ff:692b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78e49b04-6c72-4a66-7943-08d6c365cef9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR21MB1334; x-ms-traffictypediagnostic: BYAPR21MB1334: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(366004)(346002)(376002)(13464003)(189003)(199004)(55016002)(33656002)(478600001)(9686003)(86362001)(53936002)(10090500001)(102836004)(86612001)(6246003)(186003)(76176011)(7696005)(14444005)(105586002)(256004)(99286004)(11346002)(5660300002)(6506007)(14454004)(476003)(74316002)(8936002)(8676002)(53546011)(305945005)(81166006)(68736007)(6116002)(52536014)(106356001)(22452003)(7736002)(6436002)(446003)(81156014)(46003)(2906002)(71200400001)(229853002)(25786009)(97736004)(4326008)(486006)(71190400001)(316002)(10290500003)(8990500004)(110136005)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR21MB1334; H:BYAPR21MB1256.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5bkkhJj2w2b+GLrI+Z9Lw8V/jaDNqpUq0ett7grR64SVR99+EFFiAk/4N+YMCBriv+rWHAEukyuU/F6ewPWBhIfPlMkFPz6r4TI+Wg2CsvKwOs1zPJnDqKyQkeZo19nbLWFrnTdXnjiWVUqJm6mPMEENicwKRVjV/gGXaHS2WAADrDmmRxccUNqaPMqMBe6oeCgIYPPqqOFT+8+IJqdpJ3bj5LpfqohSy3fGIOEOJolvs4ohw2pdt3DiuklehqgQr1FZeHHOvILkyaXVp/zQ9laZmGpuQZ9D4suPtu/5Xsb6nKIQfF8phjufFpJRMi4p8d6RraYBAzId3dhIG2ar9kGfVHhXqBHT7iqozK7X3OH+nm4qVctDCRfODdKpXt1r8qWI6FosbNOcOH8hqI5Pv0Kpp8u0rsMcVcJt9bZrBMA= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78e49b04-6c72-4a66-7943-08d6c365cef9 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 18:52:14.9074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR21MB1334 Archived-At: X-Mailman-Approved-At: Thu, 18 Apr 2019 09:46:11 -0700 Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 17 Apr 2019 18:52:19 -0000 Previously, you'd start the RTO timer on the first packet, and the timer wo= uld run until an ACK was received. Now, the timer is reset on each new pack= et. So the concern is that there exist cases where previously TCP would red= uce the CWnd and retransmit, but not anymore. If all such cases are app-limited cases, then I like Hiren's point about th= is being a "keep CWnd in check while app-limited" problem.=20 -----Original Message----- From: hiren panchasara =20 Sent: Wednesday, April 17, 2019 11:14 AM To: Yi Huang Cc: tcpm@ietf.org; Matt Olson Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft On 04/17/19 at 01:48P, Yi Huang wrote: > Hi, Hi! I don't see anything inherently wrong in how this works or I am missing som= ething. >=20 > I have a question about PTO/RTO rescheduling logic in RACK draft. The dra= ft states, in Section 6.5.1, "If there was a previously scheduled PTO or RT= O pending, then that pending PTO or RTO should first be cancelled, and then= the new PTO should be scheduled". So if an app keeps posting data in an in= terval less than PTO and RTO (say one byte each time and Cwnd is large enou= gh) and no acks are coming back due to network failures or a receiver that = just does not send anything back, the app will never fires RTO since the ti= mer is pushed out each time we send this one byte data. Is this a problem? By growing CWND, TCP has decided that it is okay to send that much without = needing an ACK. I think something along the lines of detecting that connection is app-limit= ed OR doing newcwv like validation may help to keep CWND in check? > What is the intention of pushing out the timer for each send? 6.5.1 (Step 1) indicated a few conditions for scheduling PTO (i.e. pushing out the timer) so its not blindly doing for each send. But it would= do that for the case you described as app *is* handing new data to be sent= to TCP. >I think in this case the sender should disconnect the connection because, = without TLP, the sender would have had several RTOs and closed the connecti= on. I am probably not understanding something. I think you are saying TLP is ca= using RTO to be pushed out unnecessarily. One cannot schedule PTO when a TLP is out. So, on first timeout i.e. PTO as= we prefer that over RTO, you send a TLP out. And if you don't get an ACK b= ack for that, next timeout would be an RTO as 6.5.1. Phase 1 condition 1 s= uggests. But if there is new data to be sent, RTO would also gets pushed out, no? >=20 > Also, RFC 6298 Section 5 (5.1) states "Every time a packet containing dat= a is sent (including a retransmission), if the timer is not running, start = it running so that it will expire after RTO seconds (for the current value = of RTO).", which says TCP should schedule timer only when it is not schedul= e yet and this kind of conflicts with (or is overridden by) what is in RACK= /TLP draft. I am not sure I follow. For the connection, you need a timeout mechanism. A= nd RACK draft suggests keeping PTO aligned with RTO as the former is less e= xpensive. Try PTO and if it doesn't work, do RTO. I believe the wordings around "first cancel the pending one and then only s= chedule new one" are for clarity around implementation details. Gist is to not keep 2 sets of timers running for the same timeout mechanism= .=20 Someone with more clue on the list would probably correct me. :-) Cheers, H= iren From nobody Thu Apr 18 10:53:22 2019 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 BAE6312038C; Thu, 18 Apr 2019 10:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usBY_oNTkEPq; Thu, 18 Apr 2019 10:53:18 -0700 (PDT) Received: from mail.strugglingcoder.info (unknown [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 67DAB12015E; Thu, 18 Apr 2019 10:53:18 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id ED95117BF9; Thu, 18 Apr 2019 10:53:17 -0700 (PDT) Date: Thu, 18 Apr 2019 10:53:17 -0700 From: hiren panchasara To: Neal Cardwell Cc: draft-ietf-tcpm-rack@ietf.org, Matt Olson , "tcpm@ietf.org" , Yi Huang , Yuchung Cheng , Nandita Dukkipati , Priyaranjan Jha Message-ID: <20190418175317.GE45038@strugglingcoder.info> References: <20190417181344.GM31257@strugglingcoder.info> <20190417192202.GN31257@strugglingcoder.info> <20190417211521.GA45038@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ns7jmDPpOpCD+GE/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft 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, 18 Apr 2019 17:53:20 -0000 --Ns7jmDPpOpCD+GE/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/18/19 at 09:18P, Neal Cardwell wrote: > On Wed, Apr 17, 2019 at 5:15 PM hiren panchasara > wrote: > > I'll keep this to the point I thought got missed. > > > > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-04.txt > > > > Is where we can see `Scheduling a loss probe` getting changed. > > Specifically, following condition has been removed from -04: > > > > 3. The connection is either limited by congestion window (the data > > in flight matches or exceeds the cwnd) or application-limited > > (there is no unsent data that the receiver window allows to be > > sent). > > > > And afaict, Linux code still has this condition in. If you can provide > > some rationale behind this change, it'd be great. >=20 > We removed the code for that condition from Linux around 2017-12-13, > in this commit (GPLv2 patch in this link): > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/comm= it/net/ipv4/tcp_output.c?id=3Db4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd >=20 > The commit description explains the rationale for removing that > condition, but here is a paraphrased description of the rationale for > removing that code and that condition in the draft: [skip] Thanks a lot. This makes sense. Apologies for misreading the code. Cheers, Hiren --Ns7jmDPpOpCD+GE/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJcuLmLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lOgkH/3m31FuhTlwOSmNI9ye/r+XN tv2AuU1kNk6rGlucLmZRCsP74TbITshWBOe1ZVq/A21sR1EJ8CJN4mrng2Snz+Za lrieXntMPeWBFzRKktkMZuJ7iI6LqUq+l4zdTy74b8Q5QEjKiMeKZjnq9pJOxGoY 2wYfb9T+EChI2hCdzIdDNTCqi2NFpDD5wWY2NsbBkm9dbkdwb0C391gXm1irYxfs BfdekuFC75hy4x3zPXo+lBVo3ospistzZKDO/7LMj5oxNuG59ChvHfC7hIzqp/Ua B9XxzZKXN4mD5phSWCYpL9BBvRmtuo8cPb3AhELqsonHkAyd3YUlC+4vifR4e8g= =WxQo -----END PGP SIGNATURE----- --Ns7jmDPpOpCD+GE/-- From nobody Tue Apr 23 22:41:53 2019 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 F15901200CD for ; Tue, 23 Apr 2019 22:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hRDI+yyl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VqlDauZB 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 GsKkIOEK4uyQ for ; Tue, 23 Apr 2019 22:41:49 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A81712002E for ; Tue, 23 Apr 2019 22:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12874; q=dns/txt; s=iport; t=1556084509; x=1557294109; h=from:to:cc:subject:date:message-id:mime-version; bh=fPdHpfKoiLaunLsfvo2PBCD9d3b+KpocejRIJViXxGk=; b=hRDI+yyljBNVKDc/0Vceprsu31aDe2AjdNGtaQq9Ws584NRyQZ5MBZU0 TzVn/MhcmyLcsmppfcglIr7LeEZwQdyXjBcDm6iO1xP70Z7qxpiV1j5jS 6d1dklgbs5Jq+/hdk1op/QBNwYaCFo1P0JOYFQEIuQ8bsZPOkK8DbYg0N E=; IronPort-PHdr: =?us-ascii?q?9a23=3AKaZs/BxKPe8/S8rXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZueBlD9IPf0YgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAABv9r9c/49dJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ4vJCwDaFUgBAsoCodMA4RSikUcgjuPVIJ6A4JUgXiBLhS?= =?us-ascii?q?BZw4BASMKhEAChiwjNAkOAQMBAQQBAQIBAm0cDIVKAQYtEwEBNwERAQgRAwE?= =?us-ascii?q?CKDkUCQoEAQ0FgyOBHUwDHAECDJ08AooUgiCCeQEBBYFGQYMCGIINAwaBMgG?= =?us-ascii?q?LSReBQD+BEYMSPoJhAgMBgSVGEg0JhSuRcJRqCQKCCIYPhiSFdxuVFIwEhj2?= =?us-ascii?q?NfgIEAgQFAg4BAQWBTziBVnAVgyeCD4NvhRSFP3KBKY4oAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.60,388,1549929600"; d="scan'208,217";a="267293586" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2019 05:41:47 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x3O5fl5o002448 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Apr 2019 05:41:47 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Apr 2019 00:41:46 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Apr 2019 00:41:46 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Apr 2019 00:41:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JKjnK8WLLCHzQ+4nu9sjaep4bytuZJL4bhwgB80rkDw=; b=VqlDauZB3SMebBOoDu5XpGjV8YBMF5dPJFsnjwRTu9gTFzz65BOay1F27OWmbh3Y6HxW2MQT/cahzFUX8qXYsNU/1MV1z998AvxXbN9DuB63o3lP5pqyXX+H1Hp9YaZsNP5uCcO28KHSCyB7z6O0id8+CplVy3U9iCqmSctTqpE= Received: from DM6PR11MB3563.namprd11.prod.outlook.com (20.178.229.161) by DM6PR11MB3626.namprd11.prod.outlook.com (20.178.230.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Wed, 24 Apr 2019 05:41:45 +0000 Received: from DM6PR11MB3563.namprd11.prod.outlook.com ([fe80::745a:5d42:ba2a:5d8d]) by DM6PR11MB3563.namprd11.prod.outlook.com ([fe80::745a:5d42:ba2a:5d8d%2]) with mapi id 15.20.1835.010; Wed, 24 Apr 2019 05:41:45 +0000 From: "Sri Gundavelli (sgundave)" To: "mohamed.boucadair@orange.com" , "tcpm@ietf.org" CC: "Konda, Tirumaleswar Reddy (TirumaleswarReddy_Konda@McAfee.com)" , JACQUENET Christian TGI/OLN Thread-Topic: [tcpm] Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-converter) Thread-Index: AQHU+mBm379i5uZs+UuHjtUEsAtaPw== Date: Wed, 24 Apr 2019 05:41:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgundave@cisco.com; x-originating-ip: [128.107.241.164] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c3272d1-ae47-4838-3233-08d6c877897a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM6PR11MB3626; x-ms-traffictypediagnostic: DM6PR11MB3626: x-ms-exchange-purlcount: 37 x-microsoft-antispam-prvs: x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(136003)(346002)(366004)(199004)(189003)(26005)(68736007)(966005)(2906002)(14454004)(478600001)(476003)(71190400001)(606006)(2616005)(256004)(36756003)(71200400001)(102836004)(19273905006)(66446008)(64756008)(66556008)(66476007)(186003)(66946007)(53546011)(7736002)(86362001)(97736004)(91956017)(73956011)(76116006)(6436002)(25786009)(6506007)(2501003)(6512007)(3846002)(229853002)(236005)(53936002)(8936002)(790700001)(6486002)(53376002)(5660300002)(66066001)(110136005)(58126008)(54906003)(6116002)(6306002)(6246003)(54896002)(316002)(486006)(8676002)(81156014)(4326008)(99286004)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3626; H:DM6PR11MB3563.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tOSXU0VQ6ITrsuSpDhN+w3HtChrGcjl5qzGVyjuak7rbdC53kbA5ttYQMXt+HRqcXgnANrLR9TZk8uPmNfSloJWw/2ddbpa3iU1tKiwLWtclraEqp/Soj4vKsGtTJdMtjbeIKBydbYQ6xI3ArzxuV8I4PzdWlz14TnK14y068cFF1gWBYhcw3GalgFYiPoFlrYVd1iVKzCmkbnt+UJ7joFAI5jTU4TgLDlymIZ4jtd3A6OoeKRBfvh425BDF08Zwav6NZ54+wOgFEbX5NWVB8jEoexwaOKSu+u9V8CJzZZgyU10Hncf2XztAJ6EngCqA79hjwrp0JAilaQbewAHU/vZ3vC6KjqYiLtQI9JNsBsmhQfIVrfC+RhZ4obKiILGLTAnkdVe6e6ojr9WUUcZKfDoFmRCfs/pK7K76pizTvX0= Content-Type: multipart/alternative; boundary="_000_D8E5435A2F3E5Fsgundaveciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c3272d1-ae47-4838-3233-08d6c877897a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 05:41:45.2043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3626 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [tcpm] Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-converter) 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, 24 Apr 2019 05:41:52 -0000 --_000_D8E5435A2F3E5Fsgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Med & WG: I have reviewed the draft (draft-boucadair-tcpm-dhc-converter) and I think = this is a useful option. Configuration of converter address on the endpoint= , or for that matter, any configuration element is a pain. In that sense, a= ny steps to eliminate this static configuration will help deployments and t= herefore I am supportive of this work. Also, FWIW, I was earlier exploring = L2 signaling approaches for provisioning the same and I think DHCP option m= akes lot more sense. I hope you will find support for this work. Sri From: tcpm > on behalf = of "mohamed.boucadair@orange.com" > Date: Wednesday, April 17, 2019 at 7:05 AM To: "tcpm@ietf.org" > Cc: "Konda, Tirumaleswar Reddy (TirumaleswarReddy_Konda@McAfee.com)" >, JACQUENET Christian TGI/OLN > Subject: [tcpm] Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-con= verter) Dear all, Now that the 0-RTT Converter spec is about to be LCed, we would like to ask= the WG to consider this draft https://datatracker.ietf.org/doc/draft-boucadair-tcpm-dhc-converter/ which = is useful for the dynamic provisioning of the Converters to CPEs, in partic= ular. The converters discovery options cannot be defined in the dhc WG because it= s charter says the following: =93Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are generally outside of scope for the DHC WG. Such options should be defined within their respective WGs=94 We hope that tcpm can host this work. Cheers, Med --_000_D8E5435A2F3E5Fsgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Med & WG:

I have reviewed the draft (draft-boucadair-tcpm-dhc-converter) and I t= hink this is a useful option. Configuration of converter address on the end= point, or for that matter, any configuration element is a pain. In that sen= se, any steps to eliminate this static configuration will help deployments and therefore I am supportive o= f this work. Also, FWIW, I was earlier exploring L2 signaling approaches fo= r provisioning the same and I think DHCP option makes lot more sense.  = ;I hope you will find support for this work.

Sri





From: tcpm <tcpm-bounces@ietf.org> on behalf of "mohamed.boucadair@orange.com= " <mohamed.boucadai= r@orange.com>
Date: Wednesday, April 17, 2019 at = 7:05 AM
To: "tcpm@ietf.org" <tcpm@i= etf.org>
Cc: "Konda, Tirumaleswar Reddy= (TirumaleswarReddy_K= onda@McAfee.com)" <TirumaleswarReddy_Konda@McAfee.com>, JACQUENET Christian TGI/OLN <christian.jacquenet@orange.com>
Subject: [tcpm] Provisioning 0-RTT = Converters (draft-boucadair-tcpm-dhc-converter)

Dear all,

 

Now that the 0-RTT Converter spec is about = to be LCed, we would like to ask the WG to consider this draft

https://datatracker.ietf.org/doc/draf= t-boucadair-tcpm-dhc-converter/ which is useful for the dynamic provisioning of the Converters to CPEs, in particular.

 

The converters discovery options cannot be = defined in the dhc WG because its charter says the following:

 

=93Definitions of new DHCP options that are= delivered using standard

mechanisms with documented semantics are no= t considered a protocol

extension and thus are generally outside of= scope for the DHC WG. Such

options should be defined with= in their respective WGs=94

 

We hope that tcpm can host this work.

 

Cheers,

Med

 --_000_D8E5435A2F3E5Fsgundaveciscocom_-- From nobody Wed Apr 24 00:35:38 2019 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 B44E51200F6 for ; Wed, 24 Apr 2019 00:35:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ckCVmPZ7MvW for ; Wed, 24 Apr 2019 00:35:33 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 8D6A112006F for ; Wed, 24 Apr 2019 00:35:32 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id d1so14946384edd.13 for ; Wed, 24 Apr 2019 00:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Egl4qyh/OLdYDuLHgUT/uUo9R/gNGAeSPXYJjPDezOw=; b=wJ6sBO18WjBVeyaHk/1xDMnFzv5rXgrSG7oPO3ZEWtSIRSG4kDv2exPCZq1OTLIjHr QF8dK8Gehf2EAGB30lyLBZfBvDgiDwc+3g8i8PKMmDrFIcbEgF+WcdKN6v85OJBBCqL6 4En0OXbtyXrhOQsxuk/nMI0UP8aOJSN8HwyCYipYmzyOhMUJ8B2oyPHOZ6/pZtSV2VF4 qwYCy8DeeyT1+yrWN5/ddyN+Fbaio6MvbZ0zJ2p8+TOZVEqvRTPymn9L0fJv2v1aRu6D +BUP1p0DBNRYZEZVVH689Y9hCCrvS5aSspgwfgyv3CO9K8XAgD8WVC7yB4hvarSBmKE+ ChuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Egl4qyh/OLdYDuLHgUT/uUo9R/gNGAeSPXYJjPDezOw=; b=nN9RxTqbkHa1cKNWHNCHcBFrMzBBN2tV+ov640QA06Ovwyf9DJZIGU1VOaKYRL/2T2 E4DtUDivBvfBzx8dSXQr8iMhlCOF8lYAn6duRUQpV4UWDfe1lp3Zo87ao4MBEMtcHhie hN12PIiE6ifWAypUboG+z/dF9KfTVhyRrTlpNlBImU6lzUW3bNtqROojPZ/J2yVoj3r7 3/oRRS29PLDgdZQnliqdG7Uq5gOvvBJEhRvdq1Nw3l5g2Eb4xCE+P6LBVSczm26FU4Fa i62S9cHbMASxZT+jjGJK1kDSCaXaGczxJiQhTg1FqX1qcE772oBTI6ickHHaRlbIj2Um tZCg== X-Gm-Message-State: APjAAAVlm71CJ/NNMNyjabOwIXIszp+LG/eS6nxB8hSgYb1/Kc0Ns7nD 4FQkN5YB8+YHLDwgkj7++D+PS7Ew5McJtoV4uDvEwCVo3jloxc4/psyeKGRYA1qm4x/Dqat1 X-Google-Smtp-Source: APXvYqzO+ZNOhiilRPzMQYTBuFHgmn/mGM8VVFqEsyKxxc+RbtHCNGH4z6q6nEKU5YocshYM4E4P4Q== X-Received: by 2002:a17:906:6152:: with SMTP id p18mr15311322ejl.245.1556091330961; Wed, 24 Apr 2019 00:35:30 -0700 (PDT) Received: from ?IPv6:2001:6a8:308f:2:45fd:6a5b:a571:9abd? ([2001:6a8:308f:2:45fd:6a5b:a571:9abd]) by smtp.gmail.com with ESMTPSA id 30sm5463760edr.2.2019.04.24.00.35.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 00:35:29 -0700 (PDT) From: Olivier Bonaventure Message-Id: <3F0B64FE-4B3E-4060-9C2C-328222D0593C@tessares.net> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 24 Apr 2019 09:35:28 +0200 In-Reply-To: Cc: "mohamed.boucadair@orange.com" , "tcpm@ietf.org" , "Konda, Tirumaleswar Reddy (TirumaleswarReddy_Konda@McAfee.com)" , JACQUENET Christian TGI/OLN To: "Sri Gundavelli (sgundave)" References: X-Mailer: Apple Mail (2.3445.104.8) Content-Type: multipart/alternative; boundary="Apple-Mail=_ACA831C4-9B85-47D6-8655-05BAF6027EDB" Archived-At: Subject: Re: [tcpm] Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-converter) 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, 24 Apr 2019 07:35:36 -0000 --Apple-Mail=_ACA831C4-9B85-47D6-8655-05BAF6027EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hello, >=20 >=20 > I have reviewed the draft (draft-boucadair-tcpm-dhc-converter) and I thin= k this is a useful option. Configuration of converter address on the endpoi= nt, or for that matter, any configuration element is a pain.=20 I agree. This DHCP extension is one of the possible ways to disseminate the= information about the converter address. I support this draft Olivier >=20 >=20 > From: tcpm > on beha= lf of "mohamed.boucadair@orange.com " = > > Date: Wednesday, April 17, 2019 at 7:05 AM > To: "tcpm@ietf.org " > > Cc: "Konda, Tirumaleswar Reddy (TirumaleswarReddy_Konda@McAfee.com )" >, JACQUENET Christian TGI/OLN = > > Subject: [tcpm] Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-c= onverter) >=20 > Dear all, > =20 > Now that the 0-RTT Converter spec is about to be LCed, we would like to a= sk the WG to consider this draft > https://datatracker.ietf.org/doc/draft-boucadair-tcpm-dhc-converter/ which is= useful for the dynamic provisioning of the Converters to CPEs, in particul= ar.=20 > =20 > The converters discovery options cannot be defined in the dhc WG because = its charter says the following: > =20 > =E2=80=9CDefinitions of new DHCP options that are delivered using standar= d > mechanisms with documented semantics are not considered a protocol > extension and thus are generally outside of scope for the DHC WG. Such > options should be defined within their respective WGs=E2=80=9D > =20 > We hope that tcpm can host this work. > =20 > Cheers, > Med > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --=20 Disclaimer: https://www.tessares.net/mail-disclaimer/=20 --Apple-Mail=_ACA831C4-9B85-47D6-8655-05BAF6027EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hello,
=


I have reviewed the draft (draft-boucadair-tcpm-dhc-converter) and I thin= k this is a useful option. Configuration of converter address on the endpoi= nt, or for that matter, any configuration element is a pain. 

I agree. This DHCP extension is o= ne of the possible ways to disseminate the information about the converter = address. I support this draft

Olivier





From: tcpm <= tcpm-bounces@ietf.org> on behalf of "<= a href=3D"mailto:mohamed.boucadair@orange.com" style=3D"color: purple; text= -decoration: underline;" class=3D"">mohamed.boucadair@orange.com" <<= a href=3D"mailto:mohamed.boucadair@orange.com" style=3D"color: purple; text= -decoration: underline;" class=3D"">mohamed.boucadair@orange.com>Date: Wednesday, April 17, 2019 at= 7:05 AM
To: "tcpm@ietf.org" <tcpm@ietf.org>
Cc: "Konda, Tirumaleswar Reddy (TirumaleswarReddy_Konda@McAfee.com= )" <TirumaleswarReddy_Konda@M= cAfee.com>, JACQUENET Christian TGI/OLN <christian.jacquenet@orange.com>
Subject: [tcpm] Provisioning 0-RTT Converters (draft-b= oucadair-tcpm-dhc-converter)

Dear all,
=  
= Now that the 0-RTT Converter spec is about to be LCed, we would like to ask= the WG to consider this draft
https://datatracker.ietf.org/doc/draft-b= oucadair-tcpm-dhc-converter/ = ;which is useful for the dynamic provisioning of the Converters to C= PEs, in particular. 
 
= The converters discovery options cannot be defined in= the dhc WG because its charter says the following:
 
=E2=80=9CDefinitions of new DHCP options that are delivered using standar= d
mechanisms with documented semantics are not considered a proto= col
extension and thus are generally outside of scope for the DHC = WG. Such
options should be defined within their respective WGs=E2=80=9D
 =
We hope that tcpm c= an host this work.
 
Cheers,
Med
_______________________________= ________________
tcpm mailing list
tcpm@i= etf.org
https://www= .ietf.org/mailman/listinfo/tcpm

=



--Apple-Mail=_ACA831C4-9B85-47D6-8655-05BAF6027EDB-- From nobody Fri Apr 26 06:46:47 2019 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 CC745120072 for ; Fri, 26 Apr 2019 06:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 X_ElOLiRhpSJ for ; Fri, 26 Apr 2019 06:46:42 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975B112004B for ; Fri, 26 Apr 2019 06:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bGBQEZ+rrmH2HQTbj7ccYXialxl11KxFh9ZEzGD6ge4=; b=TWfUpvutHtDgathsBtH3kg3GJM1ACJIGk8fw9d81ldhx8JSfWn4jgaKe65Jc/v90r3yLr1FofHRf2X7i/5LgoxnOayhVyX8HDQGYhptbEiFvX3BM7lb/lhqX/PnXfitBy9gVLeGZm4qcRydKwt4xtEGJKPUwVaqRn1AIiZSA1J8= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB4315.eurprd07.prod.outlook.com (20.176.167.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.9; Fri, 26 Apr 2019 13:46:38 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::8085:df69:92b4:8bbb]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::8085:df69:92b4:8bbb%4]) with mapi id 15.20.1835.010; Fri, 26 Apr 2019 13:46:38 +0000 From: Ingemar Johansson S To: "tcpm@ietf.org" CC: Ingemar Johansson S Thread-Topic: ACK aggregation and congestion window growth Thread-Index: AdT8NTrQyrmIo4MtTwOc3MNifKi5sA== Date: Fri, 26 Apr 2019 13:46:37 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93699172-39ae-49c0-2ced-08d6ca4d9b08 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4315; x-ms-traffictypediagnostic: HE1PR07MB4315: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1443; x-forefront-prvs: 001968DD50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(346002)(396003)(376002)(199004)(189003)(73956011)(86362001)(6916009)(316002)(81166006)(6436002)(4744005)(2501003)(8676002)(8936002)(33656002)(81156014)(5660300002)(55016002)(2351001)(5640700003)(1730700003)(4326008)(76116006)(25786009)(97736004)(66946007)(66616009)(66446008)(66556008)(64756008)(66476007)(26005)(6506007)(99936001)(14454004)(66066001)(68736007)(186003)(9686003)(52536014)(6306002)(476003)(71200400001)(486006)(74316002)(53936002)(54896002)(107886003)(2906002)(256004)(3846002)(66574012)(6116002)(99286004)(790700001)(7696005)(102836004)(71190400001)(478600001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4315; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 883j2Oro+8fyuSVCcOtu4ioYe1WSDmmrV/ZkcL74kujfDih+V5ukXcZOchrNyOlpE7mkXqFNDvFxtYtS4MKGQUgKfXNtZl7x3gNGq5mi3kwgLLnpF2Zc6QmZROGrKeCJTRLMOQ+bhcIL2jxfRI/xNPFGTjqYKjEEaP6J5JrfrqKaHqRCEfAkMqJ9qtSOnnFuDJWG/m26ZrqrhuuS2b3O/1KXqq+MG6WFd+hoMbiOE5pFAVQDlPiop3/T+iRXUz4wm6uJoxd9OjCQULfosu0ZiT0fafPISRQyezwUJVC0Gj82X7JGong8tj5UALyhcSkZkd1HfLZRLPUf84gsbGRxBAj2VBjZUN2VoBvch/wVxI6TVSLx2N1hMgW3Y07nWEj8zYtGE3X1+m2cKot2uSBvMRPAn+37alHHgBp542OJKT8= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0568_01D4FC47.38B52460" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 93699172-39ae-49c0-2ced-08d6ca4d9b08 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 13:46:38.0269 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4315 Archived-At: Subject: [tcpm] ACK aggregation and congestion window growth 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: Fri, 26 Apr 2019 13:46:45 -0000 ------=_NextPart_000_0568_01D4FC47.38B52460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0569_01D4FC47.38B52460" ------=_NextPart_001_0569_01D4FC47.38B52460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 I am experimenting with a simple test setup with 2 Ubuntu 18.04 PCs = (Cubic CC).=20 Between these two I have a simple setup that aggregates ACKs so that = they are forwarded to the server only every 10ms. The min RTT is 18ms.=20 The problem I see is that even though I should reach 1Gbps throughput, I only get around 200Mbps.=20 I would believe that the congestion window should eventually increase = enough to handle the burstiness given by the ACK aggregation but it seems like = this is not the case.=20 Is there a limitation in the Linux stack that prevents congestion window growth when ACKs arrive in bursts like this ?=20 =20 /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc.=20 Master Researcher =20 Ericsson Research Network Protocols & E2E Performance Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com =20 Nothing to stop this being the best day ever U2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ------=_NextPart_001_0569_01D4FC47.38B52460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I am experimenting with a simple test setup with 2 Ubuntu = 18.04 PCs (Cubic CC).

Between these two I have a simple setup that aggregates = ACKs so that they are forwarded to the server only every 10ms. The min = RTT is 18ms.

The problem I see is that even though I should reach 1Gbps = throughput, I only get around 200Mbps.

I would believe that the congestion = window should eventually increase enough to handle the burstiness given = by the ACK aggregation but it seems like this is not the case. =

Is there a = limitation in the Linux stack that prevents congestion window growth = when ACKs arrive in bursts like this ?

=A0

/Ingemar

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

Ingemar Johansson=A0 M.Sc. =

Master = Researcher

 

Ericsson = Research

Network Protocols & E2E = Performance

Labratoriegr=E4nd = 11

971 28, Lule=E5, = Sweden

Phone +46-1071 = 43042

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

<= p class=3DMsoNormal style=3D'text-autospace:none'> 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Nothing to stop this

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = being the best day ever

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 U2

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

 

------=_NextPart_001_0569_01D4FC47.38B52460-- ------=_NextPart_000_0568_01D4FC47.38B52460 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3 MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J 0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9 7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP 9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6 Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8 TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3 OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO 30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3 0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5 S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT 05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT 9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx 5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+ i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xOTA0MjYxMzQ2MzJaMCMGCSqGSIb3DQEJBDEWBBRnPD9NljNVtwfXVSKP lRq8A6rmszBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAIwknkM44GDMAiTLf2Oz9o/UTAjbn1R6neQA5KlB 3bh6cjuk6KKme6wB9K3oI8nE3r84e+8IKpvEnsMrWV0QzS7bqJtc1Nm6GKgNkbrYk9i/EKtsCuOt h83VZLC+2F635lRBq8oVZhAwpq5OfSYUE9CGnL65ZsyiJe9pKhooIO8cNyDvg9xYY00skBVSZjcu 147tR8/QCiS5cuy5d3frD8D9KtJee8ZbAf3elUoNwAPQOOdPAR2xRGJTInPzToxEfc34I6uIHc2N 4aD7GY5AlzkTEZ0wQHFcYUxpm5wGdj1A2kzykoljLr+ODk4Yycv6Ca3wqgYVo0jv9VH3dZ6vjrwA AAAAAAA= ------=_NextPart_000_0568_01D4FC47.38B52460-- From nobody Fri Apr 26 07:03:13 2019 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 85B281201D9 for ; Fri, 26 Apr 2019 07:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=mac.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 xUQ0zajIRUDI for ; Fri, 26 Apr 2019 07:03:08 -0700 (PDT) Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FF41201CA for ; Fri, 26 Apr 2019 07:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=04042017; t=1556287387; bh=n6VX/oPwzn+xqP5UHtZSw8PtF1nOchIT5Ljs/3zxSww=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=RQTZD4fiQyTCR5TQGYG/ha89TZVQ9YGwUN/r5C6xe2LsFHe+m8J7PQ/+SwDyd3h7R LDndfyC8GO8uP0zXGGdwFSA18bxwS8xEsTQTX2gPiMrBWtWrAHKoJlkiRcHUOIOdfp mrxB57OQ0wlQzm/xurtK/R6P5ehBxIXwrcq4SbxW8gKORV0r/QdRf2X3/dKWsYTBBm CKg179n2p/7/NWZpkdb/OqhJSLCGnlc1uiztCmtoV70QrMOQAvE8YONQukhzFF8q3r k0sonHH4V3fF76yW7IVWB9l5fEH9Vdzcp+GopRfW2VAleJCsBaWZNKZuaIiWX/7lHD 4w56kIjE/9gLw== Received: from [192.168.1.180] (76-220-56-249.lightspeed.sntcca.sbcglobal.net [76.220.56.249]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id A1F3740020A; Fri, 26 Apr 2019 14:03:07 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-83E3FBCC-80A3-4573-B380-3D50CC6855D6 Mime-Version: 1.0 (1.0) From: Rick Jones X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Fri, 26 Apr 2019 07:03:06 -0700 Cc: "tcpm@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: To: Ingemar Johansson S X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-26_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=350 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1904260097 Archived-At: Subject: Re: [tcpm] ACK aggregation and congestion window growth 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: Fri, 26 Apr 2019 14:03:11 -0000 --Apple-Mail-83E3FBCC-80A3-4573-B380-3D50CC6855D6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Does your ACK aggregator also delay the ACKs of SYNchronize segments? If not= , perhaps the congestion control sees the increase (?) in round trip time af= ter connection establishment as a signal of congestion and behaves according= ly.=20 > On Apr 26, 2019, at 06:46, Ingemar Johansson S wrote: >=20 > Hi > =20 > I am experimenting with a simple test setup with 2 Ubuntu 18.04 PCs (Cubic= CC). > Between these two I have a simple setup that aggregates ACKs so that they a= re forwarded to the server only every 10ms. The min RTT is 18ms. > The problem I see is that even though I should reach 1Gbps throughput, I o= nly get around 200Mbps. > I would believe that the congestion window should eventually increase enou= gh to handle the burstiness given by the ACK aggregation but it seems like t= his is not the case. > Is there a limitation in the Linux stack that prevents congestion window g= rowth when ACKs arrive in bursts like this ? > =20 > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Master Researcher > =20 > Ericsson Research > Network Protocols & E2E Performance > Labratoriegr=C3=A4nd 11 > 971 28, Lule=C3=A5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > Nothing to stop this > being the best day ever > U2 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-83E3FBCC-80A3-4573-B380-3D50CC6855D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Doe= s your ACK aggregator also delay the ACKs of SYNchronize segments? If not, p= erhaps the congestion control sees the increase (?) in round trip time after= connection establishment as a signal of congestion and behaves accordingly.=  

On Apr 26, 2019, at 06:46, Ingemar Johansso= n S <ingemar.s.johans= son@ericsson.com> wrote:

Hi

 

I am experimenting with a simple test s= etup with 2 Ubuntu 18.04 PCs (Cubic CC).

Between these two I have a simple setup that a= ggregates ACKs so that they are forwarded to the server only every 10ms. The= min RTT is 18ms.

The problem I see is that even though I should reach 1Gbps throughpu= t, I only get around 200Mbps.

<= span lang=3D"EN-US">I would believe that the congestion window should eventu= ally increase enough to handle the burstiness given by the ACK aggregation b= ut it seems like this is not the case.

Is there a limitation in the Linux stack that p= revents congestion window growth when ACKs arrive in bursts like this ?

 

/Ingemar

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

=

Ingemar Johansson  M.Sc.

Master Researcher

 

Ericsson Research

N= etwork Protocols & E2E Performance

Labratoriegr=C3=A4nd 11

971 28, Lule=C3=A5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

inge= mar.s.johansson@ericsson.com

www.ericsson.com

 

        &n= bsp;       Nothing to stop this

      &= nbsp;      being the best day ever

      &nb= sp;            &= nbsp;        U2

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

&nbs= p;

_______________________________________________
tc= pm mailing list
tcpm@ietf.o= rg
https://www.ietf.org/mailman/listinfo/tcpm
= --Apple-Mail-83E3FBCC-80A3-4573-B380-3D50CC6855D6-- From nobody Fri Apr 26 07:27:45 2019 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 7B77F12004B for ; Fri, 26 Apr 2019 07:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, HTML_MESSAGE=0.001, 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=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 ljPRcQSkbT0z for ; Fri, 26 Apr 2019 07:27:30 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 7E3D812043C for ; Fri, 26 Apr 2019 07:27:30 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id e5so2762456otk.12 for ; Fri, 26 Apr 2019 07:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2WTT3RSYkHslW2jPOrLfi5oJpUYB6VhuqwmeIzvoI9Y=; b=tvIw6Quvu7VAh5O5qZTPNrLJELePlGP81xaNvyUFe11PoJO5Q2rq0k0BA7vtgOFiYX G6zgLuMT2Bt43MPMXuHwrq/uOA1r3UT/6NNPlRUwuZkUEyDEv2Y/BBXaueQarGUm6lwC gKRXstA7aHPNpDq3eItSiiuL4ycWneXHXVL/SgKYUyEVNflolW1S3S18be9R0hkrtLty BzYnzyhtQaC4MaCt2yasku9Mdxwu1UBLWaG13qpu0vwPie5+iECQcWeGd+hDhdinupqj nhPUACrDdrjcZOq9MYNKnWwtIQeAnXxLv81n4vTFLtovdAXIPgz5EWB/Yupa0iMBGJ1e +QQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2WTT3RSYkHslW2jPOrLfi5oJpUYB6VhuqwmeIzvoI9Y=; b=uam3PoG6LoeaXJJLrk88Ao83Xahka0zuXoEkefO/ErfNFtVlzvI2Tl66z1GAZOi9wJ i+RgmW3k7epk9GNTl63IcEvr+JeKcTmdUakERdh6+V1jjPhM9kxIaKEq+y2LJM/tRNLo 6/3+XJKqohOwhIe6vXunV0ccdExvyn4diocuaMdblPm7NbwwX7YGvlL3Rc3VO0waedpv RV2a1gkrw/VbYDtMb3QjLx5IZuHgHJqS7PUosMgLzvC52qU4xFbKKi1fV7RzQpn+GwT8 KSH6q9KV9EsSPROI4Q6YBuiMmi2L7KyWS4OywGu9efZg3Ndso8NVy3sMiDnHFumoEvm5 wHEw== X-Gm-Message-State: APjAAAV6xw5OJ4HmD3r0aoPqVH6kMNgK1+41DEP5s8gS5rU8VQecMLaG GwSVhDcxQMH4M6CVT7Ela2DlDkjgM2pkhwV2GslQpA== X-Google-Smtp-Source: APXvYqwfoLHw4zPhaat1zCNIboDkwKTOWizjwvcLgZo/GVwJe7EOWMq1jvXBwlZVXyUBl8fiEzaGPNOb3eLR17NWV1Y= X-Received: by 2002:a9d:5882:: with SMTP id x2mr8242973otg.49.1556288848145; Fri, 26 Apr 2019 07:27:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Fri, 26 Apr 2019 10:27:10 -0400 Message-ID: To: Ingemar Johansson S Cc: "tcpm@ietf.org" , Yuchung Cheng , Eric Dumazet , Rick Jones Content-Type: multipart/alternative; boundary="000000000000f6b74905876fbb50" Archived-At: Subject: Re: [tcpm] ACK aggregation and congestion window growth 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: Fri, 26 Apr 2019 14:27:44 -0000 --000000000000f6b74905876fbb50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ingemar, Thanks for the report. From the description of the issue, I suspect there is some combination of the following: (1) This may be related to some buggy behavior in the Linux TCP logic for assessing whether a connection is cwnd-limited or application-limited. In the scenario you describe, with those high speeds and long gaps between ACKs, it sounds like the flow may have cwnd that is unused due to to TSO deferral, and this may be causing the logic to erroneously mark the flow as not being cwnd-limited, which would prevent cwnd growth by CUBIC. (2) If there are entire flights of data that are ACKed with a single ACK, then the CUBIC code may assess the long gaps between transmits and ACKs as an idle period, and erroneously push its epoch_start forward to skip any cwnd growth that would have been slated for that period. (I would guess (1) is more likely, since the Reno emulation code path in CUBIC should not be affected by (2), so CUBIC should eventually grow cwnd in a Reno-style fashion whether or not it hits (2).) We can provide some proposed patches for those issues. Would you be able to apply the patches and test them in your workload? If so, what exact kernel version would the patches need to be generated for? Also, would you be able to post (suitably anonymized, heads-only) tcpdump packet traces so that we can see what the exact scenario is? This would be particularly useful if you are unable to apply the patches to verify the fix. thanks, neal On Fri, Apr 26, 2019 at 10:03 AM Rick Jones wrote: > Does your ACK aggregator also delay the ACKs of SYNchronize segments? If > not, perhaps the congestion control sees the increase (?) in round trip > time after connection establishment as a signal of congestion and behaves > accordingly. > > On Apr 26, 2019, at 06:46, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > Hi > > > > I am experimenting with a simple test setup with 2 Ubuntu 18.04 PCs (Cubi= c > CC). > > Between these two I have a simple setup that aggregates ACKs so that they > are forwarded to the server only every 10ms. The min RTT is 18ms. > > The problem I see is that even though I should reach 1Gbps throughput, I > only get around 200Mbps. > > I would believe that the congestion window should eventually increase > enough to handle the burstiness given by the ACK aggregation but it seems > like this is not the case. > > Is there a limitation in the Linux stack that prevents congestion window > growth when ACKs arrive in bursts like this ? > > > > /Ingemar > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson Research > > Network Protocols & E2E Performance > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > Nothing to stop this > > being the best day ever > > U2 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > 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 > --000000000000f6b74905876fbb50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ingemar,

Thanks for= the report. From the description of the issue, I suspect there is some com= bination of the following:

(1) This may be related= to some buggy behavior in the Linux TCP logic for assessing=C2=A0whether a= connection is cwnd-limited or application-limited. In the scenario you des= cribe, with those high speeds and long gaps between ACKs, it sounds like th= e flow may have cwnd that is unused due to to TSO deferral, and this may be= causing the logic to erroneously mark the flow as not being cwnd-limited, = which would prevent cwnd growth by CUBIC.

(2) If t= here are entire flights of data that are ACKed with a single ACK, then the = CUBIC code may assess the long gaps between transmits and ACKs as an idle p= eriod, and erroneously push its epoch_start forward to skip any cwnd growth= that would have been slated for that period.

(I w= ould guess (1) is more likely, since the Reno emulation code path in CUBIC = should not be affected=C2=A0by (2), so CUBIC should eventually grow cwnd in= a Reno-style fashion whether or not it hits (2).)

We can provide some proposed patches for those issues. Would you be able t= o apply the patches and test them in your workload?=C2=A0 If so, what exact= kernel version would the patches need to be generated for?

<= /div>
Also, would you be able to post (suitably anonymized, heads-only)= tcpdump packet traces so that we can see what the exact scenario is? This = would be particularly useful if you are unable to apply the patches to veri= fy the fix.

thanks,
neal

<= /div>




On Fri, Apr 26, 201= 9 at 10:03 AM Rick Jones <perfgeek=3D40mac.com@dmarc.ietf.org> wrote:
<= div dir=3D"ltr">Does your ACK aggregator also delay the ACKs of SYNchronize= segments? If not, perhaps the congestion control sees the increase (?) in = round trip time after connection establishment as a signal of congestion an= d behaves accordingly.=C2=A0

On Apr 26, 2019, at = 06:46, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi<= /p>

=C2=A0

I am experimenting with a simple test setup with 2 Ubunt= u 18.04 PCs (Cubic CC).

Between these two I have a simple setup that aggregates A= CKs so that they are forwarded to the server only every 10ms. The min RTT i= s 18ms.

The problem I see is that even though I should reach 1Gbps throughput, I = only get around 200Mbps.

I would believe that the congestion window should eventu= ally increase enough to handle the burstiness given by the ACK aggregation = but it seems like this is not the case.

Is there a limitation in the Linux stac= k that prevents congestion window growth when ACKs arrive in bursts like th= is ?

= =C2=A0

= /Ingemar

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

Ingema= r Johansson=C2=A0 M.Sc.

Master Researcher

=C2=A0

Ericsson Research

Network Protocols & E2E Perform= ance

La= bratoriegr=C3=A4nd 11

971 28, Lule=C3=A5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.jo= hansson@ericsson.com

www= .ericsson.com

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Nothing to stop this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 being the best day ever

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 U2=

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

=C2=A0

_______________________________________________<= /span>
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
--000000000000f6b74905876fbb50-- From nobody Fri Apr 26 18:39:57 2019 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 A4DA91200B2; Fri, 26 Apr 2019 18:39:47 -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.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <155632918763.6767.9854550028096422576@ietfa.amsl.com> Date: Fri, 26 Apr 2019 18:39:47 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-05.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: Sat, 27 Apr 2019 01:39:48 -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 : RACK: a time-based fast loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Priyaranjan Jha Filename : draft-ietf-tcpm-rack-05.txt Pages : 29 Date : 2019-04-26 Abstract: This document presents a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment"). RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option. It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-05 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 26 18:43:26 2019 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 BCDA5120372 for ; Fri, 26 Apr 2019 18:43:24 -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, HTML_MESSAGE=0.001, 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 Kcwec79Xz651 for ; Fri, 26 Apr 2019 18:43:22 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 2FF3D1201A0 for ; Fri, 26 Apr 2019 18:43:22 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id w15so6826095wmc.3 for ; Fri, 26 Apr 2019 18:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=T+8M1BFMCQWzDLwFZ44R60rQJeEfRIN4D3JiYm0DOlE=; b=ia08SDM7X2wea/tPx1mKrobI1zNh8mkowV52oqX0BN5uikqrmJg9MKH1URkAaZJBZP 6WB+P/RCDtFnP4ZBJ+cIEZn0jXcxKE3j2iLofh4xU9DdFcorGL6hBhAWRQJ5wzlR0D+Y ia8/cLC1VOn+Ad4t7H6JY1YSnrpkBP/VQWzEc0LTZGktkjHjBo/HhwUo0YfoccpCoEDk yrK+Nv+en1B95ELKq9SgHNl9tnGver1GPjwHmbFRiOu7ItfL5ULO5gKOVIfjQiK/LH7E U4XF8oysaCLffn2XWh1lhJMOIc+y0qh9ig7ZOZ2p/l0datwze2Mv1PadtjaflqfLI8QX j8eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=T+8M1BFMCQWzDLwFZ44R60rQJeEfRIN4D3JiYm0DOlE=; b=VpO19AEM+T4lzbJ0vqmERnNFS5SROojnqh8n/nO2Xo8ee/sPBUyzuFA4VN32cH1V2q afhlNqbottcVA7XwRVKrcDpJkUpriIaacZi+Y4PXhmPkAnzDAKHILAZ2rXxShC1aOgZb FHXG3zibiF2TZ6Nf9v0weKdo0nhBlTqWZZ+qZY4o7Zy4zo5P9oB80BHSyL2Pc7OBM6kX YZkrIqqCOJ3kXC9+iu8G+lJ2rAILLvwFwQUBOmZNcXkdMRbAq/Tg+z7/gvoO4iePwMvD tkE7wjN1rehGdSocMdcHcSuz1+uARrXI9lsmhwEk6Jdxm7vlBH9U89+5qwUSLHFop2Du vJAg== X-Gm-Message-State: APjAAAVE8rhTvnoV+/Wl0RSH4fDNm+9oaNhyvuMPKVvuceA/NWusshh8 rO/DT8uucgN2oYrDG27e2gj4frl2PGns0FRBVsX4sg== X-Google-Smtp-Source: APXvYqzAToG75407NP9OpZm1qdjJLtbfbYoNlvWkg4MlxEGplAYdLaARlQ3P5nNMKbNAt1qBBtnH5t8tuGrpcozETgI= X-Received: by 2002:a1c:81cc:: with SMTP id c195mr9742248wmd.61.1556329400094; Fri, 26 Apr 2019 18:43:20 -0700 (PDT) MIME-Version: 1.0 References: <155632918775.6767.10665022766872955742.idtracker@ietfa.amsl.com> In-Reply-To: <155632918775.6767.10665022766872955742.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Fri, 26 Apr 2019 18:42:43 -0700 Message-ID: To: tcpm-chairs@ietf.org, "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000000c80080587792dac" Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rack-05.txt 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: Sat, 27 Apr 2019 01:43:25 -0000 --0000000000000c80080587792dac Content-Type: text/plain; charset="UTF-8" Hi we are posting new draft per chairs' request for discussion on status. 04-05 diffs are minor edits for clarification raised by many reviewers (thanks!). No changes to algorithm / protocol. ---------- Forwarded message --------- From: Date: Fri, Apr 26, 2019 at 6:39 PM Subject: New Version Notification for draft-ietf-tcpm-rack-05.txt To: Neal Cardwell , Yuchung Cheng , Priyaranjan Jha , Nandita Dukkipati < nanditad@google.com> A new version of I-D, draft-ietf-tcpm-rack-05.txt has been successfully submitted by Yuchung Cheng and posted to the IETF repository. Name: draft-ietf-tcpm-rack Revision: 05 Title: RACK: a time-based fast loss detection algorithm for TCP Document date: 2019-04-26 Group: tcpm Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rack-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-05 Abstract: This document presents a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment"). RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option. It is intended to replace the conventional DUPACK threshold approach and its variants, as well as other nonstandard approaches. 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. The IETF Secretariat --0000000000000c80080587792dac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi we are posting new draft per chairs' request for di= scussion on status.

04-05 diffs are minor edits for clar= ification raised by many reviewers (thanks!). No changes to algorithm / pro= tocol.

---------- Forwarded message ---------
From: <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org>
Date: Fri, Apr 26, 2019 at 6:39 PM
Subject:= New Version Notification for draft-ietf-tcpm-rack-05.txt
To: Neal Cardw= ell <ncardwell= @google.com>, Yuchung Cheng <ycheng@google.com>, Priyaranjan Jha <priyarjha@google.com= >, Nandita Dukkipati <nanditad@google.com>



A new version of I-D, draft-ietf-tcpm-rack-05.txt
has been successfully submitted by Yuchung Cheng and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tcpm-rack
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RACK: a time-based fast loss detec= tion algorithm for TCP
Document date:=C2=A0 2019-04-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 29
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-05.tx= t
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-tcpm-rack-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-05

Abstract:
=C2=A0 =C2=A0This document presents a new TCP loss detection algorithm call= ed RACK
=C2=A0 =C2=A0("Recent ACKnowledgment").=C2=A0 RACK uses the notio= n of time, instead of
=C2=A0 =C2=A0packet or sequence counts, to detect losses, for modern TCP =C2=A0 =C2=A0implementations that can support per-packet timestamps and the=
=C2=A0 =C2=A0selective acknowledgment (SACK) option.=C2=A0 It is intended t= o replace
=C2=A0 =C2=A0the conventional DUPACK threshold approach and its variants, a= s well
=C2=A0 =C2=A0as other nonstandard approaches.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--0000000000000c80080587792dac-- From nobody Mon Apr 29 22:44:23 2019 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 05C2E120108 for ; Mon, 29 Apr 2019 22:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 BOQg-8RoGWPT for ; Mon, 29 Apr 2019 22:44:18 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10082.outbound.protection.outlook.com [40.107.1.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C905120110 for ; Mon, 29 Apr 2019 22:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rpBWNBrwwO9RMHLxdUpgsjakjmAYd62iVlA9EoThrHI=; b=NIKLDkggZIq8wZh8+P69Z3F5yb4y9oK6hcUbfvk55sJPF7UaDshb4JKTrlizN+7uzTCaesoeB0CKiszCWq0qDkl5rqvurds63+T3uYQkrlZEaT+0pGIGVZChs/OyiSF02kOD2G3GNvrhlKhc7mDflBzakZoKbRZU3dBgLjnz1ew= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB4220.eurprd07.prod.outlook.com (20.176.166.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.8; Tue, 30 Apr 2019 05:44:14 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::6944:b95e:c64a:6a35]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::6944:b95e:c64a:6a35%5]) with mapi id 15.20.1856.008; Tue, 30 Apr 2019 05:44:14 +0000 From: Ingemar Johansson S To: Rick Jones CC: "tcpm@ietf.org" , Ingemar Johansson S Thread-Topic: [tcpm] ACK aggregation and congestion window growth Thread-Index: AdT8NTrQyrmIo4MtTwOc3MNifKi5sAAA4qIAALefejA= Date: Tue, 30 Apr 2019 05:44:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [83.226.2.151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c159f6db-8d9e-4d64-8c18-08d6cd2ee0cd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4220; x-ms-traffictypediagnostic: HE1PR07MB4220: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:294; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(346002)(366004)(39860400002)(199004)(189003)(4326008)(256004)(76176011)(97736004)(66066001)(33656002)(55016002)(52536014)(99286004)(66574012)(54906003)(316002)(606006)(25786009)(99936001)(66556008)(64756008)(66946007)(66446008)(66476007)(66616009)(73956011)(76116006)(6306002)(54896002)(9686003)(236005)(7696005)(5660300002)(107886003)(6246003)(53386004)(53936002)(6506007)(6116002)(486006)(790700001)(3846002)(71190400001)(71200400001)(446003)(53546011)(6916009)(11346002)(476003)(74316002)(7736002)(8676002)(186003)(229853002)(102836004)(2906002)(86362001)(26005)(81166006)(81156014)(14454004)(966005)(478600001)(6436002)(8936002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4220; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tZDvcVebK+w1rHPQEB7uybNnaNF5N1I5X1idU9NqZG+ofInbOYF6PRLoDP5Q08AcBp+WgDcWupc5+68tgK+1CvdEYSnZuatqPK8Gtjh2tjCvWKRg9jpCMRxZVFkjuxf2D8Fx8llI0xriIrXVnUfuPFrwPwfwcpilQMe5X0d2cIJFd9M0tN1+ffvOFHM6zfV/SqCvqJCdO4GqdCvCllpY4Hiin2U8cM1k734MXcUh4HLWvWnmJv2OJUOybn2Szt56MzqEJgT5TwjIlf0PXbZonMOU8xZBQ5FbwOxgDIAiEbMAKAFUjhVuEVMlJA7VCMkJSs5zFAg3Q4+Opi876zl3ojoWIobP1u4myMV7uwVzIQeNE7PiU0hSRNT7KN7PZZl51YqzNAWOaJvz7KdLBssvVGl0N663NGwR3rCsVD0R8Co= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02BB_01D4FF28.804F91A0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c159f6db-8d9e-4d64-8c18-08d6cd2ee0cd X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 05:44:14.1821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4220 Archived-At: Subject: Re: [tcpm] ACK aggregation and congestion window growth 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, 30 Apr 2019 05:44:21 -0000 ------=_NextPart_000_02BB_01D4FF28.804F91A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02BC_01D4FF28.804F91A0" ------=_NextPart_001_02BC_01D4FF28.804F91A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi =20 No the ACK aggregator does not delay the 3WHS, I guess this can cause = Cubic to exit slow start. Still I would expect that CWND would = eventually increase, even in congestion avoidance. =20 Regards /Ingemar =20 From: Rick Jones =20 Sent: den 26 april 2019 16:03 To: Ingemar Johansson S Cc: tcpm@ietf.org Subject: Re: [tcpm] ACK aggregation and congestion window growth =20 Does your ACK aggregator also delay the ACKs of SYNchronize segments? If = not, perhaps the congestion control sees the increase (?) in round trip = time after connection establishment as a signal of congestion and = behaves accordingly.=20 On Apr 26, 2019, at 06:46, Ingemar Johansson S = > wrote: Hi =20 I am experimenting with a simple test setup with 2 Ubuntu 18.04 PCs = (Cubic CC).=20 Between these two I have a simple setup that aggregates ACKs so that = they are forwarded to the server only every 10ms. The min RTT is 18ms.=20 The problem I see is that even though I should reach 1Gbps throughput, I = only get around 200Mbps.=20 I would believe that the congestion window should eventually increase = enough to handle the burstiness given by the ACK aggregation but it = seems like this is not the case.=20 Is there a limitation in the Linux stack that prevents congestion window = growth when ACKs arrive in bursts like this ?=20 =20 /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc.=20 Master Researcher =20 Ericsson Research Network Protocols & E2E Performance Labratoriegr=C3=A4nd 11 971 28, Lule=C3=A5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com = =20 www.ericsson.com =20 =20 Nothing to stop this being the best day ever U2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 _______________________________________________ tcpm mailing list tcpm@ietf.org =20 https://www.ietf.org/mailman/listinfo/tcpm ------=_NextPart_001_02BC_01D4FF28.804F91A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi

 

No the ACK aggregator does not delay the 3WHS, I guess this = can cause Cubic to exit slow start. Still I would expect that CWND would = eventually increase, even in congestion = avoidance.

 

Regards

/Ingemar

 

From: Rick Jones = <perfgeek@mac.com>
Sent: den 26 april 2019 = 16:03
To: Ingemar Johansson S = <ingemar.s.johansson@ericsson.com>
Cc: = tcpm@ietf.org
Subject: Re: [tcpm] ACK aggregation and = congestion window growth

 

Does = your ACK aggregator also delay the ACKs of SYNchronize segments? If not, = perhaps the congestion control sees the increase (?) in round trip time = after connection establishment as a signal of congestion and behaves = accordingly. 


On Apr 26, 2019, at = 06:46, Ingemar Johansson S <ingemar.s.johansson@eric= sson.com> wrote:

Hi

 

I am experimenting with a simple test setup with 2 Ubuntu = 18.04 PCs (Cubic CC).

Between these two I have a simple setup that aggregates = ACKs so that they are forwarded to the server only every 10ms. The min = RTT is 18ms.

The problem I see is that even though I should reach 1Gbps = throughput, I only get around 200Mbps.

I would believe that the congestion = window should eventually increase enough to handle the burstiness given = by the ACK aggregation but it seems like this is not the case. =

Is there a = limitation in the Linux stack that prevents congestion window growth = when ACKs arrive in bursts like this ?

 

/Ingemar

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

Ingemar Johansson  M.Sc. =

Master = Researcher

 

Ericsson = Research

Network Protocols & E2E = Performance

Labratoriegr=C3=A4nd = 11

971 28, Lule=C3=A5, = Sweden

Phone +46-1071 = 43042

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@eric= sson.com

www.ericsson.com

 

      &nb= sp;         Nothing to stop = this

      &nb= sp;      being the best day = ever

      &nb= sp;           &nbs= p;         = U2

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

 

_______________________________________= ________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/= mailman/listinfo/tcpm

<= /div> ------=_NextPart_001_02BC_01D4FF28.804F91A0-- ------=_NextPart_000_02BB_01D4FF28.804F91A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3 MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J 0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9 7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP 9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6 Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8 TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3 OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO 30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3 0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5 S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT 05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT 9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx 5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+ i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xOTA0MzAwNTQ0MTFaMCMGCSqGSIb3DQEJBDEWBBSfXioPZ5IHBxfZt69e Si8FnfvoJjBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAFgypWeoB8VSaXoOc8HW9FpTI1qqwZuQrFJONyyX sbNhdvm+VDGz42Bt/ANrAOUCcXKRbew1PmI0ZkyZZNdq4D+rfo3/oMvcuXmt+CiUnrSUM3iOBPOL RzzfLdEQQWVXBU34+gOw/bkQDPivsXxYPwzFUVXhHSviXpwU2S4cXyEvFOPN+XjN/kRQP63vKoQk zOcDrDgi1ZWxg3LJd03kiP7J2QZuHbQLvxVka5w/1hnkFKAAenC+fQmj9lyUQVJ13mE60+JgeTKj byk0ZjpC6dCJn+xFOLjX1JbVHd+xwNn0CLhE4GtSYpPwTulL/bDV04RcVp2QeLtOWyIIeKKeIacA AAAAAAA= ------=_NextPart_000_02BB_01D4FF28.804F91A0-- From nobody Tue Apr 30 00:31:15 2019 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 7A6D012021B for ; Tue, 30 Apr 2019 00:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 PXxxNzGQxHar for ; Tue, 30 Apr 2019 00:31:08 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80085.outbound.protection.outlook.com [40.107.8.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA998120225 for ; Tue, 30 Apr 2019 00:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vvJRJyeTb/TLYHRuifW44m1TzO+Jp3t0eGzqf/tiOBM=; b=LPOKI79SgqDvPPNRZtDDyLegS/GnXh7XFjMoEcNKFHhax/mZblTy1QhdB9UBAtqTM9fL4qoBQ718qjhaVgLMG1X/uL/oOiTqA+3w/x71H5+jYce0NozgEiiHD+djlWdiOjujuPT9f7uYljPXoeONHLW3ESBicsnqGGn9V7JK2yI= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB4249.eurprd07.prod.outlook.com (20.176.166.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.7; Tue, 30 Apr 2019 07:31:04 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::6944:b95e:c64a:6a35]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::6944:b95e:c64a:6a35%5]) with mapi id 15.20.1856.008; Tue, 30 Apr 2019 07:31:04 +0000 From: Ingemar Johansson S To: Neal Cardwell CC: "tcpm@ietf.org" , Yuchung Cheng , Eric Dumazet , Rick Jones , Ingemar Johansson S Thread-Topic: [tcpm] ACK aggregation and congestion window growth Thread-Index: AdT8NTrQyrmIo4MtTwOc3MNifKi5sAAA4qIAAADXLAAAt096MA== Date: Tue, 30 Apr 2019 07:31:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 68c68628-f080-41d5-65eb-08d6cd3dcd8b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4249; x-ms-traffictypediagnostic: HE1PR07MB4249: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1122; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(346002)(136003)(39860400002)(51914003)(189003)(199004)(186003)(6916009)(99286004)(66066001)(68736007)(2906002)(26005)(606006)(53936002)(6246003)(7696005)(8936002)(81156014)(54896002)(6306002)(76176011)(81166006)(107886003)(53386004)(86362001)(8676002)(9686003)(54906003)(102836004)(236005)(486006)(316002)(476003)(966005)(4326008)(7736002)(256004)(53546011)(71190400001)(66574012)(14444005)(99936001)(6506007)(55016002)(229853002)(52536014)(71200400001)(6116002)(790700001)(74316002)(97736004)(6436002)(25786009)(3846002)(14454004)(73956011)(76116006)(66446008)(66946007)(5660300002)(11346002)(478600001)(66476007)(66616009)(446003)(66556008)(64756008)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4249; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uXgUZeTztwRvfk1oTRc8BRVj6ZB6hkICmohBFcShw96VIUR6bAIR865XkQcmkF4wg/j8bwBQtkQdqEQeLE/C7ncr9WZgkjmgw+U1Xxt+tKWLf0P6qT6M6Q96sEXll+pFdizFwJ5bIzn/tPlYa8ZPK7y61TGbikHPRCb/K2CXhr5AJgPSspD2YYjxaXr9fKTtl22cRsbZM098JwHG08v5tzGyqbZQx8NWYN5uqrbALH9APdpnF9Trso+kDRKuYhEmumfhHZUBBqsEFKJ4nSKwFNs2PLicgwzkGrybffMyXsFQK/ULA8rrbjDlgTNQnFiypIxTFBivYwNgkh0KV9rQ0g1Ntk+3Lxmf1ni9J8dSYiX94m966ISyByQbOTqOh8UU4q7MId2VnaH7rwlws+nFElRJdZnmEY/XAKb4kF/wFqw= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004A_01D4FF37.6D4130A0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68c68628-f080-41d5-65eb-08d6cd3dcd8b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 07:31:04.3078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4249 Archived-At: Subject: Re: [tcpm] ACK aggregation and congestion window growth 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, 30 Apr 2019 07:31:14 -0000 ------=_NextPart_000_004A_01D4FF37.6D4130A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004B_01D4FF37.6D4130A0" ------=_NextPart_001_004B_01D4FF37.6D4130A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi =20 Thanks for the hints. I will try and fix some wireshark logs, seems = though that this issue is a bit transient and admittedly it works more = often than it does not. This is perhaps a corner case ? =20 /Ingemar=20 =20 From: Neal Cardwell =20 Sent: den 26 april 2019 16:27 To: Ingemar Johansson S Cc: tcpm@ietf.org; Yuchung Cheng ; Eric Dumazet = ; Rick Jones Subject: Re: [tcpm] ACK aggregation and congestion window growth =20 Hi Ingemar, =20 Thanks for the report. From the description of the issue, I suspect = there is some combination of the following: =20 (1) This may be related to some buggy behavior in the Linux TCP logic = for assessing whether a connection is cwnd-limited or = application-limited. In the scenario you describe, with those high = speeds and long gaps between ACKs, it sounds like the flow may have cwnd = that is unused due to to TSO deferral, and this may be causing the logic = to erroneously mark the flow as not being cwnd-limited, which would = prevent cwnd growth by CUBIC. =20 (2) If there are entire flights of data that are ACKed with a single = ACK, then the CUBIC code may assess the long gaps between transmits and = ACKs as an idle period, and erroneously push its epoch_start forward to = skip any cwnd growth that would have been slated for that period. =20 (I would guess (1) is more likely, since the Reno emulation code path in = CUBIC should not be affected by (2), so CUBIC should eventually grow = cwnd in a Reno-style fashion whether or not it hits (2).) =20 We can provide some proposed patches for those issues. Would you be able = to apply the patches and test them in your workload? If so, what exact = kernel version would the patches need to be generated for? =20 Also, would you be able to post (suitably anonymized, heads-only) = tcpdump packet traces so that we can see what the exact scenario is? = This would be particularly useful if you are unable to apply the patches = to verify the fix. =20 thanks, neal =20 =20 =20 =20 =20 On Fri, Apr 26, 2019 at 10:03 AM Rick Jones 40mac.com@dmarc.ietf.org> wrote: Does your ACK aggregator also delay the ACKs of SYNchronize segments? If = not, perhaps the congestion control sees the increase (?) in round trip = time after connection establishment as a signal of congestion and = behaves accordingly.=20 On Apr 26, 2019, at 06:46, Ingemar Johansson S < = = ingemar.s.johansson@ericsson.com> wrote: Hi =20 I am experimenting with a simple test setup with 2 Ubuntu 18.04 PCs = (Cubic CC).=20 Between these two I have a simple setup that aggregates ACKs so that = they are forwarded to the server only every 10ms. The min RTT is 18ms.=20 The problem I see is that even though I should reach 1Gbps throughput, I = only get around 200Mbps.=20 I would believe that the congestion window should eventually increase = enough to handle the burstiness given by the ACK aggregation but it = seems like this is not the case.=20 Is there a limitation in the Linux stack that prevents congestion window = growth when ACKs arrive in bursts like this ?=20 =20 /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc.=20 Master Researcher =20 Ericsson Research Network Protocols & E2E Performance Labratoriegr=C3=A4nd 11 971 28, Lule=C3=A5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 = ingemar.s.johansson@ericsson.com www.ericsson.com =20 Nothing to stop this being the best day ever U2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 _______________________________________________ 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 ------=_NextPart_001_004B_01D4FF37.6D4130A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi

 

Thanks for the hints. I will try = and fix some wireshark logs, seems though that this issue is a bit = transient and admittedly it works more often than it does not. This is = perhaps a corner case ?

 

/Ingemar

 

From: Neal Cardwell = <ncardwell@google.com>
Sent: den 26 april 2019 = 16:27
To: Ingemar Johansson S = <ingemar.s.johansson@ericsson.com>
Cc: tcpm@ietf.org; = Yuchung Cheng <ycheng@google.com>; Eric Dumazet = <edumazet@google.com>; Rick Jones = <perfgeek=3D40mac.com@dmarc.ietf.org>
Subject: Re: = [tcpm] ACK aggregation and congestion window = growth

 

Hi = Ingemar,

 

Thanks for the report. From the = description of the issue, I suspect there is some combination of the = following:

 

(1) This may be related to some = buggy behavior in the Linux TCP logic for assessing whether a = connection is cwnd-limited or application-limited. In the scenario you = describe, with those high speeds and long gaps between ACKs, it sounds = like the flow may have cwnd that is unused due to to TSO deferral, and = this may be causing the logic to erroneously mark the flow as not being = cwnd-limited, which would prevent cwnd growth by = CUBIC.

 

(2) If there are entire flights of = data that are ACKed with a single ACK, then the CUBIC code may assess = the long gaps between transmits and ACKs as an idle period, and = erroneously push its epoch_start forward to skip any cwnd growth that = would have been slated for that = period.

 

(I would guess (1) is more likely, = since the Reno emulation code path in CUBIC should not be = affected by (2), so CUBIC should eventually grow cwnd in a = Reno-style fashion whether or not it hits = (2).)

 

We can provide some proposed = patches for those issues. Would you be able to apply the patches and = test them in your workload?  If so, what exact kernel version would = the patches need to be generated for?

 

Also, would you be able to post = (suitably anonymized, heads-only) tcpdump packet traces so that we can = see what the exact scenario is? This would be particularly useful if you = are unable to apply the patches to verify the = fix.

 

thanks,

neal

 

 

 

 

 

On Fri, Apr 26, 2019 at 10:03 AM = Rick Jones <perfgeek=3D40mac.com@dmarc.ietf.org> = wrote:

Does your ACK = aggregator also delay the ACKs of SYNchronize segments? If not, perhaps = the congestion control sees the increase (?) in round trip time after = connection establishment as a signal of congestion and behaves = accordingly. 


On Apr 26, 2019, = at 06:46, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi

 

I am experimenting with a simple test setup with 2 Ubuntu = 18.04 PCs (Cubic CC).

Between these two I have a simple setup that aggregates = ACKs so that they are forwarded to the server only every 10ms. The min = RTT is 18ms.

The problem I see is that even though I should reach 1Gbps = throughput, I only get around 200Mbps.

I would believe that the congestion window should = eventually increase enough to handle the burstiness given by the ACK = aggregation but it seems like this is not the case. =

Is there a limitation in the Linux stack that prevents = congestion window growth when ACKs arrive in bursts like this ? =

 

/Ingemar

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

Ingemar = Johansson  M.Sc.

Master Researcher

 

Ericsson Research

Network Protocols & E2E = Performance

Labratoriegr=C3=A4nd 11

971 28, Lule=C3=A5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

          =       Nothing to stop = this

          =    being the best day ever

          =             &= nbsp;     U2

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

 

_______________________________________________
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

= ------=_NextPart_001_004B_01D4FF37.6D4130A0-- ------=_NextPart_000_004A_01D4FF37.6D4130A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3 MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J 0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9 7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP 9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6 Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8 TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3 OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO 30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3 0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5 S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT 05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT 9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx 5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+ i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xOTA0MzAwNzMxMDJaMCMGCSqGSIb3DQEJBDEWBBSmO3JOX+LfwRXaPeyf ZHJfGiPoOzBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAFTKYUw/Ao13p4bHv/Pad3Dp7JV4u5cJOop6l8Ay eXtKzQ55UPn3dcEItgzre1FeA2OkMkx3j9ERvlvQZCjo32Re7hU+fO5jyrdN5abLWIfHC1CxjFHR SBXK+ENvYPE4pMMHQGybpbS5Pjhtsva8tQsCd2rkaFQV22fOXkMpeDM8katec/jKy0oHL+ITF87F SANENV/EZkEL2GVjLVwU+yC1DzjspwZDatpdp+GBsyeS95PY8bz/qAf01cpBpUmvgc1XeyllJ6Eg I8SvT+l7/ZbIeGO2837NTLRcLajgYV4FMEWtp+phM8DeWlDiD3ptdo3vEhJoXgqFdqdcrA7liLoA AAAAAAA= ------=_NextPart_000_004A_01D4FF37.6D4130A0-- From nobody Tue Apr 30 12:39:18 2019 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 5169712034E for ; Tue, 30 Apr 2019 12:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, HTML_MESSAGE=0.001, 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=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 uKT8LdoVG7Y0 for ; Tue, 30 Apr 2019 12:39:13 -0700 (PDT) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 3F846120352 for ; Tue, 30 Apr 2019 12:39:13 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id t81so12243890oig.10 for ; Tue, 30 Apr 2019 12:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7QasW59vHynfofoNAIoWC6dUvrmLXFP75ucTgrBx3s8=; b=bSm9AUHuIoPj3xDU3Ytryy9nVtqNBuQARhlKXPH8+BnK8ZjsxhyS3ftM/xtI2/2RiI roEwUVP3RDe8pzhHjDDsKHupZnPCJJJMRrFWVgwYoGS6yTIDXh1qoY9k9C4PswW4G2Of RhlJSN+Z17LzjQnM2irlJdcDG13sPj66dgBzLRgoRGP24dmsgE77iijX30PBTE9jiVwp rk+ChBtyrVVq51waaRchNvbegW50BiHKkSvPw72CNN+7whX+zIMn8YOt0rAQFuUGIlDv y8jS83MxgFz+d/9PrzMOnFFRg15U+FQ7fBgpUc+GhUuxcT6Up0oatEH7GRrpvl/kzL1Z 2j7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7QasW59vHynfofoNAIoWC6dUvrmLXFP75ucTgrBx3s8=; b=nuMKtxrcTpmp3AIA+9uhG/MdrrdLc4Hm4wVCBLCMyNaVpzR8yUfuOQm6/BHhUA1g4K 7pEgoL19e4Xok/oLmn3O5XFi9DdXfd3axJDMdPinLokaoTwJ7xzVdSJEfXy9q1gY/13X V4RcmyIcBMxkwgPwHqvCwoVlm2zh92wXoBtM4kFI1sqaL/boiKyCU0Y3RhX7kyHPNWFL 368B87dqWmgM3vd1KWMzNHXLvNybl5yepHYL69l99vcn8qoryhHVKU0GwpRRYEUpZeW/ axhqR4CraU/hxb2VgafHtdmvEhCkByb/nfKEed/uaDclwbVNVfqRe+8cLqnCpOCTgoIF ONIA== X-Gm-Message-State: APjAAAWkN9ggXjq+9RzE6dK6NJXsXesnPtCsdD7WPAbA3uoIR78/8x7L 5eeLMAUqUT7h8hndeEdRGKYv4/GA9CI0COcS12i3iw== X-Google-Smtp-Source: APXvYqy42t74BJObC1P6zYTP0KjS3Ng1UQiSMa3w3MD3F5hnmkeKPNR8H9pKMMJyIL7kE9pwst03wAMuC4chITGsn8U= X-Received: by 2002:aca:5c55:: with SMTP id q82mr4111549oib.95.1556653152182; Tue, 30 Apr 2019 12:39:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Tue, 30 Apr 2019 15:38:54 -0400 Message-ID: To: Ingemar Johansson S Cc: "tcpm@ietf.org" , Yuchung Cheng , Eric Dumazet , Rick Jones Content-Type: multipart/alternative; boundary="0000000000002d37f60587c48eab" Archived-At: Subject: Re: [tcpm] ACK aggregation and congestion window growth 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, 30 Apr 2019 19:39:16 -0000 --0000000000002d37f60587c48eab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ingemar, Thanks. We'll see if we can reproduce this and fix it based on our working theory. We'll follow up on this thread if we end up posting a patch for Linux TCP. If you do happen to collect a trace that shows this problem, we would love to take a look. thanks, neal On Tue, Apr 30, 2019 at 3:31 AM Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > Thanks for the hints. I will try and fix some wireshark logs, seems thoug= h > that this issue is a bit transient and admittedly it works more often tha= n > it does not. This is perhaps a corner case ? > > > > /Ingemar > > > > *From:* Neal Cardwell > *Sent:* den 26 april 2019 16:27 > *To:* Ingemar Johansson S > *Cc:* tcpm@ietf.org; Yuchung Cheng ; Eric Dumazet < > edumazet@google.com>; Rick Jones > *Subject:* Re: [tcpm] ACK aggregation and congestion window growth > > > > Hi Ingemar, > > > > Thanks for the report. From the description of the issue, I suspect there > is some combination of the following: > > > > (1) This may be related to some buggy behavior in the Linux TCP logic for > assessing whether a connection is cwnd-limited or application-limited. In > the scenario you describe, with those high speeds and long gaps between > ACKs, it sounds like the flow may have cwnd that is unused due to to TSO > deferral, and this may be causing the logic to erroneously mark the flow = as > not being cwnd-limited, which would prevent cwnd growth by CUBIC. > > > > (2) If there are entire flights of data that are ACKed with a single ACK, > then the CUBIC code may assess the long gaps between transmits and ACKs a= s > an idle period, and erroneously push its epoch_start forward to skip any > cwnd growth that would have been slated for that period. > > > > (I would guess (1) is more likely, since the Reno emulation code path in > CUBIC should not be affected by (2), so CUBIC should eventually grow cwnd > in a Reno-style fashion whether or not it hits (2).) > > > > We can provide some proposed patches for those issues. Would you be able > to apply the patches and test them in your workload? If so, what exact > kernel version would the patches need to be generated for? > > > > Also, would you be able to post (suitably anonymized, heads-only) tcpdump > packet traces so that we can see what the exact scenario is? This would b= e > particularly useful if you are unable to apply the patches to verify the > fix. > > > > thanks, > > neal > > > > > > > > > > > > On Fri, Apr 26, 2019 at 10:03 AM Rick Jones 40mac.com@dmarc.ietf.org> wrote: > > Does your ACK aggregator also delay the ACKs of SYNchronize segments? If > not, perhaps the congestion control sees the increase (?) in round trip > time after connection establishment as a signal of congestion and behaves > accordingly. > > > On Apr 26, 2019, at 06:46, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > Hi > > > > I am experimenting with a simple test setup with 2 Ubuntu 18.04 PCs (Cubi= c > CC). > > Between these two I have a simple setup that aggregates ACKs so that they > are forwarded to the server only every 10ms. The min RTT is 18ms. > > The problem I see is that even though I should reach 1Gbps throughput, I > only get around 200Mbps. > > I would believe that the congestion window should eventually increase > enough to handle the burstiness given by the ACK aggregation but it seems > like this is not the case. > > Is there a limitation in the Linux stack that prevents congestion window > growth when ACKs arrive in bursts like this ? > > > > /Ingemar > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson Research > > Network Protocols & E2E Performance > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > Nothing to stop this > > being the best day ever > > U2 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > 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 > > --0000000000002d37f60587c48eab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ingemar,

Thanks. We'll see if we= can reproduce this and fix it based on our working theory. We'll follo= w up on this thread if we end up posting a patch for Linux TCP. If you do h= appen to collect a trace that shows this problem, we would love to take a l= ook.

thanks,
neal


On= Tue, Apr 30, 2019 at 3:31 AM Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wro= te:

Hi

=C2=A0

Thanks for the hints. I will try and fix some wir= eshark logs, seems though that this issue is a bit transient and admittedly= it works more often than it does not. This is perhaps a corner case ?

=C2= =A0

/Ingemar <= u>

= =C2=A0

=

= From: Neal Cardwell= <ncardwell@go= ogle.com>
Sent: den 26 april 2019 16:27
To: Ing= emar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: tcpm@ietf.org; Yuchung C= heng <ycheng@goog= le.com>; Eric Dumazet <edumazet@google.com>; Rick Jones <perfgeek=3D40mac.com@dmarc.ie= tf.org>
Subject: Re: [tcpm] ACK aggregation and congestion= window growth

<= span lang=3D"EN-US">=C2=A0

Hi Ingemar,

=C2=A0

Thanks for the report. F= rom the description of the issue, I suspect there is some combination of th= e following:

=C2=A0

(1) This may be related to some buggy behavior = in the Linux TCP logic for assessing=C2=A0whether a connection is cwnd-limi= ted or application-limited. In the scenario you describe, with those high s= peeds and long gaps between ACKs, it sounds like the flow may have cwnd tha= t is unused due to to TSO deferral, and this may be causing the logic to er= roneously mark the flow as not being cwnd-limited, which would prevent cwnd= growth by CUBIC.

=C2=A0

(2) If there are entire flights of data th= at are ACKed with a single ACK, then the CUBIC code may assess the long gap= s between transmits and ACKs as an idle period, and erroneously push its ep= och_start forward to skip any cwnd growth that would have been slated for t= hat period.

=C2=A0

(I would guess (1) is more likely, since the Ren= o emulation code path in CUBIC should not be affected=C2=A0by (2), so CUBIC= should eventually grow cwnd in a Reno-style fashion whether or not it hits= (2).)

=C2=A0

We can provide some proposed patches for those issues= . Would you be able to apply the patches and test them in your workload?=C2= =A0 If so, what exact kernel version would the patches need to be generated= for?

=C2=A0

Also, would you be able to post (suitably anonymized,= heads-only) tcpdump packet traces so that we can see what the exact scenar= io is? This would be particularly useful if you are unable to apply the pat= ches to verify the fix.

=C2=A0

thanks,

neal

=C2=A0

<= /u>=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Apr 26, 2019 at 10:03= AM Rick Jones <perfgeek=3D40mac.com@dmarc.ietf.org> wrote:

Does your ACK a= ggregator also delay the ACKs of SYNchronize segments? If not, perhaps the = congestion control sees the increase (?) in round trip time after connectio= n establishment as a signal of congestion and behaves accordingly.=C2=A0=


On Apr 26, 2019, at 06:46, Ingemar Johan= sson S <ingemar.s.johansson@ericsson.com> wrote:

Hi

<= span lang=3D"EN-US">=C2=A0

<= span lang=3D"EN-US">I am experimenting with a simple test setup with 2 Ubun= tu 18.04 PCs (Cubic CC).

Between these two I have a simple setup that aggregates = ACKs so that they are forwarded to the server only every 10ms. The min RTT = is 18ms.

The problem I see is that even though I should reach 1Gbps throughput, I= only get around 200Mbps.

<= span lang=3D"EN-US">I would believe that the congestion window should event= ually increase enough to handle the burstiness given by the ACK aggregation= but it seems like this is not the case.

Is there a limitation in the Linux stac= k that prevents congestion window growth when ACKs arrive in bursts like th= is ?

= =C2=A0

/Ingemar

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

=

Ingemar Johansson=C2=A0 M.Sc.

Master Researcher

=C2=A0

Ericsson Research=

Network Proto= cols & E2E Performance

<= span lang=3D"EN-US">Labratoriegr=C3=A4nd 11

971 28, Lule=C3=A5, Sweden

Phone +46-1071 430= 42

SMS/= MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com=

www.ericsson.com=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Nothing to stop this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 being the best day ever

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 U2=

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

=C2=A0

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

=

_______________________________= ________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/l= istinfo/tcpm

--0000000000002d37f60587c48eab--