From nobody Fri May 1 01:56:46 2020 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 1A2FA3A0CBB for ; Fri, 1 May 2020 01:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qa7x4zC1L5o for ; Fri, 1 May 2020 01:56:42 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 223E83A0CB9 for ; Fri, 1 May 2020 01:56:41 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0418uVWT057668; Fri, 1 May 2020 10:56:32 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id A64241D53C1; Fri, 1 May 2020 10:56:30 +0200 (CEST) Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Fri, 1 May 2020 10:56:31 +0200 Message-ID: <23157b5e4063646449099e97eccde0f3.squirrel@webmail.entel.upc.edu> In-Reply-To: References: Date: Fri, 1 May 2020 10:56:31 +0200 From: "Carles Gomez Montenegro" To: "Yuchung Cheng" Cc: jon.crowcroft@cl.cam.ac.uk, "tcpm@ietf.org Extensions" , "Neal Cardwell" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at dash X-Virus-Status: Clean X-Greylist: Delayed for 72:04:10 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 01 May 2020 10:56:32 +0200 (CEST) Archived-At: Subject: Re: [tcpm] question regarding draft-gomez-tcpm-delack-suppr-reqs 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, 01 May 2020 08:56:44 -0000 Dear Yuchung, Thanks for your questions and comments. Please find below my inline responses: > thanks for the talk! > > https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-01#section-3.1 > "Note that, while Appropriate Byte Counting (ABC) [RFC3465] might be used > to address this problem, it remains as an experimental mechanism, not > fully included in RFC 5681, which specifies standard TCP congestion > control. " > > It's not clear what "fully included" means here. AFAICT, RFC5681 > includes the essence of ABC explicitly. > > https://tools.ietf.org/html/rfc5681#section-3.1 > > " During slow start, a TCP increments cwnd by at most SMSS bytes for > each ACK received that cumulatively acknowledges new data. Slow > start ends when cwnd exceeds ssthresh (or, optionally, when it > reaches it, as noted above) or when congestion is observed. While > traditionally TCP implementations have increased cwnd by precisely > SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND > that TCP implementations increase cwnd, per: > > cwnd += min (N, SMSS) (2) > > where N is the number of previously unacknowledged bytes acknowledged > in the incoming ACK. This adjustment is part of Appropriate Byte > Counting [RFC3465] and provides robustness against misbehaving > receivers that may attempt to induce a sender to artificially inflate > cwnd using a mechanism known as "ACK Division" [SCWA99]. ACK > Division consists of a receiver sending multiple ACKs for a single > TCP data segment, each acknowledging only a portion of its data. A > TCP that increments cwnd by SMSS for each such ACK will > inappropriately inflate the amount of data injected into the network." Note that the problem pointed out is that, as stated in the RFC 5681 text above: "During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges new data" It may be desirable to support, during slow start, a cwnd increase by more than SMSS per each ACK acknowledging new data. In fact, couple of paragraphs later, RFC 5681 explicitly indicates the following: "We note that [RFC3465] allows for cwnd increases of more than SMSS bytes for incoming acknowledgments during slow start on an experimental basis; however, such behavior is not allowed as part of the standard." That is what we meant by "not fully included in RFC 5681" in our document. > As a side note, Linux stack has implemented the principle of abc in > its congestion control (including slow start) Thanks for the information. Yes, in fact, I second the WG members who stated on the chat, during the interim, that it is surprising that ABC remains as an experimental document. I realize that, at an implementation level, the problem pointed out above is being addressed in many platforms. > regarding delayed ACK harming slow-start or latency, I am not too sure > either: > > 1) The ACK is delayed but not the data > > 2) The delay of the ACK can indeed delay cwnd growth during slowstart. > > But the ACK is delayed because the packet is likely a sub-MSS data, > which is again likely caused by application limit (i.e. the > application has sent all its data like a HTTP response). In this case > the delay of the cwnd growth does not hurt the performance since the > application has no data left to send. > > The only penalty occurs when the application has more data to send > but cwnd is still gated by the arrival of the delayed ACK. However, in > many request - response protocol, either the (non-delayed) ACKs > triggered by prior full-MSS data inflight or the delayed ACKs would > have returned to grow the cwnd to sending immediately. > > I can construct scenarios where delayed ACK significantly hurts > application. But I don't think the scenario is too common. I will > suggest more tests to quantify the effect of delayed ACK effect on > slow-start. Yes, I tend to agree. In fact, the two main problems due to Delayed ACKs that we identified so far in the area of slow start are: - The fact that ABC might not always be supported (due to its "Experimental" status). - Precluding sender behaviors such as chirping. Once again, thanks for your valuable feedback! Cheers, Carles > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri May 1 02:51:33 2020 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 1ED823A0D83 for ; Fri, 1 May 2020 02:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 EeTrvo3OWvmo for ; Fri, 1 May 2020 02:51:29 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 241CA3A0D80 for ; Fri, 1 May 2020 02:51:28 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0419pJoJ008505; Fri, 1 May 2020 11:51:19 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id A39B61D53C1; Fri, 1 May 2020 11:51:18 +0200 (CEST) Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Fri, 1 May 2020 11:51:19 +0200 Message-ID: <4848dd0eef4ca96ac3a5076d287a324b.squirrel@webmail.entel.upc.edu> In-Reply-To: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> Date: Fri, 1 May 2020 11:51:19 +0200 From: "Carles Gomez Montenegro" To: "Scheffenegger, Richard" Cc: "tcpm@ietf.org" , "Gorry Fairhurst" , jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 01 May 2020 11:51:20 +0200 (CEST) Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 01 May 2020 09:51:31 -0000 Hi Richard, Thanks a lot for your detailed explanation, pointers and comments. Please find below my inline responses: > Hi, > > > as many here know, I'm very much interested in transactional data > exchange across TCP sessions, rather than the more common architectural > approach of assuming unlimited data to transmit unidirectional. > > One of the issues in that space is, that these application limited > sessions can very frequently run out of data, and expirience idle periods. > > Eliciting an ACK under certain circumstances, for a timely continuation > of the data transmission / growth of the congestion window is a known > method to reduce network delay. > > E.g. Linux has been using the CWR flag for the purpose of sending out an > immediate ACK by the receiver, since there is an increased chance of a > very small cwnd when the sender had just reduced it's congestion window. > > https://lore.kernel.org/patchwork/patch/970486/ > > and we also found latency improvements doing this when running > ECN-enabled sessions > > https://reviews.freebsd.org/D22670 > > There are also numerous advisories, suggesting to disable delayed ACK > completely when latency and/or timely bandwidth recovery under > adversarial conditions is a major driver (e.g. > https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/esxi7-nfs-read-perf.pdf > for one that was just published very recently). This is, all, very useful feedback! We plan to document the "ACK Pull" approach described above in our draft, and the associated rationale. Also, in our draft we currently mention that completely disabling delayed ACKs might not be a good solution, but as you mentioned, there may be environments where it may make sense to do so. We will add a note on this as well. > To summarize: While I agree that under steady load conditions, there are > probably some benefits to be had by TCP itself thinning out ACKs, and > address certain environment (e.g. asymetric link bandwidth), there are > also conditions, where a timely ACK is crucial in maintaining low > latency and timely bandwidth recovery. Short of having a mechansim do > explicitly do this, at least for the latter issue, TLP (or TLP-like) > methods are the only ones to currently address that - but the duplicate > unconditional transmission of a (small) data packet does have additional > cost associated with it. Thanks for the assessment of the need for ACK thinning and ACK Pull (depending on the considered scenario). Cheers, Carles > Best regards, > Richard > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri May 1 03:23:38 2020 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 AB1053A0E36 for ; Fri, 1 May 2020 03:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 efWcUoSrSsYv for ; Fri, 1 May 2020 03:23:33 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 937CD3A0E35 for ; Fri, 1 May 2020 03:23:32 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 041AMgVF003872; Fri, 1 May 2020 12:22:42 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 240DE1D53C1; Fri, 1 May 2020 12:22:41 +0200 (CEST) Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Fri, 1 May 2020 12:22:42 +0200 Message-ID: <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> Date: Fri, 1 May 2020 12:22:42 +0200 From: "Carles Gomez Montenegro" To: "Neal Cardwell" Cc: "Scheffenegger, Richard" , "tcpm@ietf.org" , "Gorry Fairhurst" , "Bob Briscoe" , jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at violet X-Virus-Status: Clean X-Greylist: Delayed for 01:26:10 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Fri, 01 May 2020 12:22:42 +0200 (CEST) Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 01 May 2020 10:23:36 -0000 Hi Neil, Thanks a lot for your comments! Please find below my inline responses: > On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard > wrote: >> Eliciting an ACK under certain circumstances, for a timely continuation >> of the data transmission / growth of the congestion window is a known >> method to reduce network delay. >> >> E.g. Linux has been using the CWR flag for the purpose of sending out an >> immediate ACK by the receiver, since there is an increased chance of a >> very small cwnd when the sender had just reduced it's congestion window. >> >> https://lore.kernel.org/patchwork/patch/970486/ >> >> and we also found latency improvements doing this when running >> ECN-enabled sessions >> >> https://reviews.freebsd.org/D22670 > > Yes, agreed. > > IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1 > case. (While this question is about the solution space, I'm anyway curious...) In the context of datacenter networks, would you have any suggestion or preference regarding the solutions that have been mentioned so far? Or perhaps any particular requirement for a potential solution? > In datacenter networks the BDPs tend to be so small, and the numbers > of flows can be so large, that it's not unusual for a flow's fair > share of the BDP to be one packet or less. If the flows want to > maintain low queuing delays, then ideally they would be able to reduce > their cwnd to 1 packet (or effectively even lower, with pacing). But > the current behavior of TCP delayed ACKs often causes terrible delays > with a cwnd of 1. This is very useful input to expand the current section 3.2 of our requirements draft, which focuses on high bit rate environments. > The Linux TCP approach of sending an immediate ACK upon receiving a > packet with CWR set (see Richard's link above) helps a lot with this > case. But that's a non-standard heuristic, and doesn't help for > senders that have a congestion control that does not use ECN CWR > signals (e.g. Accurate ECN). Unless I'm missing something, it seems > like endpoints using Accurate ECN are going to run into this same > latency issue. To avoid this, I guess they may want to either use a > cwnd >= 2, or make use of some new explicit ACK-pull mechanism. Agreed. Once again, thanks for your comments! Carles > best, > neal > From nobody Fri May 1 05:20:03 2020 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 D9D403A1141 for ; Fri, 1 May 2020 05:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 WMK-QXNzt6_6 for ; Fri, 1 May 2020 05:19:57 -0700 (PDT) Received: from mail-vk1-xa41.google.com (mail-vk1-xa41.google.com [IPv6:2607:f8b0:4864:20::a41]) (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 EDAFB3A113E for ; Fri, 1 May 2020 05:19:56 -0700 (PDT) Received: by mail-vk1-xa41.google.com with SMTP id w188so2655995vkf.0 for ; Fri, 01 May 2020 05:19:56 -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=dfQEX8UAVZXER136MM3zipAa0lSbQDrsbZWAiBJ+gF8=; b=ezg5zk7KlZ9vVOwJzATpCizzA9U9DiqKEuZVXe8UhVNYejdCJuLUhSzYvzrzcCbli6 gsBoZrOLzXAjd/3p8Wb54ktHR06pSM6NcuK4LMfYHaU00+nfexXGsL7JGdtyUEnE35c7 +7spe9q6ami9UtT07nue3YUo2mnDj7TXPN95Z0jATCQadk9G55OEw/sY82xAim82CtdO O7jnm13gte3/eWRSp6Te4Ybta4bKMn4QvV1j0J5oTFsY8gLy/kQD/GMjy85rptn2L4ld xNRad1IUZXfkgZDIgW+93UoWDzC5KRAaY2UZjuQQJSiC8pqb3odJHdtM70/oHJ6phzL4 uqGQ== 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=dfQEX8UAVZXER136MM3zipAa0lSbQDrsbZWAiBJ+gF8=; b=G2fO2bib/wTkHSoiIVtNzaK2qHhFjMEBBxTgpdkUCTwknVPAlj8AHFmCIXEqNdZL/l N/wXDBIN8Q89AfFL8VE/4Tlu+GusSgmJziKzvWJmG9B3Zj2ERoh97CRcznnVQGiazkgB uctDNDw7miiK4hoCO1Ec5Yf42iXQipWTKLd46G2Tbs61rdKe0tf1/BjcA02pAq+jw4IE 6QkF57uDxGwbS1ehoCELrNAbVnUtX9dk4l8d0bMMAincKkao6xGkM4YBcYczIjvHaUZp C3GRv7wcgKPfR39tgtizexUh10nJpEvIyKSaKsxYH0EhMxF4uVj8RH447o6G4w6X9qqc UQGw== X-Gm-Message-State: AGi0PuZfFsrA6+PmSW65i7uBOdPqQ+6su6bqG26yf8YK814oxyK3kO3r J7sdzG7IvHOSnm0NneYnu95UJ5RI/q7jMKrNOJO10w== X-Google-Smtp-Source: APiQypJqOqD54IOZDGw/14V9rlyveJX5Zzda7BCmdzvcyWvEP+DXEvDrPHsb3FpczAHZviqljFAsVJzOwwKzYRIVmJ0= X-Received: by 2002:a1f:5381:: with SMTP id h123mr2332382vkb.66.1588335595331; Fri, 01 May 2020 05:19:55 -0700 (PDT) MIME-Version: 1.0 References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> In-Reply-To: <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> From: Neal Cardwell Date: Fri, 1 May 2020 08:19:38 -0400 Message-ID: To: Carles Gomez Montenegro Cc: "Scheffenegger, Richard" , "tcpm@ietf.org" , Gorry Fairhurst , Bob Briscoe , jon.crowcroft@cl.cam.ac.uk Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 01 May 2020 12:20:00 -0000 On Fri, May 1, 2020 at 6:23 AM Carles Gomez Montenegro wrote: > > Hi Neil, > > Thanks a lot for your comments! > > Please find below my inline responses: > > > On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard > > wrote: > >> Eliciting an ACK under certain circumstances, for a timely continuation > >> of the data transmission / growth of the congestion window is a known > >> method to reduce network delay. > >> > >> E.g. Linux has been using the CWR flag for the purpose of sending out an > >> immediate ACK by the receiver, since there is an increased chance of a > >> very small cwnd when the sender had just reduced it's congestion window. > >> > >> https://lore.kernel.org/patchwork/patch/970486/ > >> > >> and we also found latency improvements doing this when running > >> ECN-enabled sessions > >> > >> https://reviews.freebsd.org/D22670 > > > > Yes, agreed. > > > > IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1 > > case. > > (While this question is about the solution space, I'm anyway curious...) > In the context of datacenter networks, would you have any suggestion or > preference regarding the solutions that have been mentioned so far? > > Or perhaps any particular requirement for a potential solution? Among the solutions outlined in https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00 my first preference would be the AKP option, since that approach avoids burning a precious flag bit. The AKP option may be stripped by some middleboxes, but (a) as a performance optimization, that should be acceptable, and (b) for the datacenter case (where cwnd=1 is a motivating use case) this should not be a concern. IMHO a flag bit makes sense for a small signal that a sender might want to send frequently or at a high rate, but senders should not be trying to force immediate ACKs frequently. best, neal From nobody Fri May 1 09:46:45 2020 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 90B6A3A1787 for ; Fri, 1 May 2020 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, 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=bobbriscoe.net 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 rVQohSqeMvS7 for ; Fri, 1 May 2020 09:46:38 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 279E33A1785 for ; Fri, 1 May 2020 09:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=+XvQNzTta6vH/kVfSRf4LzergL515zfQwq+3Mmy5heg=; b=h5UY6lZPHEZeNuO1SayOe6fai1 41+ZcVRff80OCU0+e77iGAlW8LlydsGCfk6xpuorMl+5trDCmUUNS01RqswiwieFPX/nIanhKnihj RxoEAKKoDeLbJu1r2mkgwPdl1xyyOpH67m0isLzN6WirrLRrOm53s2UkMJj52aW1yJY01Mvt49dCT fVFtEr+q4KywREN0jQPfUlAjYihjZy9aIfntxAHzgyMtRo6WVfOUqjWF5xTQiO+Nyx31sbiuiTfG5 5bt+orOU08PymEsa9E37R8eVjsGZ4vSARiUVmZPr5JNXTFi3Hcwtqf36BqKDPoOmmwq9AZGrLmh2H SiujNHnA==; Received: from [31.185.128.97] (port=46538 helo=[192.168.0.6]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jUYo8-00CRpl-1z; Fri, 01 May 2020 17:46:36 +0100 To: Gorry Fairhurst Cc: tcpm IETF list References: <8c3aca0d-0ea6-69f6-5ad8-fbdc984de77b@erg.abdn.ac.uk> <42a218f6-3d9d-25f1-9e00-476144b671fc@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Fri, 1 May 2020 17:46:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] A longer follow-up on my comment on draft-gomez-tcpm-delack-suppr-reqs 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, 01 May 2020 16:46:42 -0000 Gorry, On 30/04/2020 09:36, Gorry Fairhurst wrote: > See some more explanation in line. > > On 29/04/2020 22:58, Bob Briscoe wrote: >> Gorry, >> >> On 29/04/2020 18:54, Gorry Fairhurst wrote: >> >>> - DAASS is a simple fix, that appears to help a lot when there is >>> data waiting for the arrival of the delayed ACK. >> >> Any heuristic at the receiver to detect the end of a pattern of >> start-up such as slow-start, ossifies that pattern into the Internet. >> Sender control of the DelACK ratio removes that ossification. >> > I initially thought the same, DAASS tried to fix multiple problems. > However, as regards DAASS  reducing the waiti for the ACK to a rounds > of initial cwnd growth, I think the key understanding is the sender > use of byte accounting (for stretch-ACKs) not individual ACKs, (that > might imply a need for some burst-mitigation for stretch ACKs, because > you reduce ACK clocking). > > I like what I understand Chrome's QUIC does:  In the first 100 > received packets, send an ACK for each packet (could be each pair of > packets).  This rapidly grows a cwnd of about 140 packets (assuming > exponetial growth). Once the cwnd is >100 then an ACK covering 10 > packets/segments becomes a small proportion of the cwnd (the > additional delay from per-packet ACKs is small). The receiver can > moves to a larger default ACK ratio. [BB] If it's likely that we need to move beyond slow-start behaviour in future, building heuristics around slow-start is the worst possible step we could take. That's the ossification I'm talking about. When we implemented paced chirping, it was really hard not to confuse the heuristics in Linux receivers. Linux receivers are built to detect the end of today's slow-start behaviour. Our sender wasn't using anything like slow start behaviour, which triggered their heuristics much too early. Magically increasing the delack ratio after 100 packets is another behaviour we must not encourage. Sender control of the DelAck ratio can be really simple. Then we have a simple solution that will last for ever. We must not dig the heuristics and magic numbers hole any deeper. > >> >>> ABC is important also (well what I think people understand by ABC - >>> rather than the RFC on this). >> >> Yes. >> >>> * High bit rate environments and short data segments >>> >>> If you really don’t want delayed ACKs, the protocol using TCP ought >>> to disable nagle. Or you would perhaps use DAASS... I’m not sure >>> which problem you speak about? >>> >>> >>> * Beyond classic ACK transmission behavior >>> I do agree that Delayed ACKs preclude using sender behaviors >>> intended to quickly and non-intrusively probe for available capacity >>> during slow start. This is important to me, but I am very wary about >>> the idea of sending more ACKs to do this, and we need to be careful >>> to gain sufficient information about what the receiver has seen - >>> not just to get a bunch of separate (each cumulative) ACKs. This >>> really doesn’t give much fidelity to the sender. I’d be happy to >>> talk more about what might be better! >> >> Indeed, ACK frames in QUIC that give the arrival times of data >> packets are an alternative - as long as they are not stretched beyond >> the time at which they would have been useful. >> > Interesting, I think. >> But we are more limited for space in TCP. As long as a TCP server is >> serving bulk and short flows, it can put more effort into receiving >> more ACKs during flow startup, and save its processing power by using >> less frequent ACKs for the majority of its data - transmitted in >> congestion avoidance. >> >> > Also seems true. >>> * IoT scenarios >>> I can see the argument of an ACK energy cost for the IoT device. At >>> least, I would assume IoT devices can be tuned, and the apps they >>> talk to can be tuned. Appropriate guidance helps! >> >> Tuning is for a scenario, not for widely differing scenarios. The >> message of this draft is that a connection sometimes needs to be able >> to adapt its ACK ratio at run-time. Not every IoT device is always >> deployed for just one scenario. Neither is its peer. To me this says >> adaptation mustn't be complex (and doesn't have to be). >> > Heterogeniety of the network segments is tricky. Some optimisations > could be handled by link-specific methods - header compression perhaps > is an example, other things need to be adapted end-to-end. However, > end-to-end transport has to work for all types of path (links) - and > often does not know the path. [BB] Sender control of the receiver's DelAck ratio would be always better and never worse in these cases. It might not solve the lack of path knowledge. But wherever path knowledge can be gathered, sender control of the receiver's DelAck ratio would then be useful/necessary. Then, any sender can implement "link-specific methods" unilaterally (or not if it chooses). Sndr-rcvr co-ordination is an important piece that's missing. You seem to be generating confusion. There is still good reason to add a generally useful missing capability (sender control of receiver DelACK ratio), whether or not other capabilities might sometimes be missing in certain odd scenarios. Do one thing and do it well. >>> >>> * Bursty Apps >>> I think you can add varying workloads as something important. By >>> which I mean apps that do transactional stuff, or are controlled by >>> applications where the data transmission need varies.When we looked >>> at CWV and the ideas that the applications control the traffic >>> patterns in one group of applications, we also noted that these >>> applications change the way they use the network. That’s important >>> for a timely restart to growing the cwnd (etc). Such applications >>> can also be very sensitive to network delay.  These are probably >>> also of interest! >> >> Yes. >> >>> >>> So....  the reason for hesitancy overall is I see this as tricky >>> space to get correct. >> >> But trickiness is the point of starting this requirements document, >> isn't it? >> Please can you articulate better why you seem negative about this >> exercise? >>> >>> There are many places where fewer ACKs are good - if you have per >>> ACK interrupt costs - if the capacity consumed by ACKs is important >>> - the cost of sending in the link technology is high - etc. This is >>> complicated for TCP (and much less so for QUIC - because QUIC has a >>> notion of pacing; QUIC’s loss recovery is different; and QUIC’s ACKs >>> are not easily thinned, at least at present). Any TCP method has to >>> live with networks that experience pain from more ACKs, but also may >>> deploy (various) mitigations. >> >> Yes. But reading between the lines I hear you say "Don't start this >> exercise". >> Pls explicitly articulate your implicit message. >> > The slide asked about adopting this work - my words were against doing > that at that time with that revision of this document. > > I miss seeing presentations with results and showing the thinking. I  > wonder if we need a specific agenda slot to focus on such topics. I > expect we'll learn a lot from some data from a variety of > problem-spaces/use-cases, especially if the timeslot is sufficient to > include thinking and experience from people outside of TCPM. (That's > another thought - and probably should be another thread). [BB] I certainly agree with the need to base this on experience. However, all we have at the moment is experience of protocols /without/ sender control of the DelAck behaviour of the receiver. That's useful experience, but only to demonstrate the /problem/. It would be good to hear some empirical experience of protocols /with/ sender control. > >>> >>> There are also cases where you’d like more information than a >>> delayed ACK provides (e.g. chirping and similar probing methods) and >>> there are application pathologies that would love an ACK at the end >>> of a packet burst (be that 1 or 100s of packets). Any method has to >>> live with a wide variety of paths and applications. >>> >>> Happy to discuss more. And I suspect other people may also respond >>> on list. We have lots of data for QUIC and TCP - but most of our >>> data focusses on testbeds or on actual broadband satellite services. >> [BB] As above. Data about the existing Internet without the proposed capability is useful to characterize the problem. But need to be aware of its limitations at characterizing the solution-space proposed here. Bob >> Thanks for elaborating. >> >> >> >> Bob > Gorry >> >> >>> >>> Gorry >>> >>> >>> >>> _______________________________________________ >>> 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 -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri May 1 09:49:48 2020 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 40CF43A178F for ; Fri, 1 May 2020 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 jS0ktFTBWelv for ; Fri, 1 May 2020 09:49:39 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 9F74D3A178D for ; Fri, 1 May 2020 09:49:35 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id r2so2111532uam.7 for ; Fri, 01 May 2020 09:49:35 -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=TPeJcKi+lOb3wFhNcQEFuuAMbhFcN8MRopScNb3B2AI=; b=tn5I6CV4dLIs9JQsjNwNn8yoRubkineTu8n622U9Ku8ZvZfuEoSgsL6LmlAtzWLOfZ S0LRhzKkaMkwHFdfEdAB/vnPiTemIEQoQjGlZeyUZV/S3FFENh0HC7i30h/BVOVGV1QE JZLfmCF3SXH/pW//RAq44lLhLWA03THK6QIBoGzATaq35FE8+NMJT3moLWS/blu1Ep2v wM41D31qBVJyuYIXn8Z48jcwt+1gC12vcwUT3rATio7z4YJTQxamdrqxS6DXXMfRDcE/ Mfw9DRJJQrbAc9ineDlJqUo3TKzCPMKO75BcuWR1UmQIj4vnKf0rvwUUKtcGBbxb2fYV R4GA== 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=TPeJcKi+lOb3wFhNcQEFuuAMbhFcN8MRopScNb3B2AI=; b=pav1aOh/lgf6l5JFr6sVtcAOJ4wBWpjgZGovREvnjD2J/QlZgXgSDWEretnvMHC4Hx lDLcsFedYz7e0GBh/GaXusgPKNUtuaYn8rNxPFNZwA6gAAK2PaMqewGzgVq5B8JtdmjO bYC9CDO5bJrYy4AtnQqURtYRUrOVQjbrydn/YlKSV6dgZKHVQxp3Y2GpA1UlyGwOgXED v17LbT5O02wKOnp93gSJcuxr2Ged7o6dkJl7gUNrctFrnSa5pXIGSV+z7fkgtuNmPIVJ Y5Ukb72mGtdIdnLMRBBmWkwg+7Gtboi3epUu8hnkv+EgrHkcZSvAen71MF3ASmC0Qp1p 4OmA== X-Gm-Message-State: AGi0PuY8cD712LCwODluo1wKBCnKwBZs6XR+iqCeh0lV9sMJDq0uBYJE Yx5wvvWsJz8tP0OXft7GlytlyNQm5XmnZBJYrVVAeQ== X-Google-Smtp-Source: APiQypI9XCZQxgGHXs2QAx1k40ltbH7vnrsmM3+At511E1X456UyheveLdJyIl+NKlTIkWnnOTo+udoM1qrYq+lKizQ= X-Received: by 2002:ab0:408a:: with SMTP id i10mr3648137uad.80.1588351773924; Fri, 01 May 2020 09:49:33 -0700 (PDT) MIME-Version: 1.0 References: <23157b5e4063646449099e97eccde0f3.squirrel@webmail.entel.upc.edu> In-Reply-To: <23157b5e4063646449099e97eccde0f3.squirrel@webmail.entel.upc.edu> From: Yuchung Cheng Date: Fri, 1 May 2020 09:48:57 -0700 Message-ID: To: Carles Gomez Montenegro Cc: jon.crowcroft@cl.cam.ac.uk, "tcpm@ietf.org Extensions" , Neal Cardwell Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] question regarding draft-gomez-tcpm-delack-suppr-reqs 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, 01 May 2020 16:49:47 -0000 On Fri, May 1, 2020 at 1:56 AM Carles Gomez Montenegro wrote: > > Dear Yuchung, > > Thanks for your questions and comments. > > Please find below my inline responses: > > > thanks for the talk! > > > > https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-01#section-3.1 > > "Note that, while Appropriate Byte Counting (ABC) [RFC3465] might be used > > to address this problem, it remains as an experimental mechanism, not > > fully included in RFC 5681, which specifies standard TCP congestion > > control. " > > > > It's not clear what "fully included" means here. AFAICT, RFC5681 > > includes the essence of ABC explicitly. > > > > https://tools.ietf.org/html/rfc5681#section-3.1 > > > > " During slow start, a TCP increments cwnd by at most SMSS bytes for > > each ACK received that cumulatively acknowledges new data. Slow > > start ends when cwnd exceeds ssthresh (or, optionally, when it > > reaches it, as noted above) or when congestion is observed. While > > traditionally TCP implementations have increased cwnd by precisely > > SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND > > that TCP implementations increase cwnd, per: > > > > cwnd += min (N, SMSS) (2) > > > > where N is the number of previously unacknowledged bytes acknowledged > > in the incoming ACK. This adjustment is part of Appropriate Byte > > Counting [RFC3465] and provides robustness against misbehaving > > receivers that may attempt to induce a sender to artificially inflate > > cwnd using a mechanism known as "ACK Division" [SCWA99]. ACK > > Division consists of a receiver sending multiple ACKs for a single > > TCP data segment, each acknowledging only a portion of its data. A > > TCP that increments cwnd by SMSS for each such ACK will > > inappropriately inflate the amount of data injected into the network." > > Note that the problem pointed out is that, as stated in the RFC 5681 text > above: > > "During slow start, a TCP increments cwnd by at most SMSS bytes for > each ACK received that cumulatively acknowledges new data" > > It may be desirable to support, during slow start, a cwnd increase by more > than SMSS per each ACK acknowledging new data. I agree. We in fact implemented Linux to increase cwnd by the exact amount sequence (in unit of packets) so slow-start increase function is regardless of ack-thinning effect but purely based on amount delivered. This has an important effect on Wireless as the other ack talk mentions. It also helps in case of ACK losses or reordering. > > In fact, couple of paragraphs later, RFC 5681 explicitly indicates the > following: > > "We note that [RFC3465] allows for cwnd increases of more than SMSS > bytes for incoming acknowledgments during slow start on an > experimental basis; however, such behavior is not allowed as part of > the standard." > > That is what we meant by "not fully included in RFC 5681" in our document. > > > As a side note, Linux stack has implemented the principle of abc in > > its congestion control (including slow start) > > Thanks for the information. > > Yes, in fact, I second the WG members who stated on the chat, during the > interim, that it is surprising that ABC remains as an experimental > document. > > I realize that, at an implementation level, the problem pointed out above > is being addressed in many platforms. > > > regarding delayed ACK harming slow-start or latency, I am not too sure > > either: > > > > 1) The ACK is delayed but not the data > > > > 2) The delay of the ACK can indeed delay cwnd growth during slowstart. > > > > But the ACK is delayed because the packet is likely a sub-MSS data, > > which is again likely caused by application limit (i.e. the > > application has sent all its data like a HTTP response). In this case > > the delay of the cwnd growth does not hurt the performance since the > > application has no data left to send. > > > > The only penalty occurs when the application has more data to send > > but cwnd is still gated by the arrival of the delayed ACK. However, in > > many request - response protocol, either the (non-delayed) ACKs > > triggered by prior full-MSS data inflight or the delayed ACKs would > > have returned to grow the cwnd to sending immediately. > > > > I can construct scenarios where delayed ACK significantly hurts > > application. But I don't think the scenario is too common. I will > > suggest more tests to quantify the effect of delayed ACK effect on > > slow-start. > > Yes, I tend to agree. > > In fact, the two main problems due to Delayed ACKs that we identified so > far in the area of slow start are: > > - The fact that ABC might not always be supported (due to its > "Experimental" status). > > - Precluding sender behaviors such as chirping. > > Once again, thanks for your valuable feedback! > > Cheers, > > Carles > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > From nobody Fri May 1 10:56:21 2020 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 A8FBC3A11A6 for ; Thu, 30 Apr 2020 12:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.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 dvLpjf3QnpwH for ; Thu, 30 Apr 2020 12:36:12 -0700 (PDT) Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 6C38F3A11B2 for ; Thu, 30 Apr 2020 12:36:12 -0700 (PDT) Received: by mail-oo1-xc29.google.com with SMTP id x16so173318oop.13 for ; Thu, 30 Apr 2020 12:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=cP/FVA1tThDeu8kRO+dWb33FNodm8Et5mjHuptR/8HI=; b=trjdrRNhXBaTTMKjFcdmZJpV6aBMlhzRuWjTCrgFWHwwN8vvPAdMUk9WFofha/CQsj 4iPIJ/6K/BSolu+yFDHnamWGCa1nvW1DVTeEqn4Il+AFP1ZbF1Wl0b8qNUBvuynoR0+g bvYSxNKKm/FtTl72SkWenso9wD5RIPCVoNA2qKuNNQ/OMwUQm7BEujGMdXIyyy2rWHBI MjV25R/53ML8wV7OqbuW+LOFRsYxPwT84Z/Xrw9PNXQfyJQvrq4Et7WeX4ofU6KLACM6 QYGqEFj/SUi7594OPrTAB7xBipgifFcnP9uXTJl7r6hQWF6sqKCv/YyS84/lk6tzoqkC HO1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=cP/FVA1tThDeu8kRO+dWb33FNodm8Et5mjHuptR/8HI=; b=JAzqFBSyVghN3jvCe1rCiN2Hn12hgNXqjYjG3O5Awt/kQcYP1RlwhsInYpZv6iHT+U d1YtlrppN5FE0527LIbT+fkm7gS74Vzu83sYEwTeZuE/F20NfnD6lvtqf7MnDj4LsmsF lz4xMhs8il2ugCjjlbvPgUk66w/ACVODoWjmUTTY3+li7/oyVtYWhcTfof0ZMRznp/dV EOGboQXJ7Wm1av6dWMA6qtFwy9xQcWew1Y6/h0K4ffR25Naip7xfKm/x9HbXRvoj5zpL n5g0xDhQJYai5a5DpVd4HiiF6RCAEi1DVAr3tSRbZ29xmRl14LtDPjzClH6ILR5Kq+dQ Anvw== X-Gm-Message-State: AGi0PuYjOvXSUAtjG+rq0FWaOeblthMRHw/r4KLpu9z9yjpCGdPYFdgu KFKbBsK0pXdB9gI1sLmu0H42hpc8jVzDFw== X-Google-Smtp-Source: APiQypKpYo0/Vtuy3r2oyhZlj2dvvN65+6Tg4ydSbmIzhHM+jxjQtZt+wtluwvQITrzRzTJR1DRgOQ== X-Received: by 2002:a4a:e0d4:: with SMTP id e20mr648903oot.35.1588275371307; Thu, 30 Apr 2020 12:36:11 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:a5e0:d5ef:e54f:e112]) by smtp.gmail.com with ESMTPSA id 47sm208027otg.77.2020.04.30.12.36.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 12:36:10 -0700 (PDT) From: Mark Allman X-Google-Original-From: "Mark Allman" To: tcpm@ietf.org Date: Thu, 30 Apr 2020 15:36:09 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <35789534-1A96-4B7C-9729-E4D8DD2F8D5C@icir.org> In-Reply-To: References: <158827502797.6042.15313343958284896274@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_19F9526F-8C33-4ED7-8FA8-7421EC98D0A9_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: X-Mailman-Approved-At: Fri, 01 May 2020 10:56:20 -0700 Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-11.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, 30 Apr 2020 19:36:14 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_19F9526F-8C33-4ED7-8FA8-7421EC98D0A9_= Content-Type: text/plain > Title : Requirements for Time-Based Loss Detection > Author : Mark Allman > Filename : draft-ietf-tcpm-rto-consider-11.txt > Pages : 10 > Date : 2020-04-30 I believe this version addresses the wording issue in requirement (3) brought up during WGLC. Per yesterday's meeting I think that means we can forward the document on to the IESG. allman --=_MailMate_19F9526F-8C33-4ED7-8FA8-7421EC98D0A9_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXqsoqREcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizie+AJwNFC3/iLqomZdTslrPYTz0OZx+YwCfdEai lHxmqYPWvkICzxWSxkRUsV0= =M/hv -----END PGP SIGNATURE----- --=_MailMate_19F9526F-8C33-4ED7-8FA8-7421EC98D0A9_=-- From nobody Fri May 1 11:20:23 2020 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 557883A1922 for ; Fri, 1 May 2020 11:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_FAIL=0.001, 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=bobbriscoe.net 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 Uu6f8yMXzmgK for ; Fri, 1 May 2020 11:20:20 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 811C13A1921 for ; Fri, 1 May 2020 11:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1dgmDOeo/3QSfwXXFGQ7qdwHaJN6maA3sKsnZ1EV+sM=; b=0SpkEuaOXwv7RNGAouHxtiqtK MTDBPZdYQxALtdZTwnaETDFpwLngl1PdHH+I3F44EX5rQJA2oybi4NBwnlghMYaArd1V1hYZ+n3e/ j6JAmRtl3nasrlXWMkV70S6Tj01rDK0B19XG3RJidSrHLwyBwiV42rp+Y3ao2a843mm1e3+TTiaXn yFbrx/U8RrZ2Ry7nihlp1a/Mx7BIPURAADMKAA8OtuvFGuoHzBiFoPQ0xDjg3l0p6oXX4iamd6s3R yMDSWf+05WkjVqbDpUSeb4ZxCYzeuqdoEThjLXepiryWn10VL1vKsuEHDK5Ggavwb4lZkygIwDhjM /Qf7wi0GA==; Received: from [31.185.128.97] (port=47508 helo=[192.168.0.6]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jUaGo-00CnEZ-2b; Fri, 01 May 2020 19:20:18 +0100 To: Neal Cardwell , Carles Gomez Montenegro Cc: "Scheffenegger, Richard" , "tcpm@ietf.org" , Gorry Fairhurst , jon.crowcroft@cl.cam.ac.uk References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> From: Bob Briscoe Message-ID: Date: Fri, 1 May 2020 19:20:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7C9D3AA6516DE9755D176408" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 01 May 2020 18:20:23 -0000 This is a multi-part message in MIME format. --------------7C9D3AA6516DE9755D176408 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Neal, On 01/05/2020 13:19, Neal Cardwell wrote: > On Fri, May 1, 2020 at 6:23 AM Carles Gomez Montenegro > wrote: >> Hi Neil, >> >> Thanks a lot for your comments! >> >> Please find below my inline responses: >> >>> On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard >>> wrote: >>>> Eliciting an ACK under certain circumstances, for a timely continuation >>>> of the data transmission / growth of the congestion window is a known >>>> method to reduce network delay. >>>> >>>> E.g. Linux has been using the CWR flag for the purpose of sending out an >>>> immediate ACK by the receiver, since there is an increased chance of a >>>> very small cwnd when the sender had just reduced it's congestion window. >>>> >>>> https://lore.kernel.org/patchwork/patch/970486/ >>>> >>>> and we also found latency improvements doing this when running >>>> ECN-enabled sessions >>>> >>>> https://reviews.freebsd.org/D22670 >>> Yes, agreed. >>> >>> IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1 >>> case. >> (While this question is about the solution space, I'm anyway curious...) >> In the context of datacenter networks, would you have any suggestion or >> preference regarding the solutions that have been mentioned so far? >> >> Or perhaps any particular requirement for a potential solution? > Among the solutions outlined in > https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00 > my first preference would be the AKP option, since that approach > avoids burning a precious flag bit. [BB] Eh? AKP does burn a flag bit (and you say it does below). Quoting the draft: TCP ACK Pull defines the AKP flag as bit number 6 of the 13th byte of the TCP header. (BTW, Carles, in this quoted sentence, you ought to call it "the TCP ACK Pull /proposal/" otherwise sounds like it's an official part of TCP already.) > > The AKP option may be stripped by some middleboxes, but (a) as a > performance optimization, that should be acceptable, and (b) for the > datacenter case (where cwnd=1 is a motivating use case) this should > not be a concern. > > IMHO a flag bit makes sense for a small signal that a sender might > want to send frequently or at a high rate, but senders should not be > trying to force immediate ACKs frequently. [BB] For me, the problem with the AKP approach is that it's /only/ really good in environments where you've got a small window. When you have a large window and you can cope with a certain ACK ratio (say 1:16), you would have to set AKP on every 16th packet, which doesn't really express what the sender wants (and if the receiver had just sent an ACK of its own accord just before it got one of these regular AKP requests, should it send another?). The sender in this case really wants to say "I don't particularly mind which packets you ACK, but there's no need to do it more often than 1:16". I think there's some mileage in a TCP Option that aggregates a few behaviours together under one new TCP Option. I reckon 3 bits would be enough for a good delayed ACK option, but a whole TCP Option for that could be overkill. There was going to be a talk about a low latency TCP Option in netdev0x14 before it was postponed (sorry I don't remember who by). That might be a good excuse to collect together a few related functions. It could also improve the deployment incentives. Bob > > best, > neal -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------7C9D3AA6516DE9755D176408 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Neal,

On 01/05/2020 13:19, Neal Cardwell wrote:
On Fri, May 1, 2020 at 6:23 AM Carles Gomez Montenegro
<carlesgo@entel.upc.edu> wrote:

Hi Neil,

Thanks a lot for your comments!

Please find below my inline responses:


On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard <rs.ietf@gmx.at>
wrote:

Eliciting an ACK under certain circumstances, for a timely continuation
of the data transmission / growth of the congestion window is a known
method to reduce network delay.

E.g. Linux has been using the CWR flag for the purpose of sending out an
immediate ACK by the receiver, since there is an increased chance of a
very small cwnd when the sender had just reduced it's congestion window.

https://lore.kernel.org/patchwork/patch/970486/

and we also found latency improvements doing this when running
ECN-enabled sessions

https://reviews.freebsd.org/D22670

Yes, agreed.

IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1
case.

(While this question is about the solution space, I'm anyway curious...)
In the context of datacenter networks, would you have any suggestion or
preference regarding the solutions that have been mentioned so far?

Or perhaps any particular requirement for a potential solution?

Among the solutions outlined in
  https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00
my first preference would be the AKP option, since that approach
avoids burning a precious flag bit.

[BB] Eh? AKP does burn a flag bit (and you say it does below). Quoting the draft:
   TCP ACK Pull defines the AKP flag as bit number 6 of the 13th byte of
   the TCP header.

(BTW, Carles, in this quoted sentence, you ought to call it "the TCP ACK Pull /proposal/" otherwise sounds like it's an official part of TCP already.)


The AKP option may be stripped by some middleboxes, but (a) as a
performance optimization, that should be acceptable, and (b) for the
datacenter case (where cwnd=1 is a motivating use case) this should
not be a concern.

IMHO a flag bit makes sense for a small signal that a sender might
want to send frequently or at a high rate, but senders should not be
trying to force immediate ACKs frequently.

[BB] For me, the problem with the AKP approach is that it's /only/ really good in environments where you've got a small window. When you have a large window and you can cope with a certain ACK ratio (say 1:16), you would have to set AKP on every 16th packet, which doesn't really express what the sender wants (and if the receiver had just sent an ACK of its own accord just before it got one of these regular AKP requests, should it send another?). The sender in this case really wants to say "I don't particularly mind which packets you ACK, but there's no need to do it more often than 1:16".

I think there's some mileage in a TCP Option that aggregates a few behaviours together under one new TCP Option. I reckon 3 bits would be enough for a good delayed ACK option, but a whole TCP Option for that could be overkill. There was going to be a talk about a low latency TCP Option in netdev0x14 before it was postponed (sorry I don't remember who by). That might be a good excuse to collect together a few related functions. It could also improve the deployment incentives.


Bob




best,
neal


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------7C9D3AA6516DE9755D176408-- From nobody Fri May 1 14:52:34 2020 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 6FB643A1565 for ; Fri, 1 May 2020 14:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CET8QYhIEXv for ; Fri, 1 May 2020 14:52:30 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 ADEC93A155B for ; Fri, 1 May 2020 14:52:30 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id i16so5684585ils.12 for ; Fri, 01 May 2020 14:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZO1AKovYOcCINRlTfFSe8t61kTrfoS9OzMj8jMeuWoU=; b=B2RUPRRWbO+dhwj2TnH/UcUhJY3YSUl1ISu4OUIclrd80xYvusCL6YSr+5ZqLR+neV V9PIgr7BkBWuy3YAwREymUNCsJeoMH3Bib+io3CHTC7dE4ZPJC/xPgV2WwvbiOXxQUcF HJodoMGMdc8gGGNxqI1kdGMHmQbC6UQ7HwCGaSuxT05BkOIsutiM7UVKvkYdUvJc/fZ8 c8FOVC3sBAADs2a/KxhtUe4tbRMpe0qKuwS9poKNqfc60UUdGlpGCDMfks3HyVkJT8a0 gt2jAZJNqbrxQ+WKBX1sPX94X/QVecr8S4kkzX70ksM3NPsmJNbYUvGFDYZrbtHjvxSf rxCA== 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=ZO1AKovYOcCINRlTfFSe8t61kTrfoS9OzMj8jMeuWoU=; b=r5zDl8d2cJcgOPbD2Ie4sX24ma00vhVQRvdKWOypQHX3rC7PCmfdM5wUIh6QEaFpNt QWeRxRaXwxyS53nyNReJ6lcf9XdaJoGCgOLn2uFYkzwFZd8mIvGq0SdC6OYW2tQb1E8b YTECU2/ejyPLRvxPwqe4BVMcblNxN/+G74Cy4mCThtEN5V6eBparSXdnFmgJJyLic5Y6 TGbd4UCgMtnp0bDaKE+mf9xsQW+N6vATNUNz1ozpsa1dCGhym7nP/EAgLjk/ucu2eAO9 gEPdr2n0yNn09OBKeFSjgwTQrBAW+okos1RfiUeesRvwxq8mmbdAHG9V75pYeMLcP3L5 jZgw== X-Gm-Message-State: AGi0PuYH+Lkws8rEtZ+ntcfnadD/BeMSG3z/+e3KLUy3Vq9Rfl8Jn27j Rlh2Off4eAzZ3bd6LECo+I4NM6emzt/hm1jWFvRDgMNh X-Google-Smtp-Source: APiQypIwoZ2SbPZQm5Ztu+bh6YB1MdtWxiheK1N62vQ/aHeC4ec9zz1aNTV1/MnC2Na8BqvXPi0M949JT8k2XlXuFUM= X-Received: by 2002:a92:49c2:: with SMTP id k63mr5645864ilg.303.1588369949929; Fri, 01 May 2020 14:52:29 -0700 (PDT) MIME-Version: 1.0 References: <158827502797.6042.15313343958284896274@ietfa.amsl.com> <35789534-1A96-4B7C-9729-E4D8DD2F8D5C@icir.org> In-Reply-To: <35789534-1A96-4B7C-9729-E4D8DD2F8D5C@icir.org> From: Martin Duke Date: Fri, 1 May 2020 14:52:18 -0700 Message-ID: To: Mark Allman Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000a3355405a49d3210" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-11.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: Fri, 01 May 2020 21:52:33 -0000 --000000000000a3355405a49d3210 Content-Type: text/plain; charset="UTF-8" Great! I'll start my AD review while Yoshi starts his shepherd writeup. Thanks Mark! On Fri, May 1, 2020 at 10:56 AM Mark Allman wrote: > > > Title : Requirements for Time-Based Loss Detection > > Author : Mark Allman > > Filename : draft-ietf-tcpm-rto-consider-11.txt > > Pages : 10 > > Date : 2020-04-30 > > I believe this version addresses the wording issue in requirement > (3) brought up during WGLC. Per yesterday's meeting I think that > means we can forward the document on to the IESG. > > allman > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000a3355405a49d3210 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great! I'll start my AD review while Yoshi starts= his shepherd writeup.

Thanks Mark!

On Fr= i, May 1, 2020 at 10:56 AM Mark Allman <mallman@icsi.berkeley.edu> wrote:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Requirements for Time-Based Loss Detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Mark Allman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tcpm-rto-consider-11.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 10
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-04-30

I believe this version addresses the wording issue in requirement
(3) brought up during WGLC.=C2=A0 Per yesterday's meeting I think that<= br> means we can forward the document on to the IESG.

allman
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000a3355405a49d3210-- From nobody Sat May 2 01:34:33 2020 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 119C33A0ADA for ; Sat, 2 May 2020 01:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 KHyKguWIfXWf for ; Sat, 2 May 2020 01:34:24 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 79C6A3A0AD8 for ; Sat, 2 May 2020 01:34:23 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0428YFLo055372; Sat, 2 May 2020 10:34:15 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 21BBB1D53C1; Sat, 2 May 2020 10:34:14 +0200 (CEST) Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Sat, 2 May 2020 10:34:15 +0200 Message-ID: <6b11e0a37698146c8e2bad6052634452.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <23157b5e4063646449099e97eccde0f3.squirrel@webmail.entel.upc.edu> Date: Sat, 2 May 2020 10:34:15 +0200 From: "Carles Gomez Montenegro" To: "Yuchung Cheng" Cc: jon.crowcroft@cl.cam.ac.uk, "tcpm@ietf.org Extensions" , "Neal Cardwell" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at violet X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Sat, 02 May 2020 10:34:16 +0200 (CEST) Archived-At: Subject: Re: [tcpm] question regarding draft-gomez-tcpm-delack-suppr-reqs 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, 02 May 2020 08:34:31 -0000 Hi Yuchung, >> Note that the problem pointed out is that, as stated in the RFC 5681 >> text >> above: >> >> "During slow start, a TCP increments cwnd by at most SMSS bytes for >> each ACK received that cumulatively acknowledges new data" >> >> It may be desirable to support, during slow start, a cwnd increase by >> more >> than SMSS per each ACK acknowledging new data. > I agree. We in fact implemented Linux to increase cwnd by the exact > amount sequence (in unit of packets) so slow-start increase function is > regardless of ack-thinning effect but purely based on amount > delivered. This has an important effect on > Wireless as the other ack talk mentions. It also helps in case of ACK > losses or reordering. Agreed! By the way, in the next draft update, we will add that, despite its "Experimental" status, ABC is supported in many implementations. Thanks, Carles From nobody Sat May 2 01:49:58 2020 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 5E93E3A0B18 for ; Sat, 2 May 2020 01:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 3FL2Ni_KpmUr for ; Sat, 2 May 2020 01:49:53 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 E9AD83A0B17 for ; Sat, 2 May 2020 01:49:52 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0428n2NC007149; Sat, 2 May 2020 10:49:02 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 529B31D53C1; Sat, 2 May 2020 10:49:01 +0200 (CEST) Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Sat, 2 May 2020 10:49:02 +0200 Message-ID: In-Reply-To: References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> Date: Sat, 2 May 2020 10:49:02 +0200 From: "Carles Gomez Montenegro" To: "Neal Cardwell" Cc: "Scheffenegger, Richard" , "tcpm@ietf.org" , "Gorry Fairhurst" , "Bob Briscoe" , jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at dash X-Virus-Status: Clean X-Greylist: Delayed for 23:52:30 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Sat, 02 May 2020 10:49:02 +0200 (CEST) Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 02 May 2020 08:49:57 -0000 Hi Neal, >> > On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard >> >> > wrote: >> >> Eliciting an ACK under certain circumstances, for a timely >> continuation >> >> of the data transmission / growth of the congestion window is a known >> >> method to reduce network delay. >> >> >> >> E.g. Linux has been using the CWR flag for the purpose of sending out >> an >> >> immediate ACK by the receiver, since there is an increased chance of >> a >> >> very small cwnd when the sender had just reduced it's congestion >> window. >> >> >> >> https://lore.kernel.org/patchwork/patch/970486/ >> >> >> >> and we also found latency improvements doing this when running >> >> ECN-enabled sessions >> >> >> >> https://reviews.freebsd.org/D22670 >> > >> > Yes, agreed. >> > >> > IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1 >> > case. >> >> (While this question is about the solution space, I'm anyway curious...) >> In the context of datacenter networks, would you have any suggestion or >> preference regarding the solutions that have been mentioned so far? >> >> Or perhaps any particular requirement for a potential solution? > > Among the solutions outlined in > https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00 > my first preference would be the AKP option, since that approach > avoids burning a precious flag bit. > > The AKP option may be stripped by some middleboxes, but (a) as a > performance optimization, that should be acceptable, and (b) for the > datacenter case (where cwnd=1 is a motivating use case) this should > not be a concern. > > IMHO a flag bit makes sense for a small signal that a sender might > want to send frequently or at a high rate, but senders should not be > trying to force immediate ACKs frequently. Thanks a lot for the very useful feedback. In the next draft update, we will expand the discussion of potential solutions accordingly. Cheers, Carles > best, > neal From nobody Sat May 2 02:40:34 2020 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 7653E3A0CAF for ; Sat, 2 May 2020 02:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 tWR6-7-7OjbJ for ; Sat, 2 May 2020 02:40:25 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 70A913A0CAA for ; Sat, 2 May 2020 02:40:24 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0429dUto006928; Sat, 2 May 2020 11:39:30 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id BBC381D53C1; Sat, 2 May 2020 11:39:29 +0200 (CEST) Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Sat, 2 May 2020 11:39:30 +0200 Message-ID: <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> Date: Sat, 2 May 2020 11:39:30 +0200 From: "Carles Gomez Montenegro" To: "Bob Briscoe" Cc: "Neal Cardwell" , "Scheffenegger, Richard" , "tcpm@ietf.org" , "Gorry Fairhurst" , jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at violet X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Sat, 02 May 2020 11:39:31 +0200 (CEST) Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 02 May 2020 09:40:33 -0000 Hi Bob, (Chiming in...) > Neal, > > On 01/05/2020 13:19, Neal Cardwell wrote: >> On Fri, May 1, 2020 at 6:23 AM Carles Gomez Montenegro >> wrote: >>> Hi Neil, >>> >>> Thanks a lot for your comments! >>> >>> Please find below my inline responses: >>> >>>> On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard >>>> >>>> wrote: >>>>> Eliciting an ACK under certain circumstances, for a timely >>>>> continuation >>>>> of the data transmission / growth of the congestion window is a known >>>>> method to reduce network delay. >>>>> >>>>> E.g. Linux has been using the CWR flag for the purpose of sending out >>>>> an >>>>> immediate ACK by the receiver, since there is an increased chance of >>>>> a >>>>> very small cwnd when the sender had just reduced it's congestion >>>>> window. >>>>> >>>>> https://lore.kernel.org/patchwork/patch/970486/ >>>>> >>>>> and we also found latency improvements doing this when running >>>>> ECN-enabled sessions >>>>> >>>>> https://reviews.freebsd.org/D22670 >>>> Yes, agreed. >>>> >>>> IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1 >>>> case. >>> (While this question is about the solution space, I'm anyway >>> curious...) >>> In the context of datacenter networks, would you have any suggestion or >>> preference regarding the solutions that have been mentioned so far? >>> >>> Or perhaps any particular requirement for a potential solution? >> Among the solutions outlined in >> https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00 >> my first preference would be the AKP option, since that approach >> avoids burning a precious flag bit. > > [BB] Eh? AKP does burn a flag bit (and you say it does below). Quoting > the draft: > > TCP ACK Pull defines the AKP flag as bit number 6 of the 13th byte of > the TCP header. [CG] I think that Neal referred to section 5.4 of the requirements draft ("A new 'ACK Pull' TCP option"). > (BTW, Carles, in this quoted sentence, you ought to call it "the TCP ACK > Pull /proposal/" otherwise sounds like it's an official part of TCP > already.) [CG] Well noted, thanks! (Nevertheless, if that other document went ahead, I guess that "proposal" would need to be eventually removed.) >> The AKP option may be stripped by some middleboxes, but (a) as a >> performance optimization, that should be acceptable, and (b) for the >> datacenter case (where cwnd=1 is a motivating use case) this should >> not be a concern. >> >> IMHO a flag bit makes sense for a small signal that a sender might >> want to send frequently or at a high rate, but senders should not be >> trying to force immediate ACKs frequently. > > [BB] For me, the problem with the AKP approach is that it's /only/ > really good in environments where you've got a small window. When you > have a large window and you can cope with a certain ACK ratio (say > 1:16), you would have to set AKP on every 16th packet, which doesn't > really express what the sender wants (and if the receiver had just sent > an ACK of its own accord just before it got one of these regular AKP > requests, should it send another?). The sender in this case really wants > to say "I don't particularly mind which packets you ACK, but there's no > need to do it more often than 1:16". > > I think there's some mileage in a TCP Option that aggregates a few > behaviours together under one new TCP Option. I reckon 3 bits would be > enough for a good delayed ACK option, but a whole TCP Option for that > could be overkill. There was going to be a talk about a low latency TCP > Option in netdev0x14 before it was postponed (sorry I don't remember who > by). That might be a good excuse to collect together a few related > functions. It could also improve the deployment incentives. [CG] Thanks for the comments! [CG] It seems that there are two different areas where avoiding the typical Delayed ACKs approach may be of particular interest: i) scenarios where very small window sizes are used (cwnd=1), and ii) scenarios where large window sizes, and high ACK ratios, can be used. We will reflect these considerations in the next draft update. Cheers, Carles > Bob > > > >> >> best, >> neal > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ From nobody Sat May 2 07:11:16 2020 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 66FA83A1280 for ; Sat, 2 May 2020 07:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 Pt2WXtiHmicD for ; Sat, 2 May 2020 07:11:09 -0700 (PDT) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (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 894123A127E for ; Sat, 2 May 2020 07:11:09 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id y185so8077758vsy.8 for ; Sat, 02 May 2020 07:11:09 -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=JhjWoqc81oVGyvIcoPNH0YZHMJBY6HLL/X9huCXO8NQ=; b=ipeNhGYUbtP2a6G1/yEtgGHlEYg+FpQjYz+Weq+Fq3hakl1Mz9URNHOU3cnPm7o54I eYvVBPuyqyeut6y15kAxowvTz478+/ABT40I88Rcn1UpmgXhRjQnalvrj9dMVUxzluRU xtM0ap0kPXg4Sc6AE0MgKdjNWKTXOVSxXFByYbMkRIikzAg8P9oG6uNa+3HUunaNeyo/ h1Q87FTUo6Ifp+44vKd+0AdiZvDz/Z6v/8YUNjPtRdVtjYz1CPgRUuhCGW0uPcuWnNEE FakrNdy3H4xyUdp85CcLNRexwDerRM2Ud3To4cqj3XoZuaAjEXCZ7D1LOXnQKB9kw6IQ zfEg== 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=JhjWoqc81oVGyvIcoPNH0YZHMJBY6HLL/X9huCXO8NQ=; b=CnzESftCBtcAlIsFNZnWWcCIYzkjqxPBcpyAvW2tE+xZxacx/QtkhnXplqvknT6JqO z1lcPXzHsLyq7cZtMk8NmkF5BM8UbrUlQR55Kcp+Yc6xfaUytWrbN03YRyZzkbjUhGCy 2lpCLIz3PLI/w/kFg2l7SWM1Dcw1YMtFG6i9oI7LGeyxAn2BV+ChRzTaWY6X5NVyils2 9Ol+w4L1LW5ODrYsThyAkqAT08/CjxYnXqr09/AFe/pnIy9X0sljkVm92FcLoChAKXS1 DOV25A2yc/VDQAR0Fs0owjidEnYBU5rlpMtQl2SjNlE5wcPxldr/V87zCdinVWCvPJqC jGng== X-Gm-Message-State: AGi0Pub+/aELQxaBIFvT77XUTZMl0DXox+LztLYI3iitpL3hLjNs+9/v NJMcg2NMtg3CvXxoG5w2obkJh8p77k14SFJb9tf8vg== X-Google-Smtp-Source: APiQypLY1U0LVv/ng294HH20mk5LGyxaKF0g3TT5avI5FtaEgR0De02IzKM+A+axu6l0vO4p06n2de8sW8P/fQayEwI= X-Received: by 2002:a67:8704:: with SMTP id j4mr6607015vsd.219.1588428668093; Sat, 02 May 2020 07:11:08 -0700 (PDT) MIME-Version: 1.0 References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> In-Reply-To: <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> From: Neal Cardwell Date: Sat, 2 May 2020 10:10:49 -0400 Message-ID: To: Carles Gomez Montenegro Cc: Bob Briscoe , "Scheffenegger, Richard" , "tcpm@ietf.org" , Gorry Fairhurst , jon.crowcroft@cl.cam.ac.uk Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 02 May 2020 14:11:15 -0000 On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro wrote: > > Hi Bob, > > (Chiming in...) > > > Neal, > > > > On 01/05/2020 13:19, Neal Cardwell wrote: > >> On Fri, May 1, 2020 at 6:23 AM Carles Gomez Montenegro > >> wrote: > >>> Hi Neil, > >>> > >>> Thanks a lot for your comments! > >>> > >>> Please find below my inline responses: > >>> > >>>> On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard > >>>> > >>>> wrote: > >>>>> Eliciting an ACK under certain circumstances, for a timely > >>>>> continuation > >>>>> of the data transmission / growth of the congestion window is a known > >>>>> method to reduce network delay. > >>>>> > >>>>> E.g. Linux has been using the CWR flag for the purpose of sending out > >>>>> an > >>>>> immediate ACK by the receiver, since there is an increased chance of > >>>>> a > >>>>> very small cwnd when the sender had just reduced it's congestion > >>>>> window. > >>>>> > >>>>> https://lore.kernel.org/patchwork/patch/970486/ > >>>>> > >>>>> and we also found latency improvements doing this when running > >>>>> ECN-enabled sessions > >>>>> > >>>>> https://reviews.freebsd.org/D22670 > >>>> Yes, agreed. > >>>> > >>>> IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1 > >>>> case. > >>> (While this question is about the solution space, I'm anyway > >>> curious...) > >>> In the context of datacenter networks, would you have any suggestion or > >>> preference regarding the solutions that have been mentioned so far? > >>> > >>> Or perhaps any particular requirement for a potential solution? > >> Among the solutions outlined in > >> https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00 > >> my first preference would be the AKP option, since that approach > >> avoids burning a precious flag bit. > > > > [BB] Eh? AKP does burn a flag bit (and you say it does below). Quoting > > the draft: > > > > TCP ACK Pull defines the AKP flag as bit number 6 of the 13th byte of > > the TCP header. > > [CG] I think that Neal referred to section 5.4 of the requirements draft > ("A new 'ACK Pull' TCP option"). Yes, as Carles says, when I mentioned "AKP option" I was referring to the alternative discussed in section 5.4, "A new 'ACK Pull' TCP option", which does not burn a flag bit: https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00#section-5.4 When I mentioned "flag bit" I was referring to section 5.3, "TCP ACK Pull (AKP) flag", which does burn a flag bit: https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00#section-5.3 > > (BTW, Carles, in this quoted sentence, you ought to call it "the TCP ACK > > Pull /proposal/" otherwise sounds like it's an official part of TCP > > already.) > > [CG] Well noted, thanks! (Nevertheless, if that other document went > ahead, I guess that "proposal" would need to be eventually removed.) > > >> The AKP option may be stripped by some middleboxes, but (a) as a > >> performance optimization, that should be acceptable, and (b) for the > >> datacenter case (where cwnd=1 is a motivating use case) this should > >> not be a concern. > >> > >> IMHO a flag bit makes sense for a small signal that a sender might > >> want to send frequently or at a high rate, but senders should not be > >> trying to force immediate ACKs frequently. > > > > [BB] For me, the problem with the AKP approach is that it's /only/ > > really good in environments where you've got a small window. When you > > have a large window and you can cope with a certain ACK ratio (say > > 1:16), you would have to set AKP on every 16th packet, which doesn't > > really express what the sender wants (and if the receiver had just sent > > an ACK of its own accord just before it got one of these regular AKP > > requests, should it send another?). The sender in this case really wants > > to say "I don't particularly mind which packets you ACK, but there's no > > need to do it more often than 1:16". > > > > I think there's some mileage in a TCP Option that aggregates a few > > behaviours together under one new TCP Option. I reckon 3 bits would be > > enough for a good delayed ACK option, but a whole TCP Option for that > > could be overkill. There was going to be a talk about a low latency TCP > > Option in netdev0x14 before it was postponed (sorry I don't remember who > > by). That might be a good excuse to collect together a few related > > functions. It could also improve the deployment incentives. > > [CG] Thanks for the comments! > > [CG] It seems that there are two different areas where avoiding the > typical Delayed ACKs approach may be of particular interest: i) scenarios > where very small window sizes are used (cwnd=1), and ii) scenarios where > large window sizes, and high ACK ratios, can be used. We will reflect > these considerations in the next draft update. Yes, I wholeheartedly agree with Bob's point that it's also extremely useful for TCP senders to be able to say things like: "I don't particularly mind which packets you ACK, but there's no need to do it more often than 1:16". QUIC has a mechanism like this, and it seems to allow significant CPU savings, even allowing QUIC to run faster than TCP in some cases, AFAICT due to the reduced overhead for handling ACKs: https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 So I agree with the usefulness of the two-use-case taxonomy Carles has outlined: 1: "please ACK now"; because sender's cwnd is low 2: "ACK at frequency K"; because sender's cwnd is high It seems those could both be addressed cleanly with one or two TCP option kinds. A single TCP option kind might suffice if the ACK frequency of 0 or 1 is taken to mean "please ACK now". best, neal From nobody Sat May 2 07:26:32 2020 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 E0F883A12D0 for ; Sat, 2 May 2020 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 i23GykmMUhWW for ; Sat, 2 May 2020 07:26:27 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316223A12CF for ; Sat, 2 May 2020 07:26:26 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:7172:6c7:bb0f:a532] (unknown [IPv6:2a02:8109:1140:c3d:7172:6c7:bb0f:a532]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 8A169722CF6AF; Sat, 2 May 2020 16:26:22 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Tuexen In-Reply-To: Date: Sat, 2 May 2020 16:26:21 +0200 Cc: Carles Gomez Montenegro , jon.crowcroft@cl.cam.ac.uk, "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> To: Neal Cardwell X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 02 May 2020 14:26:30 -0000 > On 2. May 2020, at 16:10, Neal Cardwell = wrote: >=20 > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro > wrote: >>=20 >> Hi Bob, >>=20 >> (Chiming in...) >>=20 >>> Neal, >>>=20 >>> On 01/05/2020 13:19, Neal Cardwell wrote: >>>> On Fri, May 1, 2020 at 6:23 AM Carles Gomez Montenegro >>>> wrote: >>>>> Hi Neil, >>>>>=20 >>>>> Thanks a lot for your comments! >>>>>=20 >>>>> Please find below my inline responses: >>>>>=20 >>>>>> On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard >>>>>> >>>>>> wrote: >>>>>>> Eliciting an ACK under certain circumstances, for a timely >>>>>>> continuation >>>>>>> of the data transmission / growth of the congestion window is a = known >>>>>>> method to reduce network delay. >>>>>>>=20 >>>>>>> E.g. Linux has been using the CWR flag for the purpose of = sending out >>>>>>> an >>>>>>> immediate ACK by the receiver, since there is an increased = chance of >>>>>>> a >>>>>>> very small cwnd when the sender had just reduced it's congestion >>>>>>> window. >>>>>>>=20 >>>>>>> https://lore.kernel.org/patchwork/patch/970486/ >>>>>>>=20 >>>>>>> and we also found latency improvements doing this when running >>>>>>> ECN-enabled sessions >>>>>>>=20 >>>>>>> https://reviews.freebsd.org/D22670 >>>>>> Yes, agreed. >>>>>>=20 >>>>>> IMHO an explicit ACK-pull mechanism would be very nice for the = cwnd<=3D1 >>>>>> case. >>>>> (While this question is about the solution space, I'm anyway >>>>> curious...) >>>>> In the context of datacenter networks, would you have any = suggestion or >>>>> preference regarding the solutions that have been mentioned so = far? >>>>>=20 >>>>> Or perhaps any particular requirement for a potential solution? >>>> Among the solutions outlined in >>>> https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00 >>>> my first preference would be the AKP option, since that approach >>>> avoids burning a precious flag bit. >>>=20 >>> [BB] Eh? AKP does burn a flag bit (and you say it does below). = Quoting >>> the draft: >>>=20 >>> TCP ACK Pull defines the AKP flag as bit number 6 of the 13th = byte of >>> the TCP header. >>=20 >> [CG] I think that Neal referred to section 5.4 of the requirements = draft >> ("A new 'ACK Pull' TCP option"). >=20 > Yes, as Carles says, when I mentioned "AKP option" I was referring to > the alternative discussed in section 5.4, "A new 'ACK Pull' TCP > option", which does not burn a flag bit: >=20 > = https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00#section-= 5.4 >=20 > When I mentioned "flag bit" I was referring to section 5.3, "TCP ACK > Pull (AKP) flag", which does burn a flag bit: >=20 > = https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00#section-= 5.3 >=20 >>> (BTW, Carles, in this quoted sentence, you ought to call it "the TCP = ACK >>> Pull /proposal/" otherwise sounds like it's an official part of TCP >>> already.) >>=20 >> [CG] Well noted, thanks! (Nevertheless, if that other document went >> ahead, I guess that "proposal" would need to be eventually removed.) >>=20 >>>> The AKP option may be stripped by some middleboxes, but (a) as a >>>> performance optimization, that should be acceptable, and (b) for = the >>>> datacenter case (where cwnd=3D1 is a motivating use case) this = should >>>> not be a concern. >>>>=20 >>>> IMHO a flag bit makes sense for a small signal that a sender might >>>> want to send frequently or at a high rate, but senders should not = be >>>> trying to force immediate ACKs frequently. >>>=20 >>> [BB] For me, the problem with the AKP approach is that it's /only/ >>> really good in environments where you've got a small window. When = you >>> have a large window and you can cope with a certain ACK ratio (say >>> 1:16), you would have to set AKP on every 16th packet, which doesn't >>> really express what the sender wants (and if the receiver had just = sent >>> an ACK of its own accord just before it got one of these regular AKP >>> requests, should it send another?). The sender in this case really = wants >>> to say "I don't particularly mind which packets you ACK, but there's = no >>> need to do it more often than 1:16". >>>=20 >>> I think there's some mileage in a TCP Option that aggregates a few >>> behaviours together under one new TCP Option. I reckon 3 bits would = be >>> enough for a good delayed ACK option, but a whole TCP Option for = that >>> could be overkill. There was going to be a talk about a low latency = TCP >>> Option in netdev0x14 before it was postponed (sorry I don't remember = who >>> by). That might be a good excuse to collect together a few related >>> functions. It could also improve the deployment incentives. >>=20 >> [CG] Thanks for the comments! >>=20 >> [CG] It seems that there are two different areas where avoiding the >> typical Delayed ACKs approach may be of particular interest: i) = scenarios >> where very small window sizes are used (cwnd=3D1), and ii) scenarios = where >> large window sizes, and high ACK ratios, can be used. We will reflect >> these considerations in the next draft update. >=20 > Yes, I wholeheartedly agree with Bob's point that it's also extremely > useful for TCP senders to be able to say things like: "I don't > particularly mind which packets you ACK, but there's no need to do it > more often than 1:16". QUIC has a mechanism like this, and it seems to > allow significant CPU savings, even allowing QUIC to run faster than > TCP in some cases, AFAICT due to the reduced overhead for handling > ACKs: > = https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency= > https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 >=20 > So I agree with the usefulness of the two-use-case taxonomy Carles has = outlined: >=20 > 1: "please ACK now"; because sender's cwnd is low >=20 > 2: "ACK at frequency K"; because sender's cwnd is high >=20 > It seems those could both be addressed cleanly with one or two TCP > option kinds. A single TCP option kind might suffice if the ACK > frequency of 0 or 1 is taken to mean "please ACK now". I might be useful if the sender can trigger an ACK for this particular = packet, but leave the rate unchanged. And change the rate from now on. If using an option, you could encode "send an ack for this packet, but = don't change the ack rate" by using 0, and encode "change the ack rate to 1 = for n" by using n, n > 0. Best regards Michael >=20 > best, > neal >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat May 2 07:35:05 2020 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 716EC3A12E7 for ; Sat, 2 May 2020 07:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 hFn_wWDwEzRe for ; Sat, 2 May 2020 07:34:58 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 9F79E3A12E6 for ; Sat, 2 May 2020 07:34:58 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id t8so4821399uap.3 for ; Sat, 02 May 2020 07:34:58 -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=5sKyEhS+r2iR3EhJKWYQgZ13NDDdqLgBC1XNp0mdGtM=; b=Swjvjc24OptB6n3DIGvKb9/Gj7gVYF0XoZ50caq0YINxjDj1dRzDVPQOV5qc5jqW0t FzQhSlCm52/5gRJ6uXtjwZW+mOmnxCLp8mwWrx87EtWestzSrknTnRGoUUKdw4+vTpcv mRCpWvUIaC50CYuU4TjJU2fkefVg5z0PJC3NE/i0sjFVAX/bHRhbTe5EkJxXwSM0qyg4 wfyejl2QWa8wvBhEWHqRhPCSywOfraNaqfQgpuewvwiz1m55JQdQdv90KrV2lwRDkz+v HMJQjwKYDMHS9l1mn9b+Aw2sZsZy2tqaWtPrhsZrCq66ltIx+E9wi6Gm42Bx88qlz4KL LjtA== 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=5sKyEhS+r2iR3EhJKWYQgZ13NDDdqLgBC1XNp0mdGtM=; b=MUAaNIYvaZZyIgcnXKoVB2kO7yyOXi/hbAl9srZ5nyQSvITVcD3WaGktLNC+uupjTy Hy9y5C80bL0i4iupNyGU+uGqB2nO7PIAqZqMCrMlAgdRCNxg71QV2VqXw/h7zAI6qMW+ 3zSXaTnEPZa1gt1agoIKDwRoq69Pq/6KC6I7EckvaMFgVmP9hlLmJf/98GSTH8HK0uof MoKs8GkAlHS10JiNVhgZevsYLeGuDLmzs6LUvfflW6YU2DJkPEenxXWEFdUgrtkr85bU eaimmDtSWD1s8aj+DC5dPCIqotrRetMVuCGq+gxe08GEYdP7PlC2+Ec4jTrbar4EigOZ MOGw== X-Gm-Message-State: AGi0PuabPoKOyrM1a63Q9U4mGCXuk3Llwti4vtzizfKeFsC+9p5MWt1a GroHxuR9Lh2UGeubW4RCZlJjt6rvKXWcBash9/esEA== X-Google-Smtp-Source: APiQypJN7l+fJRn1FbmYynOkkVNpFblg0obicwyUAROLB5UDeDU0WTSjzN09drEy3yuJILdH0BSUcscBWRaDAZtQSGM= X-Received: by 2002:a9f:2065:: with SMTP id 92mr5789822uam.33.1588430097218; Sat, 02 May 2020 07:34:57 -0700 (PDT) MIME-Version: 1.0 References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> In-Reply-To: <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> From: Neal Cardwell Date: Sat, 2 May 2020 10:34:40 -0400 Message-ID: To: Michael Tuexen Cc: Carles Gomez Montenegro , jon.crowcroft@cl.cam.ac.uk, "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 02 May 2020 14:35:02 -0000 On Sat, May 2, 2020 at 10:26 AM Michael Tuexen wrote: > > > On 2. May 2020, at 16:10, Neal Cardwell wrote: > > > > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro ... > >> [CG] It seems that there are two different areas where avoiding the > >> typical Delayed ACKs approach may be of particular interest: i) scenarios > >> where very small window sizes are used (cwnd=1), and ii) scenarios where > >> large window sizes, and high ACK ratios, can be used. We will reflect > >> these considerations in the next draft update. > > > > Yes, I wholeheartedly agree with Bob's point that it's also extremely > > useful for TCP senders to be able to say things like: "I don't > > particularly mind which packets you ACK, but there's no need to do it > > more often than 1:16". QUIC has a mechanism like this, and it seems to > > allow significant CPU savings, even allowing QUIC to run faster than > > TCP in some cases, AFAICT due to the reduced overhead for handling > > ACKs: > > https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency > > https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 > > > > So I agree with the usefulness of the two-use-case taxonomy Carles has outlined: > > > > 1: "please ACK now"; because sender's cwnd is low > > > > 2: "ACK at frequency K"; because sender's cwnd is high > > > > It seems those could both be addressed cleanly with one or two TCP > > option kinds. A single TCP option kind might suffice if the ACK > > frequency of 0 or 1 is taken to mean "please ACK now". > I might be useful if the sender can trigger an ACK for this particular packet, > but leave the rate unchanged. And change the rate from now on. > If using an option, you could encode "send an ack for this packet, but don't > change the ack rate" by using 0, and encode "change the ack rate to 1 for n" > by using n, n > 0. Yes, that sounds like a very nice idea. best, neal From nobody Sat May 2 07:55:45 2020 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 95F813A133D for ; Sat, 2 May 2020 07:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 UfbPq-LwQ6LV for ; Sat, 2 May 2020 07:55:38 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 342A03A133A for ; Sat, 2 May 2020 07:55:38 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id z2so7674065iol.11 for ; Sat, 02 May 2020 07:55:38 -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=4Id3x2BCOTD4v3pMt6gOMKFQaYWwaWHXDb5Wnd0QfeM=; b=AShP4oCmWcMH+1znat4S+zmwxQrxp6mpmYNkBIrarFc1jj6vgGQWURX+lNuqjWlliO HtirfVCdTOA6IvCEfLwkUMk+PFhiUVUkO1IvQqTjmpsnlzww4iDOrmgXjRFI3BdIGSCA C6w1k/9BERefeU4O8JraUTkvvfbj6FsR410l4/8w/Q/PqHsG/ljyF5ENBjri8Llm6pcI fkJogQHwAdUsdRM25rTcQHEfj5ULJ6noS5uVdeYMYr8rWBZn26C0Mm78R5Q1Gs1QLxRt jRo5eAqoxf3koGjwGnZY6mgZQ3b0wXxZXZ+uY3kidNMZ0+haQyxevH8YQ+DYAgrto0Ey p+Ug== 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=4Id3x2BCOTD4v3pMt6gOMKFQaYWwaWHXDb5Wnd0QfeM=; b=PJ7ia+gGOz/ksfM2HLannsINvv6wlkFoTf+5JfmmLBiAh6WvtNUZTKzjNXxdT5MTmN OsZjI3DjAYuFTTCLMECv6bUouUeOk4k31jX7jzCHme+TzH3MiOKzepj8z+kZOB0Owyw1 s8f5MvtXWyP3QlsEWChhIsQLLmz8w3WGz4aCCppp/i4ryh7VL+EuXi83ohyt8t8NDb0A fqO5erJ0Bc2GHcV8SkcEa2OSvcbEm8dmfWoO/4UpzxStLwnGFnjNSa7Z2DtbPTiOzhi5 hcbmpL6CT153W5pm3N2BuvZdRaBP7wNV7AOKvPTbOgSNVO0qP2RriGEGHHDu0Pw19486 ZB1A== X-Gm-Message-State: AGi0PuYlokPU8xTrZ5OalCXLegX7X/Nsev389/sCsWQL54WEKeKyvTTt 5WQYWNo56vTzuSCvyi3SivXG5KJ9ZCl2YmQnEHkTZA== X-Google-Smtp-Source: APiQypLG4RArtm4+yJdHw+/ozb6Tj7jaD11eMkCynOYjlAacrwP4bixJuoclWbxHnNxNhG0BxuJifpU7K7AgRxGru7g= X-Received: by 2002:a5d:914b:: with SMTP id y11mr8556048ioq.3.1588431336987; Sat, 02 May 2020 07:55:36 -0700 (PDT) MIME-Version: 1.0 References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> In-Reply-To: From: Matt Mathis Date: Sat, 2 May 2020 07:55:25 -0700 Message-ID: To: Neal Cardwell Cc: Michael Tuexen , Jon Crowcroft , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000097bcb105a4ab7d5d" Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 02 May 2020 14:55:43 -0000 --00000000000097bcb105a4ab7d5d Content-Type: text/plain; charset="UTF-8" Another probably small opportunity would be to make the RTT estimators less noisy, by having the receiver always ACK the first (or last) TSO segment. The RTT is currently fuzzed by both del ACK and TCP strides. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay We must not tolerate intolerance; however our response must be carefully measured: too strong would be hypocritical and risks spiraling out of control; too weak risks being mistaken for tacit approval. On Sat, May 2, 2020 at 7:35 AM Neal Cardwell wrote: > On Sat, May 2, 2020 at 10:26 AM Michael Tuexen > wrote: > > > > > On 2. May 2020, at 16:10, Neal Cardwell 40google.com@dmarc.ietf.org> wrote: > > > > > > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro > .... > > >> [CG] It seems that there are two different areas where avoiding the > > >> typical Delayed ACKs approach may be of particular interest: i) > scenarios > > >> where very small window sizes are used (cwnd=1), and ii) scenarios > where > > >> large window sizes, and high ACK ratios, can be used. We will reflect > > >> these considerations in the next draft update. > > > > > > Yes, I wholeheartedly agree with Bob's point that it's also extremely > > > useful for TCP senders to be able to say things like: "I don't > > > particularly mind which packets you ACK, but there's no need to do it > > > more often than 1:16". QUIC has a mechanism like this, and it seems to > > > allow significant CPU savings, even allowing QUIC to run faster than > > > TCP in some cases, AFAICT due to the reduced overhead for handling > > > ACKs: > > > > https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency > > > https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 > > > > > > So I agree with the usefulness of the two-use-case taxonomy Carles has > outlined: > > > > > > 1: "please ACK now"; because sender's cwnd is low > > > > > > 2: "ACK at frequency K"; because sender's cwnd is high > > > > > > It seems those could both be addressed cleanly with one or two TCP > > > option kinds. A single TCP option kind might suffice if the ACK > > > frequency of 0 or 1 is taken to mean "please ACK now". > > I might be useful if the sender can trigger an ACK for this particular > packet, > > but leave the rate unchanged. And change the rate from now on. > > If using an option, you could encode "send an ack for this packet, but > don't > > change the ack rate" by using 0, and encode "change the ack rate to 1 > for n" > > by using n, n > 0. > > Yes, that sounds like a very nice idea. > > best, > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000097bcb105a4ab7d5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another probably small opportunity would be to make the RT= T estimators less noisy, by having the receiver always ACK the first (or la= st) TSO segment.=C2=A0 =C2=A0The RTT is currently fuzzed by both del ACK an= d TCP strides.

Thanks,
--MM--
The best way to = predict the future is to create it. =C2=A0- Alan Kay

We must not tol= erate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however= our response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypocritical and risks spirali= ng out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too = weak risks being mistaken for tacit approval.
=


On Sat, May 2, 2020 at 7:35 AM Neal Cardwell <ncar= dwell=3D40google.com@dmarc.i= etf.org> wrote:
On Sat, May 2, 2020 at 10:26 AM Michael Tuexen
<m= ichael.tuexen@lurchi.franken.de> wrote:
>
> > On 2. May 2020, at 16:10, Neal Cardwell <ncardwell=3D40google.com@dmar= c.ietf.org> wrote:
> >
> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro
....
> >> [CG] It seems that there are two different areas where avoidi= ng the
> >> typical Delayed ACKs approach may be of particular interest: = i) scenarios
> >> where very small window sizes are used (cwnd=3D1), and ii) sc= enarios where
> >> large window sizes, and high ACK ratios, can be used. We will= reflect
> >> these considerations in the next draft update.
> >
> > Yes, I wholeheartedly agree with Bob's point that it's al= so extremely
> > useful for TCP senders to be able to say things like: "I don= 't
> > particularly mind which packets you ACK, but there's no need = to do it
> > more often than 1:16". QUIC has a mechanism like this, and i= t seems to
> > allow significant CPU savings, even allowing QUIC to run faster t= han
> > TCP in some cases, AFAICT due to the reduced overhead for handlin= g
> > ACKs:
> >=C2=A0 https://ww= w.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency
> >=C2=A0 https://tools.ietf.org/= html/draft-iyengar-quic-delayed-ack-00
> >
> > So I agree with the usefulness of the two-use-case taxonomy Carle= s has outlined:
> >
> > 1: "please ACK now"; because sender's cwnd is low > >
> > 2: "ACK at frequency K"; because sender's cwnd is h= igh
> >
> > It seems those could both be addressed cleanly with one or two TC= P
> > option kinds. A single TCP option kind might suffice if the ACK > > frequency of 0 or 1 is taken to mean "please ACK now".<= br> > I might be useful if the sender can trigger an ACK for this particular= packet,
> but leave the rate unchanged. And change the rate from now on.
> If using an option, you could encode "send an ack for this packet= , but don't
> change the ack rate" by using 0, and encode "change the ack = rate to 1 for n"
> by using n, n > 0.

Yes, that sounds like a very nice idea.

best,
neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--00000000000097bcb105a4ab7d5d-- From nobody Sat May 2 20:21:45 2020 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 DAF063A1348 for ; Sat, 2 May 2020 20:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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=apple.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 4EGNBsAStdFV for ; Sat, 2 May 2020 20:21:42 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 5FB7B3A1347 for ; Sat, 2 May 2020 20:21:42 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0433F3Te048975; Sat, 2 May 2020 20:21:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=c3wA8pPy94B3gtL8OFQILyE69XpAoIzPV+tJFgtVmPo=; b=HKoby0YD1nW/xh+/+/BVSoFbdhXkqxGZCh4nB9S+1g1dffVrg2S5D4FawdkvAGjlWdSH wjoSW5c94HsjbAagPT8P8s91NnGSJMsC/F1Qx4ghio3qIfBlEfGWdHvlUNBnZnMHNMdU 499XrtXqMXgrMhl6eHaqXYN9ER87SGTKa8wMqIF6zxqvl9QWIWSOWfy6wQ1EMWlaSsxV S5UfiRKFmLKPwq8F54zhdw5TcXqV1C2PT3AYUSiXfC06Uw6DddAimHc/MvUhhzTllYJg fLwQbrmDuhE7TLr5OnpHLZQ5rPLz7NRV9Sp5aJC9Z1nmKtXOjtaK62T3bYTCI1U4z4c3 Qw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 30s5hrum7n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 02 May 2020 20:21:16 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9Q00Y3FJZFRL30@rn-mailsvcp-mta-lapp02.rno.apple.com>; Sat, 02 May 2020 20:21:15 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9Q00H00JKOBV00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Sat, 02 May 2020 20:21:15 -0700 (PDT) X-Va-A: X-Va-T-CD: 2f95281216c8a929340b3b08893ca44f X-Va-E-CD: bc8decff378cc134416bbd31db2ade2c X-Va-R-CD: 565b461b119590696dc32e8713b2a42a X-Va-CD: 0 X-Va-ID: 321ef7ec-b023-4196-8b2e-7cbc14aece01 X-V-A: X-V-T-CD: 2f95281216c8a929340b3b08893ca44f X-V-E-CD: bc8decff378cc134416bbd31db2ade2c X-V-R-CD: 565b461b119590696dc32e8713b2a42a X-V-CD: 0 X-V-ID: 2adfce89-5065-411c-bb6d-f27cde890a2c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-02_13:2020-05-01, 2020-05-02 signatures=0 Received: from vimac.scv.apple.com (vimac.scv.apple.com [17.192.171.33]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9Q006EVJZF3I00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Sat, 02 May 2020 20:21:15 -0700 (PDT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.13.2.1\)) From: Vidhi Goel X-Priority: 3 (Normal) In-reply-to: <6b11e0a37698146c8e2bad6052634452.squirrel@webmail.entel.upc.edu> Date: Sat, 02 May 2020 20:21:15 -0700 Cc: Yuchung Cheng , "tcpm@ietf.org Extensions" , jon.crowcroft@cl.cam.ac.uk Content-transfer-encoding: quoted-printable Message-id: References: <23157b5e4063646449099e97eccde0f3.squirrel@webmail.entel.upc.edu> <6b11e0a37698146c8e2bad6052634452.squirrel@webmail.entel.upc.edu> To: Carles Gomez Montenegro X-Mailer: Apple Mail (2.3608.80.13.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-02_13:2020-05-01, 2020-05-02 signatures=0 Archived-At: Subject: Re: [tcpm] question regarding draft-gomez-tcpm-delack-suppr-reqs 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: Sun, 03 May 2020 03:21:44 -0000 Hi Carles, >> I agree. We in fact implemented Linux to increase cwnd by the exact >> amount sequence (in unit of packets) so slow-start increase function = is >> regardless of ack-thinning effect but purely based on amount >> delivered. This has an important effect on >> Wireless as the other ack talk mentions. It also helps in case of ACK >> losses or reordering. >=20 > Agreed! >=20 > By the way, in the next draft update, we will add that, despite its > "Experimental" status, ABC is supported in many implementations. Some time ago, I had brought up this same problem with ABC (RFC 3465) = that increasing by at most one MSS during slow start makes the growth = some what non-exponential in cases where ACK ratio < 1 (for example, = receivers doing GRO or ACK compression, ACK losses etc). To allow an = exponential growth, we should certainly increase congestion window by = the amount of bytes ACKed (what Linux does). Vidhi=20 > On May 2, 2020, at 1:34 AM, Carles Gomez Montenegro = wrote: >=20 > Hi Yuchung, >=20 > >=20 >>> Note that the problem pointed out is that, as stated in the RFC 5681 >>> text >>> above: >>>=20 >>> "During slow start, a TCP increments cwnd by at most SMSS bytes = for >>> each ACK received that cumulatively acknowledges new data" >>>=20 >>> It may be desirable to support, during slow start, a cwnd increase = by >>> more >>> than SMSS per each ACK acknowledging new data. >> I agree. We in fact implemented Linux to increase cwnd by the exact >> amount sequence (in unit of packets) so slow-start increase function = is >> regardless of ack-thinning effect but purely based on amount >> delivered. This has an important effect on >> Wireless as the other ack talk mentions. It also helps in case of ACK >> losses or reordering. >=20 > Agreed! >=20 > By the way, in the next draft update, we will add that, despite its > "Experimental" status, ABC is supported in many implementations. >=20 > >=20 > Thanks, >=20 > Carles >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon May 4 05:16:14 2020 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 60DA33A0832 for ; Mon, 4 May 2020 05:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 9XDMis_H-o7g for ; Mon, 4 May 2020 05:16:11 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id D717C3A083F for ; Mon, 4 May 2020 05:16:10 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3A8811B0007A; Mon, 4 May 2020 13:16:02 +0100 (BST) To: Matt Mathis , Neal Cardwell Cc: Michael Tuexen , "tcpm@ietf.org" , Jon Crowcroft References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> From: Gorry Fairhurst Message-ID: <54809559-05ef-b104-6cee-e61c8231dbae@erg.abdn.ac.uk> Date: Mon, 4 May 2020 13:16:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FA43BCB4611E9EAE8CBE621F" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 04 May 2020 12:16:13 -0000 This is a multi-part message in MIME format. --------------FA43BCB4611E9EAE8CBE621F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 02/05/2020 15:55, Matt Mathis wrote: > Another probably small opportunity would be to make the RTT estimators > less noisy, by having the receiver always ACK the first (or last) TSO > segment.   The RTT is currently fuzzed by both del ACK and TCP strides. > I agree this might help: The TCP spec lets receivers do this right now, if they wish to? > Thanks, > --MM-- > The best way to predict the future is to create it.  - Alan Kay > > We must not tolerate intolerance; >        however our response must be carefully measured: >             too strong would be hypocritical and risks spiraling out > of control; >   too weak risks being mistaken for tacit approval. > > > On Sat, May 2, 2020 at 7:35 AM Neal Cardwell > > wrote: > > On Sat, May 2, 2020 at 10:26 AM Michael Tuexen > > wrote: > > > > > On 2. May 2020, at 16:10, Neal Cardwell > > wrote: > > > > > > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro > ..... > > >> [CG] It seems that there are two different areas where > avoiding the > > >> typical Delayed ACKs approach may be of particular interest: > i) scenarios > > >> where very small window sizes are used (cwnd=1), and ii) > scenarios where > > >> large window sizes, and high ACK ratios, can be used. We will > reflect > > >> these considerations in the next draft update. > > > > > > Yes, I wholeheartedly agree with Bob's point that it's also > extremely > > > useful for TCP senders to be able to say things like: "I don't > > > particularly mind which packets you ACK, but there's no need > to do it > > > more often than 1:16". QUIC has a mechanism like this, and it > seems to > > > allow significant CPU savings, even allowing QUIC to run > faster than > > > TCP in some cases, AFAICT due to the reduced overhead for handling > > > ACKs: > > > > https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency > > > https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 > > > > QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or ACK content, it's likely an extension to the spec in the future. Anyway, I don't think TCP is the same as QUIC - TCP's notion of pacing is different; TCP's design differs, and there are many flavours and apps that use TCP in different ways. Changing the ACK policy and usage also brings lots of trade-offs: some may be good in some use-cases, but also can work out really bad if the design doesn't match the application/network path. > > > So I agree with the usefulness of the two-use-case taxonomy > Carles has outlined: > > > > > > 1: "please ACK now"; because sender's cwnd is low > > > > > > 2: "ACK at frequency K"; because sender's cwnd is high > > > > > > It seems those could both be addressed cleanly with one or two TCP > > > option kinds. A single TCP option kind might suffice if the ACK > > > frequency of 0 or 1 is taken to mean "please ACK now". > > I might be useful if the sender can trigger an ACK for this > particular packet, > > but leave the rate unchanged. And change the rate from now on. > > If using an option, you could encode "send an ack for this > packet, but don't > > change the ack rate" by using 0, and encode "change the ack rate > to 1 for n" > > by using n, n > 0. > > Yes, that sounds like a very nice idea. > > best, > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > I like that also. An option calling for an ACK-now, seems a little reminiscent of the way some stacks used "PUSH". I can immediately see some good things about eliciting that immediate response for a particular sequence number. Gorry > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------FA43BCB4611E9EAE8CBE621F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 02/05/2020 15:55, Matt Mathis wrote:
Another probably small opportunity would be to make the RTT estimators less noisy, by having the receiver always ACK the first (or last) TSO segment.   The RTT is currently fuzzed by both del ACK and TCP strides.

I agree this might help: The TCP spec lets receivers do this right now, if they wish to?
Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured: 
            too strong would be hypocritical and risks spiraling out of control;
  too weak risks being mistaken for tacit approval.



On Sat, May 2, 2020 at 7:35 AM Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:
On Sat, May 2, 2020 at 10:26 AM Michael Tuexen
<michael.tuexen@lurchi.franken.de> wrote:
>
> > On 2. May 2020, at 16:10, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:
> >
> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro
.....
> >> [CG] It seems that there are two different areas where avoiding the
> >> typical Delayed ACKs approach may be of particular interest: i) scenarios
> >> where very small window sizes are used (cwnd=1), and ii) scenarios where
> >> large window sizes, and high ACK ratios, can be used. We will reflect
> >> these considerations in the next draft update.
> >
> > Yes, I wholeheartedly agree with Bob's point that it's also extremely
> > useful for TCP senders to be able to say things like: "I don't
> > particularly mind which packets you ACK, but there's no need to do it
> > more often than 1:16". QUIC has a mechanism like this, and it seems to
> > allow significant CPU savings, even allowing QUIC to run faster than
> > TCP in some cases, AFAICT due to the reduced overhead for handling
> > ACKs:
> >  https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency
> >  https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00
> >

QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or ACK content, it's likely an extension to the spec in the future. Anyway, I don't think TCP is the same as QUIC - TCP's notion of pacing is different; TCP's design differs, and there are many flavours and apps that use TCP in different ways.

Changing the ACK policy and usage also brings lots of trade-offs: some may be good in some use-cases, but also can work out really bad if the design doesn't match the application/network path.

> > So I agree with the usefulness of the two-use-case taxonomy Carles has outlined:
> >
> > 1: "please ACK now"; because sender's cwnd is low
> >
> > 2: "ACK at frequency K"; because sender's cwnd is high
> >
> > It seems those could both be addressed cleanly with one or two TCP
> > option kinds. A single TCP option kind might suffice if the ACK
> > frequency of 0 or 1 is taken to mean "please ACK now".
> I might be useful if the sender can trigger an ACK for this particular packet,
> but leave the rate unchanged. And change the rate from now on.
> If using an option, you could encode "send an ack for this packet, but don't
> change the ack rate" by using 0, and encode "change the ack rate to 1 for n"
> by using n, n > 0.

Yes, that sounds like a very nice idea.

best,
neal

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


I like that also. An option calling for an ACK-now, seems a little reminiscent of the way some stacks used "PUSH". I can immediately see some good things about eliciting that immediate response for a particular sequence number.

Gorry

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--------------FA43BCB4611E9EAE8CBE621F-- From nobody Mon May 4 06:14:57 2020 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 80E5E3A087D for ; Mon, 4 May 2020 06:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Bp8PsOZ8JesR for ; Mon, 4 May 2020 06:14:53 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 AE46E3A0879 for ; Mon, 4 May 2020 06:14:52 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id k12so8355370wmj.3 for ; Mon, 04 May 2020 06:14:52 -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=KCiMhPelcWcC60VdRx46bLiYQlsw1uhX0ZsjlGChRxU=; b=n5/LP2Ni04K9/t0qEDfm3zW51CbvCuHoEVcS4OAz8xd9pjS378M9gp6T1AK5e9y6iH UrwvwhGckaX68nwP5Gb/OYhDy6OGVRltMyBHhG6bddWlrLIh+81BSUwbISOQt8Z1OBHI wGPuAY8GDrwe2julDIMqO9Zu9Fn5GtemkKMtvsT+uFd7yh7WlcqOpouLlKE+5TWtoJwN YYb7WBHjTpFps/o7qNRTcWkGYHWjc+JgB2rrTk3ktXlk6jnjhCLxoDuvnBd3Jb9CEitr Y0wzXYzLf88VFxuSeMRzbiE+H1D3OOXKQJFJSpWrx8cSRpT+2q7wCW0qNwmE1TEoEi11 UE5A== 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=KCiMhPelcWcC60VdRx46bLiYQlsw1uhX0ZsjlGChRxU=; b=Rrdv+D0EZ7fvUsywoY9vwOcb/ITAqEV9nLLN/wmKqsynQEqQH/g5DJ7pEYQiTHLPBU 77SdJ2s92NFvIFC2nl2eVpJnMwMhnBX1Bg9KpyuuJaT9fTr+ULZQHCEu0TUxZHYzdAAy SWbbNAei9B7kUfW4nTdv3k21+bRtDoq8qZqzUCC+PqUy1UAjhkh0/nHJHN4MuR3eGfoC 6ST0/wYt32KcNspUZ4xyAXD5YdbCuhVx+9wIh/l9tcxhcZS/u9tpEqH0x3XlEnz/jNUp aBg6OQ2x3VHeRIa4bPnv7NoWersPwr8XEenP21Wl2RJ/YYY84LGIoBaDFRIzbjl5CiIB Plpg== X-Gm-Message-State: AGi0PuYGxX00NihHuvtalg88rS5NaUW47BpgrqbLIrFvrZffISILMpLH 60jp9Od9QQijVTPRL2t8PeOWfd1rIjDFpuxOGKaGLQ== X-Google-Smtp-Source: APiQypLhCevJTp/8FQ04MLRoPpcKRWh2W5CipWin36GZX0sIpahGHBiWGjMLsIeodO2OGrl3Yef+Q8qYCS4BcX3Pjz0= X-Received: by 2002:a1c:f306:: with SMTP id q6mr14508647wmq.169.1588598090887; Mon, 04 May 2020 06:14:50 -0700 (PDT) MIME-Version: 1.0 References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> <54809559-05ef-b104-6cee-e61c8231dbae@erg.abdn.ac.uk> In-Reply-To: <54809559-05ef-b104-6cee-e61c8231dbae@erg.abdn.ac.uk> From: Ian Swett Date: Mon, 4 May 2020 09:14:38 -0400 Message-ID: To: Gorry Fairhurst Cc: Matt Mathis , Neal Cardwell , Michael Tuexen , "tcpm@ietf.org" , Jon Crowcroft Content-Type: multipart/alternative; boundary="000000000000e6665105a4d25064" Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 04 May 2020 13:14:56 -0000 --000000000000e6665105a4d25064 Content-Type: text/plain; charset="UTF-8" On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst wrote: > > On 02/05/2020 15:55, Matt Mathis wrote: > > Another probably small opportunity would be to make the RTT estimators > less noisy, by having the receiver always ACK the first (or last) TSO > segment. The RTT is currently fuzzed by both del ACK and TCP strides. > > I agree this might help: The TCP spec lets receivers do this right now, if > they wish to? > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > We must not tolerate intolerance; > however our response must be carefully measured: > too strong would be hypocritical and risks spiraling out of > control; > > too weak risks being mistaken for tacit approval. > > > > On Sat, May 2, 2020 at 7:35 AM Neal Cardwell 40google.com@dmarc.ietf.org> wrote: > >> On Sat, May 2, 2020 at 10:26 AM Michael Tuexen >> wrote: >> > >> > > On 2. May 2020, at 16:10, Neal Cardwell > 40google.com@dmarc.ietf.org> wrote: >> > > >> > > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro >> ..... >> > >> [CG] It seems that there are two different areas where avoiding the >> > >> typical Delayed ACKs approach may be of particular interest: i) >> scenarios >> > >> where very small window sizes are used (cwnd=1), and ii) scenarios >> where >> > >> large window sizes, and high ACK ratios, can be used. We will reflect >> > >> these considerations in the next draft update. >> > > >> > > Yes, I wholeheartedly agree with Bob's point that it's also extremely >> > > useful for TCP senders to be able to say things like: "I don't >> > > particularly mind which packets you ACK, but there's no need to do it >> > > more often than 1:16". QUIC has a mechanism like this, and it seems to >> > > allow significant CPU savings, even allowing QUIC to run faster than >> > > TCP in some cases, AFAICT due to the reduced overhead for handling >> > > ACKs: >> > > >> https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency >> > > https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 >> > > >> > QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or > ACK content, it's likely an extension to the spec in the future. Anyway, I > don't think TCP is the same as QUIC - TCP's notion of pacing is different; > TCP's design differs, and there are many flavours and apps that use TCP in > different ways. > I'm curious about some of these comments. I agree TCP and QUIC are different(otherwise why standardize QUIC), but TCP's notion of pacing is no different from QUIC's in my opinion. Both have various ways to implement pacing, and neither has any spec specifying exactly how it should be done. For TCP, the closest I can find is RFC3449 . You seem to be implying that the set of apps which use TCP will always be wider than QUIC. If anything, I suspect the opposite is true, since QUIC can enable applications where 100% reliability is undesirable. > Changing the ACK policy and usage also brings lots of trade-offs: some may > be good in some use-cases, but also can work out really bad if the design > doesn't match the application/network path. > I completely agree. > > > So I agree with the usefulness of the two-use-case taxonomy Carles has >> outlined: >> > > >> > > 1: "please ACK now"; because sender's cwnd is low >> > > >> > > 2: "ACK at frequency K"; because sender's cwnd is high >> > > >> > > It seems those could both be addressed cleanly with one or two TCP >> > > option kinds. A single TCP option kind might suffice if the ACK >> > > frequency of 0 or 1 is taken to mean "please ACK now". >> > I might be useful if the sender can trigger an ACK for this particular >> packet, >> > but leave the rate unchanged. And change the rate from now on. >> > If using an option, you could encode "send an ack for this packet, but >> don't >> > change the ack rate" by using 0, and encode "change the ack rate to 1 >> for n" >> > by using n, n > 0. >> >> Yes, that sounds like a very nice idea. >> >> best, >> neal >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > > I like that also. An option calling for an ACK-now, seems a little > reminiscent of the way some stacks used "PUSH". I can immediately see some > good things about eliciting that immediate response for a particular > sequence number. > > Gorry > > _______________________________________________ > tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000e6665105a4d25064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 4, 2020 at 8:16 AM Gorry = Fairhurst <gorry@erg.abdn.ac.uk<= /a>> wrote:
=20 =20 =20


On 02/05/2020 15:55, Matt Mathis wrote:
=20
Another probably small opportunity would be to make the RTT estimators less noisy, by having the receiver always ACK the first (or last) TSO segment.=C2=A0 =C2=A0The RTT is currently f= uzzed by both del ACK and TCP strides.

I agree this might help: The TCP spec lets receivers do this right now, if they wish to?
Thanks,
--MM--
The best way to predict the future is to create it. =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however o= ur response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too st= rong would be hypocritical and risks spiraling out of control;
=C2=A0 too weak risks being mistaken for tacit approval.



On Sat, May 2, 2020 at 7:35 A= M Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
On Sat, May 2, 2020 at 10:26 AM Michael Tuexen
<michael.tuexen@lurchi.franken.de> wrote:
>
> > On 2. May 2020, at 16:10, Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
> >
> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro
.....
> >> [CG] It seems that there are two different areas where avoiding the
> >> typical Delayed ACKs approach may be of particular interest: i) scenarios
> >> where very small window sizes are used (cwnd=3D1), and ii) scenarios where
> >> large window sizes, and high ACK ratios, can be used. We will reflect
> >> these considerations in the next draft update.
> >
> > Yes, I wholeheartedly agree with Bob's point that it's also extremely
> > useful for TCP senders to be able to say things like: "I don't
> > particularly mind which packets you ACK, but there'= s no need to do it
> > more often than 1:16". QUIC has a mechanism like this, and it seems to
> > allow significant CPU savings, even allowing QUIC to run faster than
> > TCP in some cases, AFAICT due to the reduced overhead for handling
> > ACKs:
> >=C2=A0 = https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency<= /a>
> >=C2=A0 https://tools= .ietf.org/html/draft-iyengar-quic-delayed-ack-00
> >

QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or ACK content, it's likely an extension to the spec in the future. Anyway, I don't think TCP is the same as QUIC - TCP&#= 39;s notion of pacing is different; TCP's design differs, and there ar= e many flavours and apps that use TCP in different ways.


I'm curious about some of these comments.= =C2=A0 I agree TCP and QUIC are different(otherwise why standardize QUIC), = but TCP's notion of pacing is no different from QUIC's in my opinio= n.=C2=A0 Both have various ways to implement pacing, and neither has any sp= ec specifying exactly how it should be done.=C2=A0 For TCP, the closest I c= an find is RFC3= 449.=C2=A0 You seem to be implying that the set of apps which use TCP w= ill always be wider than QUIC.=C2=A0 If anything, I suspect the opposite is= true, since QUIC can enable applications where 100% reliability is undesir= able.

Changing the ACK policy and usage also brings lots of trade-offs: some may be good in some use-cases, but also can work out really bad if the design doesn't match the application/network path.

=
I completely agree.
> > So I agree with the usefulness of the two-use-case taxonomy Carles has outlined:
> >
> > 1: "please ACK now"; because sender's cwn= d is low
> >
> > 2: "ACK at frequency K"; because sender's= cwnd is high
> >
> > It seems those could both be addressed cleanly with one or two TCP
> > option kinds. A single TCP option kind might suffice if the ACK
> > frequency of 0 or 1 is taken to mean "please ACK now".
> I might be useful if the sender can trigger an ACK for this particular packet,
> but leave the rate unchanged. And change the rate from now on.
> If using an option, you could encode "send an ack for this packet, but don't
> change the ack rate" by using 0, and encode "chang= e the ack rate to 1 for n"
> by using n, n > 0.

Yes, that sounds like a very nice idea.

best,
neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tcpm


I like that also. An option calling for an ACK-now, seems a little reminiscent of the way some stacks used "PUSH". I ca= n immediately see some good things about eliciting that immediate response for a particular sequence number.

Gorry

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000e6665105a4d25064-- From nobody Mon May 4 06:38:59 2020 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 0203E3A08A7 for ; Mon, 4 May 2020 06:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 am9EbYalwtjE for ; Mon, 4 May 2020 06:38:56 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF7A3A08A6 for ; Mon, 4 May 2020 06:38:55 -0700 (PDT) Received: from Gs-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B57D61B001FC; Mon, 4 May 2020 14:38:44 +0100 (BST) To: Ian Swett Cc: Matt Mathis , Neal Cardwell , Michael Tuexen , "tcpm@ietf.org" , Jon Crowcroft References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> <54809559-05ef-b104-6cee-e61c8231dbae@erg.abdn.ac.uk> From: Gorry Fairhurst Message-ID: <89b3c210-ac29-462e-daa1-373eeb4addf4@erg.abdn.ac.uk> Date: Mon, 4 May 2020 14:38:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------57C96426CBD9C9B3133770B3" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 04 May 2020 13:38:59 -0000 This is a multi-part message in MIME format. --------------57C96426CBD9C9B3133770B3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 04/05/2020 14:14, Ian Swett wrote: > > > On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst > wrote: > > > On 02/05/2020 15:55, Matt Mathis wrote: >> Another probably small opportunity would be to make the RTT >> estimators less noisy, by having the receiver always ACK the >> first (or last) TSO segment.   The RTT is currently fuzzed by >> both del ACK and TCP strides. >> > I agree this might help: The TCP spec lets receivers do this right > now, if they wish to? >> Thanks, >> --MM-- >> The best way to predict the future is to create it.  - Alan Kay >> >> We must not tolerate intolerance; >>        however our response must be carefully measured: >>             too strong would be hypocritical and risks spiraling >> out of control; >>   too weak risks being mistaken for tacit approval. >> >> > >> On Sat, May 2, 2020 at 7:35 AM Neal Cardwell >> > > wrote: >> >> On Sat, May 2, 2020 at 10:26 AM Michael Tuexen >> > > wrote: >> > >> > > On 2. May 2020, at 16:10, Neal Cardwell >> > > wrote: >> > > >> > > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro >> ..... >> > >> [CG] It seems that there are two different areas where >> avoiding the >> > >> typical Delayed ACKs approach may be of particular >> interest: i) scenarios >> > >> where very small window sizes are used (cwnd=1), and ii) >> scenarios where >> > >> large window sizes, and high ACK ratios, can be used. We >> will reflect >> > >> these considerations in the next draft update. >> > > >> > > Yes, I wholeheartedly agree with Bob's point that it's >> also extremely >> > > useful for TCP senders to be able to say things like: "I >> don't >> > > particularly mind which packets you ACK, but there's no >> need to do it >> > > more often than 1:16". QUIC has a mechanism like this, >> and it seems to >> > > allow significant CPU savings, even allowing QUIC to run >> faster than >> > > TCP in some cases, AFAICT due to the reduced overhead for >> handling >> > > ACKs: >> > > >> https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency >> > > https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 >> > > >> > QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, > timing, or ACK content, it's likely an extension to the spec in > the future. Anyway, I don't think TCP is the same as QUIC - TCP's > notion of pacing is different; TCP's design differs, and there are > many flavours and apps that use TCP in different ways. > > > I'm curious about some of these comments.  I agree TCP and QUIC are > different(otherwise why standardize QUIC), but TCP's notion of pacing > is no different from QUIC's in my opinion.  Both have various ways to > implement pacing, and neither has any spec specifying exactly how it > should be done.  For TCP, the closest I can find is RFC3449 > .  You seem to be > implying that the set of apps which use TCP will always be wider than > QUIC. QUIC seems to anticipate the need for pacing in its deisgn assumptions - I may be wrong? TCP has various recommendations that to me suggest pacing is a good idea (I would agree), but I expect lots of stacks do not implement burst mitigation. > If anything, I suspect the opposite is true, since QUIC can enable > applications where 100% reliability is undesirable. My comment was meant to say there are already a very wide range of protocols using TCP. From routing protocols, DNS, to other core protocols, to streaming video, to web, bulk transfer, IoT, transaction processing, etc. I was hoping to suggest that already many of these stacks have been optimised, and we are living with many decades of legacy and diversity. On the other hand, I agree QUIC has applicability to datagrams for instance where reliability is not required for data, so I do need to learn more about how/whether these will handle CC and pacing, etc. > Changing the ACK policy and usage also brings lots of trade-offs: > some may be good in some use-cases, but also can work out really > bad if the design doesn't match the application/network path. > > I completely agree. > >> > > So I agree with the usefulness of the two-use-case >> taxonomy Carles has outlined: >> > > >> > > 1: "please ACK now"; because sender's cwnd is low >> > > >> > > 2: "ACK at frequency K"; because sender's cwnd is high >> > > >> > > It seems those could both be addressed cleanly with one >> or two TCP >> > > option kinds. A single TCP option kind might suffice if >> the ACK >> > > frequency of 0 or 1 is taken to mean "please ACK now". >> > I might be useful if the sender can trigger an ACK for this >> particular packet, >> > but leave the rate unchanged. And change the rate from now on. >> > If using an option, you could encode "send an ack for this >> packet, but don't >> > change the ack rate" by using 0, and encode "change the ack >> rate to 1 for n" >> > by using n, n > 0. >> >> Yes, that sounds like a very nice idea. >> >> best, >> neal >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> > I like that also. An option calling for an ACK-now, seems a little > reminiscent of the way some stacks used "PUSH". I can immediately > see some good things about eliciting that immediate response for a > particular sequence number. > > Gorry > >> _______________________________________________ >> 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 > -- G. Fairhurst, School of Engineering Gorry --------------57C96426CBD9C9B3133770B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 04/05/2020 14:14, Ian Swett wrote:


On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:


On 02/05/2020 15:55, Matt Mathis wrote:
Another probably small opportunity would be to make the RTT estimators less noisy, by having the receiver always ACK the first (or last) TSO segment.   The RTT is currently fuzzed by both del ACK and TCP strides.

I agree this might help: The TCP spec lets receivers do this right now, if they wish to?
Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured: 
            too strong would be hypocritical and risks spiraling out of control;
  too weak risks being mistaken for tacit approval.



On Sat, May 2, 2020 at 7:35 AM Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:
On Sat, May 2, 2020 at 10:26 AM Michael Tuexen
<michael.tuexen@lurchi.franken.de> wrote:
>
> > On 2. May 2020, at 16:10, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:
> >
> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro
.....
> >> [CG] It seems that there are two different areas where avoiding the
> >> typical Delayed ACKs approach may be of particular interest: i) scenarios
> >> where very small window sizes are used (cwnd=1), and ii) scenarios where
> >> large window sizes, and high ACK ratios, can be used. We will reflect
> >> these considerations in the next draft update.
> >
> > Yes, I wholeheartedly agree with Bob's point that it's also extremely
> > useful for TCP senders to be able to say things like: "I don't
> > particularly mind which packets you ACK, but there's no need to do it
> > more often than 1:16". QUIC has a mechanism like this, and it seems to
> > allow significant CPU savings, even allowing QUIC to run faster than
> > TCP in some cases, AFAICT due to the reduced overhead for handling
> > ACKs:
> >  https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency
> >  https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00
> >

QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or ACK content, it's likely an extension to the spec in the future. Anyway, I don't think TCP is the same as QUIC - TCP's notion of pacing is different; TCP's design differs, and there are many flavours and apps that use TCP in different ways.


I'm curious about some of these comments.  I agree TCP and QUIC are different(otherwise why standardize QUIC), but TCP's notion of pacing is no different from QUIC's in my opinion.  Both have various ways to implement pacing, and neither has any spec specifying exactly how it should be done.  For TCP, the closest I can find is RFC3449.  You seem to be implying that the set of apps which use TCP will always be wider than QUIC.
QUIC seems to anticipate the need for pacing in its deisgn assumptions - I may be wrong? TCP has various recommendations that to me suggest pacing is a good idea (I would agree), but I expect lots of stacks do not implement burst mitigation.
If anything, I suspect the opposite is true, since QUIC can enable applications where 100% reliability is undesirable.

My comment was meant to say there are already a very wide range of protocols using TCP. From routing protocols, DNS, to other core protocols, to streaming video, to web, bulk transfer, IoT, transaction processing, etc. I was hoping to suggest that already many of these stacks have been optimised, and we are living with many decades of legacy and diversity.

On the other hand, I agree QUIC has applicability to datagrams for instance where reliability is not required for data, so I do need to learn more about how/whether these will handle CC and pacing, etc. 

Changing the ACK policy and usage also brings lots of trade-offs: some may be good in some use-cases, but also can work out really bad if the design doesn't match the application/network path.

I completely agree.
> > So I agree with the usefulness of the two-use-case taxonomy Carles has outlined:
> >
> > 1: "please ACK now"; because sender's cwnd is low
> >
> > 2: "ACK at frequency K"; because sender's cwnd is high
> >
> > It seems those could both be addressed cleanly with one or two TCP
> > option kinds. A single TCP option kind might suffice if the ACK
> > frequency of 0 or 1 is taken to mean "please ACK now".
> I might be useful if the sender can trigger an ACK for this particular packet,
> but leave the rate unchanged. And change the rate from now on.
> If using an option, you could encode "send an ack for this packet, but don't
> change the ack rate" by using 0, and encode "change the ack rate to 1 for n"
> by using n, n > 0.

Yes, that sounds like a very nice idea.

best,
neal

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


I like that also. An option calling for an ACK-now, seems a little reminiscent of the way some stacks used "PUSH". I can immediately see some good things about eliciting that immediate response for a particular sequence number.

Gorry

_______________________________________________
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
-- 
G. Fairhurst, School of Engineering


Gorry
--------------57C96426CBD9C9B3133770B3-- From nobody Mon May 4 06:58:19 2020 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 774893A08C9; Mon, 4 May 2020 06:58:17 -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.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158860069744.3950.3308140997730331697@ietfa.amsl.com> Date: Mon, 04 May 2020 06:58:17 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 13:58:17 -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 : Requirements for Time-Based Loss Detection Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-12.txt Pages : 10 Date : 2020-05-04 Abstract: Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, protocols ultimately can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-12 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 4 07:04:13 2020 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 013613A08E4 for ; Mon, 4 May 2020 07:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 IpmrZOSfQmJI for ; Mon, 4 May 2020 07:04:09 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 713553A08E6 for ; Mon, 4 May 2020 07:04:09 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id z6so9213122wml.2 for ; Mon, 04 May 2020 07:04:09 -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=0QGRN7jGbSmyQSYiFdLvu9GyZR2oazqFh98iFcKSwro=; b=ak9p0zUPODwFWBrxMQmiCC8Zb9XHdqsVYJ37K3GIYajvqUgbk0M4mTkjw0IWfHmm8k VATPIGNLXAQQeL4e5FPGm8eQ8hbRoY5Q3zZyyYaiNGp5Aa5DVgldvTyGZTZmqn9k8XjV 2RRAbs5yQHHwzO45KPo3Q6DtSJ5TaNUQFxxZRGVza96CegMNaKybbe2tBDHXyoU2fuiF 6DESz9j9tTTFHyt6EazPVfp1nbV4aVGDs3IAnK3Qc72BFt1rZHu5CTxSKdk9bRpa9rjM 0cN18B0aWYtq5pOUM43sQ94s4qDcz7KLrJhcV3nEnFFtF8goKhF1sBfv6Uquzz03En7J 2N4Q== 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=0QGRN7jGbSmyQSYiFdLvu9GyZR2oazqFh98iFcKSwro=; b=qx0QV/DTVJ/poJMImMBJn5yDr2KKwIRjVvRSqTuyzTUI4LB4kcbpBl+s/OaqXLswvn zZERmg73sYsrUyoGIQs+6sM1QIEV3sy4CdwhvcupdAr+9XzkFd/vU3qvTlXJ8pb+0qE8 vwn5vTYnXTGq/Z3vU1RbU9B46GUplLDx7ngN1ve0Kdpgc+1xaHIICsihhJnRVispy4DZ acdrTp7iSxCJPLc1s9+TxsuIqJC/A/C3R8qaYSj63lOs3Zt6QRPCDCkUBPAlF4BHfjIb 2xOGChTFWPngszbB81MaSrqRNfc0/c6IDDu1zk7UQbbZD3wmtEbVPgmDgiD+c2ajnW6q 4S+g== X-Gm-Message-State: AGi0Pua41JjP7qgtYV917BRywy/t5aD3/rdS5r0+xYsR9yxGlwyYqHm0 Wb3nVukAymiPwBekNVLITkDldNaLN12kJIinUd1HLg== X-Google-Smtp-Source: APiQypLoxpRbQnAfaloLaDoevaSDzw/5GwN7/2IQ4AMc65wTR6Dldv7lgATtlF8O7P4RoS9TOJub2ekDs7S9amG4iOE= X-Received: by 2002:a1c:4d17:: with SMTP id o23mr14541572wmh.120.1588601047565; Mon, 04 May 2020 07:04:07 -0700 (PDT) MIME-Version: 1.0 References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> <54809559-05ef-b104-6cee-e61c8231dbae@erg.abdn.ac.uk> <89b3c210-ac29-462e-daa1-373eeb4addf4@erg.abdn.ac.uk> In-Reply-To: <89b3c210-ac29-462e-daa1-373eeb4addf4@erg.abdn.ac.uk> From: Ian Swett Date: Mon, 4 May 2020 10:03:55 -0400 Message-ID: To: Gorry Fairhurst Cc: Matt Mathis , Neal Cardwell , Michael Tuexen , "tcpm@ietf.org" , Jon Crowcroft Content-Type: multipart/alternative; boundary="00000000000021bd2605a4d3016c" Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 04 May 2020 14:04:12 -0000 --00000000000021bd2605a4d3016c Content-Type: text/plain; charset="UTF-8" Thanks for the clarification. In implementation, I expect the status of pacing to be extremely similar for TCP and QUIC. Many stacks and applications that do it for TCP will do it for QUIC, and those which don't pace TCP probably won't bother with QUIC. On Mon, May 4, 2020 at 9:38 AM Gorry Fairhurst wrote: > > On 04/05/2020 14:14, Ian Swett wrote: > > > > On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst > wrote: > >> >> On 02/05/2020 15:55, Matt Mathis wrote: >> >> Another probably small opportunity would be to make the RTT estimators >> less noisy, by having the receiver always ACK the first (or last) TSO >> segment. The RTT is currently fuzzed by both del ACK and TCP strides. >> >> I agree this might help: The TCP spec lets receivers do this right now, >> if they wish to? >> >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> >> We must not tolerate intolerance; >> however our response must be carefully measured: >> too strong would be hypocritical and risks spiraling out of >> control; >> >> too weak risks being mistaken for tacit approval. >> >> >> >> On Sat, May 2, 2020 at 7:35 AM Neal Cardwell > 40google.com@dmarc.ietf.org> wrote: >> >>> On Sat, May 2, 2020 at 10:26 AM Michael Tuexen >>> wrote: >>> > >>> > > On 2. May 2020, at 16:10, Neal Cardwell >> 40google.com@dmarc.ietf.org> wrote: >>> > > >>> > > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro >>> ..... >>> > >> [CG] It seems that there are two different areas where avoiding the >>> > >> typical Delayed ACKs approach may be of particular interest: i) >>> scenarios >>> > >> where very small window sizes are used (cwnd=1), and ii) scenarios >>> where >>> > >> large window sizes, and high ACK ratios, can be used. We will >>> reflect >>> > >> these considerations in the next draft update. >>> > > >>> > > Yes, I wholeheartedly agree with Bob's point that it's also extremely >>> > > useful for TCP senders to be able to say things like: "I don't >>> > > particularly mind which packets you ACK, but there's no need to do it >>> > > more often than 1:16". QUIC has a mechanism like this, and it seems >>> to >>> > > allow significant CPU savings, even allowing QUIC to run faster than >>> > > TCP in some cases, AFAICT due to the reduced overhead for handling >>> > > ACKs: >>> > > >>> https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency >>> > > https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 >>> > > >>> >> QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or >> ACK content, it's likely an extension to the spec in the future. Anyway, I >> don't think TCP is the same as QUIC - TCP's notion of pacing is different; >> TCP's design differs, and there are many flavours and apps that use TCP in >> different ways. >> > > I'm curious about some of these comments. I agree TCP and QUIC are > different(otherwise why standardize QUIC), but TCP's notion of pacing is no > different from QUIC's in my opinion. Both have various ways to implement > pacing, and neither has any spec specifying exactly how it should be done. > For TCP, the closest I can find is RFC3449 > . You seem to be > implying that the set of apps which use TCP will always be wider than QUIC. > > QUIC seems to anticipate the need for pacing in its deisgn assumptions - I > may be wrong? TCP has various recommendations that to me suggest pacing is > a good idea (I would agree), but I expect lots of stacks do not implement > burst mitigation. > > If anything, I suspect the opposite is true, since QUIC can enable > applications where 100% reliability is undesirable. > > My comment was meant to say there are already a very wide range of > protocols using TCP. From routing protocols, DNS, to other core protocols, > to streaming video, to web, bulk transfer, IoT, transaction processing, > etc. I was hoping to suggest that already many of these stacks have been > optimised, and we are living with many decades of legacy and diversity. > > On the other hand, I agree QUIC has applicability to datagrams for > instance where reliability is not required for data, so I do need to learn > more about how/whether these will handle CC and pacing, etc. > > Changing the ACK policy and usage also brings lots of trade-offs: some may >> be good in some use-cases, but also can work out really bad if the design >> doesn't match the application/network path. >> > I completely agree. > >> > > So I agree with the usefulness of the two-use-case taxonomy Carles >>> has outlined: >>> > > >>> > > 1: "please ACK now"; because sender's cwnd is low >>> > > >>> > > 2: "ACK at frequency K"; because sender's cwnd is high >>> > > >>> > > It seems those could both be addressed cleanly with one or two TCP >>> > > option kinds. A single TCP option kind might suffice if the ACK >>> > > frequency of 0 or 1 is taken to mean "please ACK now". >>> > I might be useful if the sender can trigger an ACK for this particular >>> packet, >>> > but leave the rate unchanged. And change the rate from now on. >>> > If using an option, you could encode "send an ack for this packet, but >>> don't >>> > change the ack rate" by using 0, and encode "change the ack rate to 1 >>> for n" >>> > by using n, n > 0. >>> >>> Yes, that sounds like a very nice idea. >>> >>> best, >>> neal >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> >> >> I like that also. An option calling for an ACK-now, seems a little >> reminiscent of the way some stacks used "PUSH". I can immediately see some >> good things about eliciting that immediate response for a particular >> sequence number. >> >> Gorry >> >> _______________________________________________ >> tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > -- > G. Fairhurst, School of Engineering > > > Gorry > > > --00000000000021bd2605a4d3016c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the clarification.=C2=A0 In implementation, I e= xpect the status of pacing to be extremely similar for TCP and QUIC.=C2=A0 = Many stacks and applications that do it for TCP will do it for QUIC, and th= ose which don't pace TCP probably won't bother with QUIC.

=
On Mon, Ma= y 4, 2020 at 9:38 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
=20 =20 =20


On 04/05/2020 14:14, Ian Swett wrote:
=20


On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:


On 02/05/2020 15:55, Matt Mathis wrote:
Another probably small opportunity would be to make the RTT estimators less noisy, by having the receiver always ACK the first (or last) TSO segment.=C2=A0 =C2=A0The RTT is currently fuzzed by both = del ACK and TCP strides.

I agree this might help: The TCP spec lets receivers do this right now, if they wish to?
Thanks,
--MM--
The best way to predict the future is to create it. =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0however our response must be carefully measured:=C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 too strong would be hypocritical and risks spiraling out of control;
=C2=A0 too weak risks being mistaken for tacit approval.



On Sat, May 2, 2020 at 7:35 AM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.= org> wrote:
On Sat,= May 2, 2020 at 10:26 AM Michael Tuexen
<michael.tuexen@lurchi.franken.de> wrote:
>
> > On 2. May 2020, at 16:10, Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
> >
> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro
.....
> >> [CG] It seems that there are two different areas where avoiding the
> >> typical Delayed ACKs approach may be of particular interest: i) scenarios
> >> where very small window sizes are used (cwnd=3D1), and ii) scenarios where
> >> large window sizes, and high ACK ratios, can be used. We will reflect
> >> these considerations in the next draft update.
> >
> > Yes, I wholeheartedly agree with Bob's point that it's also extremely
> > useful for TCP senders to be able to say things like: "I don't
> > particularly mind which packets you ACK, but there's no need to do it
> > more often than 1:16". QUIC has a mechanism like this, and it seems to
> > allow significant CPU savings, even allowing QUIC to run faster than
> > TCP in some cases, AFAICT due to the reduced overhead for handling
> > ACKs:
> >=C2=A0 https://www.fastly.com/blog/measuring-quic-vs-tcp-computational= -efficiency
> >=C2=A0 htt= ps://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00
> >

QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or ACK content, it's likely an extension to the spec in the future. Anyway, I don't think TCP is the same as QUIC - TCP's notion of pacing is different; TCP's design differs, and there are many flavours and apps that use TCP in different ways.


I'm curious about some of these comments.=C2=A0 I agree = TCP and QUIC are different(otherwise why standardize QUIC), but TCP's notion of pacing is no different from QUIC's in m= y opinion.=C2=A0 Both have various ways to implement pacing, and neither has any spec specifying exactly how it should be done.=C2=A0 For TCP, the closest I can find is RFC3449.= =C2=A0 You seem to be implying that the set of apps which use TCP will always be wider than QUIC.
QUIC seems to anticipate the need for pacing in its deisgn assumptions - I may be wrong? TCP has various recommendations that to me suggest pacing is a good idea (I would agree), but I expect lots of stacks do not implement burst mitigation.
If anything, I suspect the opposite is true, since QUIC can enable applications where 100% reliability is undesirable.

My comment was meant to say there are already a very wide range of protocols using TCP. From routing protocols, DNS, to other core protocols, to streaming video, to web, bulk transfer, IoT, transaction processing, etc. I was hoping to suggest that already many of these stacks have been optimised, and we are living with many decades of legacy and diversity.

On the other hand, I agree QUIC has applicability to datagrams for instance where reliability is not required for data, so I do need to learn more about how/whether these will handle CC and pacing, etc.=C2=A0

Changing the ACK policy and usage also brings lots of trade-offs: some may be good in some use-cases, but also can work out really bad if the design doesn't match the application/network path.

I completely agree.
> &= gt; So I agree with the usefulness of the two-use-case taxonomy Carles has outlined:
> >
> > 1: "please ACK now"; because sender= 's cwnd is low
> >
> > 2: "ACK at frequency K"; because se= nder's cwnd is high
> >
> > It seems those could both be addressed cleanly with one or two TCP
> > option kinds. A single TCP option kind might suffice if the ACK
> > frequency of 0 or 1 is taken to mean "please ACK now".
> I might be useful if the sender can trigger an ACK for this particular packet,
> but leave the rate unchanged. And change the rate from now on.
> If using an option, you could encode "send an ack for this packet, but don't
> change the ack rate" by using 0, and encode "change the ack rate to 1 for n"
> by using n, n > 0.

Yes, that sounds like a very nice idea.

best,
neal

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


I like that also. An option calling for an ACK-now, seems a little reminiscent of the way some stacks used "PUSH". I can immediately see some good things ab= out eliciting that immediate response for a particular sequence number.

Gorry

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.or= g
https://www.ietf.org/mailman/listinfo/tcpm= 
--=20
G. Fairhurst, School of Engineering


Gorry
--00000000000021bd2605a4d3016c-- From nobody Mon May 4 08:55:44 2020 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 71DD13A0B5D for ; Mon, 4 May 2020 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 OAu9zzzKXbcB for ; Mon, 4 May 2020 08:55:39 -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 7E58A3A0B5C for ; Mon, 4 May 2020 08:55:39 -0700 (PDT) Received: from Gs-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id C6AC21B00108; Mon, 4 May 2020 16:55:29 +0100 (BST) To: Ian Swett Cc: Matt Mathis , Neal Cardwell , Michael Tuexen , "tcpm@ietf.org" , Jon Crowcroft References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> <54809559-05ef-b104-6cee-e61c8231dbae@erg.abdn.ac.uk> <89b3c210-ac29-462e-daa1-373eeb4addf4@erg.abdn.ac.uk> From: Gorry Fairhurst Message-ID: <06ab818f-df0e-8bd3-c818-1a06c029881e@erg.abdn.ac.uk> Date: Mon, 4 May 2020 16:55:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------81527E3B048AEE1C140DF93B" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] On Sender Control of Delayed Acks in TCP 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, 04 May 2020 15:55:43 -0000 This is a multi-part message in MIME format. --------------81527E3B048AEE1C140DF93B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 04/05/2020 15:03, Ian Swett wrote: > Thanks for the clarification.  In implementation, I expect the status > of pacing to be extremely similar for TCP and QUIC.  Many stacks and > applications that do it for TCP will do it for QUIC, and those which > don't pace TCP probably won't bother with QUIC. Probably so, time will tell. Gorry > > On Mon, May 4, 2020 at 9:38 AM Gorry Fairhurst > wrote: > > > On 04/05/2020 14:14, Ian Swett wrote: >> >> >> On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst >> > wrote: >> >> >> On 02/05/2020 15:55, Matt Mathis wrote: >>> Another probably small opportunity would be to make the RTT >>> estimators less noisy, by having the receiver always ACK the >>> first (or last) TSO segment.  The RTT is currently fuzzed by >>> both del ACK and TCP strides. >>> >> I agree this might help: The TCP spec lets receivers do this >> right now, if they wish to? >>> Thanks, >>> --MM-- >>> The best way to predict the future is to create it.  - Alan Kay >>> >>> We must not tolerate intolerance; >>>        however our response must be carefully measured: >>>             too strong would be hypocritical and risks >>> spiraling out of control; >>>   too weak risks being mistaken for tacit approval. >>> >>> >> >>> On Sat, May 2, 2020 at 7:35 AM Neal Cardwell >>> >> > wrote: >>> >>> On Sat, May 2, 2020 at 10:26 AM Michael Tuexen >>> >> > wrote: >>> > >>> > > On 2. May 2020, at 16:10, Neal Cardwell >>> >> > wrote: >>> > > >>> > > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro >>> ..... >>> > >> [CG] It seems that there are two different areas >>> where avoiding the >>> > >> typical Delayed ACKs approach may be of particular >>> interest: i) scenarios >>> > >> where very small window sizes are used (cwnd=1), >>> and ii) scenarios where >>> > >> large window sizes, and high ACK ratios, can be >>> used. We will reflect >>> > >> these considerations in the next draft update. >>> > > >>> > > Yes, I wholeheartedly agree with Bob's point that >>> it's also extremely >>> > > useful for TCP senders to be able to say things >>> like: "I don't >>> > > particularly mind which packets you ACK, but there's >>> no need to do it >>> > > more often than 1:16". QUIC has a mechanism like >>> this, and it seems to >>> > > allow significant CPU savings, even allowing QUIC to >>> run faster than >>> > > TCP in some cases, AFAICT due to the reduced >>> overhead for handling >>> > > ACKs: >>> > > >>> https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency >>> > > >>> https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 >>> > > >>> >> QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, >> timing, or ACK content, it's likely an extension to the spec >> in the future. Anyway, I don't think TCP is the same as QUIC >> - TCP's notion of pacing is different; TCP's design differs, >> and there are many flavours and apps that use TCP in >> different ways. >> >> >> I'm curious about some of these comments.  I agree TCP and QUIC >> are different(otherwise why standardize QUIC), but TCP's notion >> of pacing is no different from QUIC's in my opinion.  Both have >> various ways to implement pacing, and neither has any spec >> specifying exactly how it should be done. For TCP, the closest I >> can find is RFC3449 >> . You seem to be >> implying that the set of apps which use TCP will always be wider >> than QUIC. > QUIC seems to anticipate the need for pacing in its deisgn > assumptions - I may be wrong? TCP has various recommendations that > to me suggest pacing is a good idea (I would agree), but I expect > lots of stacks do not implement burst mitigation. >> If anything, I suspect the opposite is true, since QUIC can >> enable applications where 100% reliability is undesirable. > > My comment was meant to say there are already a very wide range of > protocols using TCP. From routing protocols, DNS, to other core > protocols, to streaming video, to web, bulk transfer, IoT, > transaction processing, etc. I was hoping to suggest that already > many of these stacks have been optimised, and we are living with > many decades of legacy and diversity. > > On the other hand, I agree QUIC has applicability to datagrams for > instance where reliability is not required for data, so I do need > to learn more about how/whether these will handle CC and pacing, etc. > >> Changing the ACK policy and usage also brings lots of >> trade-offs: some may be good in some use-cases, but also can >> work out really bad if the design doesn't match the >> application/network path. >> >> I completely agree. >> >>> > > So I agree with the usefulness of the two-use-case >>> taxonomy Carles has outlined: >>> > > >>> > > 1: "please ACK now"; because sender's cwnd is low >>> > > >>> > > 2: "ACK at frequency K"; because sender's cwnd is high >>> > > >>> > > It seems those could both be addressed cleanly with >>> one or two TCP >>> > > option kinds. A single TCP option kind might suffice >>> if the ACK >>> > > frequency of 0 or 1 is taken to mean "please ACK now". >>> > I might be useful if the sender can trigger an ACK for >>> this particular packet, >>> > but leave the rate unchanged. And change the rate from >>> now on. >>> > If using an option, you could encode "send an ack for >>> this packet, but don't >>> > change the ack rate" by using 0, and encode "change >>> the ack rate to 1 for n" >>> > by using n, n > 0. >>> >>> Yes, that sounds like a very nice idea. >>> >>> best, >>> neal >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> >> I like that also. An option calling for an ACK-now, seems a >> little reminiscent of the way some stacks used "PUSH". I can >> immediately see some good things about eliciting that >> immediate response for a particular sequence number. >> >> Gorry >> >>> _______________________________________________ >>> 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 >> > -- > G. Fairhurst, School of Engineering > > > Gorry > -- G. Fairhurst, School of Engineering --------------81527E3B048AEE1C140DF93B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 04/05/2020 15:03, Ian Swett wrote:
Thanks for the clarification.  In implementation, I expect the status of pacing to be extremely similar for TCP and QUIC.  Many stacks and applications that do it for TCP will do it for QUIC, and those which don't pace TCP probably won't bother with QUIC.

Probably so, time will tell.

Gorry


On Mon, May 4, 2020 at 9:38 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:


On 04/05/2020 14:14, Ian Swett wrote:


On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:


On 02/05/2020 15:55, Matt Mathis wrote:
Another probably small opportunity would be to make the RTT estimators less noisy, by having the receiver always ACK the first (or last) TSO segment.   The RTT is currently fuzzed by both del ACK and TCP strides.

I agree this might help: The TCP spec lets receivers do this right now, if they wish to?
Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured: 
            too strong would be hypocritical and risks spiraling out of control;
  too weak risks being mistaken for tacit approval.



On Sat, May 2, 2020 at 7:35 AM Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:
On Sat, May 2, 2020 at 10:26 AM Michael Tuexen
<michael.tuexen@lurchi.franken.de> wrote:
>
> > On 2. May 2020, at 16:10, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:
> >
> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro
.....
> >> [CG] It seems that there are two different areas where avoiding the
> >> typical Delayed ACKs approach may be of particular interest: i) scenarios
> >> where very small window sizes are used (cwnd=1), and ii) scenarios where
> >> large window sizes, and high ACK ratios, can be used. We will reflect
> >> these considerations in the next draft update.
> >
> > Yes, I wholeheartedly agree with Bob's point that it's also extremely
> > useful for TCP senders to be able to say things like: "I don't
> > particularly mind which packets you ACK, but there's no need to do it
> > more often than 1:16". QUIC has a mechanism like this, and it seems to
> > allow significant CPU savings, even allowing QUIC to run faster than
> > TCP in some cases, AFAICT due to the reduced overhead for handling
> > ACKs:
> >  https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency
> >  https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00
> >

QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or ACK content, it's likely an extension to the spec in the future. Anyway, I don't think TCP is the same as QUIC - TCP's notion of pacing is different; TCP's design differs, and there are many flavours and apps that use TCP in different ways.


I'm curious about some of these comments.  I agree TCP and QUIC are different(otherwise why standardize QUIC), but TCP's notion of pacing is no different from QUIC's in my opinion.  Both have various ways to implement pacing, and neither has any spec specifying exactly how it should be done.  For TCP, the closest I can find is RFC3449.  You seem to be implying that the set of apps which use TCP will always be wider than QUIC.
QUIC seems to anticipate the need for pacing in its deisgn assumptions - I may be wrong? TCP has various recommendations that to me suggest pacing is a good idea (I would agree), but I expect lots of stacks do not implement burst mitigation.
If anything, I suspect the opposite is true, since QUIC can enable applications where 100% reliability is undesirable.

My comment was meant to say there are already a very wide range of protocols using TCP. From routing protocols, DNS, to other core protocols, to streaming video, to web, bulk transfer, IoT, transaction processing, etc. I was hoping to suggest that already many of these stacks have been optimised, and we are living with many decades of legacy and diversity.

On the other hand, I agree QUIC has applicability to datagrams for instance where reliability is not required for data, so I do need to learn more about how/whether these will handle CC and pacing, etc. 

Changing the ACK policy and usage also brings lots of trade-offs: some may be good in some use-cases, but also can work out really bad if the design doesn't match the application/network path.

I completely agree.
> > So I agree with the usefulness of the two-use-case taxonomy Carles has outlined:
> >
> > 1: "please ACK now"; because sender's cwnd is low
> >
> > 2: "ACK at frequency K"; because sender's cwnd is high
> >
> > It seems those could both be addressed cleanly with one or two TCP
> > option kinds. A single TCP option kind might suffice if the ACK
> > frequency of 0 or 1 is taken to mean "please ACK now".
> I might be useful if the sender can trigger an ACK for this particular packet,
> but leave the rate unchanged. And change the rate from now on.
> If using an option, you could encode "send an ack for this packet, but don't
> change the ack rate" by using 0, and encode "change the ack rate to 1 for n"
> by using n, n > 0.

Yes, that sounds like a very nice idea.

best,
neal

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


I like that also. An option calling for an ACK-now, seems a little reminiscent of the way some stacks used "PUSH". I can immediately see some good things about eliciting that immediate response for a particular sequence number.

Gorry

_______________________________________________
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
-- 
G. Fairhurst, School of Engineering


Gorry


-- 
G. Fairhurst, School of Engineering
--------------81527E3B048AEE1C140DF93B-- From nobody Mon May 4 10:37:03 2020 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 006013A0DCB; Mon, 4 May 2020 10:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 kVZRTa7_XXfY; Mon, 4 May 2020 10:36:59 -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 B3F963A0DCD; Mon, 4 May 2020 10:36:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B211025A13; Mon, 4 May 2020 19:36:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1588613815; bh=8NUHPWjRCGbvWqeTKZufek6OKsh8lfgdBZ7EwwakxI8=; h=From:To:CC:Subject:Date:From; b=KNmIMxJXG4FDfYp/+MHKIEIcAHuPhHQXtI0fCkmWAJ38BEQt6pTVKDAS/X0OoRWBy 19BxQmGhujIVJqUJAIQLgjk/3xtaaXtvtVbJDSknRs3FmIt/TKog5l7OG2WCxmf7uo F2xqpsnIIAwbP63gaD+bgc4IxM/IqOPrIDpy6UiA= 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 GwVMWbVZNp7q; Mon, 4 May 2020 19:36:54 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 4 May 2020 19:36:54 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 4 May 2020 19:36:54 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Interim meeting minutes Thread-Index: AdYiOpDQHCEq7iRSRcyifaHoo1Cgcw== Date: Mon, 4 May 2020 17:36:53 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DBB5CA3@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.48.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Interim meeting minutes 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, 04 May 2020 17:37:01 -0000 Hi all, The material of the past interim meeting can be found at: https://datatrack= er.ietf.org/meeting/interim-2020-tcpm-01/session/tcpm I have uploaded draft minutes based on the excellent Etherpad notes from Ri= chard Richard Scheffenegger (thanks!): https://datatracker.ietf.org/meeting= /interim-2020-tcpm-01/materials/minutes-interim-2020-tcpm-01-202004291600 Please let the chairs know if anything needs to be fixed therein. Thanks Michael From nobody Mon May 4 10:58:08 2020 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 CB56D3A0DDA for ; Mon, 4 May 2020 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 CryhBuvEB_KW for ; Mon, 4 May 2020 10:58:03 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 ECFD73A0DE7 for ; Mon, 4 May 2020 10:57:52 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id s5so158066uad.4 for ; Mon, 04 May 2020 10:57:52 -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:content-transfer-encoding; bh=2fOshTZ2RxXA1nNyejekjQiYsvTgIE+slsW+4oN+pyA=; b=o895s8Niz+Qukn3R32CgZK86jQ17CajqIQt61PvTAg172A/kqQ3Ea+JaWglkG/j3NC ZPDbsdNHnV7haxFemCJ0N5mC2VbA6Sd9Ua4cpZQedN7w2ZT998FreASZAB6XV7/77U54 xJPxY8vWo2TEaBnKBZYUYvX2IcpPV/mvFA/J8YjpklFqNEeUo64MymBUKIEZcJgVksqC 08FvEEdFLfzTqNnylDAXoR0NB84U3piciCiap75m033eaiUdQQOaNY/OLbezvrc9X32S ywTIixmLtJipvewjf7hlLFpMvNSAgEEfIevLSF1DBaKNZ5fMq7NuOm+rI4+pWdhgWOKA F88Q== 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:content-transfer-encoding; bh=2fOshTZ2RxXA1nNyejekjQiYsvTgIE+slsW+4oN+pyA=; b=ZoWSx1U/wmqsBSWhX7WHKepVht4bQtjBXvoq45AdZm7yYp2Zp2OxVjV8XacC5NrZTB ZnKBxbYUgz7lnKeuccXSnA7us0K8E0w6XkMHIOE5hapqqDZZePFTO1QVVwinvgXGwLHn g+em+qRnN5HaPIW5g1zjL0Ws0PTIb/KT3Q6K+c1wB0WUMYGe90TnWNbvHdG1T4fPT/k3 0aryLrET7LqDaAML3Ad25t0+UCCPd1z/CKFAFJA7eDXzvIkUj0sIx8zGTHdDox9fXjxK nFsH7IRhWao5NuUx9CPSwXkyc1gP/R5GBVyZW/Fa3Y8IH+yg2VIqLgj0vlL4hKSZaJaH Yjeg== X-Gm-Message-State: AGi0PuYG5p3btiW3AE5G6vcXPPGhpRL7QIMmzY1LZRlp8D48AmqjbFQ5 poJm131MVzdZqh7QDckZboToQ5Xphvekebef1s6SgQ== X-Google-Smtp-Source: APiQypLiNPvISN1XsTaEhgtLu/X6L4mlhA0T+6wLZf/0A3SWJ6jayrRQdRKwto5QzavEAEqY8DntKLx5gaP0RD/yrr8= X-Received: by 2002:ab0:408a:: with SMTP id i10mr157675uad.80.1588615071393; Mon, 04 May 2020 10:57:51 -0700 (PDT) MIME-Version: 1.0 References: <23157b5e4063646449099e97eccde0f3.squirrel@webmail.entel.upc.edu> <6b11e0a37698146c8e2bad6052634452.squirrel@webmail.entel.upc.edu> In-Reply-To: From: Yuchung Cheng Date: Mon, 4 May 2020 10:57:15 -0700 Message-ID: To: Vidhi Goel Cc: Carles Gomez Montenegro , "tcpm@ietf.org Extensions" , jon.crowcroft@cl.cam.ac.uk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] question regarding draft-gomez-tcpm-delack-suppr-reqs 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, 04 May 2020 17:58:06 -0000 On Sat, May 2, 2020 at 8:21 PM Vidhi Goel wrote: > > Hi Carles, > > >> I agree. We in fact implemented Linux to increase cwnd by the exact > >> amount sequence (in unit of packets) so slow-start increase function i= s > >> regardless of ack-thinning effect but purely based on amount > >> delivered. This has an important effect on > >> Wireless as the other ack talk mentions. It also helps in case of ACK > >> losses or reordering. > > > > Agreed! > > > > By the way, in the next draft update, we will add that, despite its > > "Experimental" status, ABC is supported in many implementations. > > Some time ago, I had brought up this same problem with ABC (RFC 3465) tha= t increasing by at most one MSS during slow start makes the growth some wha= t non-exponential in cases where ACK ratio < 1 (for example, receivers doin= g GRO or ACK compression, ACK losses etc). To allow an exponential growth, = we should certainly increase congestion window by the amount of bytes ACKed= (what Linux does). +1 I do want to mention that there's a legit concern of always increasing based on #bytes: slow start (or generally congestion control) can be more bursty with stretched-ACKs. IMHO idle-restart bursts are just as bad and probably even more frequent with many TCP senders disable slow-start after-idle and don't bother to pace. The best form to de-burst is through (good) pacers like Linux's fq/pacing. In other words congestion control and burst control should not be juggled together via only congestion window changes. > > > Vidhi > > > On May 2, 2020, at 1:34 AM, Carles Gomez Montenegro wrote: > > > > Hi Yuchung, > > > > > > > >>> Note that the problem pointed out is that, as stated in the RFC 5681 > >>> text > >>> above: > >>> > >>> "During slow start, a TCP increments cwnd by at most SMSS bytes for > >>> each ACK received that cumulatively acknowledges new data" > >>> > >>> It may be desirable to support, during slow start, a cwnd increase by > >>> more > >>> than SMSS per each ACK acknowledging new data. > >> I agree. We in fact implemented Linux to increase cwnd by the exact > >> amount sequence (in unit of packets) so slow-start increase function i= s > >> regardless of ack-thinning effect but purely based on amount > >> delivered. This has an important effect on > >> Wireless as the other ack talk mentions. It also helps in case of ACK > >> losses or reordering. > > > > Agreed! > > > > By the way, in the next draft update, we will add that, despite its > > "Experimental" status, ABC is supported in many implementations. > > > > > > > > Thanks, > > > > Carles > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue May 5 00:25:30 2020 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 7BA6E3A15B9 for ; Tue, 5 May 2020 00:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdoKU1D6e4eo for ; Tue, 5 May 2020 00:25:26 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 A3E133A15B7 for ; Tue, 5 May 2020 00:25:26 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id y3so1443389wrt.1 for ; Tue, 05 May 2020 00:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hntnrNOxJjF3ImZ+plEEZ12HgphNj1DSC/7LhQqWZGQ=; b=q8wgc9R/WcluQQCAyvxQui68c4KmUvBL9a8t7E0WdAORQhkgaZFsYQ2Y9aQ4aM/2RM ysLgZhQKBv75nD0WiPx3SFouFZe7Ghqz9vF1ahb76pyc8uyK/YR49DuBg13dJH7iARSJ guMl1vM0epz+Zq5J7A05/ADncgV5ASKVCtHYDRQn4zcu7i2bE2X/Nh053ykaS7G9viWx dPhK9kC1lIUQ7wQg81xZ1fW2o9OG8U9JBSFioRCpzVpdOaAT1ZeId1RSlTdUkaEO6Ovq YO/VGZybVWO9r/bTr1fFAEAMmTmHlPm/FlkFeGyQ6XEC/tiup4cWhrX0gKpE+BMyjIIf abng== 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:content-transfer-encoding; bh=hntnrNOxJjF3ImZ+plEEZ12HgphNj1DSC/7LhQqWZGQ=; b=rIgT0KxLgrIbOATkOAYmkOR9rfPdGPr+CdE6ny+LPHRyFLdhWTQINkPBqHZbDHP865 eD7odbK/pT3HAmRe7seZb3L7ghgno8D5qOdpxSgo3Cv9rZca6996Z67HrTEMmO/8WTOM pxMgJD4VM9Y0z47zeDUZitkP6cyHEO3fmKhoesVV21F9/BZiPebb7knVUcTYEbabety8 dM4LIzVbTShnuIZBczrzrYdZAoAM/1JFUJIbT9AI/bqMnJgW/gi1NHODotZXsjh2EaXp Vy8VP6Ew/DdRM4YnwqPP6ZS6bkmg65PedMEyr3TpWM3LbS2P1ZBEWwuDvo6pRWx6bMx3 CvOA== X-Gm-Message-State: AGi0PuZsSukQdmL4480I6fLmt1thxIz/9LFflwAzt4KYbN+tPd8d8M2S r93A1aLpmaDTHI2txskASQnljMtG+Omg4IkXOAk= X-Google-Smtp-Source: APiQypL11YT7R7dq06cXgYnT2wdokmtCcYOekZ4V+MP953fI5+ezMKuAC9QrcLIHCxsIn5U3oylAab0klPskzMud0HA= X-Received: by 2002:a5d:4092:: with SMTP id o18mr2015166wrp.227.1588663525003; Tue, 05 May 2020 00:25:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: juhamatk@gmail.com Date: Tue, 5 May 2020 10:25:12 +0300 Message-ID: To: Joseph Touch Cc: tcpm@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] RFC 5925 SNE algorithm concern 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, 05 May 2020 07:25:28 -0000 Hello, And there seems to be a minor parenthesis mismatch in the pseudo-code of the improved algorithm I sent earlier. Here is a new fixed version below for the record. Improved algorithm suggestion pseudo-code: PRE =3D 0; // set the flag when the SEG.SEQ first rolls over if ((RCV.SNE_FLAG =3D=3D 0) && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { RCV.SNE =3D RCV.SNE + 1; RCV.SNE_FLAG =3D 1; } // decide which SNE to use after incremented, // pre-increment is used for retransmits if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ > 0x7fffffff)) { SNE =3D RCV.SNE - 1; // use the pre-increment value PRE =3D 1; } else { SNE =3D RCV.SNE; // use the current value } // reset the flag in the *middle* of the window, // include SEG.SEQ equals half so that we do not miss // that edge case if (PRE =3D=3D 0) { if(RCV.PREV_SEQ < 0x7fffffff && SEG.SEQ >=3D 0x7fffffff) { RCV.SNE_FLAG =3D 0; } // save the current SEQ for the next time through the code, // if we are not retransmitting RCV.PREV_SEQ =3D SEG.SEQ; } BR, -- Juhamatti On Thu, 30 Apr 2020 at 19:43, wrote: > > > Hello Joe, > > Thanks for your reply. While I talk about retransmit, I refer actually to= the other side retransmitting. So this is the receive side pseudo code. Do= es that change the situation? > > Thanks for the clarifications, > -- > Juhamatti > > to 30. huhtikuuta 2020 klo 17.31 Joseph Touch kirj= oitti: >> >> Hi, Juhamatti, >> >> See embedded below: >> >> > On Apr 30, 2020, at 12:31 AM, juhamatk@gmail.com wrote: >> > >> > Hello all, >> > >> > While working with RFC 5925, I have been checking the details of >> > example SNE algorithm. I have a slight concern with the example >> > algorithm proposed by the RFC. >> > >> > The idea of SNE is to simulate 64-bit sequence number with 32-bit >> > sequences to prevent replay attacks. RFC 5925 proposes the following >> > algorithm to implement 64-bit sequence numbering: >> > >> > Original algorithm pseudo-code in the RFC 5925 + errata: >> > /* set the flag when the SEG.SEQ first rolls over */ >> > if ((RCV.SNE_FLAG =3D=3D 0) >> > && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { >> > RCV.SNE =3D RCV.SNE + 1; >> > RCV.SNE_FLAG =3D 1; >> > } >> > /* decide which SNE to use after incremented */ >> > if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ > 0x7fffffff)) { >> > SNE =3D RCV.SNE - 1; # use the pre-increment value >> > } else { >> > SNE =3D RCV.SNE; # use the current value >> > } >> > /* reset the flag in the *middle* of the window */ >> > if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ > 0x7fffffff)) { >> > RCV.SNE_FLAG =3D 0; >> > } >> > /* save the current SEQ for the next time through the code */ >> > RCV.PREV_SEQ =3D SEG.SEQ; >> > >> > When looking into this in detail, to me it looks like there might be >> > an issue when 32-bit sequence wraps back to the beginning and a >> > retransmission occurs with the high sequence range. >> >> Retransmission should always use the value cached with that segment, so = there should not be an issue. >> >> > Then SNE is >> > increased unexpectedly and does not follow proper sequencing. A test >> > case below: >> > >> > State: >> > PREV_SEQ =3D 0xffffffe >> > RCV.SNE =3D 0 >> > RCV.SNE_FLAG =3D 0 >> > >> > New frame: >> > SEG.SEQ =3D 0x0 >> > RCV.SNE =3D> 1 >> > RCV.SNE_FLAG =3D> 1 >> > PREV_SEQ =3D> 0 >> > >> > Retransmit: >> > SEG.SEQ =3D 0xfffffffd >> > RCV.SNE_FLAG =3D> 0 - incorrectly updated >> > PREV_SEQ =3D> 0xfffffffd - incorrectly updated >> >> You=E2=80=99re using the pseudocode that creates new SNEs with a previou= sly transmitted value. It=E2=80=99s acting like you=E2=80=99ve wrapped too = quickly. >> >> > >> > New frame: >> > SEG.SEQ =3D 0x2 >> > RCV.SNE =3D> 2 - incorrect value, should be 1 based on sequencing >> > RCV.SNE_FLAG =3D> 1 >> > PREV_SEQ =3D> 0x2 >> > >> > I could not figure out any reason why the above sequence would not be >> > valid. >> >> Because retransmission should be using the values cached when the origin= al transmission occurred. >> >> I don=E2=80=99t think the new code is needed - at least from this exampl= e. >> >> Joe >> >> > Even though it is mentioned in the RFC that the algorithm is >> > just an example, the sequencing mismatch is unfortunate as mismatching >> > SNEs on different sides will bring the authenticated TCP session down >> > and cause data loss through timeout. Thus, for interoperability, it is >> > crucial that correct sequencing is used on both ends. >> > >> > If above is really a real problem, then perhaps an improved algorithm >> > could be as follows: >> > >> > Improved algorithm suggestion pseudo-code: >> > PRE =3D 0; >> > // set the flag when the SEG.SEQ first rolls over >> > if ((RCV.SNE_FLAG =3D=3D 0) >> > && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { >> > RCV.SNE =3D RCV.SNE + 1; >> > RCV.SNE_FLAG =3D 1; >> > } >> > // decide which SNE to use after incremented, >> > // pre-increment is used for retransmits >> > if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ > 0x7fffffff)) { >> > SNE =3D RCV.SNE - 1; # use the pre-increment value >> > PRE =3D 1; >> > } else { >> > SNE =3D RCV.SNE; # use the current value >> > } >> > // reset the flag in the *middle* of the window, >> > // include SEG.SEQ equals half so that we do not miss >> > // that edge case >> > if (PRE =3D=3D 0) { >> > if(RCV.SNE_FLAG =3D=3D 1 && >> > RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ >=3D 0x7fffffff)) { >> > RCV.SNE_FLAG =3D 0; >> > } >> > // save the current SEQ for the next time through the code, >> > // if we are not retransmitting >> > RCV.PREV_SEQ =3D SEG.SEQ; >> > } >> > >> > This passes the problematic case (and bunch of others I have tested). >> > This also includes a small additional fix in the middle window >> > handling where SEG.SEQ was missing one edge value (SEG.SEQ > >> > 0x7fffffff =3D> SEG.SEQ >=3D 0x7fffffff). I hope I have not missed >> > anything else, but it is certainly possible, so comments are welcome. >> > >> > So, what do you think, is this a real concern? If it is a real issue, >> > what would be the best way to handle this, perhaps an errata with an >> > improved algorithm after throughout review of the new algorithm? >> > >> > Thank you, >> > -- >> > Juhamatti >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> From nobody Tue May 5 08:31:45 2020 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 3A5183A0831 for ; Tue, 5 May 2020 08:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, 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 aHbSkHf0bEf9 for ; Tue, 5 May 2020 08:31:40 -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 EB41B3A0101 for ; Tue, 5 May 2020 08:31:39 -0700 (PDT) Received: from mbp.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6DCC472243804 for ; Tue, 5 May 2020 17:31:36 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_63ECF804-6BB7-45E1-B742-3A10FCB05FDD"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: References: To: tcpm IETF list Date: Tue, 5 May 2020 17:31:35 +0200 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [tcpm] Fwd: Reminder: Survey on planning for possible online IETF meetings 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, 05 May 2020 15:31:44 -0000 --Apple-Mail=_63ECF804-6BB7-45E1-B742-3A10FCB05FDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Begin forwarded message: >=20 > From: Alissa Cooper > Subject: Fwd: Reminder: Survey on planning for possible online IETF = meetings > Date: 5. May 2020 at 13:48:03 CEST > To: IETF WG Chairs >=20 > Please circulate this to your working group lists. The survey data = will be very important as we plan future IETF meetings. Done. Best regards Michael >=20 > Thanks, > Alissa >=20 >> Begin forwarded message: >>=20 >> From: IETF Executive Director >> Subject: Reminder: Survey on planning for possible online IETF = meetings >> Date: May 4, 2020 at 3:03:35 AM EDT >> To: "IETF Announcement List" >> Reply-To: ietf108planning@ietf.org >>=20 >> This is a reminder that we need the IETF community to help us plan = for the possibility that one or more upcoming IETF meetings in 2020 and = possibly 2021 may not be able to go ahead in person. You can help us = with this by filling out the following survey:=20 >>=20 >> https://www.surveymonkey.com/r/5328FFJ >>=20 >> So far we have 114 responses and we would ideally like 500 or more. >>=20 >> The survey contains the following pages and will take 15-20 minutes = to complete: >>=20 >> 1. Welcome >> 2. Online IETF 107 and the subsequent virtual interims >> 3. Replacing a cancelled in-person meeting >> 4. Online meeting format and timezone >> 5. Replicating humming >> 6. Replicating the hallway environment >> 7. Fees >> 8. Thanks and anything else >>=20 >> We run the survey in anonymous mode which means that we only see data = that you explicitly provide. >>=20 >> Thank you in advance for your help. >>=20 >> --=20 >> Alissa Cooper, IETF Chair >> Jay Daley, IETF Executive Director >> Colin Perkins, IRTF Chair >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 --Apple-Mail=_63ECF804-6BB7-45E1-B742-3A10FCB05FDD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1 MDUxNTMxMzVaMC8GCSqGSIb3DQEJBDEiBCDNIva9OnZmmLx3seEnTmhUSb6+312sh9DC9DL1OQmg OzCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEASxvO90YJTR8ivBxQrEJ8xpbI3sZm Y+6wZUAsclbBXHIviE4q8saxIGAVDro7npGHSubmfqUshOHsTBVQvDK4bfOWIAOYSe3j9uN7ib83 kZvFZJCiczHPeXiQN4engh+FrrwiBSKPtNlLw4fcYMUUmSxLac8VgB+y9QFkHEjF4DzVWSk6cYlx bJQKsWhmlNhmU3Gf3g9hZ9wMBujWl2oj38PA2SDVAuO/bBsR3dVd5I5sl0DgEm/kBdqnpv6JTnCt JSqg4QyGHqJq+EDGoOUB8bDTfrzsAXVFK/0ZRTGEJBtNAnz1/7ByDf84zMMNMQPa2gVYWOeoCVUs yWvJo56kmgAAAAAAAA== --Apple-Mail=_63ECF804-6BB7-45E1-B742-3A10FCB05FDD-- From nobody Tue May 5 08:52:21 2020 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 297A63A084A for ; Tue, 5 May 2020 08:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, 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=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 5vnqUgQ1PbXh for ; Tue, 5 May 2020 08:52:10 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60043.outbound.protection.outlook.com [40.107.6.43]) (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 8EFDB3A08B5 for ; Tue, 5 May 2020 08:52:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EaikKjM0OFLz/TSsjuc8FNaGKZy4jQeSH7rlOIuu0PRg/NLLAX+MAo376Cdwz7AyHHB66ohLXVG6sRKaxYF/NusNrF6WHqYVNTcG3Dvb9p11sb7tkW8BdQuHWllyN4Rc5y7j3XUgAkqiX2vGoujWSct9N/bVUJAs+sc746tdLjsCvfeLowfglX6sIE1uIEIGSvdJ9uEQ2uoH0kOngr97flwl8JDgOv7e5SQ4Dif0LfJfWL+EULCkqvXsVw2Yuch+Yk/IUx5is0vjTlJDb2EMlLitCdf8Ikdca3IatFvEsHZ46JbcRFmG/+7CNugVND8lgPafntBbfhLX5edblTWKYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+35zFOA2yGoc5vkFFcENFcc1qcSqs117TEdKpWNEmE=; b=Ca8wAGaRxf4kDmS6QHVHw7NssLwTEx3vFRq6dqEvSDYvSX7aI6oHsoalzboDfIn4o5EgorPiUCoRs50jmqxsKeBMbUZbffV+MUAOSq6SFAq5NosbKsuJARB/VpIL/6cc3rPgrqmAL0+sKkmiijfWm1MYoeHNfCCMTYiFQLpV6mHWN0DFlUHTAXR7W9sncHuJposJiYuAo9OuAjqxAhEjpbnt9D2MC3MVqLvPGH57/CFFTdXzwQ0HaFoO5cLPU5Co/BjZC0+ii6oh1iHCt/JrK7lLNLijXY6HCxFNcr/B3gsHpjzrqyy1b9i5P1Q78Q4hdZ27KjQAV+5NkugO2EugJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=X+35zFOA2yGoc5vkFFcENFcc1qcSqs117TEdKpWNEmE=; b=ZMIpJGzk0fnVcDgcJrP++LYfD0cOWe2cHNGCNde/CQatDZpRvPhjH8oygKtpersRp73EeRA4bUsRo81DqxbZ7KwxPcelv+4xfD3yJbxacbFDNJJgXd3Vidun42li9BAIs3CkiLNiXj4bSitzPvyRYXIvDCzpWaGSzGfWSI/IoS0= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (2603:10a6:208:75::30) by AM0PR07MB4322.eurprd07.prod.outlook.com (2603:10a6:208:ba::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.14; Tue, 5 May 2020 15:52:08 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::d8e:b09e:d5be:3f89]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::d8e:b09e:d5be:3f89%7]) with mapi id 15.20.2979.024; Tue, 5 May 2020 15:52:08 +0000 From: Mirja Kuehlewind To: Mark Allman , "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-11.txt Thread-Index: AQHWHyXhwCRYm2XdvU6ihXXrj3p/P6iThWwKgAZIEgA= Date: Tue, 5 May 2020 15:52:08 +0000 Message-ID: References: <158827502797.6042.15313343958284896274@ietfa.amsl.com> <35789534-1A96-4B7C-9729-E4D8DD2F8D5C@icir.org> In-Reply-To: <35789534-1A96-4B7C-9729-E4D8DD2F8D5C@icir.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: icsi.berkeley.edu; dkim=none (message not signed) header.d=none;icsi.berkeley.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e727:100:2937:ba4d:95d0:7fbc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 865f1c4f-423c-4d25-2d2b-08d7f10c4462 x-ms-traffictypediagnostic: AM0PR07MB4322: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MsqCKqmscQjFf3mBqdestVajqZu05fa94MASz6cnc2o/nd9kXCV+8osrjc5gMbA0RJxqer53LDnDp8YxxGhXaymXJaIfrDVHGnHL3VG8vnSSiOSjZkpsvzuQ22FYoqb8kxpcigmYMDmwl7cCYxtNn90fCWuEaU0KAS/cUvbADdx18SLQ7bz5sEABClRfq6q6nFKssWYm0Oz1XbF77359XI3Dg24kNKKVdQqY90mV7z2weadTzp7lltb3mIHFoE44KnqIGo6ramW2YKlIIggbTMjioZ4xcr/6DbOgVK1PzAvlRjLdRDL5VDxlCg932fvjNROL436w9L0cscIkdXNwnP0dZ3APBedkIg8Vf39GhoKWbG1zWuY/GX4T+Vkl1Zn8Jghjy5PRQWODVf6pQfaZ9y3qYRrHEwRb21VApPSPT8AWEWhcJh/ByLZVyz8AdUE3B3byRnTz609Ma4RyurUEc4hu2LoEs3OQO1ENmsISa5ns2/DMdVmPvmIp1QLhSqTectEE5O1+vNmdClA+icDYIQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4691.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(33430700001)(33656002)(186003)(6486002)(110136005)(66556008)(86362001)(33440700001)(5660300002)(478600001)(316002)(6506007)(36756003)(64756008)(2906002)(66946007)(66446008)(8676002)(66476007)(71200400001)(8936002)(6512007)(2616005)(44832011)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 1myEXZxH/gJC8n9T1Sh7Qq3Ty4zUq0/BHtHhqWC/rG8lAWQJsENi2uAqcnoYfQFazhzjyWnP/o4xqvmNLjT1QpeYqxogz9ZRV7auT1HUcpTTrratiN+g+JozKrpLmkcL7+4NXJTGWgwE/3H2BM0Faoo+umND332tn3z+w1AQNm3kUgGe0FDNuKHvk3LGSRY9QSvdzYr1RT8gAnxej4dvu6qrHjXQWOGMYBOoW0Qc+ArqFqR6i/+dbABv9shOuGB1UdUvnEKDx+NDvkRJbYsNNHh+hkFy0R5/GzSJcoLA+kqipmRoJjP35fgmfObij+aAdX1mUYu8X1WFZahCqJfRLsEBLy3roauOHklJhYWwnyBVFkBOKXX79GmIOQAH453zUfBGHQ308uxHKsOhiNgqtTqedTuI3QOscPUR3fHdxE3h35wjWRgkY8jUMdQlpbkfBSiIqvCrtn4i76z/6NtyiGTqN4OiwqfF6tsiH1m1J6bb/7+NwrSSgSxGvCFyVm1mdpT/NThvSqaX33CMpcelGQqYBWNyV+Sn0NVjnGVPc/089oTeNMk1wABrHKgbcsc4IykuVwnfQCNFI4MEudG4nwxmMuuvmZDDxuxM1DASvSBZUj/i1B5fSzgU7m0qwpR6eCdaFJJ9+nFOStlaSH6aRQ/UP/Uigzbo5js5jr3abrrs5i/aXgKoKpWqUCGk9rBCzvsHL3PLAlT3Tqs8zGvZgOAGf4uqX7sqyPIhP/FYhci2zYm8JYo0sGpCh9kueG0vxTgv3TWnOp1AZ6ZXVOf1FG6DTTkfQ+gbK1R7CvbQQfzYIhXduEn5sooZu3mWFE2bkQ3Lx/3/Y2sxrCZaM/ktsxeUgw8Q/ebE1UD49Mt1rTs= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <29F139ABCDA20D46B149E2B088416063@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 865f1c4f-423c-4d25-2d2b-08d7f10c4462 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 15:52:08.3781 (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-CrossTenant-userprincipalname: 5c8NCPTNM+QSbw5SvdAgYtw4ITi6VNtq0mCb5OtBjY8YsvmgJkV4UjT77GuulRZx8OBzzgtSikYfKp3kwfZDzqsJk/l9RAub1+qmjV4B8MQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4322 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-11.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: Tue, 05 May 2020 15:52:19 -0000 SGkgTWFyaywgaGkgYWxsLA0KDQpzb3JyeSBvZiBiZWluZyBzdXBlciBsYXRlciBoZXJlIGJ1dCBJ IGZpbmFsbHkgZm91bmQgc29tZSB0aW1lIHRvIGZ1bGx5IHJlYWQgdGhlIGRvY3VtZW50IGFnYWlu LiBUaGFua3MgZm9yIHJld3JpdGluZyBpdCB3aXRoIGEgZm9jdXMgb24gbG9zcyBkZXRlY3Rpb24u IEkgdGhpbmsgdGhpcyB3b3JrcyByZWFsbHkgd2VsbCBhbmQgSSdtIGhhcHB5IHRvIHNlZSB0aGlz IGRvY3VtZW50IG1vdmluZyBmb3J3YXJkIG5vdy4NCg0KR2l2ZW4gSSd2ZSByZWFkIGl0IG5vdywg SSBhbHNvIGRvIGhhdmUgdHdvIHNtYWxsaXNoIGNvbW1lbnRzOg0KDQpUaGUgZmlyc3Qgb25lIGlz IHJhdGhlciBlZGl0b3JpYWwuIFlvdSBzYXkgZmlyc3Qgc2VudGVuY2UgaW4gc2VjIDI6DQoiIFRo aXMgZG9jdW1lbnQgaXMgZGlmZmVyZW50IGZyb20gb3RoZXIgc3RhbmRhcmRzIGRvY3VtZW50cyBp biB0aGF0IGl0DQogICAgaXMgYmFja3dhcmRzIGZyb20gdGhlIHdheSB3ZSBnZW5lcmFsbHkgbGlr ZSB0byBlbmdpbmVlciBzeXN0ZW1zLiINCkkgd291bGQgdGhpbmsgdGhhdCB0aGlzIGlzIHJhdGhl ciBub3JtYWwgZm9yIEJDUHMuLi4gSSBndWVzcyB5b3UgY291bGQganVzdCBjdXQgdGhpcyBzZW50 ZW5jZSBpbiBhIGZ1dHVyZSB2ZXJzaW9uIGJ1dCBubyB3b3JyaWVzLi4uDQoNClRoZSBzZWNvbmQg Y29tbWVudC9xdWVzdGlvbiBpcyBwb3RlbnRpYWxseSBtb3JlIHRlY2huaWNhbCwgcmVnYXJkaW5n IHRoaXMgaW4gc2VjIDQ6DQoiIEluIHN0ZWFkeSBzdGF0ZSB0aGUgUlRPIFNIT1VMRCBiZSBzZXQg YmFzZWQgb24gb2JzZXJ2YXRpb25zDQogICAgICAgICAgICBvZiBib3RoIHRoZSBGVCBhbmQgdGhl IHZhcmlhbmNlIG9mIHRoZSBGVC4iDQpJIGd1ZXNzIHlvdSBjb3VsZCBiZSBtb3JlIGV4cGxpY2l0 bHkgdGhhdCB0aGUgUlRPIHNob3VsZCBiZSBub3Qgc21hbGxlciB0aGFuIHRoZSBGVCt2YXJpYXRp b24uIE9yIGlzIHRoYXQgbm90IHRoZSBpbnRlbmRlZCBndWlkYW5jZT8gRnVydGhlciwgd2hhdCBk b2VzIHN0ZWFkeSBzdGF0ZSBhY3R1YWxseSByZWFsbHkgbWVhbiBhbmQgd2hhdCdzIHRoZSBndWlk YW5jZSBmb3Igbm9uLXN0ZWFkeSBzdGF0ZT8NCg0KTWlyamENCg0KDQoNCu+7v09uIDAxLjA1LjIw LCAxOTo1NiwgInRjcG0gb24gYmVoYWxmIG9mIE1hcmsgQWxsbWFuIiA8dGNwbS1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBtYWxsbWFuQGljc2kuYmVya2VsZXkuZWR1PiB3cm90ZToNCg0K ICAgIA0KICAgID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBSZXF1aXJlbWVudHMgZm9yIFRp bWUtQmFzZWQgTG9zcyBEZXRlY3Rpb24NCiAgICA+ICAgICAgICAgQXV0aG9yICAgICAgICAgIDog TWFyayBBbGxtYW4NCiAgICA+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRjcG0tcnRv LWNvbnNpZGVyLTExLnR4dA0KICAgID4gCVBhZ2VzICAgICAgICAgICA6IDEwDQogICAgPiAJRGF0 ZSAgICAgICAgICAgIDogMjAyMC0wNC0zMA0KICAgIA0KICAgIEkgYmVsaWV2ZSB0aGlzIHZlcnNp b24gYWRkcmVzc2VzIHRoZSB3b3JkaW5nIGlzc3VlIGluIHJlcXVpcmVtZW50DQogICAgKDMpIGJy b3VnaHQgdXAgZHVyaW5nIFdHTEMuICBQZXIgeWVzdGVyZGF5J3MgbWVldGluZyBJIHRoaW5rIHRo YXQNCiAgICBtZWFucyB3ZSBjYW4gZm9yd2FyZCB0aGUgZG9jdW1lbnQgb24gdG8gdGhlIElFU0cu DQogICAgDQogICAgYWxsbWFuDQogICAgDQoNCg== From nobody Wed May 6 12:07:38 2020 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 40AC23A0AA4 for ; Wed, 6 May 2020 12:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 4xnXjFM8OWXg for ; Wed, 6 May 2020 12:07:34 -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 862193A0AA3 for ; Wed, 6 May 2020 12:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=References:To:In-Reply-To:Subject:Date: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cY4qeg2TF15SGpmK4rn/MvTuJkXTwT/AEHcEaFZjPpM=; b=ns84a+DKuNOPVw7gD9pAGJubv 7cHh5SLVFXfYHhRKqav9smJdQpIr7cMJGi1xfXMpYjMX4NeQXfhCytz+xOz35fuWh59yqqQ0jedtn lHvCoJceu9AZWhkQ9WKIYGMVwOjIWbZMkvN3XOp16QDNRZAyeQWPowgZXKrtu4tisShaylfxgcU6h ZShuQEZblSpYazrsdDOSUpqcTSqJoJ+ZyTITxSX4KX+kI5AghaSkRDz46yN7NLzUVZXY18T+EEEZ2 BKSxlqfrQcqhlC++2yz0uckhNB1oKGksn5xG77IqGwe8dwgQVA9XRlA/ICSaa0p3y5P7PWOZXoeDg WQpanTBuw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61267 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jWPOA-000xcQ-BS; Wed, 06 May 2020 15:07:30 -0400 From: Joseph Touch Message-Id: <26C2355F-AAF8-405B-BA38-8E7F50013D27@strayalpha.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F8BAE5A5-1401-4BC7-9935-3D86928C0329" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Wed, 6 May 2020 12:07:25 -0700 In-Reply-To: To: tcpm IETF list References: X-Mailer: Apple Mail (2.3608.60.0.2.5) 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] RFC 5925 SNE algorithm concern 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, 06 May 2020 19:07:37 -0000 --Apple-Mail=_F8BAE5A5-1401-4BC7-9935-3D86928C0329 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, Juhamatti pointed out a flaw in the pseudocode for receive-side SNE = computation in RFC 5925. The good news (in a sense) is that the code was not normative;=20 The implementation of SNEs is not specified in this document, but one possible way is described here that can be used for either RCV.SNE, SND.SNE, or both. The corrections that Juhamatti posted don=E2=80=99t address the key = issue, which is that there are several possible interpretations of any = received SEQ. There is no simple way to fix this except to handle all = the cases (which the code below does - I believe minimally): - it is in-order - moving the receive window forward - incrementing the SNE if it wraps the number space - it is out-of-order - which might use either the current SNE or SNE-1, = depending on whether it is pre-wrap of the number space Because the number space wraps, all received SEQ could be interpreted as = in-order or out-of-order; the only way to know the difference is the = distance between the two =E2=80=94 which cannot be larger than 0x7FFF = FFFF (half the number space minus 1). The following is code that covers the cases and passes all current = tests. Given this is not as obvious as it might seem and might be more = useful than for just RFC 5925 and the SNE alg in 5925 is =E2=80=9Cnot = specified=E2=80=9D anyway, I propose to submit this as a stand-alone = doc. So here are the ways forward: 1) have that doc =E2=80=9CUPDATE=E2=80=9D RFC 5925 this is the cleanest because it would more definitely be = caught by implementers but it requires the new alg be standards-track, which = seems odd (though we could say what SNE is as a standard and still leave its implementation as informative rather = than normative) 2) publish that doc as informational then we could issue an errata on 5925 to point to the = new RFC 3) issue the new alg as an errata to 5925 only Any thoughts? Joe =E2=80=94=E2=80=94 PS - here=E2=80=99s the alg: #DEFINE HALF (0x80000000) SNE =3D RCV_SNE; // use current SNE (as = default) if (distance(SEG_SEQ,RCV_PREV_SEQ) < HALF) { // both in same SNE range? if ((SEG_SEQ >=3D HALF)=20 && (RCV_PREV_SEQ < HALF)) { // jumps fwd over N/2? RCV_SNE_FLAG =3D 0; // reset wrap increment = flag } RCV_PREV_SEQ =3D MAX(SEG_SEQ,RCV_PREV_SEQ); // move prev forward if = needed } else { // both in diff SNE ranges if (SEG_SEQ < HALF) { // jumps forward over zero? RCV_PREV_SEQ =3D SEG_SEQ; // update prev if (RCV_SNE_FLAG =3D=3D 0) {. // first jump over = zero? (wrap) RCV_SNE_FLAG =3D 1; // set flag so we = increment once RCV_SNE =3D RCV_SNE + 1; // increment window SNE =3D RCV_SNE; // use updated SNE value } } else { // jump backward over zero SNE =3D RCV_SNE - 1; // use pre-rollover SNE = value } }= --Apple-Mail=_F8BAE5A5-1401-4BC7-9935-3D86928C0329 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all,

Juhamatti = pointed out a flaw in the pseudocode for receive-side SNE computation in = RFC 5925.

The = good news (in a sense) is that the code was not = normative; 

   The implementation of SNEs is not specified in this document, =
but one
   possible way is described here that can be used for either RCV.SNE,
   SND.SNE, or both.

The corrections that Juhamatti posted don=E2=80=99t = address the key issue, which is that there are several possible = interpretations of any received SEQ. There is no simple way to fix this = except to handle all the cases (which the code below does - I believe = minimally):

- it is = in-order
- moving the receive = window forward
- incrementing the = SNE if it wraps the number space
- it is = out-of-order
- which might use either = the current SNE or SNE-1, depending on whether it is pre-wrap of the = number space

Because the number = space wraps, all received SEQ could be interpreted as in-order or = out-of-order; the only way to know the difference is the distance = between the two =E2=80=94 which cannot be larger than 0x7FFF FFFF (half = the number space minus 1).

The = following is code that covers the cases and passes all current tests. = Given this is not as obvious as it might seem and might be more useful = than for just RFC 5925 and the SNE alg in 5925 is =E2=80=9Cnot = specified=E2=80=9D anyway, I propose to submit this as a stand-alone = doc.

So here are the ways = forward:

1) have = that doc =E2=80=9CUPDATE=E2=80=9D RFC 5925
= this is the cleanest because it would more definitely be caught = by implementers
but it requires the new = alg be standards-track, which seems odd (though we could say what SNE is = as a standard
and still leave its = implementation as informative rather than normative)

2) publish that doc as = informational
then we could issue an = errata on 5925 to point to the new RFC

3) issue the new alg as an errata = to 5925 only

Any = thoughts?

Joe

=E2=80=94=E2=80=94

PS - here=E2=80=99s the alg:


#DEFINE HALF = (0x80000000)

SNE =3D RCV_SNE;         =                     =   // use current = SNE (as default)
if = (distance(SEG_SEQ,RCV_PREV_SEQ) < HALF) { // both in same SNE range?
  if ((SEG_SEQ >=3D = HALF) 
      && (RCV_PREV_SEQ < = HALF)) {     =        // jumps fwd over N/2?
    RCV_SNE_FLAG =3D 0;               =          // reset wrap increment flag
  }
  = RCV_PREV_SEQ =3D MAX(SEG_SEQ,RCV_PREV_SEQ);  // move prev forward if needed
} else {              =                     =    // both in diff = SNE ranges
  if (SEG_SEQ < HALF) {             =          // jumps forward over zero?
    RCV_PREV_SEQ =3D SEG_SEQ; =                  // update prev
    if (RCV_SNE_FLAG =3D=3D 0) {.             =    // first jump over zero? (wrap)
      RCV_SNE_FLAG =3D = 1;       =                // set flag so we increment = once
      = RCV_SNE =3D RCV_SNE + 1; =                 // increment window
      SNE =3D RCV_SNE; =                     =     // use = updated SNE value
  =   }
  } else {       =                     =         // jump backward over zero
    SNE =3D RCV_SNE - 1;             =           // use pre-rollover SNE value
  }
}
= --Apple-Mail=_F8BAE5A5-1401-4BC7-9935-3D86928C0329-- From nobody Wed May 6 12:15:17 2020 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 037E03A0ABC for ; Wed, 6 May 2020 12:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 o51o3EUG5w24 for ; Wed, 6 May 2020 12:15:11 -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 8D18F3A0AB4 for ; Wed, 6 May 2020 12:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=References:To:In-Reply-To:Subject:Date: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VxGhjQjMvZ+1NBFrUBrkvzple5JmVvTBwVhnp53pcxw=; b=yxF08TTru1S8kRwWKpnAo9kSc e/HidkMu3uXS0c7PLcGSZy71Pt9/0zQlnsX1KWcJ/UQpwhh/IPB9CrVvQRTVl0pixtJg5FrBRCva4 V1fIJtwCvhiy0DD4K860dX6/DtALAqJrJpmcHujaWSvAqlqAwj0Qgy6GenZItx2/hOOAw7a/4lwY5 IXTuOT+oqy7AJehlnH+kGh9N7rNBF6W9dWJOGHDIzZzhj+0QHRjIS0Tv574/39zleO1Lr5pKNzQPw 9DkrSziugWX4Vas2iNP/5csp/ZtpPJwD7zLXLW2EcNC1obrOwtcxAed2XOlFgpr5XVCFaWL3Bsgcm S376r5Q+Q==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61299 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jWPVZ-00183h-Jv; Wed, 06 May 2020 15:15:10 -0400 From: Joseph Touch Message-Id: <85AAF68F-DB45-475C-996C-8F99EF66D198@strayalpha.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A9A98273-C120-4BD2-B6D0-2D3080CD9D2C" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Wed, 6 May 2020 12:15:04 -0700 In-Reply-To: <26C2355F-AAF8-405B-BA38-8E7F50013D27@strayalpha.com> To: tcpm IETF list References: <26C2355F-AAF8-405B-BA38-8E7F50013D27@strayalpha.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) 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] RFC 5925 SNE algorithm concern 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, 06 May 2020 19:15:14 -0000 --Apple-Mail=_A9A98273-C120-4BD2-B6D0-2D3080CD9D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 PS -=20 #define distance(x,y) (((x)<(y))?((y)-(x)):((x)-(y))) The idea is that if we treat the two values as if they=E2=80=99re in the = same SNE, would they be valid (i.e., jump less than half). If so, = they=E2=80=99re in the same SNE. If not, then they must be in different = SNEs (and then their distance would be less than half). Joe > On May 6, 2020, at 12:07 PM, Joseph Touch = wrote: >=20 > Hi, all, >=20 > Juhamatti pointed out a flaw in the pseudocode for receive-side SNE = computation in RFC 5925. >=20 > The good news (in a sense) is that the code was not normative;=20 >=20 > The implementation of SNEs is not specified in this document, but = one > possible way is described here that can be used for either RCV.SNE, > SND.SNE, or both. >=20 > The corrections that Juhamatti posted don=E2=80=99t address the key = issue, which is that there are several possible interpretations of any = received SEQ. There is no simple way to fix this except to handle all = the cases (which the code below does - I believe minimally): >=20 > - it is in-order > - moving the receive window forward > - incrementing the SNE if it wraps the number space > - it is out-of-order > - which might use either the current SNE or SNE-1, = depending on whether it is pre-wrap of the number space >=20 > Because the number space wraps, all received SEQ could be interpreted = as in-order or out-of-order; the only way to know the difference is the = distance between the two =E2=80=94 which cannot be larger than 0x7FFF = FFFF (half the number space minus 1). >=20 > The following is code that covers the cases and passes all current = tests. Given this is not as obvious as it might seem and might be more = useful than for just RFC 5925 and the SNE alg in 5925 is =E2=80=9Cnot = specified=E2=80=9D anyway, I propose to submit this as a stand-alone = doc. >=20 > So here are the ways forward: >=20 > 1) have that doc =E2=80=9CUPDATE=E2=80=9D RFC 5925 > this is the cleanest because it would more definitely be = caught by implementers > but it requires the new alg be standards-track, which = seems odd (though we could say what SNE is as a standard > and still leave its implementation as informative rather = than normative) >=20 > 2) publish that doc as informational > then we could issue an errata on 5925 to point to the = new RFC >=20 > 3) issue the new alg as an errata to 5925 only >=20 > Any thoughts? >=20 > Joe >=20 > =E2=80=94=E2=80=94 >=20 > PS - here=E2=80=99s the alg: >=20 >=20 > #DEFINE HALF (0x80000000) >=20 > SNE =3D RCV_SNE; // use current SNE (as = default) > if (distance(SEG_SEQ,RCV_PREV_SEQ) < HALF) { // both in same SNE = range? > if ((SEG_SEQ >=3D HALF)=20 > && (RCV_PREV_SEQ < HALF)) { // jumps fwd over N/2? > RCV_SNE_FLAG =3D 0; // reset wrap increment = flag > } > RCV_PREV_SEQ =3D MAX(SEG_SEQ,RCV_PREV_SEQ); // move prev forward if = needed > } else { // both in diff SNE = ranges > if (SEG_SEQ < HALF) { // jumps forward over = zero? > RCV_PREV_SEQ =3D SEG_SEQ; // update prev > if (RCV_SNE_FLAG =3D=3D 0) {. // first jump over = zero? (wrap) > RCV_SNE_FLAG =3D 1; // set flag so we = increment once > RCV_SNE =3D RCV_SNE + 1; // increment window > SNE =3D RCV_SNE; // use updated SNE = value > } > } else { // jump backward over = zero > SNE =3D RCV_SNE - 1; // use pre-rollover SNE = value > } > } > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_A9A98273-C120-4BD2-B6D0-2D3080CD9D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 PS = - 

#define distance(x,y) =   (((x)<(y))?((y)-(x)):((x)-(y)))

The idea is that if we treat the two = values as if they=E2=80=99re in the same SNE, would they be valid (i.e., = jump less than half). If so, they=E2=80=99re in the same SNE. If not, = then they must be in different SNEs (and then their distance would be = less than half).

Joe

On May 6, 2020, at 12:07 PM, = Joseph Touch <touch@strayalpha.com> wrote:

Hi, all,

Juhamatti pointed out a = flaw in the pseudocode for receive-side SNE computation in RFC = 5925.

The good = news (in a sense) is that the code was not normative; 

   The implementation of SNEs =
is not specified in this document, but one
   possible way is described here that can be used for either RCV.SNE,
   SND.SNE, or both.

The corrections that Juhamatti posted = don=E2=80=99t address the key issue, which is that there are several = possible interpretations of any received SEQ. There is no simple way to = fix this except to handle all the cases (which the code below does - I = believe minimally):

= - it is in-order
- = moving the receive window forward
= - incrementing the SNE if it wraps the number = space
- it is out-of-order
= - which might use either the current SNE or SNE-1, depending on = whether it is pre-wrap of the number space

Because the number space wraps, all = received SEQ could be interpreted as in-order or out-of-order; the only = way to know the difference is the distance between the two =E2=80=94 = which cannot be larger than 0x7FFF FFFF (half the number space minus = 1).

The = following is code that covers the cases and passes all current tests. = Given this is not as obvious as it might seem and might be more useful = than for just RFC 5925 and the SNE alg in 5925 is =E2=80=9Cnot = specified=E2=80=9D anyway, I propose to submit this as a stand-alone = doc.

So here = are the ways forward:

= 1) have that doc =E2=80=9CUPDATE=E2=80=9D RFC 5925
= this is the cleanest because it would more definitely be caught = by implementers
but it requires the new = alg be standards-track, which seems odd (though we could say what SNE is = as a standard
and still leave its = implementation as informative rather than normative)

2) = publish that doc as informational
= then we could issue an errata on 5925 to point to the new = RFC

3) issue = the new alg as an errata to 5925 only

Any thoughts?

Joe

=E2=80=94=E2=80=94

PS - here=E2=80=99s the = alg:


#DEFINE HALF = (0x80000000)

SNE =3D = RCV_SNE;                   =             // use current SNE (as = default)
if = (distance(SEG_SEQ,RCV_PREV_SEQ) < HALF) { // both in same SNE range?
  if ((SEG_SEQ >=3D HALF) 
      && = (RCV_PREV_SEQ < HALF)) {     =        // jumps fwd over N/2?
    = RCV_SNE_FLAG =3D 0; =                     =    // reset wrap = increment flag
  }
  RCV_PREV_SEQ =3D = MAX(SEG_SEQ,RCV_PREV_SEQ);  // move prev forward if needed
} = else {    =                     =              // both in diff SNE ranges
  if (SEG_SEQ < = HALF) {             =          // jumps forward over zero?
    RCV_PREV_SEQ =3D SEG_SEQ;       =            // update prev
    if (RCV_SNE_FLAG =3D=3D 0) {. =                // first jump over zero? = (wrap)
      RCV_SNE_FLAG =3D 1;       =                // set flag so we increment = once
      RCV_SNE =3D RCV_SNE + 1;       =           // increment window
      = SNE =3D RCV_SNE;                 =         // use updated SNE value
    = }
  } else = {                     =               // jump backward over = zero
    SNE =3D RCV_SNE - 1;             =           // use pre-rollover SNE value
  }
}
_______________________________________________tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_A9A98273-C120-4BD2-B6D0-2D3080CD9D2C-- From nobody Wed May 6 12:36:33 2020 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 DAD363A0AC1 for ; Wed, 6 May 2020 12:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 3OhR0l5JjMnL for ; Wed, 6 May 2020 12:36:27 -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 CFFF03A0ABC for ; Wed, 6 May 2020 12:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=References:To:In-Reply-To:Subject:Date: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7tfhCUBXB+Tc4CDLWMIUIIH/J0BOd1HSVPnYwB4Kvw4=; b=nRTGK4tIgjnNZIuu1zoLTY3Vk BSxApLNZ0wisMjk0LSKSsBImaWJRPVkWNmUqo8iSJdOgs6CrzHBQ7Yt2N2aIF2DtQT+/15gRUtURk b6eGxxfNkX5zcq366KFD4nKSjX42MrLCsNZl2f+n9dnE5QYyAFHcpdpEYOxSRF4k+mgAgKcnK4Geu 6hittpYNlpMuo3E9rJt9h7XBMj3HdMgVfKmEFrPVoz4XG+HOX3CIK1dGJaqcd58u0Z90aVfS7Fq6y svCwOvW8VxRBjC7f9zPYsFDGqvKrE+8cLJCqv+njJAbVot2MFZ7o8omtXdp1AI7ZQx+c2J3KgNWSg uiqSK6iQQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61343 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jWPqB-001XhO-0F; Wed, 06 May 2020 15:36:27 -0400 From: Joseph Touch Message-Id: <4E2DD376-438F-416E-9D1C-0934F517E2C2@strayalpha.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A7C2B710-EF89-40DF-9510-AD09176A1501" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Wed, 6 May 2020 12:36:22 -0700 In-Reply-To: <85AAF68F-DB45-475C-996C-8F99EF66D198@strayalpha.com> To: tcpm IETF list References: <26C2355F-AAF8-405B-BA38-8E7F50013D27@strayalpha.com> <85AAF68F-DB45-475C-996C-8F99EF66D198@strayalpha.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) 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] RFC 5925 SNE algorithm concern 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, 06 May 2020 19:36:31 -0000 --Apple-Mail=_A7C2B710-EF89-40DF-9510-AD09176A1501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s a full version, with everything including initialization = and definitions.=20 // compute the distance from x to y assuming they are in the same SNE #define DIST(x,y) (((x)<(y))?((y)-(x)):((x)-(y))) #define HALF (0x80000000) // shorthand used in the = code below // variables, with inits where required unsigned long RCV_SNE =3D 0; // high-watermark SNE, = init per RFC5925 int RCV_SNE_FLAG =3D 1; // set during first half = of rollover unsigned long RCV_PREV_SEQ; // high-watermark SEQ, init = by ISN unsigned long SEG_SEQ; // input - received SEQ unsigned long SNE; // output - SNE = corresponding to received SEQ if (SYN =3D=3D 1) { // SYN or SYN-ACK = initialization RCV_PREV_SEQ =3D RECV_ISN; } // after SYN or SYN-ACK SNE =3D RCV_SNE; // use current SNE (as = default) if (DIST(SEG_SEQ,RCV_PREV_SEQ) < HALF) { // both in same SNE range? if ((SEG_SEQ >=3D HALF)=20 && (RCV_PREV_SEQ < HALF)) { // jumps fwd over N/2? RCV_SNE_FLAG =3D 0; // reset wrap increment = flag } RCV_PREV_SEQ =3D MAX(SEG_SEQ,RCV_PREV_SEQ); // move prev forward if = needed } else { // both in diff SNE ranges if (SEG_SEQ < HALF) { // jumps forward over zero? RCV_PREV_SEQ =3D SEG_SEQ; // update prev if (RCV_SNE_FLAG =3D=3D 0) {. // first jump over zero? = (wrap) RCV_SNE_FLAG =3D 1; // set flag so we = increment once RCV_SNE =3D RCV_SNE + 1; // increment window SNE =3D RCV_SNE; // use updated SNE value } } else { // jump backward over zero SNE =3D RCV_SNE - 1; // use pre-rollover SNE = value } } --Apple-Mail=_A7C2B710-EF89-40DF-9510-AD09176A1501 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Here=E2=80=99s a full version, with everything including = initialization and definitions. 

// = compute the distance from x to y assuming they are in the same = SNE
#define DIST(x,y) (((x)<(y))?((y)-(x)):((x)-(y)))
#define HALF     =  (0x80000000)             =  // shorthand used in the code below

// variables, with inits where required
unsigned long RCV_SNE =3D 0;     =              // high-watermark SNE, = init per RFC5925
int         =   RCV_SNE_FLAG =3D 1;         =     // set during first half of rollover
unsigned long RCV_PREV_SEQ;     =             // high-watermark SEQ, = init by ISN
unsigned long SEG_SEQ;    =                   // = input - received SEQ
unsigned long SNE;  =                     =     // output - SNE corresponding to received = SEQ

if (SYN =3D=3D 1) {     =                     =     // SYN or SYN-ACK initialization
  RCV_PREV_SEQ =3D = RECV_ISN;
}         =                     =               // after SYN or = SYN-ACK
SNE =3D RCV_SNE;             =                  // use = current SNE (as default)
if (DIST(SEG_SEQ,RCV_PREV_SEQ)= < HALF) {    // both in same SNE range?
  if ((SEG_SEQ >=3D HALF) 
      && (RCV_PREV_SEQ = < HALF)) {           // jumps fwd = over N/2?
    RCV_SNE_FLAG =3D 0;   =                   =   // reset wrap increment flag
  }
  RCV_PREV_SEQ =3D MAX(SEG_SEQ,RCV_PREV_SEQ); // move = prev forward if needed
} else {     =                     =            // both in diff SNE ranges
  if (SEG_SEQ < HALF) {     =                 // jumps = forward over zero?
    RCV_PREV_SEQ =3D SEG_SEQ; =                 // update = prev
    if (RCV_SNE_FLAG =3D=3D 0) {. =               // first jump over = zero? (wrap)
      RCV_SNE_FLAG =3D 1; =                   =   // set flag so we increment once
    =   RCV_SNE =3D RCV_SNE + 1;           =      // increment window
    =   SNE =3D RCV_SNE;               =          // use updated SNE value
    }
  } else { =                     =              // jump backward over = zero
    SNE =3D RCV_SNE - 1;     =                  // use = pre-rollover SNE value
  }
}

= --Apple-Mail=_A7C2B710-EF89-40DF-9510-AD09176A1501-- From nobody Wed May 6 23:00:57 2020 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 72F9E3A093D for ; Wed, 6 May 2020 23:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cflQLTdAsl13 for ; Wed, 6 May 2020 23:00:49 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 040F33A0939 for ; Wed, 6 May 2020 23:00:48 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id s8so4804243wrt.9 for ; Wed, 06 May 2020 23:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=THxoPjFvHiEJxFyDjs8YXFTmvudobQcwZsFSdbVFrw8=; b=Ev54sW9yfsWZOvSiwC7ArVHbVXQPTVmrxzReGl6wq2M4VOGM7GJs6d7CdauORXr2Yc N8MNlNbQ5A69aMl+mS2TwELVXpE8Qw+w8douAjU/DsWX9anBCfL5wny8xEUZBPaok/BS H3EU+GeYk5yy2V61qzz9UueU31/iVkMsGpTiPCBmiMbT1vcuzhOeqEeiynoyPtyFEMUk eRY+DqBcACh6oiQeK/MNbZ/1te94cPc5uYSsVg4nvVJdphkDvvBctmaihBxxPjxV6tls fIuSrRpRGGZrtzHxGLN/TrdAP9r6UF4JygHTeW6DrSU4i4sDB7a+GAnMoDJ8LuWNdzlF k1tw== 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:content-transfer-encoding; bh=THxoPjFvHiEJxFyDjs8YXFTmvudobQcwZsFSdbVFrw8=; b=X23Q5iV1DNp8HSLSKJW8nZ81E7SkD9ia2+aJ/ig/IQzmOapGZRRtqXvuRqy+++lhz2 ABgjCEN8bsp9ac7DNAUYZt3pqW6ZVE/5EyK4IPxvdT9TCr3kXPsrBAzzHSnJQI6x5CwQ p9yuN43UUsps0PNuuEUjJOvudqeVShwgOy0m1Gg+ULEOxkxs347leGfvA7LN+/1h2rqi Wz4oL0s28YL7E7AW1HNxC8UOpj6xxHvIc3IFDm/p8+S/GJoSzpxgz9M3UeNpxgGc+0CX TEzRrobXPEGrOncjWwFl/nfC1t77jVEvOI5Bdb1smZZpLb2Jq5ANyNenWAFFiU+2Q7rR adJg== X-Gm-Message-State: AGi0PuZ3IeVbU/oRuga9LOO6479pdCj5hahTQhlBr2FrwZIeLzb2Ivr1 OoSOhn48pbgEnDGVxzemEVTNBGS0NXiQLfjfSejGGIsL X-Google-Smtp-Source: APiQypLZ9bRsl6alz3a1wjSskYmVD//V8821nAaw6lDVLXRjInU8mB1NI9IK+UxsQHiwRxbX1S88MiApNiNTcTJqCPU= X-Received: by 2002:adf:9447:: with SMTP id 65mr13730410wrq.331.1588831246431; Wed, 06 May 2020 23:00:46 -0700 (PDT) MIME-Version: 1.0 References: <26C2355F-AAF8-405B-BA38-8E7F50013D27@strayalpha.com> <85AAF68F-DB45-475C-996C-8F99EF66D198@strayalpha.com> <4E2DD376-438F-416E-9D1C-0934F517E2C2@strayalpha.com> In-Reply-To: <4E2DD376-438F-416E-9D1C-0934F517E2C2@strayalpha.com> From: juhamatk@gmail.com Date: Thu, 7 May 2020 09:00:34 +0300 Message-ID: To: tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] RFC 5925 SNE algorithm concern 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, 07 May 2020 06:00:55 -0000 Hello, +1 for below algorithm. The earlier improved algorithm I suggested did not handle middle-range retransmissions correctly, this one does. It also passes other tests I have (which found the original issues). Thank you, -- Juhamatti On Wed, 6 May 2020 at 22:36, Joseph Touch wrote: > > Here=E2=80=99s a full version, with everything including initialization a= nd definitions. > > // compute the distance from x to y assuming they are in the same SNE > #define DIST(x,y) (((x)<(y))?((y)-(x)):((x)-(y))) > #define HALF (0x80000000) // shorthand used in the code= below > > // variables, with inits where required > unsigned long RCV_SNE =3D 0; // high-watermark SNE, init= per RFC5925 > int RCV_SNE_FLAG =3D 1; // set during first half of= rollover > unsigned long RCV_PREV_SEQ; // high-watermark SEQ, init b= y ISN > unsigned long SEG_SEQ; // input - received SEQ > unsigned long SNE; // output - SNE corresponding= to received SEQ > > if (SYN =3D=3D 1) { // SYN or SYN-ACK initial= ization > RCV_PREV_SEQ =3D RECV_ISN; > } // after SYN or SYN-ACK > SNE =3D RCV_SNE; // use current SNE (as defa= ult) > if (DIST(SEG_SEQ,RCV_PREV_SEQ) < HALF) { // both in same SNE range? > if ((SEG_SEQ >=3D HALF) > && (RCV_PREV_SEQ < HALF)) { // jumps fwd over N/2? > RCV_SNE_FLAG =3D 0; // reset wrap increment fla= g > } > RCV_PREV_SEQ =3D MAX(SEG_SEQ,RCV_PREV_SEQ); // move prev forward if nee= ded > } else { // both in diff SNE ranges > if (SEG_SEQ < HALF) { // jumps forward over zero? > RCV_PREV_SEQ =3D SEG_SEQ; // update prev > if (RCV_SNE_FLAG =3D=3D 0) {. // first jump over zero? = (wrap) > RCV_SNE_FLAG =3D 1; // set flag so we increment= once > RCV_SNE =3D RCV_SNE + 1; // increment window > SNE =3D RCV_SNE; // use updated SNE value > } > } else { // jump backward over zero > SNE =3D RCV_SNE - 1; // use pre-rollover SNE val= ue > } > } > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri May 8 10:05:05 2020 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 1004A3A0F11; Fri, 8 May 2020 10:04:51 -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.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158895749102.16082.17869942226392212066@ietfa.amsl.com> Date: Fri, 08 May 2020 10:04:51 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:04:58 -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 : Requirements for Time-Based Loss Detection Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-13.txt Pages : 11 Date : 2020-05-08 Abstract: Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, protocols ultimately can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-13 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-13 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 May 8 10:07:14 2020 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 7BCD53A0D66 for ; Fri, 8 May 2020 10:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 qLylWsNoDXWT for ; Fri, 8 May 2020 10:07:08 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (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 39A183A0D7F for ; Fri, 8 May 2020 10:06:52 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id j26so2055220ots.0 for ; Fri, 08 May 2020 10:06:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=h+YNVxIcmYZ7bp07/Bi1QtDSa06gqmIjctJiybw9/Dk=; b=RY2skKtCXryqGjjoBVZhVklpSCR3wWVUuNnKGo8dpgpCMsXsKcn2au1pTy5/zsWv/N 4kVC08D9S8sOb45O5H4SXP7PBOILHb0t+tbe0gBo9eVVg/6fQciDFTkc5dNvimCY3rF3 4dBP6rEtsG2ze0I8QBjtMPtOq+FiddvWRS1MuQCnhMxR5A2edifUfWT08GvBK18l4xY4 FOmKkOeCR8UA2J3t6vcQkNuxaXtlGNdM2P7/CIdbWzIvocZmAdcRfT8jHeQc5fVbEzRE /naMNpkHfJy69aNOPmyJzOFMc6wWf8D+bcpphSHjh6JkQr6/zOr+DVAOuhp4P73iRu8v bpSw== X-Gm-Message-State: AGi0PuY/Ax72gRFlPdge0S85TXOolva0Csf30Eavv2HMOK3Rfe0s4sYh iKNYEip7TZbxHlGbuRNUv57raf1PXQzxaQ== X-Google-Smtp-Source: APiQypKZyKHUzvZS0glBsA2v6qKU9Lbwq3lpaibPo0/SWI+d5TQe1qzokoGFAI0xacOhCPl0x7SUTQ== X-Received: by 2002:a9d:7ad8:: with SMTP id m24mr3220295otn.22.1588957611148; Fri, 08 May 2020 10:06:51 -0700 (PDT) Received: from [169.254.253.174] ([2600:1700:b380:3f00:3c34:d53e:4afc:de26]) by smtp.gmail.com with ESMTPSA id u82sm2347074oia.35.2020.05.08.10.06.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 May 2020 10:06:50 -0700 (PDT) From: "Mark Allman" To: tcpm@ietf.org Date: Fri, 08 May 2020 13:06:49 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: <158895749102.16082.17869942226392212066@ietfa.amsl.com> References: <158895749102.16082.17869942226392212066@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_017BF880-A588-4769-844A-267055FB9FE4_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-13.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: Fri, 08 May 2020 17:07:12 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_017BF880-A588-4769-844A-267055FB9FE4_= Content-Type: text/plain This version includes clarifications stemming from Martin's AD review of the document. allman > 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 : Requirements for Time-Based Loss Detection > Author : Mark Allman > Filename : draft-ietf-tcpm-rto-consider-13.txt > Pages : 11 > Date : 2020-05-08 > > Abstract: > Many protocols must detect packet loss for various reasons (e.g., to > ensure reliability using retransmissions or to understand the level > of congestion along a network path). While many mechanisms have > been designed to detect loss, protocols ultimately can only count on > the passage of time without delivery confirmation to declare a > packet "lost". Each implementation of a time-based loss detection > mechanism represents a balance between correctness and timeliness > and therefore no implementation suits all situations. This document > provides high-level requirements for time-based loss detectors > appropriate for general use in the Internet. Within the > requirements, implementations have latitude to define particulars > that best address each situation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-13 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-13 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=_MailMate_017BF880-A588-4769-844A-267055FB9FE4_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXrWRqREcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizn7gAJ40uxYSEAQMqpmZdHSSjHXGLPwiHACfQEs+ +qpEJaw5xSdA7Xx1GM7EIQc= =hyLI -----END PGP SIGNATURE----- --=_MailMate_017BF880-A588-4769-844A-267055FB9FE4_=-- From nobody Fri May 8 16:08:42 2020 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 EC5713A106F for ; Fri, 8 May 2020 16:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 NgWmjJBdzWrb for ; Fri, 8 May 2020 16:08:33 -0700 (PDT) Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) (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 1E7403A105C for ; Fri, 8 May 2020 16:08:33 -0700 (PDT) Received: by mail-vk1-xa44.google.com with SMTP id i185so866129vki.12 for ; Fri, 08 May 2020 16:08:33 -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:content-transfer-encoding; bh=daZizMW/hvMktefnFxXDsbHHmMMsRvPd53gytqD2HBk=; b=lyjPUx4710pHRs2NGYDQBPL3b5VU6epspAxu/bJQhSQAuAStWT5JROCimM1v4270QO Ef69Fn7YzSxSBbkIocP/Ox7xljWpOYPumkixjG9skWuhN07bPdjF7+dhGeBGiofKkRXb flx0eFlwyzwE7cRKQVBYdsr3VosCsycnMAJXettvClH26tphdvnwmo2ZZR6eVeT/+mun Xn12FLa3E/obli3bQ2F89Rrp4LSQKMB8gembeDRENCIVwsxODNk/XDMnRr8IWGmCjaxd ltpkJ84VclTiemNfxgpPz78p8l8y8c6VENlddYGsMfBCtDXLsxCOiLbByrBhY6GZ3Cgh nSnA== 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:content-transfer-encoding; bh=daZizMW/hvMktefnFxXDsbHHmMMsRvPd53gytqD2HBk=; b=dOWotiu1G5MNk+ZjQdJb/hSM4tXXphWvtxbL/BiBHPGaA/9HeudhB1xVo1q0uvX6RF s5c5a3AoA2khJVD37jEq0t+qie+0lyHGAPLKBCpEyyCYMg6uxosGkXZ0jkdTBD6LUuaA nJJWzgKmiPuFdNowpLbodXWhEPXYyx6pSz3+/b2GZdU4D4TTie5NkoT23akBK71vtflY buHjyxI5YjmI7weLDvm5vR348qiMGb2EYiNfQto3PVxSMEX1qU8Zaeoftk72SSRoWPVG E6Zl1BxnP7HG5/1gu9KOnuXm/jxEOoXoZUwz7yQ/SUTme8RPxVVMkiO05QR5KHKJnMw6 rF7A== X-Gm-Message-State: AGi0PuZAj3kYVCuOTfA1+CmcjJr59LKEoO3Y5CXDOYbYS8p2hrMO1Vpk OH87ZKYlaLF966Hnxo1MFofViupio2dUVVe2JYSUQw== X-Google-Smtp-Source: APiQypLt3DCxX4g1oOqTtneQU7BwSuy7a/QEgx6NiZcD+NXDSlo8SJgn/BCpXQzrdqb8ECno1dK6CsiFgnTMvOsOsIY= X-Received: by 2002:a1f:1757:: with SMTP id 84mr4224482vkx.68.1588979311678; Fri, 08 May 2020 16:08:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Fri, 8 May 2020 16:07:55 -0700 Message-ID: To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= Cc: "tcpm@ietf.org Extensions" , Neal Cardwell , Nandita Dukkipati , Priyaranjan Jha Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-rack-07 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, 08 May 2020 23:08:38 -0000 On Mon, Apr 6, 2020 at 2:01 PM Ilpo J=C3=A4rvinen wrote: > > Hi Yuchung, > > Certainly improved on many things, however, I'm surprised that the lost > rexmit comment was not addressed at all. Aren't the rexmit losses > supposed to be detected by RACK or have I misunderstood something? > > I don't understand how lost rexmits are detected by the algorithms in > the draft. I think the algorithms are either flawed or lack something > (mainly RACK_detect_loss is relevant I think). My original comment > from below. > > Is RACK_detect_loss() supposed to detect also lost rexmits? How? > The rexmit code itself is not in the draft so it's hard to evaluat= e > how the Packet booleans are supposed to work in the first place. > I'm not saying the rexmit code should be included but currently it > surely looks like any rexmitted packet just remains .lost =3D TRUE > and .retransmitted =3D TRUE state until RTO? Sorry to miss this point earlier -- RACK definitely detects lost-retransmits, but the current algorithm does not properly define some variables. Here is how I propose to address these by adding these: Per-packet variables Theses variables indicate the status of the most recent transmission of a data packet: =E2=80=9CPacket.lost=E2=80=9D is true if the most recent (re)transm= ission of the Packet has been considered lost and needs to be retransmitted. False otherwise. =E2=80=9CPacket.retransmitted=E2=80=9D is tue if its sequence numbe= rs were retransmitted in the most recent transmission. False otherwise. =E2=80=9CPacket.xmit_ts=E2=80=9D is the time of the last transmissi= on of a data packet, including retransmissions, if any. The sender needs to record the transmission time for each packet sent and not yet acknowledged. The time MUST be stored at millisecond granularity or finer. Transmitting a data packet Upon transmitting a new packet or retransmitting an old packet, record the time in Packet.xmit_ts. --- src RACK_transmit_data(Packet): Packet.time_ts =3D Now() Packet.lost =3D FALSE RACK_retransmit_data(Packet) Packet.retransmitted =3D TRUE RACK_transmit_data(Packet) --- When a packet is retransmitted again, its Packet.lost is reset and transmission timestamp is renewed. Therefore, when its transmission time falls out of the RACK reordering window in RACK_detect_loss(), it will be marked as lost (again). > > Also my timeout "some" vs "all" internal inconsistency comment relates to > this same algorithm: > > "For timely loss detection, the sender MAY > install a "reordering settling" timer set to fire at the earlie= st > moment at which it is safe to conclude that some packet is lost= . The > earliest moment is the time it takes to expire the reordering w= indow > of the earliest unacked packet in flight." > vs > RACK_detect_loss(): > ... > timeout =3D max(remaining, timeout) > Which way it is, "some" or "all"? The use of max() in RACK_detect_= loss() > seems to indicate that the timeout will be set according to the lo= ngest > time, that is, the latest moment rather than earliest moments. Whi= ch > is the intented behavior here? (I can there might be merits in bot= h > approaches). Comment 1.2: good catch. We changed to: 'For timely loss detection, the sender is RECOMMENDED to install a "reordering settling" timer. The timer expires at the earliest moment when it is safe to conclude that all the unacknowledged packets within the reordering window are lost.' > > > Then there are some other comments I made which seem also unaddressed but > I'll not duplicate them all here. > > > -- > i. > > > On Mon, 9 Mar 2020, Yuchung Cheng wrote: > > > Hi Ilpo, > > Thanks for a detailed review and the great suggestions. Here's all the = edits > > we made. > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-08 > > > > We defined the missing terms and addressed the nits, removed the less > > critical parts like recommending PRR, and edited TLP algorithms (sectio= ns > > 7.4 to 7.6). I hope you find it's better now and would be happy to hear= any > > improvements you'd like to make. > > > > Yuchung > > > > On Fri, Feb 14, 2020 at 4:22 AM Ilpo J=C3=A4rvinen > > wrote: > > In general, I find the draft quite good shape already, it's > > quite easy > > to read and follow (that is, except the TLP sections that are > > specifically > > mentioned below). > > > > Here's the list of issues I came across: > > > > Sect 6.1 > > > > "RACK.pkts_sacked" lacks the empty line separator. > > > > Sect 7.2 > > > > "This > > heuristic would fail to update RACK stats if the packet is > > spuriously > > retransmitted because of a recent minimum RTT decrease (e.g. > > path > > change)." > > This defies my logic as RTT decrease should not result in > > spurious > > retransmissions but help to avoid them. > > > > > > "Note that > > extensions that require additional TCP features (e.g. DSACK) > > would > > work if the feature functions simply return false." > > Please rephrase this. I suspect you meant that if some functions > > relate > > to TCP features that are not available, the given code still > > works > > as long as the functions related to such features return false > > when > > the TCP feature is not available but that surely isn't what the > > sentence currently says. > > > > Sect 7.2 Step 5 > > > > "For timely loss detection, the sender MAY > > install a "reordering settling" timer set to fire at the > > earliest > > moment at which it is safe to conclude that some packet is > > lost. The > > earliest moment is the time it takes to expire the reordering > > window > > of the earliest unacked packet in flight." > > vs > > RACK_detect_loss(): > > ... > > timeout =3D max(remaining, timeout) > > Which way it is, "some" or "all"? The use of max() in > > RACK_detect_lost() > > seems to indicate that the timeout will be set according to the > > longest > > time, that is, the latest moment rather than earliest moments. > > Which > > is the intented behavior here? (I can there might be merits in > > both > > approaches). > > > > > > In general, I didn't like the presentation order here as this > > form looks > > the most obvious to me: > > now >=3D Packet.xmit_ts + RACK.reo_wnd + (RACK.ack_ts - > > RACK.xmit_ts) > > ...and I find the derivation of it just complicating things > > rather > > than helping but that's perhaps just my opinion. > > > > > > "It is also useful when the timestamp clock granularity is > > close to > > or longer than the actual round trip time." > > Given that some things based on timestamps will obviously stop > > working > > if the clock is slower than one tick per RTT I found this > > fragment a bit > > odd. RFC 7323 says "the clock SHOULD tick at least once per > > window's worth > > of data". I can understand though that a host might find clock > > tick > > granularity challenging due to extensive RTT range but on the > > same > > I'd not want such a "too slow clock" behavior to be endorsed as > > if > > it would be just normal. That is, I'm not against RACK handling > > also this case nicely but it would be nice to somehow downplay > > the > > normalness tone in it with something along the lines of "This > > check is > > also useful if the recommended one tick per RTT cannot be > > achieved due > > to timestamp clock granularity." > > > > Is RACK_detect_lost() supposed to detect also lost rexmits? How? > > The rexmit code itself is not in the draft so it's hard to > > evaluate > > how the Packet booleans are supposed to work in the first place. > > I'm not saying the rexmit code should be included but currently > > it > > surely looks like any rexmitted packet just remains .lost =3D TRU= E > > and > > .retransmitted =3D TRUE state until RTO? > > > > > > Sect 7.4 > > > > "PTO" just appears out of nowhere (and is not even written open > > in the first instance). > > > > "2. ... in step (2) of the algorithm." > > "step (2)" is forward-refing, it would naturally refer back to > > "Step 2: Update RACK stats" so it makes very little sense as is. > > > > Sect 7.5 > > > > Separator missing for PTO: and TLPRxtOut: > > > > Sect 7.5.1 > > > > "3. Upon receiving a SACK that selectively acknowledges data > > that was > > last sent before the segment with SEG.SEQ=3DSND.UNA was > > last > > (re)transmitted" > > This is hard to understand, perhaps rephrase it somehow? > > > > > > "But choosing PTO to be > > exactly an SRTT is likely to generate spurious probes given > > that > > network delay variance and even end-system timings can easily > > push an > > ACK to be above an SRTT. We chose PTO to be the next > > integral > > multiple of SRTT. > > > > Similarly, network delay variations and end-system processing > > latencies and timer granularities can easily delay ACKs > > beyond > > 2*SRTT, so senders SHOULD add at least 2ms to a computed PTO > > value > > (and MAY add more if the sending host OS timer granularity is > > more > > coarse than 1ms)." > > Does this later paragraph depend on some assumptions (such as > > very > > low RTT?) as I don't otherwise understand why you say what you > > say > > in the given order. First you said x & y can push ACK over SRTT > > so > > we pick 2* but then you say the same things can push over 2*SRTT > > too? > > > > WCDelAckT to terminology? > > > > Sect 7.5.2 > > > > TLP_send_probe(): > > - Perhaps set TLPRxtOut somewhere? > > - Add "Arm RTO" to the end? > > > > "In the case where > > there is only one original outstanding segment of data (N=3D1)= , > > the > > same logic (trivially) applies: an ACK for a single > > outstanding > > segment tells the sender the N-1=3D0 segments preceding that > > segment > > were lost. Furthermore, whether there are N>1 or N=3D1 > > outstanding > > segments," > > If this distinction is useful to make at all, maybe just simply > > say: > > "Applies also in case N=3D1." > > > > Sect 7.6 > > > > "SND.NXT at the time the episode started." > > Isn't this TLPHighRxt, why not use it here? > > > > Sect 7.6.2 > > > > "Upon sending a TLP probe that is a retransmission, the sender > > sets > > TLPRxtOut to true and TLPHighRxt to SND.NXT." > > This should appear in TLP_send_probe(). > > > > "Detecting recoveries accomplished by loss probes" > > Did you want to start another section here? > > > > "Step 1: Track ACKs ..." until what point? (It's told on later > > but > > this question comes into mind when reading the draft in order). > > > > > > Sect 7.4 - 7.6.2 > > > > In general, this particular part of the draft seems to require > > some > > further editing. After reading it all through, I feel most bits > > are > > present but the text is very hard to follow. I think the > > presentation > > order needs significant work. There are random bits here and > > there > > that are explained only later. Also, algorithm lacks some parts > > discussed only in the text but variable like items should > > definitely > > be included to the algorithm. > > > > > > Sect 8.4 > > > > "RACK is compatible with and does not interfere with the the > > standard > > RTO [RFC6298], RTO-restart [RFC7765], F-RTO [RFC5682] and > > Eifel > > algorithms [RFC3522]. ... > > It neither changes the RTO timer calculation nor detects > > spurious > > timeouts." > > For F-RTO, also send order is significant. > > > > Sect 8.5 > > > > SHOULDs PRR (and also placed to normative references) that is > > only > > experimental and RACK aims to standards track. I feel that PRR > > is > > disjoint enough anyway, which I think was also your intention > > when > > maintaining the decoupling CC and RACK, that it's bit odd to > > take > > this strong stance on PRR (indepedent of the stds track vs > > experimental thing). > > > > "due to congestion window validation." > > Does this refer to CWV as in RFC? Or some other mechanism in > > which > > case you shouldn't use the same term here. > > > > I find the described scenario somewhat unconvincing becase > > the description ends with: > > "... > > The ending congestion window after recovery also impacts > > subsequent data transfer." > > ...First there wasn't enough data to fill cwnd of 20 packets and > > then suddenly transferring that non-existing data is impacted. > > > > References > > > > QUIC-LR is very old ref and even the filename has changed a few > > times from draft-tsvwg-... > > > > > > Nits > > > > "runt" made the sentence incomprehendable for me, I had to look > > up > > that word (and only second source was descriptive enough that I > > think I could understand the meaning, and I'd guessed wrong > > because > > I thought there was some special intent here because of the > > quotes). > > > > is dicussed -> is discussed > > RACT.RTT -> RACK.rtt > > First "TSO" -> TCP Segmentation Offload (TSO) > > grainularity -> granularity > > higher-sequenc -> higher-sequence > > > > > > -- > > i. > > > > > > From nobody Sat May 9 01:30:54 2020 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 C4DD43A08F6 for ; Sat, 9 May 2020 01:30:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cs.helsinki.fi 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 G4uXUU4dADew for ; Sat, 9 May 2020 01:30:48 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28FB3A08F4 for ; Sat, 9 May 2020 01:30:47 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Sat, 09 May 2020 11:30:40 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=Zfx3CSZ8ESXy1ryot Kyy+zu5z9bDd5HqohGmgmXn/as=; b=eHSaaYQlA9lnGpb5nxqe0uJG74xQaCz07 yCIymOfkelBMHqKYwP1Srbwoqlou0lTETmD/xAtelYgIHxgcN8UjfWqNjc6pP57i 0r6GUadX00XseAvH7pYk9YuTW1ymAgtt9ZjB7linsx4b4UjsdlxCHle3z0+L/SfM yW6jwwo4lk= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Sat, 09 May 2020 11:30:40 +0300 id 00000000005A0170.000000005EB66A30.00007E8D Date: Sat, 9 May 2020 11:30:40 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Yuchung Cheng cc: "tcpm@ietf.org Extensions" , Neal Cardwell , Nandita Dukkipati , Priyaranjan Jha In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-32421-1589013040-0001-2" Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-rack-07 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, 09 May 2020 08:30:52 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-32421-1589013040-0001-2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 8 May 2020, Yuchung Cheng wrote: > On Mon, Apr 6, 2020 at 2:01 PM Ilpo J=C3=A4rvinen > wrote: > > > > Hi Yuchung, > > > > Certainly improved on many things, however, I'm surprised that the lo= st > > rexmit comment was not addressed at all. Aren't the rexmit losses > > supposed to be detected by RACK or have I misunderstood something? > > > > I don't understand how lost rexmits are detected by the algorithms in > > the draft. I think the algorithms are either flawed or lack something > > (mainly RACK_detect_loss is relevant I think). My original comment > > from below. > > > > Is RACK_detect_loss() supposed to detect also lost rexmits? Ho= w? > > The rexmit code itself is not in the draft so it's hard to eva= luate > > how the Packet booleans are supposed to work in the first plac= e. > > I'm not saying the rexmit code should be included but currentl= y it > > surely looks like any rexmitted packet just remains .lost =3D = TRUE > > and .retransmitted =3D TRUE state until RTO? >=20 > Sorry to miss this point earlier -- RACK definitely detects > lost-retransmits, but the current algorithm does not properly define > some variables. Here is how I propose to address these by adding > these: Np and I was pleased to note already during the interim presentation=20 that you'd addressed this. > Per-packet variables >=20 >=20 > Theses variables indicate the status of the most recent transmission > of a data packet: > =E2=80=9CPacket.lost=E2=80=9D is true if the most recent (re)tr= ansmission of > the Packet has been considered lost and needs to be retransmitted. > False otherwise. > =E2=80=9CPacket.retransmitted=E2=80=9D is tue if its sequence n= umbers were > retransmitted in the most recent transmission. False otherwise. > =E2=80=9CPacket.xmit_ts=E2=80=9D is the time of the last transm= ission of a > data packet, including retransmissions, if any. The sender needs to > record the transmission time for each packet sent and not yet > acknowledged. The time MUST be stored at millisecond granularity or > finer. >=20 >=20 > Transmitting a data packet > Upon transmitting a new packet or retransmitting an old packet, record > the time in Packet.xmit_ts. >=20 > --- src >=20 > RACK_transmit_data(Packet): >=20 > Packet.time_ts =3D Now() >=20 > Packet.lost =3D FALSE >=20 >=20 > RACK_retransmit_data(Packet) >=20 > Packet.retransmitted =3D TRUE > RACK_transmit_data(Packet) >=20 > --- >=20 > When a packet is retransmitted again, its Packet.lost is reset and > transmission timestamp is renewed. Therefore, when its transmission > time falls out of the RACK reordering window in RACK_detect_loss(), it > will be marked as lost (again). >=20 >=20 >=20 >=20 > > > > Also my timeout "some" vs "all" internal inconsistency comment relate= s to > > this same algorithm: > > > > "For timely loss detection, the sender MAY > > install a "reordering settling" timer set to fire at the ea= rliest > > moment at which it is safe to conclude that some packet is = lost. The > > earliest moment is the time it takes to expire the reorderi= ng window > > of the earliest unacked packet in flight." > > vs > > RACK_detect_loss(): > > ... > > timeout =3D max(remaining, timeout) > > Which way it is, "some" or "all"? The use of max() in RACK_det= ect_loss() > > seems to indicate that the timeout will be set according to th= e longest > > time, that is, the latest moment rather than earliest moments. = Which > > is the intented behavior here? (I can there might be merits in = both > > approaches). >=20 > Comment 1.2: good catch. We changed to: 'For timely loss detection, > the sender is RECOMMENDED to install a "reordering settling" timer. > The timer expires at the earliest moment when it is safe to conclude > that all the unacknowledged packets within the reordering window are > lost.' I was under impression it's likely what you intented to propose right=20 from the start. In that case this change seems not enough to address my=20 concern, the algorithm seems to do exactly opposite on timeout =3D max(remaining, timeout) line, no? That is, if there is a moment further away in the future,=20 the line selects it rather than "the earliest moment". This inconsistency=20 between the text and algorithm is why I brought this up and I think the=20 algorithm requires some small tweak to remove the inconsistency here. --=20 i. >=20 >=20 > > > > > > Then there are some other comments I made which seem also unaddressed = but > > I'll not duplicate them all here. > > > > > > -- > > i. > > > > > > On Mon, 9 Mar 2020, Yuchung Cheng wrote: > > > > > Hi Ilpo, > > > Thanks for a detailed review and the great suggestions. Here's all = the edits > > > we made. > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-08 > > > > > > We defined the missing terms and addressed the nits, removed the l= ess > > > critical parts like recommending PRR, and edited TLP algorithms (se= ctions > > > 7.4 to 7.6). I hope you find it's better now and would be happy to = hear any > > > improvements you'd like to make. > > > > > > Yuchung > > > > > > On Fri, Feb 14, 2020 at 4:22 AM Ilpo J=C3=A4rvinen > > > wrote: > > > In general, I find the draft quite good shape already, it's > > > quite easy > > > to read and follow (that is, except the TLP sections that are > > > specifically > > > mentioned below). > > > > > > Here's the list of issues I came across: > > > > > > Sect 6.1 > > > > > > "RACK.pkts_sacked" lacks the empty line separator. > > > > > > Sect 7.2 > > > > > > "This > > > heuristic would fail to update RACK stats if the packet is > > > spuriously > > > retransmitted because of a recent minimum RTT decrease (e.= g. > > > path > > > change)." > > > This defies my logic as RTT decrease should not result in > > > spurious > > > retransmissions but help to avoid them. > > > > > > > > > "Note that > > > extensions that require additional TCP features (e.g. DSA= CK) > > > would > > > work if the feature functions simply return false." > > > Please rephrase this. I suspect you meant that if some functi= ons > > > relate > > > to TCP features that are not available, the given code still > > > works > > > as long as the functions related to such features return fals= e > > > when > > > the TCP feature is not available but that surely isn't what t= he > > > sentence currently says. > > > > > > Sect 7.2 Step 5 > > > > > > "For timely loss detection, the sender MAY > > > install a "reordering settling" timer set to fire at the > > > earliest > > > moment at which it is safe to conclude that some packet is > > > lost. The > > > earliest moment is the time it takes to expire the reorder= ing > > > window > > > of the earliest unacked packet in flight." > > > vs > > > RACK_detect_loss(): > > > ... > > > timeout =3D max(remaining, timeout) > > > Which way it is, "some" or "all"? The use of max() in > > > RACK_detect_lost() > > > seems to indicate that the timeout will be set according to t= he > > > longest > > > time, that is, the latest moment rather than earliest moments= . > > > Which > > > is the intented behavior here? (I can there might be merits i= n > > > both > > > approaches). > > > > > > > > > In general, I didn't like the presentation order here as this > > > form looks > > > the most obvious to me: > > > now >=3D Packet.xmit_ts + RACK.reo_wnd + (RACK.ack_ts - > > > RACK.xmit_ts) > > > ...and I find the derivation of it just complicating things > > > rather > > > than helping but that's perhaps just my opinion. > > > > > > > > > "It is also useful when the timestamp clock granularity is > > > close to > > > or longer than the actual round trip time." > > > Given that some things based on timestamps will obviously sto= p > > > working > > > if the clock is slower than one tick per RTT I found this > > > fragment a bit > > > odd. RFC 7323 says "the clock SHOULD tick at least once per > > > window's worth > > > of data". I can understand though that a host might find cloc= k > > > tick > > > granularity challenging due to extensive RTT range but on the > > > same > > > I'd not want such a "too slow clock" behavior to be endorsed = as > > > if > > > it would be just normal. That is, I'm not against RACK handli= ng > > > also this case nicely but it would be nice to somehow downpla= y > > > the > > > normalness tone in it with something along the lines of "This > > > check is > > > also useful if the recommended one tick per RTT cannot be > > > achieved due > > > to timestamp clock granularity." > > > > > > Is RACK_detect_lost() supposed to detect also lost rexmits? H= ow? > > > The rexmit code itself is not in the draft so it's hard to > > > evaluate > > > how the Packet booleans are supposed to work in the first pla= ce. > > > I'm not saying the rexmit code should be included but current= ly > > > it > > > surely looks like any rexmitted packet just remains .lost =3D = TRUE > > > and > > > .retransmitted =3D TRUE state until RTO? > > > > > > > > > Sect 7.4 > > > > > > "PTO" just appears out of nowhere (and is not even written op= en > > > in the first instance). > > > > > > "2. ... in step (2) of the algorithm." > > > "step (2)" is forward-refing, it would naturally refer back t= o > > > "Step 2: Update RACK stats" so it makes very little sense as = is. > > > > > > Sect 7.5 > > > > > > Separator missing for PTO: and TLPRxtOut: > > > > > > Sect 7.5.1 > > > > > > "3. Upon receiving a SACK that selectively acknowledges da= ta > > > that was > > > last sent before the segment with SEG.SEQ=3DSND.UNA wa= s > > > last > > > (re)transmitted" > > > This is hard to understand, perhaps rephrase it somehow? > > > > > > > > > "But choosing PTO to be > > > exactly an SRTT is likely to generate spurious probes give= n > > > that > > > network delay variance and even end-system timings can eas= ily > > > push an > > > ACK to be above an SRTT. We chose PTO to be the next > > > integral > > > multiple of SRTT. > > > > > > Similarly, network delay variations and end-system process= ing > > > latencies and timer granularities can easily delay ACKs > > > beyond > > > 2*SRTT, so senders SHOULD add at least 2ms to a computed P= TO > > > value > > > (and MAY add more if the sending host OS timer granularity = is > > > more > > > coarse than 1ms)." > > > Does this later paragraph depend on some assumptions (such as > > > very > > > low RTT?) as I don't otherwise understand why you say what yo= u > > > say > > > in the given order. First you said x & y can push ACK over SR= TT > > > so > > > we pick 2* but then you say the same things can push over 2*S= RTT > > > too? > > > > > > WCDelAckT to terminology? > > > > > > Sect 7.5.2 > > > > > > TLP_send_probe(): > > > - Perhaps set TLPRxtOut somewhere? > > > - Add "Arm RTO" to the end? > > > > > > "In the case where > > > there is only one original outstanding segment of data (N=3D= 1), > > > the > > > same logic (trivially) applies: an ACK for a single > > > outstanding > > > segment tells the sender the N-1=3D0 segments preceding th= at > > > segment > > > were lost. Furthermore, whether there are N>1 or N=3D1 > > > outstanding > > > segments," > > > If this distinction is useful to make at all, maybe just simp= ly > > > say: > > > "Applies also in case N=3D1." > > > > > > Sect 7.6 > > > > > > "SND.NXT at the time the episode started." > > > Isn't this TLPHighRxt, why not use it here? > > > > > > Sect 7.6.2 > > > > > > "Upon sending a TLP probe that is a retransmission, the sen= der > > > sets > > > TLPRxtOut to true and TLPHighRxt to SND.NXT." > > > This should appear in TLP_send_probe(). > > > > > > "Detecting recoveries accomplished by loss probes" > > > Did you want to start another section here? > > > > > > "Step 1: Track ACKs ..." until what point? (It's told on late= r > > > but > > > this question comes into mind when reading the draft in order= ). > > > > > > > > > Sect 7.4 - 7.6.2 > > > > > > In general, this particular part of the draft seems to requir= e > > > some > > > further editing. After reading it all through, I feel most bi= ts > > > are > > > present but the text is very hard to follow. I think the > > > presentation > > > order needs significant work. There are random bits here and > > > there > > > that are explained only later. Also, algorithm lacks some par= ts > > > discussed only in the text but variable like items should > > > definitely > > > be included to the algorithm. > > > > > > > > > Sect 8.4 > > > > > > "RACK is compatible with and does not interfere with the th= e > > > standard > > > RTO [RFC6298], RTO-restart [RFC7765], F-RTO [RFC5682] and > > > Eifel > > > algorithms [RFC3522]. ... > > > It neither changes the RTO timer calculation nor detects > > > spurious > > > timeouts." > > > For F-RTO, also send order is significant. > > > > > > Sect 8.5 > > > > > > SHOULDs PRR (and also placed to normative references) that is > > > only > > > experimental and RACK aims to standards track. I feel that PR= R > > > is > > > disjoint enough anyway, which I think was also your intention > > > when > > > maintaining the decoupling CC and RACK, that it's bit odd to > > > take > > > this strong stance on PRR (indepedent of the stds track vs > > > experimental thing). > > > > > > "due to congestion window validation." > > > Does this refer to CWV as in RFC? Or some other mechanism in > > > which > > > case you shouldn't use the same term here. > > > > > > I find the described scenario somewhat unconvincing becase > > > the description ends with: > > > "... > > > The ending congestion window after recovery also impacts > > > subsequent data transfer." > > > ...First there wasn't enough data to fill cwnd of 20 packets = and > > > then suddenly transferring that non-existing data is impacted= . > > > > > > References > > > > > > QUIC-LR is very old ref and even the filename has changed a f= ew > > > times from draft-tsvwg-... > > > > > > > > > Nits > > > > > > "runt" made the sentence incomprehendable for me, I had to lo= ok > > > up > > > that word (and only second source was descriptive enough that = I > > > think I could understand the meaning, and I'd guessed wrong > > > because > > > I thought there was some special intent here because of the > > > quotes). > > > > > > is dicussed -> is discussed > > > RACT.RTT -> RACK.rtt > > > First "TSO" -> TCP Segmentation Offload (TSO) > > > grainularity -> granularity > > > higher-sequenc -> higher-sequence > > > > > > > > > -- > > > i. > > > > > > > > > > --=_script-32421-1589013040-0001-2-- From nobody Mon May 11 09:40:37 2020 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 860773A09B8 for ; Mon, 11 May 2020 09:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 ViH8rv3TuXDO for ; Mon, 11 May 2020 09:40:33 -0700 (PDT) Received: from mail-vk1-xa41.google.com (mail-vk1-xa41.google.com [IPv6:2607:f8b0:4864:20::a41]) (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 9DD203A0998 for ; Mon, 11 May 2020 09:40:32 -0700 (PDT) Received: by mail-vk1-xa41.google.com with SMTP id 134so1507072vky.2 for ; Mon, 11 May 2020 09:40:32 -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:content-transfer-encoding; bh=thearFoBqJ3h8Flb0Vn6u25BvVfCTvXDqlRdh5JIU44=; b=gp1b7SpBFz9Vfa+fHxUOmczKpzo1P0vrvY75DJcl9RzaSA4CIWijNQt+pQruKj3kg6 vMxIa32bgtcmyaDjHsL0/oQCqMWnnjnowXxbDOesk5rn+MJ9cbPyUWtg+1hTwH5waTkA +io2E2u4stIuIodC0dsFhNWD7LX3kYP82mwaY1ktaxNH0xaErclbTJSdTli14pZzN6yQ Q3aUt9OwoC2FQfilzIjQ4VG8iW6cltY5ST5kbM839RXr7xh/SBIqUbhHmGA5dhnl5TKI AZzalCM4MSfCWUpZfAdY3bHYP9J+O3rNVOirWGnLJ+BMq9UmKrEWFocyc1dTDLWKsE5h Gt5g== 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:content-transfer-encoding; bh=thearFoBqJ3h8Flb0Vn6u25BvVfCTvXDqlRdh5JIU44=; b=niXwnhRMpHy2vfMsSWOsLl2snphSpORTkrV9z+nQoPTiXdY0ov9Mhb871ryEnTWWjZ e0h4pl+QA7kNDO8j68ulqbGM2r1N4UWohaFjiYYUlOX2LIr0PKWcZFNw633iLSr7NJsU Wj0/KKBLBNCT7FKBVZzEAsUMT15BBhzlQxxkI08BhAl10oMHNZaFOy6VQeY8tl0kAMoM EJ/yqaoat7pEO+iiWscHGDBlAqk3xHrWqUsxwLfVwKzZzsmxBOfdS3EJtmNO2I1ibdem Dl9qhRAWDPUTLgVgExjHtU75coFNyRf1rIcLqimIbFqMrOvjh31Gsvnbhjw1ewsVUSYp f34Q== X-Gm-Message-State: AGi0Pua2WSqdmIokyqnDnuzobeYOTdtS5HltQYr1POIfxeZ2nR3wI2Uz m7M5MTGN76KY7vdR+/6M0L8UiMkvU6tdf0kwSJisde8vA3g= X-Google-Smtp-Source: APiQypJ8POXWz4WRg9/KOEzVBIBIkn0lklBS7aibvCtEbdweh7p+LDrg++FrXSQAK3sFCptuLInmRFc4B50waUAEQJQ= X-Received: by 2002:a1f:cd83:: with SMTP id d125mr12367241vkg.35.1589215230786; Mon, 11 May 2020 09:40:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Mon, 11 May 2020 09:39:54 -0700 Message-ID: To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= Cc: "tcpm@ietf.org Extensions" , Neal Cardwell , Nandita Dukkipati , Priyaranjan Jha Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-rack-07 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, 11 May 2020 16:40:36 -0000 On Sat, May 9, 2020 at 1:30 AM Ilpo J=C3=A4rvinen wrote: > > On Fri, 8 May 2020, Yuchung Cheng wrote: > > > On Mon, Apr 6, 2020 at 2:01 PM Ilpo J=C3=A4rvinen > > wrote: > > > > > > Hi Yuchung, > > > > > > Certainly improved on many things, however, I'm surprised that the lo= st > > > rexmit comment was not addressed at all. Aren't the rexmit losses > > > supposed to be detected by RACK or have I misunderstood something? > > > > > > I don't understand how lost rexmits are detected by the algorithms in > > > the draft. I think the algorithms are either flawed or lack something > > > (mainly RACK_detect_loss is relevant I think). My original comment > > > from below. > > > > > > Is RACK_detect_loss() supposed to detect also lost rexmits? Ho= w? > > > The rexmit code itself is not in the draft so it's hard to eva= luate > > > how the Packet booleans are supposed to work in the first plac= e. > > > I'm not saying the rexmit code should be included but currentl= y it > > > surely looks like any rexmitted packet just remains .lost =3D = TRUE > > > and .retransmitted =3D TRUE state until RTO? > > > > Sorry to miss this point earlier -- RACK definitely detects > > lost-retransmits, but the current algorithm does not properly define > > some variables. Here is how I propose to address these by adding > > these: > > Np and I was pleased to note already during the interim presentation > that you'd addressed this. > > > Per-packet variables > > > > > > Theses variables indicate the status of the most recent transmission > > of a data packet: > > =E2=80=9CPacket.lost=E2=80=9D is true if the most recent (re)tr= ansmission of > > the Packet has been considered lost and needs to be retransmitted. > > False otherwise. > > =E2=80=9CPacket.retransmitted=E2=80=9D is tue if its sequence n= umbers were > > retransmitted in the most recent transmission. False otherwise. > > =E2=80=9CPacket.xmit_ts=E2=80=9D is the time of the last transm= ission of a > > data packet, including retransmissions, if any. The sender needs to > > record the transmission time for each packet sent and not yet > > acknowledged. The time MUST be stored at millisecond granularity or > > finer. > > > > > > Transmitting a data packet > > Upon transmitting a new packet or retransmitting an old packet, record > > the time in Packet.xmit_ts. > > > > --- src > > > > RACK_transmit_data(Packet): > > > > Packet.time_ts =3D Now() > > > > Packet.lost =3D FALSE > > > > > > RACK_retransmit_data(Packet) > > > > Packet.retransmitted =3D TRUE > > RACK_transmit_data(Packet) > > > > --- > > > > When a packet is retransmitted again, its Packet.lost is reset and > > transmission timestamp is renewed. Therefore, when its transmission > > time falls out of the RACK reordering window in RACK_detect_loss(), it > > will be marked as lost (again). > > > > > > > > > > > > > > Also my timeout "some" vs "all" internal inconsistency comment relate= s to > > > this same algorithm: > > > > > > "For timely loss detection, the sender MAY > > > install a "reordering settling" timer set to fire at the ea= rliest > > > moment at which it is safe to conclude that some packet is = lost. The > > > earliest moment is the time it takes to expire the reorderi= ng window > > > of the earliest unacked packet in flight." > > > vs > > > RACK_detect_loss(): > > > ... > > > timeout =3D max(remaining, timeout) > > > Which way it is, "some" or "all"? The use of max() in RACK_det= ect_loss() > > > seems to indicate that the timeout will be set according to th= e longest > > > time, that is, the latest moment rather than earliest moments.= Which > > > is the intented behavior here? (I can there might be merits in= both > > > approaches). > > > > Comment 1.2: good catch. We changed to: 'For timely loss detection, > > the sender is RECOMMENDED to install a "reordering settling" timer. > > The timer expires at the earliest moment when it is safe to conclude > > that all the unacknowledged packets within the reordering window are > > lost.' > > I was under impression it's likely what you intented to propose right > from the start. In that case this change seems not enough to address my > concern, the algorithm seems to do exactly opposite on > timeout =3D max(remaining, timeout) > line, no? That is, if there is a moment further away in the future, > the line selects it rather than "the earliest moment". This inconsistency > between the text and algorithm is why I brought this up and I think the > algorithm requires some small tweak to remove the inconsistency here. The diff is not the "earliest moment" wording. it was "the earliest moment of some packet" but it is now "the earliest moment of all unacked packets" Here is the old and proposed new text ...; but this risks a timeout (RTO) if no more ACKs come back (e.g, due to losses or application limit). For timely loss detection, the sender MAY install a "reordering settling" timer set to fire at the earliest moment at which it is safe to conclude that some packet is lost. The earliest moment is the time it takes to expire the reordering window of the earliest unacked packet in flight. new text: ... but this risks a timeout (RTO) if no more ACKs come back (e.g, due to losses or application-limited transmissions). For timely loss detection, the sender is RECOMMENDED to install a reordering settling timer. This timer expires at the earliest moment when it is safe to conclude that all the unacknowledged packets within the reordering window are lost. so the keyword all would make the description match the pseudo code. > > > -- > i. > > > > > > > > > > > > > > Then there are some other comments I made which seem also unaddressed= but > > > I'll not duplicate them all here. > > > > > > > > > -- > > > i. > > > > > > > > > On Mon, 9 Mar 2020, Yuchung Cheng wrote: > > > > > > > Hi Ilpo, > > > > Thanks for a detailed review and the great suggestions. Here's all = the edits > > > > we made. > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-08 > > > > > > > > We defined the missing terms and addressed the nits, removed the l= ess > > > > critical parts like recommending PRR, and edited TLP algorithms (se= ctions > > > > 7.4 to 7.6). I hope you find it's better now and would be happy to = hear any > > > > improvements you'd like to make. > > > > > > > > Yuchung > > > > > > > > On Fri, Feb 14, 2020 at 4:22 AM Ilpo J=C3=A4rvinen > > > > wrote: > > > > In general, I find the draft quite good shape already, it's > > > > quite easy > > > > to read and follow (that is, except the TLP sections that are > > > > specifically > > > > mentioned below). > > > > > > > > Here's the list of issues I came across: > > > > > > > > Sect 6.1 > > > > > > > > "RACK.pkts_sacked" lacks the empty line separator. > > > > > > > > Sect 7.2 > > > > > > > > "This > > > > heuristic would fail to update RACK stats if the packet is > > > > spuriously > > > > retransmitted because of a recent minimum RTT decrease (e.= g. > > > > path > > > > change)." > > > > This defies my logic as RTT decrease should not result in > > > > spurious > > > > retransmissions but help to avoid them. > > > > > > > > > > > > "Note that > > > > extensions that require additional TCP features (e.g. DSA= CK) > > > > would > > > > work if the feature functions simply return false." > > > > Please rephrase this. I suspect you meant that if some functi= ons > > > > relate > > > > to TCP features that are not available, the given code still > > > > works > > > > as long as the functions related to such features return fals= e > > > > when > > > > the TCP feature is not available but that surely isn't what t= he > > > > sentence currently says. > > > > > > > > Sect 7.2 Step 5 > > > > > > > > "For timely loss detection, the sender MAY > > > > install a "reordering settling" timer set to fire at the > > > > earliest > > > > moment at which it is safe to conclude that some packet is > > > > lost. The > > > > earliest moment is the time it takes to expire the reorder= ing > > > > window > > > > of the earliest unacked packet in flight." > > > > vs > > > > RACK_detect_loss(): > > > > ... > > > > timeout =3D max(remaining, timeout) > > > > Which way it is, "some" or "all"? The use of max() in > > > > RACK_detect_lost() > > > > seems to indicate that the timeout will be set according to t= he > > > > longest > > > > time, that is, the latest moment rather than earliest moments= . > > > > Which > > > > is the intented behavior here? (I can there might be merits i= n > > > > both > > > > approaches). > > > > > > > > > > > > In general, I didn't like the presentation order here as this > > > > form looks > > > > the most obvious to me: > > > > now >=3D Packet.xmit_ts + RACK.reo_wnd + (RACK.ack_ts - > > > > RACK.xmit_ts) > > > > ...and I find the derivation of it just complicating things > > > > rather > > > > than helping but that's perhaps just my opinion. > > > > > > > > > > > > "It is also useful when the timestamp clock granularity is > > > > close to > > > > or longer than the actual round trip time." > > > > Given that some things based on timestamps will obviously sto= p > > > > working > > > > if the clock is slower than one tick per RTT I found this > > > > fragment a bit > > > > odd. RFC 7323 says "the clock SHOULD tick at least once per > > > > window's worth > > > > of data". I can understand though that a host might find cloc= k > > > > tick > > > > granularity challenging due to extensive RTT range but on the > > > > same > > > > I'd not want such a "too slow clock" behavior to be endorsed = as > > > > if > > > > it would be just normal. That is, I'm not against RACK handli= ng > > > > also this case nicely but it would be nice to somehow downpla= y > > > > the > > > > normalness tone in it with something along the lines of "This > > > > check is > > > > also useful if the recommended one tick per RTT cannot be > > > > achieved due > > > > to timestamp clock granularity." > > > > > > > > Is RACK_detect_lost() supposed to detect also lost rexmits? H= ow? > > > > The rexmit code itself is not in the draft so it's hard to > > > > evaluate > > > > how the Packet booleans are supposed to work in the first pla= ce. > > > > I'm not saying the rexmit code should be included but current= ly > > > > it > > > > surely looks like any rexmitted packet just remains .lost =3D= TRUE > > > > and > > > > .retransmitted =3D TRUE state until RTO? > > > > > > > > > > > > Sect 7.4 > > > > > > > > "PTO" just appears out of nowhere (and is not even written op= en > > > > in the first instance). > > > > > > > > "2. ... in step (2) of the algorithm." > > > > "step (2)" is forward-refing, it would naturally refer back t= o > > > > "Step 2: Update RACK stats" so it makes very little sense as = is. > > > > > > > > Sect 7.5 > > > > > > > > Separator missing for PTO: and TLPRxtOut: > > > > > > > > Sect 7.5.1 > > > > > > > > "3. Upon receiving a SACK that selectively acknowledges da= ta > > > > that was > > > > last sent before the segment with SEG.SEQ=3DSND.UNA wa= s > > > > last > > > > (re)transmitted" > > > > This is hard to understand, perhaps rephrase it somehow? > > > > > > > > > > > > "But choosing PTO to be > > > > exactly an SRTT is likely to generate spurious probes give= n > > > > that > > > > network delay variance and even end-system timings can eas= ily > > > > push an > > > > ACK to be above an SRTT. We chose PTO to be the next > > > > integral > > > > multiple of SRTT. > > > > > > > > Similarly, network delay variations and end-system process= ing > > > > latencies and timer granularities can easily delay ACKs > > > > beyond > > > > 2*SRTT, so senders SHOULD add at least 2ms to a computed P= TO > > > > value > > > > (and MAY add more if the sending host OS timer granularity= is > > > > more > > > > coarse than 1ms)." > > > > Does this later paragraph depend on some assumptions (such as > > > > very > > > > low RTT?) as I don't otherwise understand why you say what yo= u > > > > say > > > > in the given order. First you said x & y can push ACK over SR= TT > > > > so > > > > we pick 2* but then you say the same things can push over 2*S= RTT > > > > too? > > > > > > > > WCDelAckT to terminology? > > > > > > > > Sect 7.5.2 > > > > > > > > TLP_send_probe(): > > > > - Perhaps set TLPRxtOut somewhere? > > > > - Add "Arm RTO" to the end? > > > > > > > > "In the case where > > > > there is only one original outstanding segment of data (N= =3D1), > > > > the > > > > same logic (trivially) applies: an ACK for a single > > > > outstanding > > > > segment tells the sender the N-1=3D0 segments preceding th= at > > > > segment > > > > were lost. Furthermore, whether there are N>1 or N=3D1 > > > > outstanding > > > > segments," > > > > If this distinction is useful to make at all, maybe just simp= ly > > > > say: > > > > "Applies also in case N=3D1." > > > > > > > > Sect 7.6 > > > > > > > > "SND.NXT at the time the episode started." > > > > Isn't this TLPHighRxt, why not use it here? > > > > > > > > Sect 7.6.2 > > > > > > > > "Upon sending a TLP probe that is a retransmission, the sen= der > > > > sets > > > > TLPRxtOut to true and TLPHighRxt to SND.NXT." > > > > This should appear in TLP_send_probe(). > > > > > > > > "Detecting recoveries accomplished by loss probes" > > > > Did you want to start another section here? > > > > > > > > "Step 1: Track ACKs ..." until what point? (It's told on late= r > > > > but > > > > this question comes into mind when reading the draft in order= ). > > > > > > > > > > > > Sect 7.4 - 7.6.2 > > > > > > > > In general, this particular part of the draft seems to requir= e > > > > some > > > > further editing. After reading it all through, I feel most bi= ts > > > > are > > > > present but the text is very hard to follow. I think the > > > > presentation > > > > order needs significant work. There are random bits here and > > > > there > > > > that are explained only later. Also, algorithm lacks some par= ts > > > > discussed only in the text but variable like items should > > > > definitely > > > > be included to the algorithm. > > > > > > > > > > > > Sect 8.4 > > > > > > > > "RACK is compatible with and does not interfere with the th= e > > > > standard > > > > RTO [RFC6298], RTO-restart [RFC7765], F-RTO [RFC5682] and > > > > Eifel > > > > algorithms [RFC3522]. ... > > > > It neither changes the RTO timer calculation nor detects > > > > spurious > > > > timeouts." > > > > For F-RTO, also send order is significant. > > > > > > > > Sect 8.5 > > > > > > > > SHOULDs PRR (and also placed to normative references) that is > > > > only > > > > experimental and RACK aims to standards track. I feel that PR= R > > > > is > > > > disjoint enough anyway, which I think was also your intention > > > > when > > > > maintaining the decoupling CC and RACK, that it's bit odd to > > > > take > > > > this strong stance on PRR (indepedent of the stds track vs > > > > experimental thing). > > > > > > > > "due to congestion window validation." > > > > Does this refer to CWV as in RFC? Or some other mechanism in > > > > which > > > > case you shouldn't use the same term here. > > > > > > > > I find the described scenario somewhat unconvincing becase > > > > the description ends with: > > > > "... > > > > The ending congestion window after recovery also impacts > > > > subsequent data transfer." > > > > ...First there wasn't enough data to fill cwnd of 20 packets = and > > > > then suddenly transferring that non-existing data is impacted= . > > > > > > > > References > > > > > > > > QUIC-LR is very old ref and even the filename has changed a f= ew > > > > times from draft-tsvwg-... > > > > > > > > > > > > Nits > > > > > > > > "runt" made the sentence incomprehendable for me, I had to lo= ok > > > > up > > > > that word (and only second source was descriptive enough that= I > > > > think I could understand the meaning, and I'd guessed wrong > > > > because > > > > I thought there was some special intent here because of the > > > > quotes). > > > > > > > > is dicussed -> is discussed > > > > RACT.RTT -> RACK.rtt > > > > First "TSO" -> TCP Segmentation Offload (TSO) > > > > grainularity -> granularity > > > > higher-sequenc -> higher-sequence > > > > > > > > > > > > -- > > > > i. > > > > > > > > > > > > > > From nobody Mon May 11 09:54:20 2020 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 7F62B3A0AF3 for ; Mon, 11 May 2020 09:54:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cs.helsinki.fi 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 J3k16mIvBWwu for ; Mon, 11 May 2020 09:53:59 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143BA3A0ADE for ; Mon, 11 May 2020 09:53:58 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Mon, 11 May 2020 19:53:51 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=2pc2xwVRiQOCiR1d+ JhWYQlAED/qI2NEtWV8EMLcr6Q=; b=UHXI/p1Czlk9fvZQ3YsUDGAPF2ZzHQf2E gsYnAUviiOznhz+2AFfZFesdi/vG0BllJX2tjedPqbHuoR6bM+xaZ2U2uvtIhq3W SDfiedvwpRrFsPMZoN3lxfLrxVqb17ftH3Mv1+8Lpn+7LGrIe7yGCBtRGpmEMomW HTCvIP+gO0= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Mon, 11 May 2020 19:53:51 +0300 id 00000000005A014E.000000005EB9831F.0000532F Date: Mon, 11 May 2020 19:53:51 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Yuchung Cheng cc: "tcpm@ietf.org Extensions" , Neal Cardwell , Nandita Dukkipati , Priyaranjan Jha In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-21394-1589216031-0001-2" Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-rack-07 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, 11 May 2020 16:54:09 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-21394-1589216031-0001-2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 11 May 2020, Yuchung Cheng wrote: > On Sat, May 9, 2020 at 1:30 AM Ilpo J=C3=A4rvinen > wrote: > > > > On Fri, 8 May 2020, Yuchung Cheng wrote: > > > > > On Mon, Apr 6, 2020 at 2:01 PM Ilpo J=C3=A4rvinen > > > wrote: > > > > > > > > Hi Yuchung, > > > > > > > > Certainly improved on many things, however, I'm surprised that th= e lost > > > > rexmit comment was not addressed at all. Aren't the rexmit losses > > > > supposed to be detected by RACK or have I misunderstood something= ? > > > > > > > > I don't understand how lost rexmits are detected by the algorithm= s in > > > > the draft. I think the algorithms are either flawed or lack somet= hing > > > > (mainly RACK_detect_loss is relevant I think). My original commen= t > > > > from below. > > > > > > > > Is RACK_detect_loss() supposed to detect also lost rexmits= ? How? > > > > The rexmit code itself is not in the draft so it's hard to = evaluate > > > > how the Packet booleans are supposed to work in the first = place. > > > > I'm not saying the rexmit code should be included but curr= ently it > > > > surely looks like any rexmitted packet just remains .lost = =3D TRUE > > > > and .retransmitted =3D TRUE state until RTO? > > > > > > Sorry to miss this point earlier -- RACK definitely detects > > > lost-retransmits, but the current algorithm does not properly defin= e > > > some variables. Here is how I propose to address these by adding > > > these: > > > > Np and I was pleased to note already during the interim presentation > > that you'd addressed this. > > > > > Per-packet variables > > > > > > > > > Theses variables indicate the status of the most recent transmissio= n > > > of a data packet: > > > =E2=80=9CPacket.lost=E2=80=9D is true if the most recent (r= e)transmission of > > > the Packet has been considered lost and needs to be retransmitted. > > > False otherwise. > > > =E2=80=9CPacket.retransmitted=E2=80=9D is tue if its sequen= ce numbers were > > > retransmitted in the most recent transmission. False otherwise. > > > =E2=80=9CPacket.xmit_ts=E2=80=9D is the time of the last tr= ansmission of a > > > data packet, including retransmissions, if any. The sender needs to > > > record the transmission time for each packet sent and not yet > > > acknowledged. The time MUST be stored at millisecond granularity or > > > finer. > > > > > > > > > Transmitting a data packet > > > Upon transmitting a new packet or retransmitting an old packet, rec= ord > > > the time in Packet.xmit_ts. > > > > > > --- src > > > > > > RACK_transmit_data(Packet): > > > > > > Packet.time_ts =3D Now() > > > > > > Packet.lost =3D FALSE > > > > > > > > > RACK_retransmit_data(Packet) > > > > > > Packet.retransmitted =3D TRUE > > > RACK_transmit_data(Packet) > > > > > > --- > > > > > > When a packet is retransmitted again, its Packet.lost is reset and > > > transmission timestamp is renewed. Therefore, when its transmission > > > time falls out of the RACK reordering window in RACK_detect_loss(), = it > > > will be marked as lost (again). > > > > > > > > > > > > > > > > > > > > Also my timeout "some" vs "all" internal inconsistency comment re= lates to > > > > this same algorithm: > > > > > > > > "For timely loss detection, the sender MAY > > > > install a "reordering settling" timer set to fire at th= e earliest > > > > moment at which it is safe to conclude that some packet = is lost. The > > > > earliest moment is the time it takes to expire the reor= dering window > > > > of the earliest unacked packet in flight." > > > > vs > > > > RACK_detect_loss(): > > > > ... > > > > timeout =3D max(remaining, timeout) > > > > Which way it is, "some" or "all"? The use of max() in RACK= _detect_loss() > > > > seems to indicate that the timeout will be set according t= o the longest > > > > time, that is, the latest moment rather than earliest mome= nts. Which > > > > is the intented behavior here? (I can there might be merit= s in both > > > > approaches). > > > > > > Comment 1.2: good catch. We changed to: 'For timely loss detection, > > > the sender is RECOMMENDED to install a "reordering settling" timer. > > > The timer expires at the earliest moment when it is safe to conclud= e > > > that all the unacknowledged packets within the reordering window ar= e > > > lost.' > > > > I was under impression it's likely what you intented to propose right > > from the start. In that case this change seems not enough to address = my > > concern, the algorithm seems to do exactly opposite on > > timeout =3D max(remaining, timeout) > > line, no? That is, if there is a moment further away in the future, > > the line selects it rather than "the earliest moment". This inconsist= ency > > between the text and algorithm is why I brought this up and I think t= he > > algorithm requires some small tweak to remove the inconsistency here. >=20 > The diff is not the "earliest moment" wording. it was "the earliest > moment of some packet" but it is now "the earliest moment of all > unacked packets" >=20 > Here is the old and proposed new text >=20 > ...; but this > risks a timeout (RTO) if no more ACKs come back (e.g, due to losses > or application limit). For timely loss detection, the sender MAY > install a "reordering settling" timer set to fire at the earliest > moment at which it is safe to conclude that some packet is lost. Th= e > earliest moment is the time it takes to expire the reordering window > of the earliest unacked packet in flight. >=20 > new text: >=20 > ... but this risks a timeout (RTO) if no more ACKs come back (e.g, due > to losses or application-limited transmissions). For timely loss > detection, the sender is RECOMMENDED to install a reordering settling > timer. This timer expires at the earliest moment when it is safe to > conclude that all the unacknowledged packets within the reordering > window are lost. >=20 > so the keyword all would make the description match the pseudo code. Ah, you're of course right. It was sloppy reading (and too strong=20 preconceived idea of what the fix should look like) from my side. So the correction is fine. My apologies for the noise. --=20 i. >=20 > > > > > > -- > > i. > > > > > > > > > > > > > > > > > > > > Then there are some other comments I made which seem also unaddre= ssed but > > > > I'll not duplicate them all here. > > > > > > > > > > > > -- > > > > i. > > > > > > > > > > > > On Mon, 9 Mar 2020, Yuchung Cheng wrote: > > > > > > > > > Hi Ilpo, > > > > > Thanks for a detailed review and the great suggestions. Here's = all the edits > > > > > we made. > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-08 > > > > > > > > > > We defined the missing terms and addressed the nits, removed t= he less > > > > > critical parts like recommending PRR, and edited TLP algorithms = (sections > > > > > 7.4 to 7.6). I hope you find it's better now and would be happy = to hear any > > > > > improvements you'd like to make. > > > > > > > > > > Yuchung > > > > > > > > > > On Fri, Feb 14, 2020 at 4:22 AM Ilpo J=C3=A4rvinen > > > > > wrote: > > > > > In general, I find the draft quite good shape already, it= 's > > > > > quite easy > > > > > to read and follow (that is, except the TLP sections that = are > > > > > specifically > > > > > mentioned below). > > > > > > > > > > Here's the list of issues I came across: > > > > > > > > > > Sect 6.1 > > > > > > > > > > "RACK.pkts_sacked" lacks the empty line separator. > > > > > > > > > > Sect 7.2 > > > > > > > > > > "This > > > > > heuristic would fail to update RACK stats if the packe= t is > > > > > spuriously > > > > > retransmitted because of a recent minimum RTT decrease = (e.g. > > > > > path > > > > > change)." > > > > > This defies my logic as RTT decrease should not result in > > > > > spurious > > > > > retransmissions but help to avoid them. > > > > > > > > > > > > > > > "Note that > > > > > extensions that require additional TCP features (e.g. = DSACK) > > > > > would > > > > > work if the feature functions simply return false." > > > > > Please rephrase this. I suspect you meant that if some fu= nctions > > > > > relate > > > > > to TCP features that are not available, the given code st= ill > > > > > works > > > > > as long as the functions related to such features return = false > > > > > when > > > > > the TCP feature is not available but that surely isn't wh= at the > > > > > sentence currently says. > > > > > > > > > > Sect 7.2 Step 5 > > > > > > > > > > "For timely loss detection, the sender MAY > > > > > install a "reordering settling" timer set to fire at t= he > > > > > earliest > > > > > moment at which it is safe to conclude that some packe= t is > > > > > lost. The > > > > > earliest moment is the time it takes to expire the reo= rdering > > > > > window > > > > > of the earliest unacked packet in flight." > > > > > vs > > > > > RACK_detect_loss(): > > > > > ... > > > > > timeout =3D max(remaining, timeout) > > > > > Which way it is, "some" or "all"? The use of max() in > > > > > RACK_detect_lost() > > > > > seems to indicate that the timeout will be set according = to the > > > > > longest > > > > > time, that is, the latest moment rather than earliest mom= ents. > > > > > Which > > > > > is the intented behavior here? (I can there might be meri= ts in > > > > > both > > > > > approaches). > > > > > > > > > > > > > > > In general, I didn't like the presentation order here as = this > > > > > form looks > > > > > the most obvious to me: > > > > > now >=3D Packet.xmit_ts + RACK.reo_wnd + (RACK.ack_ts = - > > > > > RACK.xmit_ts) > > > > > ...and I find the derivation of it just complicating thin= gs > > > > > rather > > > > > than helping but that's perhaps just my opinion. > > > > > > > > > > > > > > > "It is also useful when the timestamp clock granularit= y is > > > > > close to > > > > > or longer than the actual round trip time." > > > > > Given that some things based on timestamps will obviously = stop > > > > > working > > > > > if the clock is slower than one tick per RTT I found this > > > > > fragment a bit > > > > > odd. RFC 7323 says "the clock SHOULD tick at least once p= er > > > > > window's worth > > > > > of data". I can understand though that a host might find = clock > > > > > tick > > > > > granularity challenging due to extensive RTT range but on = the > > > > > same > > > > > I'd not want such a "too slow clock" behavior to be endor= sed as > > > > > if > > > > > it would be just normal. That is, I'm not against RACK ha= ndling > > > > > also this case nicely but it would be nice to somehow dow= nplay > > > > > the > > > > > normalness tone in it with something along the lines of "= This > > > > > check is > > > > > also useful if the recommended one tick per RTT cannot be > > > > > achieved due > > > > > to timestamp clock granularity." > > > > > > > > > > Is RACK_detect_lost() supposed to detect also lost rexmit= s? How? > > > > > The rexmit code itself is not in the draft so it's hard t= o > > > > > evaluate > > > > > how the Packet booleans are supposed to work in the first = place. > > > > > I'm not saying the rexmit code should be included but cur= rently > > > > > it > > > > > surely looks like any rexmitted packet just remains .lost = =3D TRUE > > > > > and > > > > > .retransmitted =3D TRUE state until RTO? > > > > > > > > > > > > > > > Sect 7.4 > > > > > > > > > > "PTO" just appears out of nowhere (and is not even writte= n open > > > > > in the first instance). > > > > > > > > > > "2. ... in step (2) of the algorithm." > > > > > "step (2)" is forward-refing, it would naturally refer ba= ck to > > > > > "Step 2: Update RACK stats" so it makes very little sense = as is. > > > > > > > > > > Sect 7.5 > > > > > > > > > > Separator missing for PTO: and TLPRxtOut: > > > > > > > > > > Sect 7.5.1 > > > > > > > > > > "3. Upon receiving a SACK that selectively acknowledge= s data > > > > > that was > > > > > last sent before the segment with SEG.SEQ=3DSND.UN= A was > > > > > last > > > > > (re)transmitted" > > > > > This is hard to understand, perhaps rephrase it somehow? > > > > > > > > > > > > > > > "But choosing PTO to be > > > > > exactly an SRTT is likely to generate spurious probes = given > > > > > that > > > > > network delay variance and even end-system timings can = easily > > > > > push an > > > > > ACK to be above an SRTT. We chose PTO to be the next > > > > > integral > > > > > multiple of SRTT. > > > > > > > > > > Similarly, network delay variations and end-system pro= cessing > > > > > latencies and timer granularities can easily delay ACK= s > > > > > beyond > > > > > 2*SRTT, so senders SHOULD add at least 2ms to a comput= ed PTO > > > > > value > > > > > (and MAY add more if the sending host OS timer granula= rity is > > > > > more > > > > > coarse than 1ms)." > > > > > Does this later paragraph depend on some assumptions (suc= h as > > > > > very > > > > > low RTT?) as I don't otherwise understand why you say wha= t you > > > > > say > > > > > in the given order. First you said x & y can push ACK ove= r SRTT > > > > > so > > > > > we pick 2* but then you say the same things can push over = 2*SRTT > > > > > too? > > > > > > > > > > WCDelAckT to terminology? > > > > > > > > > > Sect 7.5.2 > > > > > > > > > > TLP_send_probe(): > > > > > - Perhaps set TLPRxtOut somewhere? > > > > > - Add "Arm RTO" to the end? > > > > > > > > > > "In the case where > > > > > there is only one original outstanding segment of data = (N=3D1), > > > > > the > > > > > same logic (trivially) applies: an ACK for a single > > > > > outstanding > > > > > segment tells the sender the N-1=3D0 segments precedin= g that > > > > > segment > > > > > were lost. Furthermore, whether there are N>1 or N=3D= 1 > > > > > outstanding > > > > > segments," > > > > > If this distinction is useful to make at all, maybe just = simply > > > > > say: > > > > > "Applies also in case N=3D1." > > > > > > > > > > Sect 7.6 > > > > > > > > > > "SND.NXT at the time the episode started." > > > > > Isn't this TLPHighRxt, why not use it here? > > > > > > > > > > Sect 7.6.2 > > > > > > > > > > "Upon sending a TLP probe that is a retransmission, the = sender > > > > > sets > > > > > TLPRxtOut to true and TLPHighRxt to SND.NXT." > > > > > This should appear in TLP_send_probe(). > > > > > > > > > > "Detecting recoveries accomplished by loss probes" > > > > > Did you want to start another section here? > > > > > > > > > > "Step 1: Track ACKs ..." until what point? (It's told on = later > > > > > but > > > > > this question comes into mind when reading the draft in o= rder). > > > > > > > > > > > > > > > Sect 7.4 - 7.6.2 > > > > > > > > > > In general, this particular part of the draft seems to re= quire > > > > > some > > > > > further editing. After reading it all through, I feel mos= t bits > > > > > are > > > > > present but the text is very hard to follow. I think the > > > > > presentation > > > > > order needs significant work. There are random bits here = and > > > > > there > > > > > that are explained only later. Also, algorithm lacks some = parts > > > > > discussed only in the text but variable like items should > > > > > definitely > > > > > be included to the algorithm. > > > > > > > > > > > > > > > Sect 8.4 > > > > > > > > > > "RACK is compatible with and does not interfere with th= e the > > > > > standard > > > > > RTO [RFC6298], RTO-restart [RFC7765], F-RTO [RFC5682] = and > > > > > Eifel > > > > > algorithms [RFC3522]. ... > > > > > It neither changes the RTO timer calculation nor detec= ts > > > > > spurious > > > > > timeouts." > > > > > For F-RTO, also send order is significant. > > > > > > > > > > Sect 8.5 > > > > > > > > > > SHOULDs PRR (and also placed to normative references) tha= t is > > > > > only > > > > > experimental and RACK aims to standards track. I feel tha= t PRR > > > > > is > > > > > disjoint enough anyway, which I think was also your inten= tion > > > > > when > > > > > maintaining the decoupling CC and RACK, that it's bit odd = to > > > > > take > > > > > this strong stance on PRR (indepedent of the stds track v= s > > > > > experimental thing). > > > > > > > > > > "due to congestion window validation." > > > > > Does this refer to CWV as in RFC? Or some other mechanism = in > > > > > which > > > > > case you shouldn't use the same term here. > > > > > > > > > > I find the described scenario somewhat unconvincing becas= e > > > > > the description ends with: > > > > > "... > > > > > The ending congestion window after recovery also impac= ts > > > > > subsequent data transfer." > > > > > ...First there wasn't enough data to fill cwnd of 20 pack= ets and > > > > > then suddenly transferring that non-existing data is impa= cted. > > > > > > > > > > References > > > > > > > > > > QUIC-LR is very old ref and even the filename has changed = a few > > > > > times from draft-tsvwg-... > > > > > > > > > > > > > > > Nits > > > > > > > > > > "runt" made the sentence incomprehendable for me, I had t= o look > > > > > up > > > > > that word (and only second source was descriptive enough = that I > > > > > think I could understand the meaning, and I'd guessed wro= ng > > > > > because > > > > > I thought there was some special intent here because of t= he > > > > > quotes). > > > > > > > > > > is dicussed -> is discussed > > > > > RACT.RTT -> RACK.rtt > > > > > First "TSO" -> TCP Segmentation Offload (TSO) > > > > > grainularity -> granularity > > > > > higher-sequenc -> higher-sequence > > > > > > > > > > > > > > > -- > > > > > i. > > > > > > > > > > > > > > > > > > > --=_script-21394-1589216031-0001-2-- From nobody Mon May 11 10:24:18 2020 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 402563A0B42 for ; Mon, 11 May 2020 10:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 IFaZh_8QsL5V for ; Mon, 11 May 2020 10:21:58 -0700 (PDT) Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) (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 B7EDC3A0B39 for ; Mon, 11 May 2020 10:21:57 -0700 (PDT) Received: by mail-ua1-x942.google.com with SMTP id i5so3697937uaq.1 for ; Mon, 11 May 2020 10:21: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:content-transfer-encoding; bh=rLod9CCJobSFfSag+wEs6+5C694fzSiS5ScSXhPuYCw=; b=DTi2TmjO2Z1fV8IVSOZOdnBzCW8BL09dzdxllsmTtAkQ8t0H4QNGiuvwoeUEWWGgmG IYuUI7o6AF7cN+Ht1PoBgYhhxnL42FUswe+1o8D3oDiTPuss6U9U6pnqw29YWY1UWaWy MRTTEgQqOMysulthqFZun5gM5sipq87ETy5HKCh4FPdxjZAgJ31uaaJZictY8eENp6ee 0CRh3clR7TLq6HmvgGuoTMTO6Kfa5OM3w85APM9+vKQDF/36O2hR+u58/SZCYRwAOujI e+ClHvsGdZEaKc+8vqePOv+Vf69hg7eCD8SGk9otU7AyYefkJv97lfh3/K9gzkADGyEL K8vw== 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:content-transfer-encoding; bh=rLod9CCJobSFfSag+wEs6+5C694fzSiS5ScSXhPuYCw=; b=JjDzU36fXZ90fGwuS511Gv738JnkseeOI0e14Dew+Iohvh3SaI6btcVXdzhY6g2JSM RdAbELvWlUoVJ9R7qrszDcPEqEvFfv6vI0AzG3HDSW741IwMSr/Lu2KUcKIF5G62Mtey 8CYQLTbyG76gM/MbKMylsx1o9362zDtWq4l3T3i4M7JFZjs8Afj8zllcFOIa29NbXXx6 YvPXwFkSCT5D0vGRh86jWVtXlDCRdSM+OiD+Tx93U64jGrt+4MhsZ1N31IswxUixtxqZ DgzBIiaAFn3jLv7slUKpgOMmtf1klFsORp4JT90Prz27x98GFiqaekPBqf4K69hKN4VG RlCA== X-Gm-Message-State: AOAM531NqPMRIij3ZaiQw9/s6Hys7FufKZ3yDcWUvBVLvDYjQuX9JIKx +RWijh1yNG8FIsoUUcGg2SaX67pyHZokap71D6ncUA== X-Google-Smtp-Source: ABdhPJz6aYv/BWfqsrkQ2HS0rXWnZv85WUwfN4RZn8k68BD2szNNjOUSAeIlo059KTcpyPREwEt1EfKYfqqtzwC8DIk= X-Received: by 2002:ab0:314a:: with SMTP id e10mr224901uam.85.1589217715957; Mon, 11 May 2020 10:21:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Mon, 11 May 2020 10:21:19 -0700 Message-ID: To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= Cc: "tcpm@ietf.org Extensions" , Neal Cardwell , Nandita Dukkipati , Priyaranjan Jha Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-rack-07 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, 11 May 2020 17:22:24 -0000 On Mon, May 11, 2020 at 9:53 AM Ilpo J=C3=A4rvinen wrote: > > On Mon, 11 May 2020, Yuchung Cheng wrote: > > > On Sat, May 9, 2020 at 1:30 AM Ilpo J=C3=A4rvinen > > wrote: > > > > > > On Fri, 8 May 2020, Yuchung Cheng wrote: > > > > > > > On Mon, Apr 6, 2020 at 2:01 PM Ilpo J=C3=A4rvinen > > > > wrote: > > > > > > > > > > Hi Yuchung, > > > > > > > > > > Certainly improved on many things, however, I'm surprised that th= e lost > > > > > rexmit comment was not addressed at all. Aren't the rexmit losses > > > > > supposed to be detected by RACK or have I misunderstood something= ? > > > > > > > > > > I don't understand how lost rexmits are detected by the algorithm= s in > > > > > the draft. I think the algorithms are either flawed or lack somet= hing > > > > > (mainly RACK_detect_loss is relevant I think). My original commen= t > > > > > from below. > > > > > > > > > > Is RACK_detect_loss() supposed to detect also lost rexmits= ? How? > > > > > The rexmit code itself is not in the draft so it's hard to= evaluate > > > > > how the Packet booleans are supposed to work in the first = place. > > > > > I'm not saying the rexmit code should be included but curr= ently it > > > > > surely looks like any rexmitted packet just remains .lost = =3D TRUE > > > > > and .retransmitted =3D TRUE state until RTO? > > > > > > > > Sorry to miss this point earlier -- RACK definitely detects > > > > lost-retransmits, but the current algorithm does not properly defin= e > > > > some variables. Here is how I propose to address these by adding > > > > these: > > > > > > Np and I was pleased to note already during the interim presentation > > > that you'd addressed this. > > > > > > > Per-packet variables > > > > > > > > > > > > Theses variables indicate the status of the most recent transmissio= n > > > > of a data packet: > > > > =E2=80=9CPacket.lost=E2=80=9D is true if the most recent (r= e)transmission of > > > > the Packet has been considered lost and needs to be retransmitted. > > > > False otherwise. > > > > =E2=80=9CPacket.retransmitted=E2=80=9D is tue if its sequen= ce numbers were > > > > retransmitted in the most recent transmission. False otherwise. > > > > =E2=80=9CPacket.xmit_ts=E2=80=9D is the time of the last tr= ansmission of a > > > > data packet, including retransmissions, if any. The sender needs to > > > > record the transmission time for each packet sent and not yet > > > > acknowledged. The time MUST be stored at millisecond granularity or > > > > finer. > > > > > > > > > > > > Transmitting a data packet > > > > Upon transmitting a new packet or retransmitting an old packet, rec= ord > > > > the time in Packet.xmit_ts. > > > > > > > > --- src > > > > > > > > RACK_transmit_data(Packet): > > > > > > > > Packet.time_ts =3D Now() > > > > > > > > Packet.lost =3D FALSE > > > > > > > > > > > > RACK_retransmit_data(Packet) > > > > > > > > Packet.retransmitted =3D TRUE > > > > RACK_transmit_data(Packet) > > > > > > > > --- > > > > > > > > When a packet is retransmitted again, its Packet.lost is reset and > > > > transmission timestamp is renewed. Therefore, when its transmission > > > > time falls out of the RACK reordering window in RACK_detect_loss(),= it > > > > will be marked as lost (again). > > > > > > > > > > > > > > > > > > > > > > > > > > Also my timeout "some" vs "all" internal inconsistency comment re= lates to > > > > > this same algorithm: > > > > > > > > > > "For timely loss detection, the sender MAY > > > > > install a "reordering settling" timer set to fire at th= e earliest > > > > > moment at which it is safe to conclude that some packet= is lost. The > > > > > earliest moment is the time it takes to expire the reor= dering window > > > > > of the earliest unacked packet in flight." > > > > > vs > > > > > RACK_detect_loss(): > > > > > ... > > > > > timeout =3D max(remaining, timeout) > > > > > Which way it is, "some" or "all"? The use of max() in RACK= _detect_loss() > > > > > seems to indicate that the timeout will be set according t= o the longest > > > > > time, that is, the latest moment rather than earliest mome= nts. Which > > > > > is the intented behavior here? (I can there might be merit= s in both > > > > > approaches). > > > > > > > > Comment 1.2: good catch. We changed to: 'For timely loss detection, > > > > the sender is RECOMMENDED to install a "reordering settling" timer. > > > > The timer expires at the earliest moment when it is safe to conclud= e > > > > that all the unacknowledged packets within the reordering window ar= e > > > > lost.' > > > > > > I was under impression it's likely what you intented to propose right > > > from the start. In that case this change seems not enough to address = my > > > concern, the algorithm seems to do exactly opposite on > > > timeout =3D max(remaining, timeout) > > > line, no? That is, if there is a moment further away in the future, > > > the line selects it rather than "the earliest moment". This inconsist= ency > > > between the text and algorithm is why I brought this up and I think t= he > > > algorithm requires some small tweak to remove the inconsistency here. > > > > The diff is not the "earliest moment" wording. it was "the earliest > > moment of some packet" but it is now "the earliest moment of all > > unacked packets" > > > > Here is the old and proposed new text > > > > ...; but this > > risks a timeout (RTO) if no more ACKs come back (e.g, due to losses > > or application limit). For timely loss detection, the sender MAY > > install a "reordering settling" timer set to fire at the earliest > > moment at which it is safe to conclude that some packet is lost. Th= e > > earliest moment is the time it takes to expire the reordering window > > of the earliest unacked packet in flight. > > > > new text: > > > > ... but this risks a timeout (RTO) if no more ACKs come back (e.g, due > > to losses or application-limited transmissions). For timely loss > > detection, the sender is RECOMMENDED to install a reordering settling > > timer. This timer expires at the earliest moment when it is safe to > > conclude that all the unacknowledged packets within the reordering > > window are lost. > > > > so the keyword all would make the description match the pseudo code. > > Ah, you're of course right. It was sloppy reading (and too strong > preconceived idea of what the fix should look like) from my side. > So the correction is fine. My apologies for the noise. No problem. We really appreciate your thorough review! > > -- > i. > > > > > > > > > > > > > -- > > > i. > > > > > > > > > > > > > > > > > > > > > > > > > > Then there are some other comments I made which seem also unaddre= ssed but > > > > > I'll not duplicate them all here. > > > > > > > > > > > > > > > -- > > > > > i. > > > > > > > > > > > > > > > On Mon, 9 Mar 2020, Yuchung Cheng wrote: > > > > > > > > > > > Hi Ilpo, > > > > > > Thanks for a detailed review and the great suggestions. Here's = all the edits > > > > > > we made. > > > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-08 > > > > > > > > > > > > We defined the missing terms and addressed the nits, removed t= he less > > > > > > critical parts like recommending PRR, and edited TLP algorithms= (sections > > > > > > 7.4 to 7.6). I hope you find it's better now and would be happy= to hear any > > > > > > improvements you'd like to make. > > > > > > > > > > > > Yuchung > > > > > > > > > > > > On Fri, Feb 14, 2020 at 4:22 AM Ilpo J=C3=A4rvinen > > > > > > wrote: > > > > > > In general, I find the draft quite good shape already, it= 's > > > > > > quite easy > > > > > > to read and follow (that is, except the TLP sections that= are > > > > > > specifically > > > > > > mentioned below). > > > > > > > > > > > > Here's the list of issues I came across: > > > > > > > > > > > > Sect 6.1 > > > > > > > > > > > > "RACK.pkts_sacked" lacks the empty line separator. > > > > > > > > > > > > Sect 7.2 > > > > > > > > > > > > "This > > > > > > heuristic would fail to update RACK stats if the packe= t is > > > > > > spuriously > > > > > > retransmitted because of a recent minimum RTT decrease= (e.g. > > > > > > path > > > > > > change)." > > > > > > This defies my logic as RTT decrease should not result in > > > > > > spurious > > > > > > retransmissions but help to avoid them. > > > > > > > > > > > > > > > > > > "Note that > > > > > > extensions that require additional TCP features (e.g. = DSACK) > > > > > > would > > > > > > work if the feature functions simply return false." > > > > > > Please rephrase this. I suspect you meant that if some fu= nctions > > > > > > relate > > > > > > to TCP features that are not available, the given code st= ill > > > > > > works > > > > > > as long as the functions related to such features return = false > > > > > > when > > > > > > the TCP feature is not available but that surely isn't wh= at the > > > > > > sentence currently says. > > > > > > > > > > > > Sect 7.2 Step 5 > > > > > > > > > > > > "For timely loss detection, the sender MAY > > > > > > install a "reordering settling" timer set to fire at t= he > > > > > > earliest > > > > > > moment at which it is safe to conclude that some packe= t is > > > > > > lost. The > > > > > > earliest moment is the time it takes to expire the reo= rdering > > > > > > window > > > > > > of the earliest unacked packet in flight." > > > > > > vs > > > > > > RACK_detect_loss(): > > > > > > ... > > > > > > timeout =3D max(remaining, timeout) > > > > > > Which way it is, "some" or "all"? The use of max() in > > > > > > RACK_detect_lost() > > > > > > seems to indicate that the timeout will be set according = to the > > > > > > longest > > > > > > time, that is, the latest moment rather than earliest mom= ents. > > > > > > Which > > > > > > is the intented behavior here? (I can there might be meri= ts in > > > > > > both > > > > > > approaches). > > > > > > > > > > > > > > > > > > In general, I didn't like the presentation order here as = this > > > > > > form looks > > > > > > the most obvious to me: > > > > > > now >=3D Packet.xmit_ts + RACK.reo_wnd + (RACK.ack_ts = - > > > > > > RACK.xmit_ts) > > > > > > ...and I find the derivation of it just complicating thin= gs > > > > > > rather > > > > > > than helping but that's perhaps just my opinion. > > > > > > > > > > > > > > > > > > "It is also useful when the timestamp clock granularit= y is > > > > > > close to > > > > > > or longer than the actual round trip time." > > > > > > Given that some things based on timestamps will obviously= stop > > > > > > working > > > > > > if the clock is slower than one tick per RTT I found this > > > > > > fragment a bit > > > > > > odd. RFC 7323 says "the clock SHOULD tick at least once p= er > > > > > > window's worth > > > > > > of data". I can understand though that a host might find = clock > > > > > > tick > > > > > > granularity challenging due to extensive RTT range but on= the > > > > > > same > > > > > > I'd not want such a "too slow clock" behavior to be endor= sed as > > > > > > if > > > > > > it would be just normal. That is, I'm not against RACK ha= ndling > > > > > > also this case nicely but it would be nice to somehow dow= nplay > > > > > > the > > > > > > normalness tone in it with something along the lines of "= This > > > > > > check is > > > > > > also useful if the recommended one tick per RTT cannot be > > > > > > achieved due > > > > > > to timestamp clock granularity." > > > > > > > > > > > > Is RACK_detect_lost() supposed to detect also lost rexmit= s? How? > > > > > > The rexmit code itself is not in the draft so it's hard t= o > > > > > > evaluate > > > > > > how the Packet booleans are supposed to work in the first= place. > > > > > > I'm not saying the rexmit code should be included but cur= rently > > > > > > it > > > > > > surely looks like any rexmitted packet just remains .lost= =3D TRUE > > > > > > and > > > > > > .retransmitted =3D TRUE state until RTO? > > > > > > > > > > > > > > > > > > Sect 7.4 > > > > > > > > > > > > "PTO" just appears out of nowhere (and is not even writte= n open > > > > > > in the first instance). > > > > > > > > > > > > "2. ... in step (2) of the algorithm." > > > > > > "step (2)" is forward-refing, it would naturally refer ba= ck to > > > > > > "Step 2: Update RACK stats" so it makes very little sense= as is. > > > > > > > > > > > > Sect 7.5 > > > > > > > > > > > > Separator missing for PTO: and TLPRxtOut: > > > > > > > > > > > > Sect 7.5.1 > > > > > > > > > > > > "3. Upon receiving a SACK that selectively acknowledge= s data > > > > > > that was > > > > > > last sent before the segment with SEG.SEQ=3DSND.UN= A was > > > > > > last > > > > > > (re)transmitted" > > > > > > This is hard to understand, perhaps rephrase it somehow? > > > > > > > > > > > > > > > > > > "But choosing PTO to be > > > > > > exactly an SRTT is likely to generate spurious probes = given > > > > > > that > > > > > > network delay variance and even end-system timings can= easily > > > > > > push an > > > > > > ACK to be above an SRTT. We chose PTO to be the next > > > > > > integral > > > > > > multiple of SRTT. > > > > > > > > > > > > Similarly, network delay variations and end-system pro= cessing > > > > > > latencies and timer granularities can easily delay ACK= s > > > > > > beyond > > > > > > 2*SRTT, so senders SHOULD add at least 2ms to a comput= ed PTO > > > > > > value > > > > > > (and MAY add more if the sending host OS timer granula= rity is > > > > > > more > > > > > > coarse than 1ms)." > > > > > > Does this later paragraph depend on some assumptions (suc= h as > > > > > > very > > > > > > low RTT?) as I don't otherwise understand why you say wha= t you > > > > > > say > > > > > > in the given order. First you said x & y can push ACK ove= r SRTT > > > > > > so > > > > > > we pick 2* but then you say the same things can push over= 2*SRTT > > > > > > too? > > > > > > > > > > > > WCDelAckT to terminology? > > > > > > > > > > > > Sect 7.5.2 > > > > > > > > > > > > TLP_send_probe(): > > > > > > - Perhaps set TLPRxtOut somewhere? > > > > > > - Add "Arm RTO" to the end? > > > > > > > > > > > > "In the case where > > > > > > there is only one original outstanding segment of data= (N=3D1), > > > > > > the > > > > > > same logic (trivially) applies: an ACK for a single > > > > > > outstanding > > > > > > segment tells the sender the N-1=3D0 segments precedin= g that > > > > > > segment > > > > > > were lost. Furthermore, whether there are N>1 or N=3D= 1 > > > > > > outstanding > > > > > > segments," > > > > > > If this distinction is useful to make at all, maybe just = simply > > > > > > say: > > > > > > "Applies also in case N=3D1." > > > > > > > > > > > > Sect 7.6 > > > > > > > > > > > > "SND.NXT at the time the episode started." > > > > > > Isn't this TLPHighRxt, why not use it here? > > > > > > > > > > > > Sect 7.6.2 > > > > > > > > > > > > "Upon sending a TLP probe that is a retransmission, the= sender > > > > > > sets > > > > > > TLPRxtOut to true and TLPHighRxt to SND.NXT." > > > > > > This should appear in TLP_send_probe(). > > > > > > > > > > > > "Detecting recoveries accomplished by loss probes" > > > > > > Did you want to start another section here? > > > > > > > > > > > > "Step 1: Track ACKs ..." until what point? (It's told on = later > > > > > > but > > > > > > this question comes into mind when reading the draft in o= rder). > > > > > > > > > > > > > > > > > > Sect 7.4 - 7.6.2 > > > > > > > > > > > > In general, this particular part of the draft seems to re= quire > > > > > > some > > > > > > further editing. After reading it all through, I feel mos= t bits > > > > > > are > > > > > > present but the text is very hard to follow. I think the > > > > > > presentation > > > > > > order needs significant work. There are random bits here = and > > > > > > there > > > > > > that are explained only later. Also, algorithm lacks some= parts > > > > > > discussed only in the text but variable like items should > > > > > > definitely > > > > > > be included to the algorithm. > > > > > > > > > > > > > > > > > > Sect 8.4 > > > > > > > > > > > > "RACK is compatible with and does not interfere with th= e the > > > > > > standard > > > > > > RTO [RFC6298], RTO-restart [RFC7765], F-RTO [RFC5682] = and > > > > > > Eifel > > > > > > algorithms [RFC3522]. ... > > > > > > It neither changes the RTO timer calculation nor detec= ts > > > > > > spurious > > > > > > timeouts." > > > > > > For F-RTO, also send order is significant. > > > > > > > > > > > > Sect 8.5 > > > > > > > > > > > > SHOULDs PRR (and also placed to normative references) tha= t is > > > > > > only > > > > > > experimental and RACK aims to standards track. I feel tha= t PRR > > > > > > is > > > > > > disjoint enough anyway, which I think was also your inten= tion > > > > > > when > > > > > > maintaining the decoupling CC and RACK, that it's bit odd= to > > > > > > take > > > > > > this strong stance on PRR (indepedent of the stds track v= s > > > > > > experimental thing). > > > > > > > > > > > > "due to congestion window validation." > > > > > > Does this refer to CWV as in RFC? Or some other mechanism= in > > > > > > which > > > > > > case you shouldn't use the same term here. > > > > > > > > > > > > I find the described scenario somewhat unconvincing becas= e > > > > > > the description ends with: > > > > > > "... > > > > > > The ending congestion window after recovery also impac= ts > > > > > > subsequent data transfer." > > > > > > ...First there wasn't enough data to fill cwnd of 20 pack= ets and > > > > > > then suddenly transferring that non-existing data is impa= cted. > > > > > > > > > > > > References > > > > > > > > > > > > QUIC-LR is very old ref and even the filename has changed= a few > > > > > > times from draft-tsvwg-... > > > > > > > > > > > > > > > > > > Nits > > > > > > > > > > > > "runt" made the sentence incomprehendable for me, I had t= o look > > > > > > up > > > > > > that word (and only second source was descriptive enough = that I > > > > > > think I could understand the meaning, and I'd guessed wro= ng > > > > > > because > > > > > > I thought there was some special intent here because of t= he > > > > > > quotes). > > > > > > > > > > > > is dicussed -> is discussed > > > > > > RACT.RTT -> RACK.rtt > > > > > > First "TSO" -> TCP Segmentation Offload (TSO) > > > > > > grainularity -> granularity > > > > > > higher-sequenc -> higher-sequence > > > > > > > > > > > > > > > > > > -- > > > > > > i. > > > > > > > > > > > > > > > > > > > > > > > > From nobody Mon May 11 15:57:33 2020 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 EFC553A0D96 for ; Mon, 11 May 2020 15:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 ZHqXuI2i7gy4 for ; Mon, 11 May 2020 15:57:28 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 06AF43A0D7F for ; Mon, 11 May 2020 15:57:27 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04BMdOGp015677; Mon, 11 May 2020 15:57:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=date : from : to : subject : message-id : mime-version : content-type; s=20180706; bh=eds7ZgC1GQ1iCfxZJIeJWZgNAGhL4eHvhtv37XAF1BQ=; b=r6s5sYJpJ6aiLVvZJR+hh7vYlb9rt7zMaz7tdgdK2IwFooQqaMKGjl1blmnBZc2v8+hs 1wxZKNQsM/pDxplDVv5keA77i0BqmZ25/zZLxVmlFpIVMnOyDiR52kJRTE8AbNJcwEPm pA9Yp5H9ss7UGyP47vb1LLlq8Rccz49IAmsr047HibwsNYARHs20Pq6MpHLfDfIQod57 mWP/4k1Tgy453UXhab6PdP5RBg/2FleB2zAMdXe4iCOSDTssnEVe8cZYdIKUVCbio/Qw FNgVs/aAv9fxpyFcuuv77270wTBqz321TkMj6uqakyXJtRQGPP190yBMP2iYAWsNiWYo GQ== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 30ws6sgkck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 May 2020 15:57:23 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QA600IPDVRNWRB0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Mon, 11 May 2020 15:57:23 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QA600I00UPDHU00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 11 May 2020 15:57:23 -0700 (PDT) X-Va-A: X-Va-T-CD: 214a97156469c479a25533fa1f70977b X-Va-E-CD: eef38c89224e1e017428b2e8d7d61714 X-Va-R-CD: 6ce155bfd92f87a3e75d7dc2c0345fea X-Va-CD: 0 X-Va-ID: 6ff2c706-067c-4b4a-bb61-3ecbe723c487 X-V-A: X-V-T-CD: 214a97156469c479a25533fa1f70977b X-V-E-CD: eef38c89224e1e017428b2e8d7d61714 X-V-R-CD: 6ce155bfd92f87a3e75d7dc2c0345fea X-V-CD: 0 X-V-ID: 0540b2fc-dd57-4f8b-8c4a-332b65e0717b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-11_11:2020-05-11, 2020-05-11 signatures=0 Received: from localhost ([17.235.13.20]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QA60071EVRM3N00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 11 May 2020 15:57:22 -0700 (PDT) Date: Mon, 11 May 2020 15:57:22 -0700 From: Christoph Paasch To: gorry@erg.abdn.ac.uk, tcpm@ietf.org Message-id: <20200511225722.GA6966@MacBook-Pro-64.local> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.12.2 (2019-09-21) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-11_11:2020-05-11, 2020-05-11 signatures=0 Archived-At: Subject: [tcpm] RFC7661 - assumes reno in Section 4.4.1 ? 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, 11 May 2020 22:57:31 -0000 Hello, I have a question regarding RFC7661. In Section 4.4.1, it specifies the congestion-window when entering and exiting the recovery-period, namely: cwnd = (Max(pipeACK,LossFlightSize))/2 and cwnd = (Max(pipeACK,LossFlightSize) - R)/2 Is the division by 2 because it assumes Reno's multiplicative decrease and if Cubic would be used that would be beta_cubic ? Or is there another reason behind the division by 2? Thanks, Christoph From nobody Mon May 11 17:30:36 2020 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 215E53A0DE0 for ; Mon, 11 May 2020 17:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 rKq-B1pFFhFx for ; Mon, 11 May 2020 17:30:33 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650109.outbound.protection.outlook.com [40.107.65.109]) (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 1DBF73A0DDF for ; Mon, 11 May 2020 17:30:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bar4R1PKkKmvCdHmJw/mz9YniLSQzZ7kkPNSJlHH6OIZTzNr6zJC7clbhAr9o8tAXBVO/7jTk6CZMgkzTglzvch3vpSO3oxynxJdPJJPkjR/8d65IVBumXUG9Q4NDblc7KOfdPgkLTkUzYRs1wPzYIib4yybOPKhcZgRoP64g3JemO6H3hplHmRObgFbdN/whjjLlYX3z0NPU5D3QzbHNbWHr6P4g1yc9LzFeiVD9vbekSjozNNBqifHZmSRZ5lrn83OJjFazqPBEWVmuy/2VoTkI1XgRwqVRi89OkTHhXRGH0uVTdLJte93Ewgh00v8wFzAW55LO3piKUKKvR4Y8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yAOdG3pZoPNG9Ut8mSOE3U2MBJfLUWa7MyHW0CescJE=; b=C9CdTUfhmCeRIHaQBWdvSO0HtHFLMgKqr+978M3Kakv8RFWMMpoe5jMZvLjlCloq4QArhMsh6afCaoMqaFBPabjXIVuCK0vQD+Lh4V/9zVvr3ZK5hAQFhknR/i9rut1V654OW/SvoZXixdxpY/QuEtabeFTLBeA7VcWUpSJZGNNYYkFmKwOnuu0VwYVsIY/Kypy2yGBkpIeHypwE6S42JaZfNgXOgk1xHY7IJ9rL4gL1FcvvN6mNWjHSXADXl+i81S5pYIeK6f8uQrvs6vi5JjYbjtl7weYxqeJWkiC5V8Azv2nGdghnRWmQGRk08nrFIUQzgImXMMpPK65NYk1xTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yAOdG3pZoPNG9Ut8mSOE3U2MBJfLUWa7MyHW0CescJE=; b=jITV1lUIZe0gijlSmuNjQzQK5laS55uq6Vv1wVPE3iriGmVnVFbKJ5Ia3nrLoJpv6p1/HgIW4Z4lgTT7uzuDxVp9rsIa24QejzdP+Wg/QYFM3yGdX8XbdaJsE7gWtFFq2VSleBnKak0pV+xR3WC/va7TYO8FEKBhaaHDhVCfthQ= Received: from BN3PR00MB0116.namprd00.prod.outlook.com (2a01:111:e400:c5f3::22) by BN8PR00MB0884.namprd00.prod.outlook.com (2603:10b6:408:a5::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3035.0; Tue, 12 May 2020 00:30:30 +0000 Received: from BN3PR00MB0116.namprd00.prod.outlook.com ([fe80::49d0:2f77:e716:4d32]) by BN3PR00MB0116.namprd00.prod.outlook.com ([fe80::49d0:2f77:e716:4d32%4]) with mapi id 15.20.3035.000; Tue, 12 May 2020 00:30:30 +0000 From: Praveen Balasubramanian To: Matt Mathis , Neal Cardwell CC: Michael Tuexen , "tcpm@ietf.org" , Jon Crowcroft Thread-Topic: [EXTERNAL] Re: [tcpm] On Sender Control of Delayed Acks in TCP Thread-Index: AQHWHmpnsEexOtQQakSXC1ojx5DBVKiTCBAAgAAgqwCAAGTDAIABANUAgABLzoCAAARXgIAAAlMAgAAFzICAAigsgA== Date: Tue, 12 May 2020 00:30:30 +0000 Message-ID: References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> 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=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-12T00:30:29.1053037Z; 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=1cab4059-7669-4134-a265-7aa014c19e1f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9:95cf:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 20c6ae7a-9a2f-4fee-e600-08d7f60bad23 x-ms-traffictypediagnostic: BN8PR00MB0884: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0401647B7F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wrjW9Jee0cpOedIYnt+o2TmDOeq26+yc88ghVdpVuQWiwW2gdQ3D/EJTaCvOvAUhUdGSiyruFlXD1LuTEWzBVsXu02YBcQH+nvR5LCurSQJXmNh9yxXFmn4rlecvGC6aqAdOWkr/1yMArlyyJyX8XXVFykFMDbrFNsnea4xUJuuYhruvwQ5tE/2zgZuP5HZu8uYCHwpr83P+oAGwWmqAk8y5o1hHXsPt2wFvzqXYVRek7NMHjutziIz3nuc0AWGE8OTsCh52vaNSEsjSYS0Y/a1aPFogUvMOnUNgcJwW+ltKxCPlOpsnP4tKUIW8qS3IaCRRXQ0e+xyGolK5RKccsYlWCXl+xFXDuF7hbpchkyIaYqg60xEkGUFycK6lu/Mtw0iFXzFkD7wXtf2Smf09ogUdAbok54suoKEwgftILcvJdRYzvaA+GU0dTG3Mkas1va0sYG+Z56lBNQw4hzXcV/jmVrLJDBd0grk2ACWtPKw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN3PR00MB0116.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(39860400002)(396003)(366004)(33430700001)(8676002)(33440700001)(71200400001)(166002)(82960400001)(82950400001)(8936002)(64756008)(66446008)(966005)(66946007)(52536014)(66556008)(478600001)(76116006)(10290500003)(66476007)(33656002)(4326008)(86362001)(316002)(186003)(55016002)(54906003)(110136005)(9686003)(8990500004)(6506007)(53546011)(5660300002)(2906002)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 22xjICms2Gl7RPYb4r0YzbmKk+jjDybCCbvDrBo+4NXOLn/OA12/6MFVCn/ul+tQt7L+9xK5UxV4sZngaqHRzVXo373PAXtS7zA2piZVACFSN8YfGuSJWeViF7+eOLMIGQcK1eR3GBbH34cKfu2rSR8VxcuwKayptGg81cIX0KIGHgeN9AFL8QRRwwbPV5fVAUMTsuXaRdPFgBKClVRBjVGDTUeVTFD0m7MLgXrpis1HsAbOsUL2uaU/FDfK9K6N4YPedg5ADYeNj/8D5acJY7sS/4tLo3d61z3vnbBr+V2tslC1YBOFqkthpnVd995PEk+yoPFC770ERHKfaa6XgizBtHIFf7CwK5H0/ugovz8p2br2cV0D+h65OjQIiAjwhUGdTFlCLL7TFlIFh24bo/bEccaWq/CcjKSzq/mNTlVlRYs/sZW7R1g5W7AwJoGwerghTOKPu07l9bq/GDLo+XEtIjZdOqA43YUOhM1CqYz9cHtlRu6lJ5F4WDopEX+MPelyZRVoqBjVcW7pgyMnachHLFZvMI7iQy/9ANrGNG8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN3PR00MB01169B7713BDF863903AC6C8B6BE0BN3PR00MB0116namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN3PR00MB0116.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20c6ae7a-9a2f-4fee-e600-08d7f60bad23 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 00:30:30.3889 (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-CrossTenant-userprincipalname: 64TpcEugiykhjPvydkqLSFATZpKlIlp6l7JkV1qgFtO85sHLoT6J94PWVgIhpSO87iG2nNg5o0HpGsar9w5/J8H3KWN4VILqcS3cf5WFIEo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR00MB0884 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: On Sender Control of Delayed Acks in TCP 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, 12 May 2020 00:30:35 -0000 --_000_BN3PR00MB01169B7713BDF863903AC6C8B6BE0BN3PR00MB0116namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIHRoZSB0d28gdXNlLWNhc2UgdGF4b25vbXkuIFdoaWxlIGl0J2QgYmUgcXVp dGUgbmljZSB0byBoYXZlIGEgc2luZ2xlIG1lY2hhbmlzbSBsaWtlIGEgVENQIG9wdGlvbiB0aGF0 IGFkZHJlc3NlcyBib3RoIHVzZSBjYXNlcywgdGhlcmUgYXJlIHByb2JsZW1zIHdpdGggYSBuZXcg b3B0aW9uIHRoYXQncyB1c2VkIGluIGRhdGEgcGFja2V0czoNCg0KMS4gbWlkZGxlYm94IHRyYXZl cnNhbA0KDQoyLiBoYXJkd2FyZSBvZmZsb2FkcyBsaWtlIFRTTyBhbmQgTFJPIG1pZ2h0IG5lZWQg dXBkYXRlcz8NCg0KDQoNCklmIHdlIGdvIGRvd24gdGhlIHBhdGggb2YgYSBuZXcgb3B0aW9uIGZv ciBkYXRhIHBhY2tldHMgdGhhdCBpcyBicm9hZGx5IGRlcGxveWVkLCBzaG91bGQgd2UgYWltIGZv ciBhIGxpc3Qgb2Yga2V5LXZhbHVlIHBhaXJzIHNvIHRoYXQgaXQgaXMgZXh0ZW5zaWJsZT8NCg0K DQoNCkFsc28sIEkgcmVjYWxsIHRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQgdXNhZ2Ug b2YgUFNIIGJpdCBmb3IgQUNLIHB1bGwuIEl04oCZcyBhbHJlYWR5IHVzZWQgZm9yIHNpZ25hbGlu ZyBtZXNzYWdlIGJvdW5kYXJ5LCBzbyBhbiBpbW1lZGlhdGUgQUNLIHVwb24gZW5kIG9mIG1lc3Nh Z2UgbWlnaHQgYWxzbyBoZWxwIGxvd2VyIGxhdGVuY3kuDQoNCg0KDQpUaGFua3MNCg0KRnJvbTog dGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWF0dCBNYXRoaXMNClNl bnQ6IFNhdHVyZGF5LCBNYXkgMiwgMjAyMCA3OjU1IEFNDQpUbzogTmVhbCBDYXJkd2VsbCA8bmNh cmR3ZWxsPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBNaWNoYWVsIFR1ZXhlbiA8 bWljaGFlbC50dWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGU+OyB0Y3BtQGlldGYub3JnOyBKb24gQ3Jv d2Nyb2Z0IDxqb24uY3Jvd2Nyb2Z0QGNsLmNhbS5hYy51az4NClN1YmplY3Q6IFtFWFRFUk5BTF0g UmU6IFt0Y3BtXSBPbiBTZW5kZXIgQ29udHJvbCBvZiBEZWxheWVkIEFja3MgaW4gVENQDQoNCkFu b3RoZXIgcHJvYmFibHkgc21hbGwgb3Bwb3J0dW5pdHkgd291bGQgYmUgdG8gbWFrZSB0aGUgUlRU IGVzdGltYXRvcnMgbGVzcyBub2lzeSwgYnkgaGF2aW5nIHRoZSByZWNlaXZlciBhbHdheXMgQUNL IHRoZSBmaXJzdCAob3IgbGFzdCkgVFNPIHNlZ21lbnQuICAgVGhlIFJUVCBpcyBjdXJyZW50bHkg ZnV6emVkIGJ5IGJvdGggZGVsIEFDSyBhbmQgVENQIHN0cmlkZXMuDQoNClRoYW5rcywNCi0tTU0t LQ0KVGhlIGJlc3Qgd2F5IHRvIHByZWRpY3QgdGhlIGZ1dHVyZSBpcyB0byBjcmVhdGUgaXQuICAt IEFsYW4gS2F5DQoNCldlIG11c3Qgbm90IHRvbGVyYXRlIGludG9sZXJhbmNlOw0KICAgICAgIGhv d2V2ZXIgb3VyIHJlc3BvbnNlIG11c3QgYmUgY2FyZWZ1bGx5IG1lYXN1cmVkOg0KICAgICAgICAg ICAgdG9vIHN0cm9uZyB3b3VsZCBiZSBoeXBvY3JpdGljYWwgYW5kIHJpc2tzIHNwaXJhbGluZyBv dXQgb2YgY29udHJvbDsNCiAgICAgICAgICAgIHRvbyB3ZWFrIHJpc2tzIGJlaW5nIG1pc3Rha2Vu IGZvciB0YWNpdCBhcHByb3ZhbC4NCg0KDQpPbiBTYXQsIE1heSAyLCAyMDIwIGF0IDc6MzUgQU0g TmVhbCBDYXJkd2VsbCA8bmNhcmR3ZWxsPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpPbiBTYXQsIE1heSAyLCAy MDIwIGF0IDEwOjI2IEFNIE1pY2hhZWwgVHVleGVuDQo8bWljaGFlbC50dWV4ZW5AbHVyY2hpLmZy YW5rZW4uZGU8bWFpbHRvOm1pY2hhZWwudHVleGVuQGx1cmNoaS5mcmFua2VuLmRlPj4gd3JvdGU6 DQo+DQo+ID4gT24gMi4gTWF5IDIwMjAsIGF0IDE2OjEwLCBOZWFsIENhcmR3ZWxsIDxuY2FyZHdl bGw9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMu aWV0Zi5vcmc+PiB3cm90ZToNCj4gPg0KPiA+IE9uIFNhdCwgTWF5IDIsIDIwMjAgYXQgNTo0MCBB TSBDYXJsZXMgR29tZXogTW9udGVuZWdybw0KLi4uLi4NCj4gPj4gW0NHXSBJdCBzZWVtcyB0aGF0 IHRoZXJlIGFyZSB0d28gZGlmZmVyZW50IGFyZWFzIHdoZXJlIGF2b2lkaW5nIHRoZQ0KPiA+PiB0 eXBpY2FsIERlbGF5ZWQgQUNLcyBhcHByb2FjaCBtYXkgYmUgb2YgcGFydGljdWxhciBpbnRlcmVz dDogaSkgc2NlbmFyaW9zDQo+ID4+IHdoZXJlIHZlcnkgc21hbGwgd2luZG93IHNpemVzIGFyZSB1 c2VkIChjd25kPTEpLCBhbmQgaWkpIHNjZW5hcmlvcyB3aGVyZQ0KPiA+PiBsYXJnZSB3aW5kb3cg c2l6ZXMsIGFuZCBoaWdoIEFDSyByYXRpb3MsIGNhbiBiZSB1c2VkLiBXZSB3aWxsIHJlZmxlY3QN Cj4gPj4gdGhlc2UgY29uc2lkZXJhdGlvbnMgaW4gdGhlIG5leHQgZHJhZnQgdXBkYXRlLg0KPiA+ DQo+ID4gWWVzLCBJIHdob2xlaGVhcnRlZGx5IGFncmVlIHdpdGggQm9iJ3MgcG9pbnQgdGhhdCBp dCdzIGFsc28gZXh0cmVtZWx5DQo+ID4gdXNlZnVsIGZvciBUQ1Agc2VuZGVycyB0byBiZSBhYmxl IHRvIHNheSB0aGluZ3MgbGlrZTogIkkgZG9uJ3QNCj4gPiBwYXJ0aWN1bGFybHkgbWluZCB3aGlj aCBwYWNrZXRzIHlvdSBBQ0ssIGJ1dCB0aGVyZSdzIG5vIG5lZWQgdG8gZG8gaXQNCj4gPiBtb3Jl IG9mdGVuIHRoYW4gMToxNiIuIFFVSUMgaGFzIGEgbWVjaGFuaXNtIGxpa2UgdGhpcywgYW5kIGl0 IHNlZW1zIHRvDQo+ID4gYWxsb3cgc2lnbmlmaWNhbnQgQ1BVIHNhdmluZ3MsIGV2ZW4gYWxsb3dp bmcgUVVJQyB0byBydW4gZmFzdGVyIHRoYW4NCj4gPiBUQ1AgaW4gc29tZSBjYXNlcywgQUZBSUNU IGR1ZSB0byB0aGUgcmVkdWNlZCBvdmVyaGVhZCBmb3IgaGFuZGxpbmcNCj4gPiBBQ0tzOg0KPiA+ ICBodHRwczovL3d3dy5mYXN0bHkuY29tL2Jsb2cvbWVhc3VyaW5nLXF1aWMtdnMtdGNwLWNvbXB1 dGF0aW9uYWwtZWZmaWNpZW5jeTxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuZmFzdGx5LmNvbSUyRmJsb2clMkZtZWFz dXJpbmctcXVpYy12cy10Y3AtY29tcHV0YXRpb25hbC1lZmZpY2llbmN5JmRhdGE9MDIlN0MwMSU3 Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzM4ZmYzZDFkODhiMjQ1ZDE5YTJiMDhkN2VlYThlYmVh JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzI0MDI4MjIw Njg4NjM2OCZzZGF0YT1VdiUyQiUyRmdVT2t2WHNzNjZoY0dvaHFudDN0UkhLNGczaW1EdDBJMG11 NXhSdyUzRCZyZXNlcnZlZD0wPg0KPiA+ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaXllbmdhci1xdWljLWRlbGF5ZWQtYWNrLTAwPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJG aHRtbCUyRmRyYWZ0LWl5ZW5nYXItcXVpYy1kZWxheWVkLWFjay0wMCZkYXRhPTAyJTdDMDElN0Nw cmF2YiU0MG1pY3Jvc29mdC5jb20lN0MzOGZmM2QxZDg4YjI0NWQxOWEyYjA4ZDdlZWE4ZWJlYSU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcyNDAyODIyMDY4 ODYzNjgmc2RhdGE9OXZ3M3NqcVRBUExQQ05BUVBDRnphM1JKU0xZJTJCMjVUOE9kcXEwUENlYyUy QkUlM0QmcmVzZXJ2ZWQ9MD4NCj4gPg0KPiA+IFNvIEkgYWdyZWUgd2l0aCB0aGUgdXNlZnVsbmVz cyBvZiB0aGUgdHdvLXVzZS1jYXNlIHRheG9ub215IENhcmxlcyBoYXMgb3V0bGluZWQ6DQo+ID4N Cj4gPiAxOiAicGxlYXNlIEFDSyBub3ciOyBiZWNhdXNlIHNlbmRlcidzIGN3bmQgaXMgbG93DQo+ ID4NCj4gPiAyOiAiQUNLIGF0IGZyZXF1ZW5jeSBLIjsgYmVjYXVzZSBzZW5kZXIncyBjd25kIGlz IGhpZ2gNCj4gPg0KPiA+IEl0IHNlZW1zIHRob3NlIGNvdWxkIGJvdGggYmUgYWRkcmVzc2VkIGNs ZWFubHkgd2l0aCBvbmUgb3IgdHdvIFRDUA0KPiA+IG9wdGlvbiBraW5kcy4gQSBzaW5nbGUgVENQ IG9wdGlvbiBraW5kIG1pZ2h0IHN1ZmZpY2UgaWYgdGhlIEFDSw0KPiA+IGZyZXF1ZW5jeSBvZiAw IG9yIDEgaXMgdGFrZW4gdG8gbWVhbiAicGxlYXNlIEFDSyBub3ciLg0KPiBJIG1pZ2h0IGJlIHVz ZWZ1bCBpZiB0aGUgc2VuZGVyIGNhbiB0cmlnZ2VyIGFuIEFDSyBmb3IgdGhpcyBwYXJ0aWN1bGFy IHBhY2tldCwNCj4gYnV0IGxlYXZlIHRoZSByYXRlIHVuY2hhbmdlZC4gQW5kIGNoYW5nZSB0aGUg cmF0ZSBmcm9tIG5vdyBvbi4NCj4gSWYgdXNpbmcgYW4gb3B0aW9uLCB5b3UgY291bGQgZW5jb2Rl ICJzZW5kIGFuIGFjayBmb3IgdGhpcyBwYWNrZXQsIGJ1dCBkb24ndA0KPiBjaGFuZ2UgdGhlIGFj ayByYXRlIiBieSB1c2luZyAwLCBhbmQgZW5jb2RlICJjaGFuZ2UgdGhlIGFjayByYXRlIHRvIDEg Zm9yIG4iDQo+IGJ5IHVzaW5nIG4sIG4gPiAwLg0KDQpZZXMsIHRoYXQgc291bmRzIGxpa2UgYSB2 ZXJ5IG5pY2UgaWRlYS4NCg0KYmVzdCwNCm5lYWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3Jn PG1haWx0bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90Y3BtPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRj cG0mZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMzhmZjNkMWQ4OGIyNDVk MTlhMmIwOGQ3ZWVhOGViZWElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM3MjQwMjgyMjA2ODk2MzYzJnNkYXRhPWxXM1c4T052WHcxTjAySmhBV09wVk00b0w2 cjRKTElGVWNxUXh6WXUlMkZhMCUzRCZyZXNlcnZlZD0wPg0K --_000_BN3PR00MB01169B7713BDF863903AC6C8B6BE0BN3PR00MB0116namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgYWdyZWUgd2l0 aCB0aGUgdHdvIHVzZS1jYXNlIHRheG9ub215LiBXaGlsZSBpdCdkIGJlIHF1aXRlIG5pY2UgdG8g aGF2ZSBhIHNpbmdsZSBtZWNoYW5pc20gbGlrZSBhIFRDUCBvcHRpb24gdGhhdCBhZGRyZXNzZXMg Ym90aCB1c2UgY2FzZXMsIHRoZXJlIGFyZSBwcm9ibGVtcyB3aXRoIGEgbmV3IG9wdGlvbiB0aGF0 J3MgdXNlZCBpbiBkYXRhIHBhY2tldHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4xLiBtaWRkbGVib3ggdHJhdmVyc2FsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4yLiBoYXJkd2FyZSBvZmZsb2FkcyBsaWtlIFRTTyBhbmQgTFJPIG1pZ2h0 IG5lZWQgdXBkYXRlcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SWYgd2UgZ28gZG93 biB0aGUgcGF0aCBvZiBhIG5ldyBvcHRpb24gZm9yIGRhdGEgcGFja2V0cyB0aGF0IGlzIGJyb2Fk bHkgZGVwbG95ZWQsIHNob3VsZCB3ZSBhaW0gZm9yIGEgbGlzdCBvZiBrZXktdmFsdWUgcGFpcnMg c28gdGhhdCBpdCBpcyBleHRlbnNpYmxlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5B bHNvLCBJIHJlY2FsbCB0aGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHVzYWdlIG9mIFBT SCBiaXQgZm9yIEFDSyBwdWxsLiBJdOKAmXMgYWxyZWFkeSB1c2VkIGZvciBzaWduYWxpbmcgbWVz c2FnZSBib3VuZGFyeSwgc28gYW4gaW1tZWRpYXRlIEFDSyB1cG9uIGVuZCBvZiBtZXNzYWdlIG1p Z2h0IGFsc28gaGVscCBsb3dlciBsYXRlbmN5Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gdGNwbSAmbHQ7dGNwbS1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5P biBCZWhhbGYgT2YgPC9iPg0KTWF0dCBNYXRoaXM8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXks IE1heSAyLCAyMDIwIDc6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IE5lYWwgQ2FyZHdlbGwgJmx0O25j YXJkd2VsbD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBN aWNoYWVsIFR1ZXhlbiAmbHQ7bWljaGFlbC50dWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGUmZ3Q7OyB0 Y3BtQGlldGYub3JnOyBKb24gQ3Jvd2Nyb2Z0ICZsdDtqb24uY3Jvd2Nyb2Z0QGNsLmNhbS5hYy51 ayZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBSZTogW3RjcG1dIE9uIFNlbmRl ciBDb250cm9sIG9mIERlbGF5ZWQgQWNrcyBpbiBUQ1A8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5vdGhlciBwcm9iYWJseSBzbWFsbCBvcHBvcnR1bml0eSB3b3VsZCBi ZSB0byBtYWtlIHRoZSBSVFQgZXN0aW1hdG9ycyBsZXNzIG5vaXN5LCBieSBoYXZpbmcgdGhlIHJl Y2VpdmVyIGFsd2F5cyBBQ0sgdGhlIGZpcnN0IChvciBsYXN0KSBUU08gc2VnbWVudC4mbmJzcDsg Jm5ic3A7VGhlIFJUVCBpcyBjdXJyZW50bHkgZnV6emVkIGJ5IGJvdGggZGVsIEFDSyBhbmQgVENQ IHN0cmlkZXMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy IGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1NTS0tPGJy Pg0KVGhlIGJlc3Qgd2F5IHRvIHByZWRpY3QgdGhlIGZ1dHVyZSBpcyB0byBjcmVhdGUgaXQuICZu YnNwOy0gQWxhbiBLYXk8YnI+DQo8YnI+DQpXZSBtdXN0IG5vdCB0b2xlcmF0ZSBpbnRvbGVyYW5j ZTs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2hvd2V2ZXIgb3VyIHJlc3BvbnNlIG11c3QgYmUgY2Fy ZWZ1bGx5IG1lYXN1cmVkOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgdG9vIHN0cm9uZyB3b3VsZCBiZSBoeXBvY3JpdGljYWwgYW5kIHJpc2tzIHNwaXJhbGluZyBv dXQgb2YgY29udHJvbDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvbyB3 ZWFrIHJpc2tzIGJlaW5nIG1pc3Rha2VuIGZvciB0YWNpdCBhcHByb3ZhbC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgTWF5IDIsIDIwMjAgYXQgNzozNSBB TSBOZWFsIENhcmR3ZWxsICZsdDtuY2FyZHdlbGw9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLm9yZyI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBNYXkgMiwg MjAyMCBhdCAxMDoyNiBBTSBNaWNoYWVsIFR1ZXhlbjxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86 bWljaGFlbC50dWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGUiIHRhcmdldD0iX2JsYW5rIj5taWNoYWVs LnR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQom Z3Q7ICZndDsgT24gMi4gTWF5IDIwMjAsIGF0IDE2OjEwLCBOZWFsIENhcmR3ZWxsICZsdDtuY2Fy ZHdlbGw9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiBTYXQsIE1heSAyLCAyMDIwIGF0IDU6NDAgQU0g Q2FybGVzIEdvbWV6IE1vbnRlbmVncm88YnI+DQouLi4uLjxicj4NCiZndDsgJmd0OyZndDsgW0NH XSBJdCBzZWVtcyB0aGF0IHRoZXJlIGFyZSB0d28gZGlmZmVyZW50IGFyZWFzIHdoZXJlIGF2b2lk aW5nIHRoZTxicj4NCiZndDsgJmd0OyZndDsgdHlwaWNhbCBEZWxheWVkIEFDS3MgYXBwcm9hY2gg bWF5IGJlIG9mIHBhcnRpY3VsYXIgaW50ZXJlc3Q6IGkpIHNjZW5hcmlvczxicj4NCiZndDsgJmd0 OyZndDsgd2hlcmUgdmVyeSBzbWFsbCB3aW5kb3cgc2l6ZXMgYXJlIHVzZWQgKGN3bmQ9MSksIGFu ZCBpaSkgc2NlbmFyaW9zIHdoZXJlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBsYXJnZSB3aW5kb3cgc2l6 ZXMsIGFuZCBoaWdoIEFDSyByYXRpb3MsIGNhbiBiZSB1c2VkLiBXZSB3aWxsIHJlZmxlY3Q8YnI+ DQomZ3Q7ICZndDsmZ3Q7IHRoZXNlIGNvbnNpZGVyYXRpb25zIGluIHRoZSBuZXh0IGRyYWZ0IHVw ZGF0ZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgWWVzLCBJIHdob2xlaGVhcnRlZGx5 IGFncmVlIHdpdGggQm9iJ3MgcG9pbnQgdGhhdCBpdCdzIGFsc28gZXh0cmVtZWx5PGJyPg0KJmd0 OyAmZ3Q7IHVzZWZ1bCBmb3IgVENQIHNlbmRlcnMgdG8gYmUgYWJsZSB0byBzYXkgdGhpbmdzIGxp a2U6ICZxdW90O0kgZG9uJ3Q8YnI+DQomZ3Q7ICZndDsgcGFydGljdWxhcmx5IG1pbmQgd2hpY2gg cGFja2V0cyB5b3UgQUNLLCBidXQgdGhlcmUncyBubyBuZWVkIHRvIGRvIGl0PGJyPg0KJmd0OyAm Z3Q7IG1vcmUgb2Z0ZW4gdGhhbiAxOjE2JnF1b3Q7LiBRVUlDIGhhcyBhIG1lY2hhbmlzbSBsaWtl IHRoaXMsIGFuZCBpdCBzZWVtcyB0bzxicj4NCiZndDsgJmd0OyBhbGxvdyBzaWduaWZpY2FudCBD UFUgc2F2aW5ncywgZXZlbiBhbGxvd2luZyBRVUlDIHRvIHJ1biBmYXN0ZXIgdGhhbjxicj4NCiZn dDsgJmd0OyBUQ1AgaW4gc29tZSBjYXNlcywgQUZBSUNUIGR1ZSB0byB0aGUgcmVkdWNlZCBvdmVy aGVhZCBmb3IgaGFuZGxpbmc8YnI+DQomZ3Q7ICZndDsgQUNLczo8YnI+DQomZ3Q7ICZndDsmbmJz cDsgPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmZhc3RseS5jb20lMkZibG9nJTJGbWVhc3VyaW5nLXF1 aWMtdnMtdGNwLWNvbXB1dGF0aW9uYWwtZWZmaWNpZW5jeSZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJh dmIlNDBtaWNyb3NvZnQuY29tJTdDMzhmZjNkMWQ4OGIyNDVkMTlhMmIwOGQ3ZWVhOGViZWElN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MjQwMjgyMjA2ODg2 MzY4JmFtcDtzZGF0YT1VdiUyQiUyRmdVT2t2WHNzNjZoY0dvaHFudDN0UkhLNGczaW1EdDBJMG11 NXhSdyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuZmFz dGx5LmNvbS9ibG9nL21lYXN1cmluZy1xdWljLXZzLXRjcC1jb21wdXRhdGlvbmFsLWVmZmljaWVu Y3k8L2E+PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYu b3JnJTJGaHRtbCUyRmRyYWZ0LWl5ZW5nYXItcXVpYy1kZWxheWVkLWFjay0wMCZhbXA7ZGF0YT0w MiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMzhmZjNkMWQ4OGIyNDVkMTlhMmIwOGQ3 ZWVhOGViZWElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3 MjQwMjgyMjA2ODg2MzY4JmFtcDtzZGF0YT05dnczc2pxVEFQTFBDTkFRUENGemEzUkpTTFklMkIy NVQ4T2RxcTBQQ2VjJTJCRSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWl5ZW5nYXItcXVpYy1kZWxheWVkLWFjay0w MDwvYT48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgU28gSSBhZ3JlZSB3aXRoIHRoZSB1 c2VmdWxuZXNzIG9mIHRoZSB0d28tdXNlLWNhc2UgdGF4b25vbXkgQ2FybGVzIGhhcyBvdXRsaW5l ZDo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgMTogJnF1b3Q7cGxlYXNlIEFDSyBub3cm cXVvdDs7IGJlY2F1c2Ugc2VuZGVyJ3MgY3duZCBpcyBsb3c8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgMjogJnF1b3Q7QUNLIGF0IGZyZXF1ZW5jeSBLJnF1b3Q7OyBiZWNhdXNlIHNlbmRl cidzIGN3bmQgaXMgaGlnaDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJdCBzZWVtcyB0 aG9zZSBjb3VsZCBib3RoIGJlIGFkZHJlc3NlZCBjbGVhbmx5IHdpdGggb25lIG9yIHR3byBUQ1A8 YnI+DQomZ3Q7ICZndDsgb3B0aW9uIGtpbmRzLiBBIHNpbmdsZSBUQ1Agb3B0aW9uIGtpbmQgbWln aHQgc3VmZmljZSBpZiB0aGUgQUNLPGJyPg0KJmd0OyAmZ3Q7IGZyZXF1ZW5jeSBvZiAwIG9yIDEg aXMgdGFrZW4gdG8gbWVhbiAmcXVvdDtwbGVhc2UgQUNLIG5vdyZxdW90Oy48YnI+DQomZ3Q7IEkg bWlnaHQgYmUgdXNlZnVsIGlmIHRoZSBzZW5kZXIgY2FuIHRyaWdnZXIgYW4gQUNLIGZvciB0aGlz IHBhcnRpY3VsYXIgcGFja2V0LDxicj4NCiZndDsgYnV0IGxlYXZlIHRoZSByYXRlIHVuY2hhbmdl ZC4gQW5kIGNoYW5nZSB0aGUgcmF0ZSBmcm9tIG5vdyBvbi48YnI+DQomZ3Q7IElmIHVzaW5nIGFu IG9wdGlvbiwgeW91IGNvdWxkIGVuY29kZSAmcXVvdDtzZW5kIGFuIGFjayBmb3IgdGhpcyBwYWNr ZXQsIGJ1dCBkb24ndDxicj4NCiZndDsgY2hhbmdlIHRoZSBhY2sgcmF0ZSZxdW90OyBieSB1c2lu ZyAwLCBhbmQgZW5jb2RlICZxdW90O2NoYW5nZSB0aGUgYWNrIHJhdGUgdG8gMSBmb3IgbiZxdW90 Ozxicj4NCiZndDsgYnkgdXNpbmcgbiwgbiAmZ3Q7IDAuPGJyPg0KPGJyPg0KWWVzLCB0aGF0IHNv dW5kcyBsaWtlIGEgdmVyeSBuaWNlIGlkZWEuPGJyPg0KPGJyPg0KYmVzdCw8YnI+DQpuZWFsPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQp0Y3BtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdD MDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MzOGZmM2QxZDg4YjI0NWQxOWEyYjA4ZDdlZWE4 ZWJlYSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcyNDAy ODIyMDY4OTYzNjMmYW1wO3NkYXRhPWxXM1c4T052WHcxTjAySmhBV09wVk00b0w2cjRKTElGVWNx UXh6WXUlMkZhMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR00MB01169B7713BDF863903AC6C8B6BE0BN3PR00MB0116namp_-- From nobody Tue May 12 12:54:34 2020 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 85D173A0A27 for ; Tue, 12 May 2020 12:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FW5Ht6G-T1j9 for ; Tue, 12 May 2020 12:54:31 -0700 (PDT) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 10A493A0A39 for ; Tue, 12 May 2020 12:54:30 -0700 (PDT) Received: by mail-ot1-f53.google.com with SMTP id d26so280080otc.7 for ; Tue, 12 May 2020 12:54:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=RO3mm+2wbVokKQtxHciPrKiaq/IxXtXtcUTAhdn288E=; b=IfNLHT+I0575k8jetbJqEhB2tGMTzaVHvq+aTZsQEHbVOmuiwdbMjJDNaDiaNxom/O WB6whrRT07fvEHQJxz/K41o465uZ4qtLe+aC3Y3iT4bFiUHnlfDfEUTlS9Suz7FMBo4Q TtBHNFCPAzRw5h1WMO/Mnxaje540G7ZCe1CsoPaAssJ4SDtGEm3nFFtm0EJXMCuijti8 4IwlHf8rHexLs43dZ6k0hZOwmKOaSnBKwkfbonNowGvMW+fu7Mf/mxaxkApvq4ObTW+n OMzpQJLuLlKq1FGJOQKcxpWp0JhjMjPSYB2Wt4/sf12zT0VTX1ek+yS+elFC4sY0yJ3o gEMg== X-Gm-Message-State: AGi0Pub9EzvQxC9n/R9cRXtni8p5MJyJr9x00PGcwpYta2zPq1XvtuUX UMm7n3csk2RHQMEEh1cPSPMQd0vlvV7WIw== X-Google-Smtp-Source: APiQypK+vjdl0MhkZgxDG8R3nzs3+LHLs3kjOWylefKsv2mgo0nJ6WA7DWWZ31MARtF4zccpv7ckKw== X-Received: by 2002:a05:6830:1082:: with SMTP id y2mr17571686oto.123.1589313269829; Tue, 12 May 2020 12:54:29 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:5901:392d:2787:d65b]) by smtp.gmail.com with ESMTPSA id l26sm1874706oos.43.2020.05.12.12.54.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2020 12:54:28 -0700 (PDT) From: "Mark Allman" To: Extensions Date: Tue, 12 May 2020 15:54:27 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_B60A6DD6-427C-4991-A9DC-4CF184882BA1_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: [tcpm] hystart++ -03 review 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, 12 May 2020 19:54:33 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_B60A6DD6-427C-4991-A9DC-4CF184882BA1_= Content-Type: text/plain I read version -03 of the HyStart++ document and my view differs from many, I guess. IMHO, this document is not ready for adoption. The draft is pretty anemic and I am not sure there is enough there to actually judge whether it is or is not a good idea. It seems like perhaps the document could get there, but at this point I think the authors have some work to do. Review below. allman Section 1: - Nit: RFC 793 does not define slow start, remove ref. (Could add a ref to original Jacobson paper.) - HyStart++ is "widely deployed", but is it widely used? Is it enabled or just there for the enabling? The document makes it sound like we have a lot of experience with this somehow, but none of that is shared (see below). - Nit: Spell out "LSS" on first use. Section 3: - Nit: Totally fine to crib the definitions from RFC 5681, but it'd be good form to note that is where they came from. - Nit: Also, since you use rwnd in one of the definitions and you're copying things, you might as well copy that one, too. Section 4: - There is so much unexplained magic in here. When setting RttThresh, what is magic about 1/8-th of the lastRoundMinRtt? Why clamp this between 4msec and 16msec? Would that really be reasonable for all networks? We need magic numbers sometimes and as long as they're resasonably chosen and motivated we have to live with having them around. But, the draft really needs to explain these choices, how they were made and how broadly applicable they might be. Further, the document suggests one MAY vary the constants, but it'd be great if it gave some sort of advice on how one might decide if different constants were OK or not OK. - The algorithm (series of equations) is here and clear. But, the document really needs to give us a flavor of the why. Talk us through what is happening and why in here, please. General / meta: - The draft offers a little intuition on why this is a good idea (i.e., to prevent massive slow start over-shoot). But, there is no sketch of evidence that shows it is effective. I see this was previously mentioned on the mailing list and Praveen said: We presented lab measurement data at the last IETF. We are in the process of doing some A/B experiments at scale with real world workloads. We did fairness comparisons in our lab measurements between Hystart and non-Hystart and we didn't see any problems. The bar ought to be higher than "didn't see any problems". It is great that there is some testing done and planned. I'd like to see this all sketched in the document itself. I am not even close to convinced that this is a good idea. - In some sense, this idea makes TCP more conservative (i.e., we stop exponential increase sooner than RFC5681 would suggest). So, the bar is likely not huge for saying this is "OK". But, I think we should have some notion that this helps *something* before agreeing to suggest it as somehow a reasonable thing to do in an RFC. Right now this document doesn't concretely show that HyStart++ is useful in any way. --=_MailMate_B60A6DD6-427C-4991-A9DC-4CF184882BA1_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXrr+8xEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizo4/AJ42BLV73K+4YhIMU7tGBtfRAb62zwCgj0hy Wj+NFiUjs1ox98S+j5HrqbI= =u/96 -----END PGP SIGNATURE----- --=_MailMate_B60A6DD6-427C-4991-A9DC-4CF184882BA1_=-- From nobody Wed May 13 05:00:52 2020 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 CCC793A10B3 for ; Wed, 13 May 2020 05:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b50iiveuVWJi for ; Wed, 13 May 2020 05:00:50 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 196873A10AE for ; Wed, 13 May 2020 05:00:49 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 04DC0c90048228; Wed, 13 May 2020 14:00:38 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 10C121D53C1; Wed, 13 May 2020 14:00:37 +0200 (CEST) Received: from 81.39.156.175 by webmail.entel.upc.edu with HTTP; Wed, 13 May 2020 14:00:37 +0200 Message-ID: <92538abd26cf9394cfc3e4b8f08a1f7e.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> Date: Wed, 13 May 2020 14:00:37 +0200 From: "Carles Gomez Montenegro" To: "Praveen Balasubramanian" Cc: "Matt Mathis" , "Neal Cardwell" , "Michael Tuexen" , "tcpm@ietf.org" , "Jon Crowcroft" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at violet X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 13 May 2020 14:00:39 +0200 (CEST) Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: On Sender Control of Delayed Acks in TCP 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, 13 May 2020 12:00:52 -0000 Hi Praveen, Thanks for your comments. Please find below some inline responses and comments: > I agree with the two use-case taxonomy. While it'd be quite nice to have a > single mechanism like a TCP option that addresses both use cases, there > are problems with a new option that's used in data packets: > > 1. middlebox traversal > > 2. hardware offloads like TSO and LRO might need updates? Indeed, our analysis in draft-gomez-tcpm-delack-suppr-reqs-01 shows that all potential solutions considered so far, including new TCP options, appear to have pros and cons. In order to evaluate solutions, I think the most critical part is determining what could be an acceptable trade-off among different goals or requirements. In this thread, several WG participants expressed a positive opinion about defining a new TCP option. (Although, as you mentioned, this approach also has drawbacks.) > If we go down the path of a new option for data packets that is broadly > deployed, should we aim for a list of key-value pairs so that it is > extensible? Capturing what Neal and Michael outlined, we might consider a new TCP option with the following format and intended functionality: Kind: TBD Length: 3 bytes Format: +---------+---------+---------+ |Kind=TBD |Length=3 | N | +---------+---------+---------+ 1 1 1 N=0 --> "Please, ACK now (but don't change the ACK rate)" N>0 --> "Change the ACK rate to 1 every N received data segments" Would the above (where the "N" field has a size of 1 byte) suffice, or would you still envision the need for a list of key-value pairs (or did you have a different approach in mind)? > Also, I recall there was some discussion about usage of PSH bit for ACK > pull. It’s already used for signaling message boundary, so an immediate > ACK upon end of message might also help lower latency. A problem that has been reported is that, when the PSH bit is set, it is not always desirable to trigger an ACK immediately: https://mailarchive.ietf.org/arch/msg/tcpm/seVEB4XAPjixXOPqfPea7zZAVmU/ Thanks, Carles > Thanks > > From: tcpm On Behalf Of Matt Mathis > Sent: Saturday, May 2, 2020 7:55 AM > To: Neal Cardwell > Cc: Michael Tuexen ; tcpm@ietf.org; Jon > Crowcroft > Subject: [EXTERNAL] Re: [tcpm] On Sender Control of Delayed Acks in TCP > > Another probably small opportunity would be to make the RTT estimators > less noisy, by having the receiver always ACK the first (or last) TSO > segment. The RTT is currently fuzzed by both del ACK and TCP strides. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > We must not tolerate intolerance; > however our response must be carefully measured: > too strong would be hypocritical and risks spiraling out of > control; > too weak risks being mistaken for tacit approval. > > > On Sat, May 2, 2020 at 7:35 AM Neal Cardwell > > > wrote: > On Sat, May 2, 2020 at 10:26 AM Michael Tuexen > > > wrote: >> >> > On 2. May 2020, at 16:10, Neal Cardwell >> > >> wrote: >> > >> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro > ..... >> >> [CG] It seems that there are two different areas where avoiding the >> >> typical Delayed ACKs approach may be of particular interest: i) >> scenarios >> >> where very small window sizes are used (cwnd=1), and ii) scenarios >> where >> >> large window sizes, and high ACK ratios, can be used. We will >> reflect >> >> these considerations in the next draft update. >> > >> > Yes, I wholeheartedly agree with Bob's point that it's also extremely >> > useful for TCP senders to be able to say things like: "I don't >> > particularly mind which packets you ACK, but there's no need to do it >> > more often than 1:16". QUIC has a mechanism like this, and it seems >> to >> > allow significant CPU savings, even allowing QUIC to run faster than >> > TCP in some cases, AFAICT due to the reduced overhead for handling >> > ACKs: >> > https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency >> > https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00 >> > >> > So I agree with the usefulness of the two-use-case taxonomy Carles has >> outlined: >> > >> > 1: "please ACK now"; because sender's cwnd is low >> > >> > 2: "ACK at frequency K"; because sender's cwnd is high >> > >> > It seems those could both be addressed cleanly with one or two TCP >> > option kinds. A single TCP option kind might suffice if the ACK >> > frequency of 0 or 1 is taken to mean "please ACK now". >> I might be useful if the sender can trigger an ACK for this particular >> packet, >> but leave the rate unchanged. And change the rate from now on. >> If using an option, you could encode "send an ack for this packet, but >> don't >> change the ack rate" by using 0, and encode "change the ack rate to 1 >> for n" >> by using n, n > 0. > > Yes, that sounds like a very nice idea. > > best, > neal From nobody Wed May 13 10:57:13 2020 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 BAD553A0045; Wed, 13 May 2020 10:57:07 -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.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158939262770.20482.3617979767286045@ietfa.amsl.com> Date: Wed, 13 May 2020 10:57:07 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-14.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: Wed, 13 May 2020 17:57:08 -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 : Requirements for Time-Based Loss Detection Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-14.txt Pages : 11 Date : 2020-05-13 Abstract: Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, protocols ultimately can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-14 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 13:02:05 2020 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 766503A08B9; Wed, 13 May 2020 13:02:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoshifumi Nishida via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Cc: tcpm@ietf.org, Yoshifumi Nishida , iesg-secretary@ietf.org, nsd.ietf@gmail.com, tcpm-chairs@ietf.org Message-ID: <158940012346.31620.4550999180514184414@ietfa.amsl.com> Date: Wed, 13 May 2020 13:02:03 -0700 Archived-At: Subject: [tcpm] Publication has been requested for draft-ietf-tcpm-rto-consider-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 20:02:04 -0000 Yoshifumi Nishida has requested publication of draft-ietf-tcpm-rto-consider-14 as Best Current Practice on behalf of the TCPM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ From nobody Wed May 13 14:40:25 2020 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 78FB03A0953; Wed, 13 May 2020 14:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 F8KeJ0oFHGmY; Wed, 13 May 2020 14:40:21 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE213A0952; Wed, 13 May 2020 14:40:16 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:4136:86f2:7b59:6ff0] (unknown [IPv6:2a02:8109:1140:c3d:4136:86f2:7b59:6ff0]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 5063A72243809; Wed, 13 May 2020 23:40:12 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_1DFB8561-7C6D-4296-BF6F-69F8AFEEBDC2"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Wed, 13 May 2020 23:40:11 +0200 Cc: draft-balasubramanian-tcpm-hystartplusplus@ietf.org To: tcpm IETF list X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 13 May 2020 21:40:24 -0000 --Apple-Mail=_1DFB8561-7C6D-4296-BF6F-69F8AFEEBDC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, this mail starts a WG adoption call for = https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03 The intended status would be PS. So I would like to solicit feedback regarding support for or objections = against the adoption of the document as a WG document in TCPM, if it hasn't been = already sent to the list. Please provide feedback before May 21st. Best regards Michael --Apple-Mail=_1DFB8561-7C6D-4296-BF6F-69F8AFEEBDC2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1 MTMyMTQwMTFaMC8GCSqGSIb3DQEJBDEiBCDnIdfuMvokNyVEpZ0GHfL2u9nH1AHqenMCv0/jnEBF WDCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAabAACQp/2jhEfnKeE5kYU3Mq2t8F g8H5KSGUOxOyc/9xuZ9If1xPV4eN7kg2k4bRk8FyxooJKnekioD3RFFGmIaMxEdOZZVzLyOxpucj uTagCPLrQsVmEoT8BGCukHvUOKToc53dxadwXKYPaLkqbT8IF3bKVND1HYNIrSdp6UkgSCdL0NET CquCSjv6tkEuUAMITFZE3jhpdKJ2xasG+ydGmssSo98hRHh8o3GFOzOU9UgSQB1PZNtP4piY068w L0A7HBkrglK/5ugCRA1Y1WrL/2SnTDjPa667M5fpnRdrB4PMIMQW1vrtvKqWnrrt//J6usZ2QwNu ZfH6u5XdMwAAAAAAAA== --Apple-Mail=_1DFB8561-7C6D-4296-BF6F-69F8AFEEBDC2-- From nobody Wed May 13 19:20:11 2020 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 9D8013A0929 for ; Wed, 13 May 2020 19:20:08 -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.130.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158942280863.25600.8118751967399197735@ietfa.amsl.com> Date: Wed, 13 May 2020 19:20:08 -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: Thu, 14 May 2020 02:20:09 -0000 Changed milestone "Submit document on Retransmission Timeout Considerations as Best Current Practice RFC", resolved as "Done", added draft-ietf-tcpm-rto-consider to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Thu May 14 01:06:35 2020 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 7A6393A044E; Thu, 14 May 2020 01:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 9KMtF-bEWQS8; Thu, 14 May 2020 01:06:31 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40055.outbound.protection.outlook.com [40.107.4.55]) (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 7A2E83A0443; Thu, 14 May 2020 01:06:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IHynY3DsMvnjxMULZ/TARMZv/ZwDeNwH63YCDK5lnzFaPnfb0BPhCfgc9CapzkWgZctpCGAf04pWpXSKjkdRwY9xiLjKZJS57fhvEX1gnSrkd4zAtV9uE+/ysoEnXOeeWYeFzq6yI//VcB5DwBF4oQh8hw6cXpFoJcKu3OS/zolG1kzxApv8pnGG2CeT/lEAqc9nRAJ+glvggzQw/2wkf+PeKuo9s12Ct4oHvxZkT5rX85C27OqaB6UiFjthMO3AcpQpne3S/MrSyZJTIcZAdCmeIvT7M5EnHIvSIhaI9dpl39RO+jSCMtFOhcu7BJ+xOlthaxOXvU9CtxD2fEA1+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K1rJPuqhV/VF3IxeCCOIpwXxXU0ibvE7IQdzgMu4/4Y=; b=dTmYkVsXosYJb/58wqRy/UxPsJOKf6ic7qNN/bWCa4Dc2DIbbHZR9AkIajJnGE3dxqS6cPLJUkLpfoJzTbbVIf2AjA/4BZdAo6vdyg5KadfH2QaHUGrO7W2rWROeT0WtrJSIh3UqgpCna5BCE5mAu2nyUGerZcaJ+//PutD9hjw6Rwh0v+EObwwPrWrYi4u2WAKVCKrdQwes8t1WSKJlnZhTlDTK7qcBMHfQGa8H8bBAgSHz324sEoWurFnTt6VGTql9Lz06qC6KjXmXdunE195UKtlplf0YrmeslJ5ZElLYWM5BHgaxaNjLG8wGMC68Sxd+JBhkLgxteBFVVMBuWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=K1rJPuqhV/VF3IxeCCOIpwXxXU0ibvE7IQdzgMu4/4Y=; b=PYg4V2J+HQIxXZPBU9ttybynECXrQJ2X3q9KNmpZ9Zbh6/5w4M76Zc9HeR3tbh3HNEbcfYwo/sc9vdnoUILU7/1iDJ+Z54PPGOtoDmk2H6VIuGzxavxjZRR5h+/VKPWO0VhM3Hf/SEjy/b1olYgLcnqbn/yJrYM9t3XjCZSLGXE= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (2603:10a6:208:75::30) by AM0PR07MB5956.eurprd07.prod.outlook.com (2603:10a6:208:10c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.13; Thu, 14 May 2020 08:06:28 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::d8e:b09e:d5be:3f89]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::d8e:b09e:d5be:3f89%7]) with mapi id 15.20.3000.016; Thu, 14 May 2020 08:06:28 +0000 From: Mirja Kuehlewind To: Michael Tuexen , tcpm IETF list CC: "draft-balasubramanian-tcpm-hystartplusplus@ietf.org" Thread-Topic: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 Thread-Index: AQHWKW8liSc525af+UKlDeLSejfuHainW8wA Date: Thu, 14 May 2020 08:06:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: fh-muenster.de; dkim=none (message not signed) header.d=none;fh-muenster.de; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e700:7a00:184f:f4f5:f7fc:bb9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 96462656-8bbe-4d0a-4026-08d7f7ddb4bf x-ms-traffictypediagnostic: AM0PR07MB5956: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JzCOgpFLxaoqDytZlXd36zFT3UI+4MVKPUmUUrFUKQ7h7SWQfLmxStfIo+VVrEfrY+gM/DBC/+ImGWYVUsT8DGCYQ4HZmyJ1+a69fYI5ccrBIA3oxFhmzspgzLnrSEIKBBoi56rXduQZa9PJXAbDUoOmZAWteNdJXOx3vY1BWBoMFjA8WFvLbd4Zw1Hi58MiDyhdVR7xTMdPXoDSQ1Y00TjQwjiJCg80VcPyZzQaFDDTEgcabYuQ3JjA3bUO5BbKt9R7rMSpMJzT6uNzVNXG9H1VVR6TLErfK3cY0LsdUxW55uRf5WNhIBN+jo7U9a93LBlPpP+GGNcyuWFJ61AE5hOTfUxyAyYMBaUuLTImORrGf17z3Kj4x2y/WYtW9AygNIdyrOgdbggMG+713/ej6pKq6x++vN8r33NLWYyTZ1D/LqKJ1pXjNFkpRE6bh95ztnxo5MA/gdD/KG9zyfnpTg0eujw8VGEnlN1fxUN6JZ7kT/J7E09Rgkabpd4Xh4nVxCphon9h+sSyW1Ld//nNLQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4691.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(136003)(346002)(376002)(396003)(4326008)(33656002)(316002)(71200400001)(4744005)(478600001)(2616005)(66476007)(76116006)(110136005)(966005)(66946007)(186003)(5660300002)(86362001)(66556008)(2906002)(8936002)(8676002)(44832011)(64756008)(6486002)(6506007)(6512007)(36756003)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: GcCY5ls2psgbTDAu6lqNcvw27oqkyo8kBXaDTKMsfPAHLEvIUvnf1BcOO1slX2ddfNWR83Hzg69Gk7yY3utAF3mn10LcHuQdBvBXHZbxqmbvEl0EJYLtPD17OYKv67G1fAUpIOkAIsE5rMbqolt4Y8Lrv95fyAw07Lsr/cnOkkAOTDRjZWIWOgO6pFpGSqxqawKMPvBVo5oz1oBCYc7O8yooJhhoHoxj2MunFT1REvGVHGPm4nm/tHhG3MD+JFfX8UCbOeEBDdFqZyOHcsiOTv8d72WGAkr059TvLPWbZzchk5c3Kl5xOgiH+eASRpIEioUKxU52R+svL/eU5aG9rA9PTPcNsbW1opsV7Ry1a86FHBbJ+WhtiiLSoiz1uACtRLw26CfNPZbwjK08ySddDbEVS0SY7yTPDgIox8liQ3FezE/wuJqvvqTqgUtOhs1ERnroTxGOmiONfxPAZEdWLw3xlnDcMoZtEvpTGQPYQGMzR/cNgohsv7mdcLoIE8z8MFp5Lzz85Wi8H1B4IYEap2ODaPrDEw0x/l0grKMpYtI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96462656-8bbe-4d0a-4026-08d7f7ddb4bf X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 08:06:28.6081 (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-CrossTenant-userprincipalname: Hh6tzeQ96+iIeUJ/zw7cykzvmu4RfjfLet2oLRDnGYfWFtKQRCcyyAfwwJNajkL3N8S3k4w4vLnXoFpcOorpFv3iapuCObvlTJ5B3S9zn2E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5956 Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 14 May 2020 08:06:34 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLg0KDQoNCu+7v09uIDEzLjA1LjIwLCAyMzo0MCwgInRjcG0gb24g YmVoYWxmIG9mIE1pY2hhZWwgVHVleGVuIiA8dGNwbS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiB0dWV4ZW5AZmgtbXVlbnN0ZXIuZGU+IHdyb3RlOg0KDQogICAgRGVhciBhbGwsDQoNCiAg ICB0aGlzIG1haWwgc3RhcnRzIGEgV0cgYWRvcHRpb24gY2FsbCBmb3INCiAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRjcG0taHlzdGFydHBsdXNw bHVzLTAzDQoNCiAgICBUaGUgaW50ZW5kZWQgc3RhdHVzIHdvdWxkIGJlIFBTLg0KDQogICAgU28g SSB3b3VsZCBsaWtlIHRvIHNvbGljaXQgZmVlZGJhY2sgcmVnYXJkaW5nIHN1cHBvcnQgZm9yIG9y IG9iamVjdGlvbnMgYWdhaW5zdCB0aGUNCiAgICBhZG9wdGlvbiBvZiB0aGUgZG9jdW1lbnQgYXMg YSBXRyBkb2N1bWVudCBpbiBUQ1BNLCBpZiBpdCBoYXNuJ3QgYmVlbiBhbHJlYWR5IHNlbnQgdG8N CiAgICB0aGUgbGlzdC4NCg0KICAgIFBsZWFzZSBwcm92aWRlIGZlZWRiYWNrIGJlZm9yZSBNYXkg MjFzdC4NCg0KICAgIEJlc3QgcmVnYXJkcw0KICAgIE1pY2hhZWwNCg0K From nobody Thu May 14 05:06:28 2020 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 82F993A09B1 for ; Thu, 14 May 2020 05:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 18AprHPYK6ud for ; Thu, 14 May 2020 05:06:25 -0700 (PDT) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (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 BA4253A09AE for ; Thu, 14 May 2020 05:06:24 -0700 (PDT) Received: by mail-oi1-f181.google.com with SMTP id x7so23391891oic.3 for ; Thu, 14 May 2020 05:06:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=UjQkMaOcwzYJfxnvJZp+a2MkLNKVerDQPiaQHKDyZrc=; b=PRgU0i5qgl2wnuj5tp5zBKM4P3UT38w1GevvsCeCX9bqYBX7vpzOgcJNPDIn6zSISn op2asKikoVQirLqrc4hOUAuDIx62zsX0vsA89aUMuWJz5gWOoafqfP1RzzItWmka1dh8 9ilawvtmyxu14/aTrdmPrhYNqPO06ULqImf0j50pMceKm6+tNgMTxeQi6sxPezbFrslC pBngYNRzINuZRlRkBxaoEOLfrhVR/C8RrkkU2A5XcMxYiy+BtiaT8Wom3xsK+kZL8bxG +U2xR9jn/5OD6dwfae70z5QDX1DWtdZHRSCCJKnCKpjsvUKPQ2rkbuf0xN5GpDWZCgvY zbhA== X-Gm-Message-State: AGi0PuZy3TaYTDAtUHlrbHebh+smw3X+rii5AWBG0uJQsLJ1jTmWd5IG NT6Z/96GVZaK4Seih3++/mxArw== X-Google-Smtp-Source: APiQypLFdeJdwz2axq0DBwVwFptQ6c9Xaw/U9rEVZZR0LeCT+pA7KlnyFUiNoTrRj7ukLVbwlc8KfA== X-Received: by 2002:a05:6808:49:: with SMTP id v9mr29334971oic.41.1589457983230; Thu, 14 May 2020 05:06:23 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:dc6a:a02b:e93b:f2a8]) by smtp.gmail.com with ESMTPSA id f25sm742962ooj.20.2020.05.14.05.06.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2020 05:06:22 -0700 (PDT) From: "Mark Allman" To: "Michael Tuexen" Cc: "tcpm IETF list" , draft-balasubramanian-tcpm-hystartplusplus@ietf.org Date: Thu, 14 May 2020 08:06:21 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_B8D9E803-FBE0-434A-8070-6853632CBA17_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 14 May 2020 12:06:27 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_B8D9E803-FBE0-434A-8070-6853632CBA17_= Content-Type: text/plain > this mail starts a WG adoption call for > https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03 > > The intended status would be PS. Per note from the other day, I think this could get there, but the current document doesn't offer enough (any, really) motivation that suggests HyStart++ is useful or effective. Since I can't figure that out, I can't support the document for WG adoption at the moment (and especially so at PS). allman --=_MailMate_B8D9E803-FBE0-434A-8070-6853632CBA17_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXr00PREcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizm6nAJ0VxDXHIw5Qf02NFXhhe+awqQnv4gCfZsPo odE0u8eN1+AnIXm5RlEAHFM= =ThSC -----END PGP SIGNATURE----- --=_MailMate_B8D9E803-FBE0-434A-8070-6853632CBA17_=-- From nobody Thu May 14 08:14:10 2020 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 594413A0AC3 for ; Thu, 14 May 2020 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, 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 ruQvs7MJir4b for ; Thu, 14 May 2020 08:14:06 -0700 (PDT) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 50A913A0AD7 for ; Thu, 14 May 2020 08:14:06 -0700 (PDT) Received: by mail-vk1-xa34.google.com with SMTP id v23so848363vke.13 for ; Thu, 14 May 2020 08:14:06 -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=WccJAMZme9/f4DUcwDr6eztDOMfWiVCWRLuJ34uOeYw=; b=dXI6FWk0kaRzbZoCof3Z4BtdwqazWqJztFpt0uXiajm3C7lShPidtw1Rs86kY5ditq IKbO1g9k6mm8ZWRG8fu98zt9NdgjCVEXbpWV3qGPbj1Z8xn4SCjfXOKuQ97VfDPfsYuq n4ciLOQEme+pdbd2s9W4FKDkS4HMEJPfh4ESvXofDBY4V8S80W/7yH4sDOICB0uioeYI YgPuRSqrdee8XuoHPALz7kcF2BX6NHWyEzZAWCvQ+xpme2PJe2VzSOx8PMf1sIneUGJl k+nFoTnMGDhv0GFLpV3c7gDnqvy8kQKKo5g1xLxh2JrO8cxqr1cJumgqw8+FBqgZoJ+S 5Chw== 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=WccJAMZme9/f4DUcwDr6eztDOMfWiVCWRLuJ34uOeYw=; b=mb+09jTDIZterPCw3USk/l5ZOHd4ODPG99voxUl4YoNy71legmdciqHfeX0OLMVWYs DUFkljtFMEej3r/BUuQsBLfyJMYeGP2hdl2xOQwfP+JV69eQCt+5Cr7Snz3PdtN+d3eo d29JLgWNMpoAuDMKsoaBm2j4HtJlMAYGcT+Ia1JWHm5kh3oDGaoccZi89xA1bpEeiUJN W4G2xcTTsQq5tAobUkPh5eLtAobBQhki/VDmBpTuCr5I91AkCnvb1SzxlbNQ+oU1Wd+Z r05Y1w4aSoBFIuN0py7eR3Atk+5Cx6r1Tr8m5u8zNg+Rp1DyeN9PsrwHJhFhcbOqo1mv Wang== X-Gm-Message-State: AOAM532QFXNjklE/LaNIYFsyf6f+nhunQf8ManA0/qHZS4vX0ioUy3m3 vxL9qcxieosaVdanXQF3R5+wBJFaQa41C9yinId16w== X-Google-Smtp-Source: ABdhPJxs31Kkek3PWziLC5LvjoR2OjvVeFbmkRXPVAUvssSPycdAJ1+hRWB5pQAorIuZLRChBtTZKc0plMPsH14Wtvs= X-Received: by 2002:a1f:54c5:: with SMTP id i188mr2531792vkb.4.1589469244825; Thu, 14 May 2020 08:14:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Thu, 14 May 2020 11:13:47 -0400 Message-ID: To: Mark Allman Cc: Michael Tuexen , tcpm IETF list , draft-balasubramanian-tcpm-hystartplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 14 May 2020 15:14:08 -0000 "On Thu, May 14, 2020 at 8:06 AM Mark Allman wrote: > > > > this mail starts a WG adoption call for > > https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03 > > > > The intended status would be PS. > > Per note from the other day, I think this could get there, but the > current document doesn't offer enough (any, really) motivation that > suggests HyStart++ is useful or effective. Since I can't figure > that out, I can't support the document for WG adoption at the moment > (and especially so at PS). Fair enough. However, I would urge that these concerns be addressed in future editorial revisions, but that we not allow them to derail progress toward WG adoption working toward PS for draft-balasubramanian-tcpm-hystartplusplus-03. I would make several arguments for WG adoption, working toward the PS level, for draft-balasubramanian-tcpm-hystartplusplus-03: (1) From previous production experience with large-scale Internet services, our team has seen that Hystart is very important in reducing packet loss rates from new flows entering the public Internet. So Hystart is important and very useful on a technical level. (2) The original Hystart has already been ubiquitously deployed on the Internet for a decade, since it has been default-enabled in Linux TCP for a decade (as part of the default-enabled CUBIC congestion control module for Linux). Just as it was important, IMHO, to document the core CUBIC algorithm in RFC8312, I think it's important to document some version of Hystart as an RFC. (3) At an algorithmic level, I see several important improvements that Hystart++ makes over the original Hystart; at least: (a) using only the delay-based variant of Hystart, and not the ack-train-based variant of Hystart (the ack-train-based variant our team has also found is liable to false positives, especially with paced flows) (b) "mitigating poor performance which can result from false positives when HyStart is used alone", by ensuring that after triggering Hystart++, a connection increases its cwnd at least as fast as Limited Slow Start allows. (c) decoupling the delay-based algorithm from the global min_rtt of the connection, and instead using lastRoundMinRTT Presuming that multiple implementations or deployments can validate that these changes are indeed resulting in good performance, I think it would be good to document this improved version, Hystart++, rather than the 10-year-old original Hystart. (4) Yes, there are magic numbers in Hystart++, but (aside from the new LSS_DIVISOR) those other four magic numbers are all identical to the magic numbers in the Hystart code that has been doing a good job of improving performance for much of the traffic on the Internet for the last decade (see (2)). So the fact that the magic numbers are not discussed or justified is a point that can be cleared up in the editing process, and IMHO need not delay progress through the RFC process. I would argue that, like the constants used for SRTT and RTO calculations, in the future we could try to do more science to try other values and quantify the performance of the alternative values, but long-term experience has shown that these magic values work well enough in practice, and thus we do not need to bikeshed them now, and so we should not let the magicness of these numbers hold back their publication as a PS RFC. We should just document the rationale for each magic number in the RFC, and explain in the document that they have stood the test of time and wide deployment/use. Slides at the meetings can quantify the performance impact of alternative values. best regards, neal From nobody Thu May 14 08:24:59 2020 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 68A303A0B4C for ; Thu, 14 May 2020 08:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZvXZjlaD2at9 for ; Thu, 14 May 2020 08:24:54 -0700 (PDT) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (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 BD7A33A0B3B for ; Thu, 14 May 2020 08:24:51 -0700 (PDT) Received: by mail-oi1-f178.google.com with SMTP id a2so24661770oia.11 for ; Thu, 14 May 2020 08:24:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=qMcsPd8mb5KF/uNa29CNP9LuBu0TYrt9cynlk5IZlHg=; b=eAEuGjfw4SiZ1BY5ArCwJCyFCX1hArfZpgbj7DeXzzPHxtoVZYG1Fb7SwuRXAiYA8m TO9Cv4kb8TS5YCidG26qMgEtt9O+t1baSPPPFo9LcAEzORHCie/6HG8tMEmBUSkzMH19 lCYbZwhDZFAcfAN8kaZkc4mq59e4Wxu+dkoWfGWQOsX+ZZuUndcMtfaUo+jVRdA9fRln I6hBwz5xRDQpedyeaIyDqRgWYsgce/DRSKUVmwuS6xRwOqysvt7PIeRijSEZ/NBcC8sM MZ/t5vcu1MRTC1KxtlsfMXnjky5rBSah2AbYQuZji9Opw7e0RoSwnSjd4S6Y+HJFKUZ8 CX8Q== X-Gm-Message-State: AGi0PuZqOjDuR2o46C+o5+oSaFIeRdwi3R8VWnVlCqH/L9dZzFw8SgAI G2kNggD7gHNKlDUFKa+rUmmoUg== X-Google-Smtp-Source: APiQypL4FKfo3IU/Z+pnsepOTjHz5R3bqD8dBNw1AoqDK4s6pjBm16VRJj9nTC0QrOoly1u0k4/Fvw== X-Received: by 2002:aca:d06:: with SMTP id 6mr28865046oin.78.1589469890958; Thu, 14 May 2020 08:24:50 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:c05e:7082:6b2e:3f06]) by smtp.gmail.com with ESMTPSA id u13sm864968oor.45.2020.05.14.08.24.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2020 08:24:50 -0700 (PDT) From: "Mark Allman" To: "Neal Cardwell" Cc: "Michael Tuexen" , "tcpm IETF list" , draft-balasubramanian-tcpm-hystartplusplus@ietf.org Date: Thu, 14 May 2020 11:24:48 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <172F0536-8FEE-4F7E-AADA-19CF30077B8F@icir.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_60BD7769-27F9-4333-95E6-B51C6BB9E790_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 14 May 2020 15:24:58 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_60BD7769-27F9-4333-95E6-B51C6BB9E790_= Content-Type: text/plain Neal- Based on your note it seems that it should be straightforward to add solid motivation in the document. (And, hopefully your high-level notions of finding that it works well can readily be turned into objective statements.) So, why don't we just do that? > However, I would urge that these concerns be addressed in future > editorial revisions, My issue is that this is **not** editorial. There is simply nothing in the document that suggests it is a good idea. That fact is completely independent of whether it is or is not a good idea. It just means there is no basis to judge given in the document. We should expect some explanation of why this is reasonable before the WG is asked to adopt and work on something. IMHO. allman --=_MailMate_60BD7769-27F9-4333-95E6-B51C6BB9E790_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXr1iwBEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizkL6AKCC9h/vdskh8LsiTepD8iWozApEuwCgjlvn XVd3fKR9KrRiLLCDLoxO6TM= =fKW1 -----END PGP SIGNATURE----- --=_MailMate_60BD7769-27F9-4333-95E6-B51C6BB9E790_=-- From nobody Thu May 14 14:04:07 2020 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 481413A0D3D for ; Thu, 14 May 2020 14:04:04 -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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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=gmx.net 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 ovx9P1icXFzR for ; Thu, 14 May 2020 14:04:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 799CA3A0C7E for ; Thu, 14 May 2020 14:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589490237; bh=cyupPaqNS8f1qweih3or00D7YQ6nf8gQy48C4dsPqIE=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=BM9MfmpQyKupPFg0oPPKdF0JJGMgblGPELUFAugrQ8JfYTs1ufIZSIkUx/qYqYN26 lHvZtaZvRxXDdCcbXf6EcEMsHEM/ZOMfk8Q0sUOsExv0C3J+Bx2403genpIFEX3ofh 3H8BwMYvG5Qb1MbxWxvXyljfBbbso0f/7ggSn+Ss= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.249.66.142] ([217.70.211.12]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N5GE1-1j7T3p42fF-0117XP for ; Thu, 14 May 2020 23:03:57 +0200 To: tcpm@ietf.org References: From: "Scheffenegger, Richard" Message-ID: <68264f23-cd2a-6581-f129-e46812926a27@gmx.at> Date: Thu, 14 May 2020 23:03:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:3EiTF+R9HjheWvl0t8o/0U0ddnhAwpQn2aQgRvtZ4OkfvbMe403 0JMhjndkyBWhUOUW6+lydWgKxX7add2TyKx4SS+Dj8nn/tOFoZZjaEXuDoBWMUCSbzoSlzI pXCiI4/CgF6CLrXpM9jXzbJdqiCYI64WNDvirnonexl08KegHT/wfXmaOyMnDe/Q9bEoldH yGq8QMg/e/XWQ5N6hK4ow== X-UI-Out-Filterresults: notjunk:1;V03:K0:06gLx+gfsfs=:aGz1QtC6GJPrpyDftgBREe XexKrx0iYeIcBQ1UxYGGsGZPWT7fd+60U7HV1PEudxjV5YgYoLTvMHOC3sILCcAqe+cogo9Zt BOOKBRsI6WHlVRMH1Fvl959opI6O5ptzWXyZqvwVyD5HnEYXvymLU7yqc6a5XqzR8JuEy0IgM Z0En6azaM2uyNkJ4LjGN1rmDJ3f/nP3JvrKTU9jJ1vA0xy5DEkayi4KroNKaGKE8NzBGRYMuJ YU2l/A9MFYpxSzL4nvW3c/32w+RA2JwBjKs04EvXm38shCEJ5xXANbPlMNP64az+g6kvY7cRC KjD1YqkMO0C7dBNFefDqoTLSfdv6yEsSlQv1W4TjIZEkuzPR7jwWiq71d8H5BqUJfGOzxM4kM T+7TE7DYpVnPdmPXlf36b9q41oMNlARU8/0A3DKEHcRhp9WbD9iqDMTh7r9ajJ7qobvo9dfUJ 34FgmkrlvHiqeWGvy8V15pVL6YSi4cwA4phu+l0gdb0ciKLG5p2S+dOdEwGH1YxnYsSzxG0qw G+HoJw/Ph96ejFMyQjJee50Saij/t+1SneJeV6xmAv6QDCBG0bSN2JcY5HY82laBCm78szvok 64yhNoOmue7ymT9/WVKiM6HMgWhiRUdNm+vec9+O6uuNc0tsfjEce3BCdQdXQViaVDCg59XhK uDs6OsYjf9RICsqaDSzJh6389Kf8MNVmtmtu7d3aa6Ih3/bPx0SMrJQniuzR19j0luY3NJ7tD KVYQ63i0It0TxXmWwV3lOn1PHhyhT/eQ95vhjz+FweLCm2c0tOKjUzad2/sIcIJLQSO5qD4j3 As1mOWb55JTZaCYBYfVPBSu3mFFP13DZTg4S5SvLcPzpgvlyu06eocTDJaxnAcML07HoMFXWe uC4+xbuQr2Ge77aQMcL9yi/KKWpqu/XdWYdJQ5WdXsVyEIcS4gp45O98mIVYXzs1o3sBMODpG DgaLEyn5kawpuPJVewZwI+qLPVkDyU1DWwGgzCIgYJaEKhGFH5E2tb5urnxvn/TYmnBgwCMgz Fsmw+WAViQ+LtjOwDkwUlp1bBT/agPyrBsm2MUTpfu1MFv4Gj76HIc/5gNUpivfc2JD6K/9Cr cPnKMgWgDw1hxBnKjSZ3+RW0QkpLErg0YlaXQA2BrzzwDRqYgQWVojz5ITIf9FGinPFySH+xf slZHcaJJ/g+29FWRZ7yITE3YYVX1tUVsoV+1BE9ZHtuvwKaxEOxSl0eme8Vc+5FllWiULsiv7 bG66OPR7karhmWp9o Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 14 May 2020 21:04:06 -0000 I would like to see this work adopted. Am 13.05.2020 um 23:40 schrieb Michael Tuexen: > Dear all, > > this mail starts a WG adoption call for > https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-0= 3 > > The intended status would be PS. > > So I would like to solicit feedback regarding support for or objections = against the > adoption of the document as a WG document in TCPM, if it hasn't been alr= eady sent to > the list. > > Please provide feedback before May 21st. > > Best regards > Michael > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu May 14 19:21:28 2020 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 DE18D3A044F; Thu, 14 May 2020 19:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 vZJrj-ShC3tr; Thu, 14 May 2020 19:21:23 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982283A044E; Thu, 14 May 2020 19:21:23 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 04F2LJWP084222; Thu, 14 May 2020 19:21:19 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net) Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 04F2LIme084221; Thu, 14 May 2020 19:21:18 -0700 (PDT) (envelope-from ietf) From: "Rodney W. Grimes" Message-Id: <202005150221.04F2LIme084221@gndrsh.dnsmgr.net> In-Reply-To: To: Michael Tuexen Date: Thu, 14 May 2020 19:21:18 -0700 (PDT) CC: tcpm IETF list , draft-balasubramanian-tcpm-hystartplusplus@ietf.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 15 May 2020 02:21:26 -0000 Dear tcpm'ers, I have read the 03 version of this draft, and support this draft being adopted by the WG. I however believe this work should be consider only a starting point for formalizing hystartplusplus, for one the description seems to ignore ECN (RFC3168) and refers to drops or loss, though I believe the implementation actually does react to a CE. I am also concerned as a "Proposed Standard" it has the text indicated one can "experiment" with magic constants, that would be fine for an experimental track, but I do not feel comfortable with that text in a PS. If these constants are not well defined perhaps this should be an experiment. Regards, Rod Grimes > Dear all, > > this mail starts a WG adoption call for > https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03 > > The intended status would be PS. > > So I would like to solicit feedback regarding support for or objections against the > adoption of the document as a WG document in TCPM, if it hasn't been already sent to > the list. > > Please provide feedback before May 21st. > > Best regards > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Rod Grimes rgrimes@freebsd.org From nobody Fri May 15 02:15:34 2020 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 1D4A03A07A8; Fri, 15 May 2020 02:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 ly_VKiy_F33u; Fri, 15 May 2020 02:15:29 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2066.outbound.protection.outlook.com [40.107.20.66]) (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 2B17C3A07A4; Fri, 15 May 2020 02:15:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZKS7ukGeH9WYqseHWkTcnGmHOi1z50g61cWnFpxtOYuQdLwaYxEc5CY479Qgaz6NMt2Nw5pJOv2HG4fMr4w5qfmrLFh2dW/XDbCcJ9zylRW4dDQ+K5aR0EZRmlKkcON95gQwD0Z6grgP23xzQ9MQ1ZtJEsmDtcCj2XIg96xs7QYck+zrxxymSXliAe6Dg/jpyMMHGJrcDw2vRfpcyJN+YK8vU4EcMx2OZWznyB1VX1PuhL1PrKM8o5uqpu2WPBvC/v2LceCQejXWTIBJAnVgccfdL4OO5x1rf2MCrHozeVmpjuiZYCsIdXpPdnzWsvChLyZhQP3ehpsU/OIwv8Uqgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mznJKhr/QDpVjIbFH9+M3Dr4oU4YTLLs0FV7m3Iab/0=; b=Dom2/X32PfaBPYyDOvg0tKfuX3P97LZB5noQs7gHURQIV5vZ/LyKA+s94iOOhof2AbFs5mmVpL4G9eZKvv/jit4+OtPyC+eyddHfmtj6qUb2BigDb5MQr0tn1N+FpROzjvXYycAZXTpGq8iXAZLuO0QxExxP5LaLm9AKii1qS1kPV8q46VGda4+E4Kr4GElIzeti/Q7JgSfg4762hbj2hXJHCnQHpp7lLtD/khxLYUPkXoOnnCbLGRw990fiU9tkoUo9AHsPjjdX1lvbCH9djFpOPZTm09HjvqAl7Dw006IvxgLfIKYGR4TvUd+OHd4uMON1EaTWHZWCIXaFEbR/CA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=mznJKhr/QDpVjIbFH9+M3Dr4oU4YTLLs0FV7m3Iab/0=; b=iRArX9JdseXGhnnnSuRvJPesU0zo4JiK5JQ2HxyWCFg1wqSzW+ssLr0DX1xYehGA04NTBtwG5zbugztcNXhZ70k+udsVo+Gmti2F/b9mFImJVzGur1UCOVhc1JfZOpIVr7F82Ha6/lGAJfSYL4VcAnzsueqd1v0h4qwzvrGFs3A= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (2603:10a6:208:75::30) by AM0PR07MB4353.eurprd07.prod.outlook.com (2603:10a6:208:bb::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.15; Fri, 15 May 2020 09:15:26 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::d8e:b09e:d5be:3f89]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::d8e:b09e:d5be:3f89%7]) with mapi id 15.20.3000.016; Fri, 15 May 2020 09:15:26 +0000 From: Mirja Kuehlewind To: Mark Allman , Neal Cardwell CC: tcpm IETF list , Michael Tuexen , "draft-balasubramanian-tcpm-hystartplusplus@ietf.org" Thread-Topic: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 Thread-Index: AQHWKW8liSc525af+UKlDeLSejfuHainfUuAgAA0XoCAAAMUAIABSbaA Date: Fri, 15 May 2020 09:15:26 +0000 Message-ID: References: <172F0536-8FEE-4F7E-AADA-19CF30077B8F@icir.org> In-Reply-To: <172F0536-8FEE-4F7E-AADA-19CF30077B8F@icir.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: icir.org; dkim=none (message not signed) header.d=none;icir.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e700:7a00:7497:d494:4392:d96] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0120ee99-316e-4193-6757-08d7f8b08199 x-ms-traffictypediagnostic: AM0PR07MB4353: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 04041A2886 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4JcFPKDGoWg6mRoXmeHzq0uKFwuaJLkeu7xo7QWhu0SCY1Ppnhnap8v/ztCzLApjyoHCxjW1KqrIBVf6yqVU2PXWmV+m2Ksmoc95pvXA2/34J9xJEh9NPB3+rkxithLSAFXBnYNdYmAwrG7R7MWAQPskeW16ShHBNeL8tm5Db3FBWry7OxnOqP2w0GD8kd1YCKylmhRgLlt47Kl84JWcR8xVPgyajMvekaNIqakGNEUcDI8NkjOX/b0e2muFWV1QUfNzT2GnvURlPqxO97MEXhiSS0n3gzaZnEew8UuQl3n/fuyJ4jREJLCmGO8Hr8Lv+WEGImKkLrYZxx33rFSmlaiaLypYezkNo50bE3J58t09F39BddVESINfBunSGP44SijtBDnTi1ejNf2WWuVYTQeFBpzdsjxDNzWqn9LfhbMoCA3oFCf9G5rUWnQZ3iHW x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4691.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(366004)(136003)(396003)(33656002)(6512007)(4326008)(44832011)(71200400001)(186003)(2906002)(6506007)(478600001)(66446008)(110136005)(316002)(8936002)(86362001)(6486002)(5660300002)(66556008)(54906003)(8676002)(66946007)(76116006)(66476007)(64756008)(2616005)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: F+MPTxS/6NG31R0pHIGXWqEB4CZNvN59FWkogqG9uLqGibLOGajz5coYaylIIeniXL2F5bhOybkZ+UCAVv22w31mN1KdBgwKSZehVUPohQryoHkWLIF8e1wIBIK5oBe4i0aWLkG9bl0Wr8G4KFd9Uc4ED6m+4cGNvW3KA3ywcPeiPPeLnxdkawoftEKu/BWO5tykqohoyHdQ0btEZYX1Rt2kV/+eOagUzck3SwqmStyovHbZ9KmDcjl+zdppKRtgIT/rr6wZEO9T3cMSHsI9O0IFnmOe/hoJeMmALr5m3Mdn+QD+j4mm3jYM5vwY45HLX/jMKuvHQnt4eSBDdqPpKr/TP8IaR2VbooU1Yz0UxwG5qYwed43Atg3rstbEnZplm8NxHB0UARC8Wn/O+qNIqCl3U9RI0qK/VpuTCZWoVrt7SABlftaOAmhbHmn9wlS+NW7uyx3oWljy1JiILbS2jgBUi+q+wVNz1Av0XZXVdPs1OsinIme1xPCw3yo4bATKSFAUpitlOQyqfiHmzJSY91D0KCeejj3UB2MMKytmY94= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0120ee99-316e-4193-6757-08d7f8b08199 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 09:15:26.7901 (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-CrossTenant-userprincipalname: Ns1rPSZwwqD7A3/LwYFe2kFZo/Pb1mMqfg4umEgYfLydDsBfzDmkotCEjnfez7PaNYKSbv/+ohwkp2OCCnK0h7lC8Ti4X6igX35dLFdvjnc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4353 Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 15 May 2020 09:15:33 -0000 SGkgTWFyaywNCg0KdGhpcyB3b3JrIGhhcyBiZWVuIHByZXNlbnRlZCBtdWx0aXBsZSB0aW1lIGlu IHRjcG0gd2hpY2ggYSBidW5jaCBvZiBtZWFzdXJlbWVudCBudW1iZXJzIG9mIHJlYWwgZGVwbG95 bWVudHMuIEkgcmVhbGx5IGRvbid0IHRoaW5rIHRoaXMgbWF0ZXJpYWwgc2hvdWxkIGVuZCB1cCBp biB0aGUgZHJhZnQuIFRoZSBkcmFmdCBwcm92aWRlcyB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUg bWVjaGFuaXNtIChwcmVmZXJhYmx5IGFzIGNvbXByZWhlbnNpdmUgYW5kIHNob3J0IGFzIHBvc3Np YmxlKS4gVGhlIElFVEYgcHJvY2VlZGluZ3MgcHJvdmlkZSB0aGUgcmVjb3JkIGZvciByZXN1bHRz IGFuZCBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uLg0KDQpNaXJqYQ0KIA0KDQrvu79PbiAxNC4wNS4y MCwgMTc6MjUsICJ0Y3BtIG9uIGJlaGFsZiBvZiBNYXJrIEFsbG1hbiIgPHRjcG0tYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWFsbG1hbkBpY2lyLm9yZz4gd3JvdGU6DQoNCg0KICAgIE5l YWwtDQoNCiAgICBCYXNlZCBvbiB5b3VyIG5vdGUgaXQgc2VlbXMgdGhhdCBpdCBzaG91bGQgYmUg c3RyYWlnaHRmb3J3YXJkIHRvIGFkZA0KICAgIHNvbGlkIG1vdGl2YXRpb24gaW4gdGhlIGRvY3Vt ZW50LiAgKEFuZCwgaG9wZWZ1bGx5IHlvdXIgaGlnaC1sZXZlbA0KICAgIG5vdGlvbnMgb2YgZmlu ZGluZyB0aGF0IGl0IHdvcmtzIHdlbGwgY2FuIHJlYWRpbHkgYmUgdHVybmVkIGludG8NCiAgICBv YmplY3RpdmUgc3RhdGVtZW50cy4pICBTbywgd2h5IGRvbid0IHdlIGp1c3QgZG8gdGhhdD8NCg0K ICAgID4gSG93ZXZlciwgSSB3b3VsZCB1cmdlIHRoYXQgdGhlc2UgY29uY2VybnMgYmUgYWRkcmVz c2VkIGluIGZ1dHVyZQ0KICAgID4gZWRpdG9yaWFsIHJldmlzaW9ucywNCg0KICAgIE15IGlzc3Vl IGlzIHRoYXQgdGhpcyBpcyAqKm5vdCoqIGVkaXRvcmlhbC4gIFRoZXJlIGlzIHNpbXBseSBub3Ro aW5nDQogICAgaW4gdGhlIGRvY3VtZW50IHRoYXQgc3VnZ2VzdHMgaXQgaXMgYSBnb29kIGlkZWEu ICBUaGF0IGZhY3QgaXMNCiAgICBjb21wbGV0ZWx5IGluZGVwZW5kZW50IG9mIHdoZXRoZXIgaXQg aXMgb3IgaXMgbm90IGEgZ29vZCBpZGVhLiAgSXQNCiAgICBqdXN0IG1lYW5zIHRoZXJlIGlzIG5v IGJhc2lzIHRvIGp1ZGdlIGdpdmVuIGluIHRoZSBkb2N1bWVudC4gIFdlDQogICAgc2hvdWxkIGV4 cGVjdCBzb21lIGV4cGxhbmF0aW9uIG9mIHdoeSB0aGlzIGlzIHJlYXNvbmFibGUgYmVmb3JlIHRo ZQ0KICAgIFdHIGlzIGFza2VkIHRvIGFkb3B0IGFuZCB3b3JrIG9uIHNvbWV0aGluZy4gIElNSE8u DQoNCiAgICBhbGxtYW4NCg0K From nobody Fri May 15 03:38:57 2020 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 5A2D33A08C7; Fri, 15 May 2020 03:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ysV4v8maWwGw; Fri, 15 May 2020 03:38:53 -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 EC1AE3A08C4; Fri, 15 May 2020 03:38:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 2D57A25A12; Fri, 15 May 2020 12:38:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1589539129; bh=VZEoKA4b0ZAzGIqAD7XniI59SRRbcTSiKtJQN5fy/vE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZpiD6ji34wL9Dc1csj6rxvCAK67V+j0FGZMYbBd++acb/zOFyrDuO3b3WqwClwOJp VGqvtlByGd23jz/0+uLLQleoaiWH66BUmaL5UYfueKYua+DcT9tMV/XaKJe3Ddd47g L6MQnxFOUsZg3WDZG9fW+6WsFHtY7fPnNA2YW4NI= 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 JQaglfUeTE1q; Fri, 15 May 2020 12:38:44 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 15 May 2020 12:38:44 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Fri, 15 May 2020 12:38:44 +0200 From: "Scharf, Michael" To: Mirja Kuehlewind , "Mark Allman" , Neal Cardwell CC: Michael Tuexen , tcpm IETF list , "draft-balasubramanian-tcpm-hystartplusplus@ietf.org" Thread-Topic: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 Thread-Index: AQHWKW8mKi2UyKe+o0yMHkHCu2sjfainW8OAgAA0X4CAAAMUAIABKyEAgAAyJIA= Date: Fri, 15 May 2020 10:38:44 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DBDEAFF@rznt8114.rznt.rzdir.fht-esslingen.de> References: <172F0536-8FEE-4F7E-AADA-19CF30077B8F@icir.org> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 15 May 2020 10:38:56 -0000 QSBkcmFmdCBjb3VsZCBhbHNvIGhhdmUgYW4gaW5mb3JtYXRpdmUgYXBwZW5kaXggb3IgYSBzaG9y dCBub24tbm9ybWF0aXZlIHNlY3Rpb24gd2l0aCBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uLg0KDQpG b3Igd2hhdCBpdCBpcyB3b3J0aCwgSSBkb24ndCBrbm93IGhvdyBtYW55IHJlYWRlcnMgb2YgYW55 IGV4aXN0aW5nIFJGQyBldmVuIGtub3cgdGhhdCB0aGUgSUVURiBoYXMgcHJvY2VlZGluZ3MuIElm IHBlb3BsZSBhcmUgZXhwZWN0ZWQgdG8gZmluZCBkYXRhIGluIHRoZSBJRVRGIHByb2NlZWRpbmdz LCBhIGRyYWZ0IHNob3VsZCBwcm9iYWJseSBpbmNsdWRlIHJlZmVyZW5jZXMsIElNSE8uDQoNCk1p Y2hhZWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0Y3BtIDx0Y3Bt LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaXJqYSBLdWVobGV3aW5kDQo+IFNlbnQ6 IEZyaWRheSwgTWF5IDE1LCAyMDIwIDExOjE1IEFNDQo+IFRvOiBNYXJrIEFsbG1hbiA8bWFsbG1h bkBpY2lyLm9yZz47IE5lYWwgQ2FyZHdlbGwNCj4gPG5jYXJkd2VsbEBnb29nbGUuY29tPg0KPiBD YzogTWljaGFlbCBUdWV4ZW4gPHR1ZXhlbkBmaC1tdWVuc3Rlci5kZT47IHRjcG0gSUVURiBsaXN0 DQo+IDx0Y3BtQGlldGYub3JnPjsgZHJhZnQtYmFsYXN1YnJhbWFuaWFuLXRjcG0taHlzdGFydHBs dXNwbHVzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gUmVxdWVzdCBmb3IgZmVlZGJh Y2sgb24gV0cgYWRvcHRpb24gb2YgZHJhZnQtDQo+IGJhbGFzdWJyYW1hbmlhbi10Y3BtLWh5c3Rh cnRwbHVzcGx1cy0wMw0KPiANCj4gSGkgTWFyaywNCj4gDQo+IHRoaXMgd29yayBoYXMgYmVlbiBw cmVzZW50ZWQgbXVsdGlwbGUgdGltZSBpbiB0Y3BtIHdoaWNoIGEgYnVuY2ggb2YNCj4gbWVhc3Vy ZW1lbnQgbnVtYmVycyBvZiByZWFsIGRlcGxveW1lbnRzLiBJIHJlYWxseSBkb24ndCB0aGluayB0 aGlzIG1hdGVyaWFsDQo+IHNob3VsZCBlbmQgdXAgaW4gdGhlIGRyYWZ0LiBUaGUgZHJhZnQgcHJv dmlkZXMgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlDQo+IG1lY2hhbmlzbSAocHJlZmVyYWJseSBh cyBjb21wcmVoZW5zaXZlIGFuZCBzaG9ydCBhcyBwb3NzaWJsZSkuIFRoZSBJRVRGDQo+IHByb2Nl ZWRpbmdzIHByb3ZpZGUgdGhlIHJlY29yZCBmb3IgcmVzdWx0cyBhbmQgYmFja2dyb3VuZCBpbmZv cm1hdGlvbi4NCj4gDQo+IE1pcmphDQo+IA0KPiANCj4g77u/T24gMTQuMDUuMjAsIDE3OjI1LCAi dGNwbSBvbiBiZWhhbGYgb2YgTWFyayBBbGxtYW4iIDx0Y3BtLQ0KPiBib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBtYWxsbWFuQGljaXIub3JnPiB3cm90ZToNCj4gDQo+IA0KPiAgICAgTmVh bC0NCj4gDQo+ICAgICBCYXNlZCBvbiB5b3VyIG5vdGUgaXQgc2VlbXMgdGhhdCBpdCBzaG91bGQg YmUgc3RyYWlnaHRmb3J3YXJkIHRvIGFkZA0KPiAgICAgc29saWQgbW90aXZhdGlvbiBpbiB0aGUg ZG9jdW1lbnQuICAoQW5kLCBob3BlZnVsbHkgeW91ciBoaWdoLWxldmVsDQo+ICAgICBub3Rpb25z IG9mIGZpbmRpbmcgdGhhdCBpdCB3b3JrcyB3ZWxsIGNhbiByZWFkaWx5IGJlIHR1cm5lZCBpbnRv DQo+ICAgICBvYmplY3RpdmUgc3RhdGVtZW50cy4pICBTbywgd2h5IGRvbid0IHdlIGp1c3QgZG8g dGhhdD8NCj4gDQo+ICAgICA+IEhvd2V2ZXIsIEkgd291bGQgdXJnZSB0aGF0IHRoZXNlIGNvbmNl cm5zIGJlIGFkZHJlc3NlZCBpbiBmdXR1cmUNCj4gICAgID4gZWRpdG9yaWFsIHJldmlzaW9ucywN Cj4gDQo+ICAgICBNeSBpc3N1ZSBpcyB0aGF0IHRoaXMgaXMgKipub3QqKiBlZGl0b3JpYWwuICBU aGVyZSBpcyBzaW1wbHkgbm90aGluZw0KPiAgICAgaW4gdGhlIGRvY3VtZW50IHRoYXQgc3VnZ2Vz dHMgaXQgaXMgYSBnb29kIGlkZWEuICBUaGF0IGZhY3QgaXMNCj4gICAgIGNvbXBsZXRlbHkgaW5k ZXBlbmRlbnQgb2Ygd2hldGhlciBpdCBpcyBvciBpcyBub3QgYSBnb29kIGlkZWEuICBJdA0KPiAg ICAganVzdCBtZWFucyB0aGVyZSBpcyBubyBiYXNpcyB0byBqdWRnZSBnaXZlbiBpbiB0aGUgZG9j dW1lbnQuICBXZQ0KPiAgICAgc2hvdWxkIGV4cGVjdCBzb21lIGV4cGxhbmF0aW9uIG9mIHdoeSB0 aGlzIGlzIHJlYXNvbmFibGUgYmVmb3JlIHRoZQ0KPiAgICAgV0cgaXMgYXNrZWQgdG8gYWRvcHQg YW5kIHdvcmsgb24gc29tZXRoaW5nLiAgSU1ITy4NCj4gDQo+ICAgICBhbGxtYW4NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFp bGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90Y3BtDQo= From nobody Fri May 15 06:26:32 2020 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 5BE6A3A09E4 for ; Fri, 15 May 2020 06:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 YCHrRP7qpH-b for ; Fri, 15 May 2020 06:26:28 -0700 (PDT) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (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 C20DE3A09E3 for ; Fri, 15 May 2020 06:26:28 -0700 (PDT) Received: by mail-ot1-f45.google.com with SMTP id 63so1858231oto.8 for ; Fri, 15 May 2020 06:26:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=MI064XBnP9C87oD+8b0TyKVadd8hxMZJpaTVjgQihL0=; b=r6rCzv9B7JZiKCqyC95Z+Z8iHXrBDfrKlXh/3wNqBQX+I3eud1b96lxO2GGb9gFdh/ t89iwASZNE4FHRYz0Ovi8ZJUmjXRFKkEukyJkWmJrvMVadx8PwR8IHtuXPOL/gzL+VGQ Oz11rNSDvd/K+lSKWPaoxQCpCn/nR7SJhCUgFEyq86vYp/kfm5YU2rASvfsjfUEo6tus zFdHLP3DCL3k4KBA7HyHWPcxEWeViCBmPU3V//LIZpUGJd9rYOMQp3oKMwOYcFfPUMOf aeV70zzSZHWplVQU+zFE0tJHi11WSTiI8ew2bIWHl0Kz34eEgphpl6X0jnH8eMd09I2o SEzA== X-Gm-Message-State: AOAM533rXbkZSaNfdtryvieGr4AAj05keerNZ6v6ClDbaIvnmI0TVV+x 2UNphDrzzj0I5rjSPabC2c22rg== X-Google-Smtp-Source: ABdhPJxKtUdaUfVkqROp356EHerPW0ewFup8ISlzGafrGKNReYtvkXYE6lRI5lGZvZhJqz7J3izdjA== X-Received: by 2002:a9d:1d03:: with SMTP id m3mr2062863otm.353.1589549187732; Fri, 15 May 2020 06:26:27 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:78:bd3e:1e27:437e]) by smtp.gmail.com with ESMTPSA id f14sm549882otl.62.2020.05.15.06.26.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2020 06:26:26 -0700 (PDT) From: "Mark Allman" To: "Mirja Kuehlewind" Cc: "Neal Cardwell" , "tcpm IETF list" , "Michael Tuexen" , draft-balasubramanian-tcpm-hystartplusplus@ietf.org Date: Fri, 15 May 2020 09:26:25 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <20DBA494-7858-4207-8E52-25D82A817B63@icir.org> In-Reply-To: References: <172F0536-8FEE-4F7E-AADA-19CF30077B8F@icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_AF5EE8AD-0D9F-45C0-876D-FECCBBE129E8_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 15 May 2020 13:26:31 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_AF5EE8AD-0D9F-45C0-876D-FECCBBE129E8_= Content-Type: text/plain > this work has been presented multiple time in tcpm which a bunch > of measurement numbers of real deployments. I really don't think > this material should end up in the draft. The draft provides the > specification of the mechanism (preferably as comprehensive and > short as possible). The IETF proceedings provide the record for > results and background information. I have never actually heard quite that framing before. I am not looking for a research paper here. But, some sketch of why this has been found to be reasonable, that the draft is just documenting existing practice, etc. would seem required to me. And, incorporating a comprehensive set of references for more and deeper information is fine. The substantive reference in this draft is from over a decade ago (yes, "the" because there is only one). I am not the sharpest knife in the drawer, but I would never think to go dig through the IETF proceedings to try to find such. Not that it might not be there, just that that would be a long slog without a reference. I also bristle somewhat at this notion that our job is just to give the "what" and not the "why". I know we are much better at the former. And, I know I have been guilty of too little of the latter at times. I know this because I have seen new folks read these RFCs and not understand why something was done. Or, that something is important for some unstated, but crucial reason. Or, decide that we do X because of Y and so if Y is different then X can be, too---even though we did X because of Z and just didn't say it well. I am clearly not consensus, but to me the adoption question is completely premature when the document doesn't offer motivation that it is reasonable (beyond an intuitive hand wave that we're preventing slow start overshoot). Neal's note does sketch out why this might be an OK thing to do. And, probably IETF talks have, as well. But, some of that motivation has to make it into the document, it seems to me. allman --=_MailMate_AF5EE8AD-0D9F-45C0-876D-FECCBBE129E8_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXr6YgREcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizm0dAKCLOmdcD/Uv4cVCxeDly6vubIwA0QCdGcJX wWnOFXE0bKypGXSkP7Gtf3I= =AgyU -----END PGP SIGNATURE----- --=_MailMate_AF5EE8AD-0D9F-45C0-876D-FECCBBE129E8_=-- From nobody Fri May 15 08:08:00 2020 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 7E7233A0A8C for ; Fri, 15 May 2020 08:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umZ8fbbOIFTP for ; Fri, 15 May 2020 08:07:57 -0700 (PDT) Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (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 2495F3A07BE for ; Fri, 15 May 2020 08:07:57 -0700 (PDT) Received: by mail-oo1-xc30.google.com with SMTP id r1so500874oog.7 for ; Fri, 15 May 2020 08:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wX9FQGOxduiEKE0AD+/oqnsg8mr4Hscru4aFQ6WQcOg=; b=SDk+I6gHxXxriVLfpDH2DMQSkZB6mhotb+IiuAESjnUuTlRT46sd1606hVgDXCBtW5 ZS8GkoBq/PHn6MuVykOFjG7EXYQxT/uFEnxei1waKzUAsvhAIkSupHoHtpiqFu/9Lz7F 13aicQkNDZnw5gBuPSsSUXs5290vo6kGfqDhTjkkKsdoeSTKSgU+gBHIgn+rsTiPqTQZ rChz4uHpWfYnIqYsYWAkGMOoyHaT5y8G5ZqcNBIuZQmY/RYKNrLcLwQ6G6oskWBPAvLU BjHDPHrCufMq0dMVCLwaMtLyptPV0sQa0XpAQoLxU5FjFugVZ0NCMaR/ji9GuZ+ugndi YD/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wX9FQGOxduiEKE0AD+/oqnsg8mr4Hscru4aFQ6WQcOg=; b=Tl+Tf6T5hq3kSdRK9JAofBU1DpUSBbSlpDqkyv9GjJraBe3TfMmZWr2X1RbWrL2Fvr cFSgKEGPGHovPr7ImdFZPl/48iA+suSqVWflCMr1SCUefdH9EI/ABMFnOeodzayT5OG4 jRdMf1DwqfGv/b7BLALB0dfviOGNChc6Rmba97o0FWdGGuwr83+gkDPCh7947OHEtcdk dH0lHb4RNVGs2YusDexnGNEcRGmjFr2Dt6tng/DlfycFlGvGd664KhsaThmCDdRAWrTn TRu0B4pAu9SsZUQpZ2cJXGVnbeXRPO7bUJH4US6s2R2vFs18n9YrU4d2VS9eRnYYrE6a Z/eA== X-Gm-Message-State: AOAM532LMn/HNE3b+kHQjaewk4l5NchzgO9SLt5dtpbR2QLbNrw+XIXD kxASZUFwsfGE8I7PDJlppcL0EEFJ87aydzzGucwFemX3 X-Google-Smtp-Source: ABdhPJyAiPjNgtZ647FUcBHPJ0751iLDfo+EZaDokra+utNJLAvrxMIIRyRaTS64wRsFvlHnmFRpI7S9GtuEh5oAP0A= X-Received: by 2002:a4a:956a:: with SMTP id n39mr2823947ooi.64.1589555276019; Fri, 15 May 2020 08:07:56 -0700 (PDT) MIME-Version: 1.0 From: Alexander Azimov Date: Fri, 15 May 2020 18:07:45 +0300 Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary="00000000000093fb6405a5b12d77" Archived-At: Subject: [tcpm] TCP Connection ID 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, 15 May 2020 15:07:59 -0000 --00000000000093fb6405a5b12d77 Content-Type: text/plain; charset="UTF-8" Dear WG, As you all know L3 LB is a common element of today's cloud infrastructure. Its original design was based on the connection state that maps backend IPs (real IPs) to connection. Recently there were several papers that were suggesting the move to the stateless L3 LB, where the state (connection id) becomes the property of connection and it kept at the client, so the L3 LB can work without keeping state for every connection. As far as I understand, for QUIC it becomes native with destination connection ID in its header. I've seen suggestions for getting this functionality in TCP by overloading the Timestamps option or even TCP SEQ - can't say that such design looks good for me. I wonder was there an attempt to add connection id in the TCP options, and if it was - why it wasn't successful? -- Best regards, Alexander Azimov --00000000000093fb6405a5b12d77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG,

As you all know L3 LB is a com= mon element of today's cloud infrastructure. Its original design was ba= sed on the connection state that maps backend IPs (real IPs) to connection.= Recently=C2=A0there were several papers that were suggesting the move to t= he stateless L3 LB, where the state (connection id) becomes the property of= connection and it kept at the client, so the L3 LB can work without keepin= g state for every connection. As far as I understand, for QUIC it becomes n= ative with destination connection ID in its header.

I've seen su= ggestions for getting this functionality=C2=A0in TCP by overloading the Tim= estamps option or even TCP SEQ - can't say that such design looks good = for me. I wonder was there an attempt to add connection id in the TCP optio= ns, and if it was - why it wasn't successful?
=

--
Best regards,
Alexander Azimo= v
--00000000000093fb6405a5b12d77-- From nobody Fri May 15 08:39:44 2020 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 89DD83A0AE8; Fri, 15 May 2020 08:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 PTvuArNIfIg3; Fri, 15 May 2020 08:39:40 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40042.outbound.protection.outlook.com [40.107.4.42]) (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 93CC43A0ADC; Fri, 15 May 2020 08:39:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XJbrt4A/It17G8yvCF4P4nH2/npX3TMR4wIpLxV58Va6VJp+JPVCg9AAHLmpAjBASSjEQU/CIs/UlqCfHtLZZfZQWkvrcy3eqP5VdweZ6j70L6yMVyfhXwnZggcRP8BIcrKAK4q6C/Ujt0FfYT2ZBgZhkUBH8aR+4GZ6mx69DDjl2pEpGmcmsB7VEW7gXj2zauTdfCZyyjaBjpsIb6U/Zuf0lDRgTYyQ1jOFFStsmeWwNT88L4JqyIaEUjJVL8EpnTdTvsMZKQ/sw/51gND5wM1M4tlW26irp5maOoM9Li/0vllzaNBQ7zYkcBkCt/CahqQYNNAGIEsT0QNXR0Xq+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l4gAlnBE1pDtF/uJz8YCH7L3XfIvQ3slZf4Al4HXFB0=; b=cSKwI/HBEiPfJzEdpIRsdCwA8c7Eo+EZ/cssdfPJc2TNAcFy9nLS5SZEoylYHvwRPIq/YONAxGzWv6lc40VRoyK1nwv71h9QwouolLus9u4iQ3RHDWHhQehVChTwQi5k3Cdk5RkSq7n3aVGVwIHQ8zUsptl0nmJzePBhsHf8i8VnXrIfVKVP/YIpElerWIiL/p8HGb6vrVyhae3Y2LzNFjXHSN+zi0nV5ADX1+8amU+g7Nojwn44XsRuBYdtQOyUbGeEWGGCIhYPQzPStIlc/PrZAm2h8GQ0n+L4WyXs8jCEE0kZ+hcsrfMNickQiu0hJcaeYmipYQsvZ7Yi7O8hgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=l4gAlnBE1pDtF/uJz8YCH7L3XfIvQ3slZf4Al4HXFB0=; b=XG3r+rlxXojhZV+nxvqVDF+FiuBx/9+6TS1W8NCiCFHrO53qbf604wLAxmfUwyIkn+MyTryyEraZL4HrVB1M+7NXYkwEfGLkDl00EkPPv8eAhgEdNG5dWhnFyLD3UwqASF9/qU3K8+gEJckjT2bZQ/B/1pXCuHiccZG6YhkbbCs= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (2603:10a6:208:75::30) by AM0PR07MB3921.eurprd07.prod.outlook.com (2603:10a6:208:42::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.11; Fri, 15 May 2020 15:39:37 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::d8e:b09e:d5be:3f89]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::d8e:b09e:d5be:3f89%7]) with mapi id 15.20.3000.016; Fri, 15 May 2020 15:39:37 +0000 From: Mirja Kuehlewind To: Mark Allman , "Scharf, Michael" CC: Neal Cardwell , tcpm IETF list , Michael Tuexen , "draft-balasubramanian-tcpm-hystartplusplus@ietf.org" Thread-Topic: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 Thread-Index: AQHWKW8liSc525af+UKlDeLSejfuHainfUuAgAA0XoCAAAMUAIABSbaAgAAni4CAAEa9AA== Date: Fri, 15 May 2020 15:39:37 +0000 Message-ID: References: <172F0536-8FEE-4F7E-AADA-19CF30077B8F@icir.org> <20DBA494-7858-4207-8E52-25D82A817B63@icir.org> In-Reply-To: <20DBA494-7858-4207-8E52-25D82A817B63@icir.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: icir.org; dkim=none (message not signed) header.d=none;icir.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e700:7a00:7497:d494:4392:d96] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 76cbb0e5-1f74-4ec6-8046-08d7f8e62cdf x-ms-traffictypediagnostic: AM0PR07MB3921: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04041A2886 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xGt8gtv73nI1mV/BtldbsKEotwNoSITLPnLMu4U1fwRSXpCG82pZYhW9x0HaH7eG/TVf4z4oX4yABl2qu+wsdpTBQBeOd5o1NBLeVmEZ5tuth7G9bR/JE79VuXFcdCUMpeGgqdcvQ32GyJfC/9FSqc9mAIftz+ZvX1VLcl0nRn+GSt3e3//iU0xOVDA+gMV5dGAhN4mX6c/gw7Sdc1KQraKe7oRBWk0rpjtLkI5v13+GLdGZUTnQzUwb/LzSuH0Kk8VcigymQ1h8wwETu+UkixjIa7uV7ueaKMMtVmvjtLgIIVSWdVxJx2DrbsXQbsMhKdHdAyeAJQnEpBjt5Gr+eQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4691.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(366004)(346002)(396003)(8676002)(8936002)(2906002)(54906003)(478600001)(186003)(33656002)(44832011)(5660300002)(86362001)(2616005)(110136005)(316002)(6506007)(6486002)(6512007)(4326008)(66446008)(64756008)(66476007)(66556008)(66946007)(76116006)(36756003)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AX616LHhX1aWRTnoI0wEnn5SJC0wrF0Y+84/Xxk0TyjfK0Xjtwa6XC3vGxTm14lF7JeTTQrH6REH7KlZr7p292HtAkvUTIHNLm5uGaEdoRusU+65ZWdmFlwdmoV30NQaWU4HfO1y7MzzkYaT3geKhVceaY4RlT64+yaNgVyISdeWk1Fire7vxozn1u/U+98rob2jBoSMTBvFtphZwPuHuKOZnZOuX56ttLT+Dp91BXdWjTDSfd/CgVTNWWDHK8V8vDqYsBS1qZqVcRemxxnOY/a9JQHD0rs8DconeE0IZAOiv0nU7TgcGRtR814OjrSvg+6SSBqfi9M0vSr42z+9bmMCyDC2iqOwHSluCDWmktug8n3Jvx3hieXDQnWOP+HvVkNZKVkIwUyU0o5PVhNGn1bjLf4/wbzVIqgTExZTGY88ZJx7ZWnuLrfMmRKVedok/NLRL+Zi6n1sobvDmHs8eopPWKBHXkfw13dg2JNXwGMhEwI/IOZMa8zHC40gsoZtGdqJi3qn5Zrj35+/as4Ll4AfK3UTaGxbzMLCZnScekk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6235AA550E66E747BD2C0DB7155EDD78@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 76cbb0e5-1f74-4ec6-8046-08d7f8e62cdf X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 15:39:37.4536 (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-CrossTenant-userprincipalname: VKedLQNoCvJPz3aIQMPxC4SvhUGAxjoOvnYZeq5yj4HsumZfh0CHKb/p6gmSy17P2Kfamsw2pqQ9nu0eppx+E9RchQPWe++8s6xizCWC+9I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3921 Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 15 May 2020 15:39:43 -0000 SGkgTWFyaywgIGFuZCBhbHNvIGhpIE1pY2hhZWwgKHJlcGx5aW5nIHRvIHlvdXIgbWFpbCBoZXJl IGFzIHdlbGwgYmFzaWNhbGx5KSwNCg0KSSBkaWRuJ3QgbWVhbnQgdG8gc2F5IHRoYXQgYSBkcmFm dCBjYW5ub3QgaGF2ZSBzdWNoIG1hdGVyaWFsIG9yIHRoYXQgcGVvcGxlIHRoYXQgcmVhZCB0aGlz IGRyYWZ0IGFmdGVyIGl0IGxlZnQgdGhlIHdvcmsgZ3JvdXBzIHNob3VsZCBkaWcgb3V0IHRoZSBw cm9jZWVkaW5nLiBCdXQgYXMgYWxzbyBpbmRpY2F0ZWQgYnkgTWljaGFlbCwgdGhpcyBraW5kIG9m IG1hdGVyaWFsIG1heSByYXRoZXIgYmUgcGFydCBvZiB0aGUgYXBwZW5kaXguIFRoZSBkcmFmdCBh bmQgZnV0dXJlIFJGQyBtdXN0IGVuc3VyZSB0aGF0IHRoZSBzcGVjIGlzIHVuZGVyc3RhbmRhYmxl IGFuZCBpbXBsZW1lbnRhYmxlLiAgDQoNCkF0IGFkb3B0aW9uIHRpbWUsIHllcywgd2UgYWxzbyBu ZWVkIHRvIHVuZGVyc3RhbmQgd2h5IHRoaXMgd29yayBpbiBuZWVkZWQgYW5kIHdoeSBpdCBtaWdo dCBiZSBiZW5lZmljaWFsLCBidXQgSSB0aGluayB3ZSBzaG91bGQgYmUgYWJsZSBpbiB0aGlzIGdy b3VwIHRvIGhhdmUgdGhpcyB1bmRlcnN0YW5kaW5nIGJhc2VkIG9uIHdoYXQgd2FzIHByZXNlbnRl ZCAoYW5kIGNhbiBiZSBmb3VuZCBpbiB0aGUgcHJvY2VlZGluZyBhbmQgYXQgbGVhc3Qgd2UgYWxs IGN1cnJlbnRseSB3b3JraW5nIGluIHRoaXMgZ3JvdXAgc2hvdWxkIGtub3cgaG93IHRvIGZpbmQg dGhlbSkuDQoNCkF0IGxlYXN0IEkgaGF2ZSBhIGdvb2QgZW5vdWdoIHVuZGVyc3RhbmRpbmcgdG8g YmUgYWJsZSB0byBzYXkgdGhhdCBJIHRoaW5rIHdlIGFzIGEgZ3JvdXAgc2hvdWxkIGZ1cnRoZXIg d29yayBvbiB0aGlzLCB3aXRoIHRoZSBnb2FsIHRvIHB1c2ggYW4gUkZDLiBGb3IgbXkgcG9pbnQg b2YgdmlldyB0aGF0J3MgYWxsIHRoYXQncyBuZWVkZWQgdG8gYWRvcHQgYSBkcmFmdCBhcyBhIHN0 YXJ0aW5nIHBvaW50IGZvciB0aGlzIHdvcmsuDQoNCk1pcmphDQoNCg0KDQoNCu+7v09uIDE1LjA1 LjIwLCAxNToyNiwgIk1hcmsgQWxsbWFuIiA8bWFsbG1hbkBpY2lyLm9yZz4gd3JvdGU6DQoNCg0K ICAgID4gdGhpcyB3b3JrIGhhcyBiZWVuIHByZXNlbnRlZCBtdWx0aXBsZSB0aW1lIGluIHRjcG0g d2hpY2ggYSBidW5jaA0KICAgID4gb2YgbWVhc3VyZW1lbnQgbnVtYmVycyBvZiByZWFsIGRlcGxv eW1lbnRzLiBJIHJlYWxseSBkb24ndCB0aGluaw0KICAgID4gdGhpcyBtYXRlcmlhbCBzaG91bGQg ZW5kIHVwIGluIHRoZSBkcmFmdC4gVGhlIGRyYWZ0IHByb3ZpZGVzIHRoZQ0KICAgID4gc3BlY2lm aWNhdGlvbiBvZiB0aGUgbWVjaGFuaXNtIChwcmVmZXJhYmx5IGFzIGNvbXByZWhlbnNpdmUgYW5k DQogICAgPiBzaG9ydCBhcyBwb3NzaWJsZSkuIFRoZSBJRVRGIHByb2NlZWRpbmdzIHByb3ZpZGUg dGhlIHJlY29yZCBmb3INCiAgICA+IHJlc3VsdHMgYW5kIGJhY2tncm91bmQgaW5mb3JtYXRpb24u DQoNCiAgICBJIGhhdmUgbmV2ZXIgYWN0dWFsbHkgaGVhcmQgcXVpdGUgdGhhdCBmcmFtaW5nIGJl Zm9yZS4NCg0KICAgIEkgYW0gbm90IGxvb2tpbmcgZm9yIGEgcmVzZWFyY2ggcGFwZXIgaGVyZS4g IEJ1dCwgc29tZSBza2V0Y2ggb2Ygd2h5DQogICAgdGhpcyBoYXMgYmVlbiBmb3VuZCB0byBiZSBy ZWFzb25hYmxlLCB0aGF0IHRoZSBkcmFmdCBpcyBqdXN0DQogICAgZG9jdW1lbnRpbmcgZXhpc3Rp bmcgcHJhY3RpY2UsIGV0Yy4gd291bGQgc2VlbSByZXF1aXJlZCB0byBtZS4NCg0KICAgIEFuZCwg aW5jb3Jwb3JhdGluZyBhIGNvbXByZWhlbnNpdmUgc2V0IG9mIHJlZmVyZW5jZXMgZm9yIG1vcmUg YW5kDQogICAgZGVlcGVyIGluZm9ybWF0aW9uIGlzIGZpbmUuICBUaGUgc3Vic3RhbnRpdmUgcmVm ZXJlbmNlIGluIHRoaXMgZHJhZnQNCiAgICBpcyBmcm9tIG92ZXIgYSBkZWNhZGUgYWdvICh5ZXMs ICJ0aGUiIGJlY2F1c2UgdGhlcmUgaXMgb25seSBvbmUpLiAgSQ0KICAgIGFtIG5vdCB0aGUgc2hh cnBlc3Qga25pZmUgaW4gdGhlIGRyYXdlciwgYnV0IEkgd291bGQgbmV2ZXIgdGhpbmsgdG8NCiAg ICBnbyBkaWcgdGhyb3VnaCB0aGUgSUVURiBwcm9jZWVkaW5ncyB0byB0cnkgdG8gZmluZCBzdWNo LiAgTm90IHRoYXQNCiAgICBpdCBtaWdodCBub3QgYmUgdGhlcmUsIGp1c3QgdGhhdCB0aGF0IHdv dWxkIGJlIGEgbG9uZyBzbG9nIHdpdGhvdXQgYQ0KICAgIHJlZmVyZW5jZS4NCg0KICAgIEkgYWxz byBicmlzdGxlIHNvbWV3aGF0IGF0IHRoaXMgbm90aW9uIHRoYXQgb3VyIGpvYiBpcyBqdXN0IHRv IGdpdmUNCiAgICB0aGUgIndoYXQiIGFuZCBub3QgdGhlICJ3aHkiLiAgSSBrbm93IHdlIGFyZSBt dWNoIGJldHRlciBhdCB0aGUNCiAgICBmb3JtZXIuICBBbmQsIEkga25vdyBJIGhhdmUgYmVlbiBn dWlsdHkgb2YgdG9vIGxpdHRsZSBvZiB0aGUgbGF0dGVyDQogICAgYXQgdGltZXMuICBJIGtub3cg dGhpcyBiZWNhdXNlIEkgaGF2ZSBzZWVuIG5ldyBmb2xrcyByZWFkIHRoZXNlIFJGQ3MNCiAgICBh bmQgbm90IHVuZGVyc3RhbmQgd2h5IHNvbWV0aGluZyB3YXMgZG9uZS4gIE9yLCB0aGF0IHNvbWV0 aGluZyBpcw0KICAgIGltcG9ydGFudCBmb3Igc29tZSB1bnN0YXRlZCwgYnV0IGNydWNpYWwgcmVh c29uLiAgT3IsIGRlY2lkZSB0aGF0IHdlDQogICAgZG8gWCBiZWNhdXNlIG9mIFkgYW5kIHNvIGlm IFkgaXMgZGlmZmVyZW50IHRoZW4gWCBjYW4gYmUsIHRvby0tLWV2ZW4NCiAgICB0aG91Z2ggd2Ug ZGlkIFggYmVjYXVzZSBvZiBaIGFuZCBqdXN0IGRpZG4ndCBzYXkgaXQgd2VsbC4NCg0KICAgIEkg YW0gY2xlYXJseSBub3QgY29uc2Vuc3VzLCBidXQgdG8gbWUgdGhlIGFkb3B0aW9uIHF1ZXN0aW9u IGlzDQogICAgY29tcGxldGVseSBwcmVtYXR1cmUgd2hlbiB0aGUgZG9jdW1lbnQgZG9lc24ndCBv ZmZlciBtb3RpdmF0aW9uIHRoYXQNCiAgICBpdCBpcyByZWFzb25hYmxlIChiZXlvbmQgYW4gaW50 dWl0aXZlIGhhbmQgd2F2ZSB0aGF0IHdlJ3JlDQogICAgcHJldmVudGluZyBzbG93IHN0YXJ0IG92 ZXJzaG9vdCkuICBOZWFsJ3Mgbm90ZSBkb2VzIHNrZXRjaCBvdXQgd2h5DQogICAgdGhpcyBtaWdo dCBiZSBhbiBPSyB0aGluZyB0byBkby4gIEFuZCwgcHJvYmFibHkgSUVURiB0YWxrcyBoYXZlLCBh cw0KICAgIHdlbGwuICBCdXQsIHNvbWUgb2YgdGhhdCBtb3RpdmF0aW9uIGhhcyB0byBtYWtlIGl0 IGludG8gdGhlDQogICAgZG9jdW1lbnQsIGl0IHNlZW1zIHRvIG1lLg0KDQogICAgYWxsbWFuDQoN Cg== From nobody Fri May 15 09:39:16 2020 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 7C02A3A0E5C for ; Fri, 15 May 2020 09:39:13 -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, SPF_HELO_NONE=0.001, 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=it.uc3m.es 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 6TREVU4JAkCR for ; Fri, 15 May 2020 09:39:11 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 A43CF3A0E15 for ; Fri, 15 May 2020 09:39:11 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id f134so2967059wmf.1 for ; Fri, 15 May 2020 09:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=ho8rr770JA0B7IRaJ7EQtX3ftiyA1Uz63aCM5fLH4+s=; b=R85L3xRspOi0tLCwJHY8TTNSj1sjm7BpDJgGMFAYtyEMAo6B07RWNRwlO2KZq6uE07 dp9EouOXcxScm7VNnHAwPwDEcRyMqohpiXA2BZ07J3DVNI3DSPIHEtKZRjxr0xIglJ8f xjdWdC4mZuz0q5yKVDzrN0Ucw58PvBJMjCR1N+7aty2skxi2en3kKRuk/Ud/nmWnDOv4 lJw3yYm25SCSqZ0uUIPFKEyREX+YmmPT3NVsPYW2N89SVMPwueu6pzyohvvpNABPYBCt sRUygyy7eG6Fi1fpkdE7urjCylFdVHYXA4uJtz0x4MO/0sHuC/ScE2FCKvlHxPDJjzpr raDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ho8rr770JA0B7IRaJ7EQtX3ftiyA1Uz63aCM5fLH4+s=; b=Q+UxaGOnU40w1bemN1EsyzHhitZInPVUbYrVERzt8BBzHb6+CGnjpr6rkRDVhIIYsV BMHfycfa20Y9afEv0fs4RfnpSGrBU7u/GEKEltBgj0WbyMVN2uh2aqmSdrAZJ7sW1qV0 JBlmJYY91OKYojVep2+NTmWml8z64h4qWMqo1YJ5WgV9Jw76TnW5aJCnd5qHJfffFer2 ph0kwOSGKrlVFM9eyKkAOlgOwiyvzlN4rpv3qt8Gx7VPfrMtVP13k5sxF2D6r3tHeQ8h mqfHoLUfGOK+G4hr0DWAnnBORSVBP0Js88R17QSWuW9mbcp+UnvEx7JfalOYWkjaoRcb OlEg== X-Gm-Message-State: AOAM533Dt7GLMfXKJ2eLYyEQ1MI1W+MeoIeyrEsDyD7MSsJUYvlsIaMe eJrRlYPE8lLSHGWNm+Ct78Q72q2uf2OtYA== X-Google-Smtp-Source: ABdhPJy1W1kdtA5vVSDKrPCswA2r3G71xMGc7YODUdyKkoe62vwdT85jwP8vBaEOkE18yuGn5IkocQ== X-Received: by 2002:a05:600c:22d6:: with SMTP id 22mr4836009wmg.121.1589560749104; Fri, 15 May 2020 09:39:09 -0700 (PDT) Received: from Macintosh-6.local (179.120.18.95.dynamic.jazztel.es. [95.18.120.179]) by smtp.gmail.com with ESMTPSA id r9sm4170089wmg.47.2020.05.15.09.39.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 May 2020 09:39:08 -0700 (PDT) To: tcpm@ietf.org References: From: marcelo bagnulo braun Message-ID: Date: Fri, 15 May 2020 18:39:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03 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, 15 May 2020 16:39:14 -0000 I support its adoption. El 13/5/20 a las 23:40, Michael Tuexen escribió: > Dear all, > > this mail starts a WG adoption call for > https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03 > > The intended status would be PS. > > So I would like to solicit feedback regarding support for or objections against the > adoption of the document as a WG document in TCPM, if it hasn't been already sent to > the list. > > Please provide feedback before May 21st. > > Best regards > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat May 16 20:39:11 2020 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 12EC53A0CEF for ; Sat, 16 May 2020 20:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] 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 g56bSfbA8RTB for ; Sat, 16 May 2020 20:39:07 -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 AFBB13A0CED for ; Sat, 16 May 2020 20:39:07 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Gry5HJBmg1E6W4OpNION5tOhXCqr7ih9mduhElRgs0A=; b=OqxVUmmylyJ+EQ/3Uo1el4SbT gXtczSkFMLn/cL0zs/S89s/xVEq5ELnEgWr1D4Vk0YoaSjfEbUtVWhZ2WR9FsLDTZC1+LlN5CBHOM xaFZYhI+ghlrPVwP65OkxeWgBntc859fsTJHljpKWeKTf1qurKurfnSDbjtas/TLMWlbGj+hUvcQx kJat8r1ysEvZuv/jol5JvT+HDJvoPpZrEe2tQ1/24yOKnrmQM0oZ8K/8mMvJd1C8Oh55guMRHJCXG jAEtfu8/uUJ0zW5lQ+i3XNZOL/BuJyZQc9p9EG/QEJ4kH09nkejT1AwTZ5PDdHRFK7qhgaBzgHurL MR05wAUUQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:62386 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jaA8h-002Yrp-GM; Sat, 16 May 2020 23:39:04 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_04A42C1A-ED56-4660-9209-40D05F714729" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Joseph Touch In-Reply-To: Date: Sat, 16 May 2020 20:38:58 -0700 Cc: tcpm@ietf.org Message-Id: <708EDB0A-3399-47A6-83DE-9A6E093F28BF@strayalpha.com> References: To: Alexander Azimov X-Mailer: Apple Mail (2.3608.80.23.2.2) 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] TCP Connection ID 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: Sun, 17 May 2020 03:39:09 -0000 --Apple-Mail=_04A42C1A-ED56-4660-9209-40D05F714729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii RFC7974 > On May 15, 2020, at 8:07 AM, Alexander Azimov = wrote: >=20 > Dear WG, >=20 > As you all know L3 LB is a common element of today's cloud = infrastructure. Its original design was based on the connection state = that maps backend IPs (real IPs) to connection. Recently there were = several papers that were suggesting the move to the stateless L3 LB, = where the state (connection id) becomes the property of connection and = it kept at the client, so the L3 LB can work without keeping state for = every connection. As far as I understand, for QUIC it becomes native = with destination connection ID in its header. >=20 > I've seen suggestions for getting this functionality in TCP by = overloading the Timestamps option or even TCP SEQ - can't say that such = design looks good for me. I wonder was there an attempt to add = connection id in the TCP options, and if it was - why it wasn't = successful? >=20 > --=20 > Best regards, > Alexander Azimov > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_04A42C1A-ED56-4660-9209-40D05F714729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
RFC7974


On May 15, 2020, at 8:07 AM, Alexander Azimov <a.e.azimov@gmail.com> wrote:

Dear WG,

As= you all know L3 LB is a common element of today's cloud infrastructure. = Its original design was based on the connection state that maps backend = IPs (real IPs) to connection. Recently there were several papers = that were suggesting the move to the stateless L3 LB, where the state = (connection id) becomes the property of connection and it kept at the = client, so the L3 LB can work without keeping state for every = connection. As far as I understand, for QUIC it becomes native with = destination connection ID in its header.

I've= seen suggestions for getting this functionality in TCP by = overloading the Timestamps option or even TCP SEQ - can't say that such = design looks good for me. I wonder was there an attempt to add = connection id in the TCP options, and if it was - why it wasn't = successful?

--
Best regards,
Alexander = Azimov
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_04A42C1A-ED56-4660-9209-40D05F714729-- From nobody Mon May 18 07:15:58 2020 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 D996F3A0064; Mon, 18 May 2020 07:15:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk CC: nsd.ietf@gmail.com, Yoshifumi Nishida , tcpm-chairs@ietf.org, tcpm@ietf.org, martin.h.duke@gmail.com, draft-ietf-tcpm-rto-consider@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158981133458.2481.15195759097492819350@ietfa.amsl.com> Date: Mon, 18 May 2020 07:15:34 -0700 Archived-At: Subject: [tcpm] Last Call: (Requirements for Time-Based Loss Detection) to Best Current Practice 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, 18 May 2020 14:15:35 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Requirements for Time-Based Loss Detection' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-06-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, protocols ultimately can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ No IPR declarations have been submitted directly on this I-D. From nobody Mon May 18 08:46:41 2020 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 EFC5F3A082A for ; Mon, 18 May 2020 08:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] 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 t--RiWhSAdvf for ; Mon, 18 May 2020 08:46:37 -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 EAD593A081B for ; Mon, 18 May 2020 08:46:37 -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:Cc:Date:In-Reply-To: From:Content-Type:Mime-Version:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3Tk2uW1iUm4FlczIdbrtZfaiEKJyzzogVF+aNACTB3w=; b=5eO+dBdBhde6C4swC4Mx5XzK0 LCf6fLzNtVlxjUXvRrZOhCkpGelcb1J3x3xdOHbSsz/TdE8upvlMW5e71UGeqTqJcLc/IzV1hnnOW 3kcp8sFQxW42bmhwvawo6PlaFSuaCIvGWNjC95h+6HRFIelIqj86qkg5K75urpp/sBvdXyn9C+YdA MVHJ8O6iUCzjYXmqjXiMsbaYJN8OwOW1JH58TCHVxXuSj7pKX0pyZrAXBenhYil42tYJfY1eKeaTw dryfrYmkEPEpN+4CNaKJlPJ7rNymuZZe1v8l2fwrMtZ9rv2DppQ7+5pXQNLVPTDosXQtCTeFh+tfI dl2l13kNA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52453 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jahyA-003uOh-UM; Mon, 18 May 2020 11:46:27 -0400 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F3D6FC3-2932-4586-A1DD-E8CD0D84790A" From: Joseph Touch X-Priority: 3 (Normal) In-Reply-To: <92538abd26cf9394cfc3e4b8f08a1f7e.squirrel@webmail.entel.upc.edu> Date: Mon, 18 May 2020 08:46:21 -0700 Cc: Praveen Balasubramanian , Neal Cardwell , Matt Mathis , "tcpm@ietf.org" , Jon Crowcroft , Michael Tuexen Message-Id: <4B1DC848-32F1-4BAF-9835-CC931C1F938C@strayalpha.com> References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu> <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu> <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de> <92538abd26cf9394cfc3e4b8f08a1f7e.squirrel@webmail.entel.upc.edu> To: Carles Gomez Montenegro X-Mailer: Apple Mail (2.3608.80.23.2.2) 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] [EXTERNAL] Re: On Sender Control of Delayed Acks in TCP 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, 18 May 2020 15:46:39 -0000 --Apple-Mail=_9F3D6FC3-2932-4586-A1DD-E8CD0D84790A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 13, 2020, at 5:00 AM, Carles Gomez Montenegro = wrote: >=20 > In this thread, several WG participants expressed a positive opinion = about > defining a new TCP option. (Although, as you mentioned, this approach = also > has drawbacks.) Why not start as defining an Experimental Option (with a corresponding = code point)? Joe= --Apple-Mail=_9F3D6FC3-2932-4586-A1DD-E8CD0D84790A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On May 13, 2020, at 5:00 AM, Carles Gomez Montenegro <carlesgo@entel.upc.edu> wrote:

In this thread, several WG = participants expressed a positive opinion about
defining a new TCP option. = (Although, as you mentioned, this approach also
has = drawbacks.)

Why not start as defining an Experimental Option (with a = corresponding code point)?

Joe
= --Apple-Mail=_9F3D6FC3-2932-4586-A1DD-E8CD0D84790A-- From nobody Wed May 20 01:29:19 2020 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 708DA3A3B68 for ; Wed, 20 May 2020 01:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSfYUC7t6NXF for ; Wed, 20 May 2020 01:29:16 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 3607D3A3B67 for ; Wed, 20 May 2020 01:29:16 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id v128so2212918oia.7 for ; Wed, 20 May 2020 01:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9LSMdBZxTNdHhiB4VT3+4llYUI7XmtWh3J28Plcvedg=; b=C05zmvCb81ZOSr92kQpzswxjbY8VtjLFekR4oVopRkOIGBmPIu6L7EdbYzKrY4k8V3 irF85CP5HJ20r5jrv8YiskmXvJpSVQJvyjUdwYzx7fomPxpVczkFOx5cfpfaXu1Yx2F+ +m5ue7ejnQdmEAOhPYrv4REYymCa9JDO+3PgIbhcJqZmbPvKSf6ibQ/SBZTjgO/n8x4O /YJ78BItTXWseW/XzEFfQ576IikjQ/apYXxtK9XTsdPkWfC1EfGHH4Od+KQmbVzb2Fjo 8FVJQ5NENWCUSEIecGhaf/ryGOREDlWKqzVXQcvwvDSkbAugsyZCFnKNOV8tRybz1FCK uuUg== 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=9LSMdBZxTNdHhiB4VT3+4llYUI7XmtWh3J28Plcvedg=; b=V7+jlSnhpWnHmz+Nyx8zEjn7eyqS8Onnb+XBXF7xe7umm8lrsIuGLwMIf2V/sOsklT mBp1lJ4MsFs+EaYRWI97iy2X1HMhIPCZNKin4jUKtWe7Xcqu2Bn6luARLQe5WFO0v/Kk JJ8NXwFgbiiCD/0JCC0S9Y8w6URUJTaquzOyd1np0QsRskrihMZibVz2KDJahk7BcTwH 7+/x8vszDE6oestcpPOZpdJ1Y6FfUCTUtFYmToiTGdgwfSXsSwSQTsjYxsItiUn5/ySq n8DzLb80MprG/A9xaUVRsUUppPkYHs+EmkB+C2sF4wgr1JYUQyKDd8uPhsW/lTjBhUho PAUA== X-Gm-Message-State: AOAM530PMVjeUetK3c7xfKEksJhwXcLG1B30xIsHVgwuY/jNRVBBCWac eepAbu3NVxmWwc4YEuQesJ+nnyPYLr9RQEVV/juy9g== X-Google-Smtp-Source: ABdhPJx6oIXL/4F3tdR8734KIxejFmImZ+VuIHFdm4x5zIsI4bK+v+xAEY/O/m3fXkVBVtKQJQsTLlrWKoTKlJMrgw8= X-Received: by 2002:aca:1e12:: with SMTP id m18mr2369510oic.128.1589963355070; Wed, 20 May 2020 01:29:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Wed, 20 May 2020 11:29:03 +0300 Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary="000000000000fc259105a610303f" Archived-At: Subject: Re: [tcpm] TCP Connection ID 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, 20 May 2020 08:29:18 -0000 --000000000000fc259105a610303f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear colleagues, I haven't got any reply which increases level my confusion. If there was no such proposal I will be glad to volunteer to write such a document. But if you believe that such functionality is not needed in TCP - I will be glad to learn your opinion in advance. =D0=BF=D1=82, 15 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 18:07, Alexander Az= imov : > Dear WG, > > As you all know L3 LB is a common element of today's cloud infrastructure= . > Its original design was based on the connection state that maps backend I= Ps > (real IPs) to connection. Recently there were several papers that were > suggesting the move to the stateless L3 LB, where the state (connection i= d) > becomes the property of connection and it kept at the client, so the L3 L= B > can work without keeping state for every connection. As far as I > understand, for QUIC it becomes native with destination connection ID in > its header. > > I've seen suggestions for getting this functionality in TCP by overloadin= g > the Timestamps option or even TCP SEQ - can't say that such design looks > good for me. I wonder was there an attempt to add connection id in the TC= P > options, and if it was - why it wasn't successful? > > -- > Best regards, > Alexander Azimov > --=20 Best regards, Alexander Azimov --000000000000fc259105a610303f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear colleagues,

I haven't got any = reply which increases level=C2=A0my confusion.=C2=A0

If there was no such proposal I will be glad to volunteer=C2=A0to write = such a document. But if you believe that such functionality is not needed i= n TCP - I will be glad to learn your opinion in=C2=A0advance.=C2=A0

=D0= =BF=D1=82, 15 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 18:07, Alexander Azimo= v <a.e.azimov@= gmail.com>:
Dear WG,

As you all know L3 LB is a = common element of today's cloud infrastructure. Its original design was= based on the connection state that maps backend IPs (real IPs) to connecti= on. Recently=C2=A0there were several papers that were suggesting the move t= o the stateless L3 LB, where the state (connection id) becomes the property= of connection and it kept at the client, so the L3 LB can work without kee= ping state for every connection. As far as I understand, for QUIC it become= s native with destination connection ID in its header.

I've seen= suggestions for getting this functionality=C2=A0in TCP by overloading the = Timestamps option or even TCP SEQ - can't say that such design looks go= od for me. I wonder was there an attempt to add connection id in the TCP op= tions, and if it was - why it wasn't successful?

--
Best regards,Alexander Azimov


--
Best regards,
Alexander Azimov
--000000000000fc259105a610303f-- From nobody Wed May 20 01:34:14 2020 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 5A1E63A3B6F for ; Wed, 20 May 2020 01:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1kKpDLwnY5e for ; Wed, 20 May 2020 01:34:11 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 10E443A3B6D for ; Wed, 20 May 2020 01:34:11 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id u16so12786lfl.8 for ; Wed, 20 May 2020 01:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7s7iOUP3CG3uXKEhs8y4NOpQPwrLs5zNqPW0uK9/zKA=; b=SGBkqg9TnQer60ZtZgkFtAbGU9/XY9upv1ooJccdC6PmVpl4DYjttk4ycJfHoMKe7P NLxmJM7aTvPgW5jZJBLJKIRcj4Ql3T5Uk+rjb9vG1zprURniyA/WXy8tMCeN1hp9Ldku Z9AhGxqlqAL8Z/pyYu8ecGrz3DK6RXtkIXEFZeniwgKxjZIn8LgguKOLVUN5wLouZfAB bhEiGIw5S5lmEIyvW9TfGqdqa4OnUrhGjlJusWFzv6dqnwaNQOeuAVMASlzDHAWxkI8h NRsUwwmYIQjyOXEftLhVPylDfA67ZOllltu5+EfFPcOpLDI7YxqGJ28r/HPMj4oQYJ2T XUDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7s7iOUP3CG3uXKEhs8y4NOpQPwrLs5zNqPW0uK9/zKA=; b=el8Sh6TCkz8nryWLOUUH2Q3EcV6IPeCOUfsOD6qJp0vodE12WS8PjxRkmwrtvlbBp1 3KFi7tPOzIKLTPIfybehOUI4b4G4zphPXPFNhINevj3eyGKW81fpgffJa/1tEOx7cRmN Gfcf/a5of4Ek5mLckLH7lBi8En/HVMzHHEvqVpjGCCS0+NFhJnkFVQXE/0nRPrpWIGSx U1E39sZkNvSbwOSp0rkc0n6XmMOi6DcDKqRzV76YL+IYbLgDDf5hnt+f4sGo9wRjNYAt 50sNJ86Kg1WROHZt/bvnLMenI23lfsApZeHQ4duyxhH4Cs/GxZUrMowBLGCr2bhn+2gu BDTw== X-Gm-Message-State: AOAM533YuxhQm/s1M43qTqiVoWAlckbH7eRrHD9NImISUBqkp/vdgr68 4VWA91QIsNBcHFVzcpl1fkk= X-Google-Smtp-Source: ABdhPJzT4TO5Rdot40UvjG18bkXYVhRhyFxqY+3Nx0CbAhag7aVOAfUSNXVSQY/Eq+bJM/4I+eyZIw== X-Received: by 2002:ac2:4c2d:: with SMTP id u13mr1886685lfq.197.1589963649414; Wed, 20 May 2020 01:34:09 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-235-192-nat-p.elisa-mobile.fi. [83.245.235.192]) by smtp.gmail.com with ESMTPSA id s4sm12120ljc.130.2020.05.20.01.34.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2020 01:34:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Jonathan Morton In-Reply-To: Date: Wed, 20 May 2020 11:34:07 +0300 Cc: tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alexander Azimov X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [tcpm] TCP Connection ID 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, 20 May 2020 08:34:12 -0000 > On 20 May, 2020, at 11:29 am, Alexander Azimov = wrote: >=20 > If there was no such proposal I will be glad to volunteer to write = such a document. But if you believe that such functionality is not = needed in TCP - I will be glad to learn your opinion in advance.=20 Joe Touch replied with a simple mention of RFC-7974. Did you not see = that? I would also point to the Flow ID field in the IPv6 header, which is = intended to carry this sort of information. - Jonathan Morton= From nobody Wed May 20 06:08:26 2020 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 59F223A0980 for ; Wed, 20 May 2020 06:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q315mQeCfx_T for ; Wed, 20 May 2020 06:08:23 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 1E0DD3A0969 for ; Wed, 20 May 2020 06:08:23 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id d191so2803703oib.12 for ; Wed, 20 May 2020 06:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2KNMfIbDvyVSyQsCq7eIch/rbJm6UdDFoalR8En5Rk8=; b=R3WF9Zat4nH72yWMaBeNwZvbS+WtElHhvGnXCaJYwgDruSZTMfagVjx0y6HMHhDbLf PTzzyUZc5Cei56vfLYpCK50VxnRKSz2u9jiJKsHf8bJ9s7X3h+e2E5IhxuRXEPwVYS08 VQIL5RrXmAbBEWSVxCUwb7jwE+uohhAqPNI+7bughWEtLOLpqgxl9DcHIBq7PFyOkQv/ Gl4RkxHL9KVccoykrSI8urcIR+fX08VhUg5Yhm083gCyuO+lv5ybNYVva8Adf4W8Wo2D 1Tr82aHyG/E5fCBlrgSgUEipGOGM4FQOekB5tOvT8icwkATcT7Y8UG+fcQxWxFmaHtB5 GEhw== 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=2KNMfIbDvyVSyQsCq7eIch/rbJm6UdDFoalR8En5Rk8=; b=WjD8AHglZ/CIDwHy1ZtxOUd2w3hiqemeGat6EniyYbjKsiTyNdRnN/dRnaYcDRP0FH BajaxiQchwx/8s0rBcXnU0VQBQETqbiCcAn+Sm3NcByVEHBedDqoSAVEkSTPC2BttjlP Qa8ZwtjPPCz806Ndgj9FxeMw9mzLsih05WNbKBiJ4nyfGp9Zawgl/qMvfFdanWwOUVyh IrSX3nWFGHTLSrlttZMiVKC7ZL6hKsEDnS30iDZaoy7F3ceneMGzYou5VNal6Z4zojG8 4W2bVUXqp8Q1dfL262ROlB97pokvXorNE4aZydJLyQ4+sZc8fDAQqLOW1i0x5A3EXGpI mJNg== X-Gm-Message-State: AOAM531Y10zAvjA882kP8Gzqecg3p3bZ4XO6YWQoT1j9++hM7ZxvlG0i RjWf3169RosyBKA+RjDLW+b4xP19HejFHswolWrLbhUL X-Google-Smtp-Source: ABdhPJx71g9x9crPYBFJNE/jQCQqt+Wh7cNjJV+Rn2iFr4mP/f+VK5lfB7/kWm2QhpUFQdjoHzlhlFCHt0EYhyGANFk= X-Received: by 2002:aca:6506:: with SMTP id m6mr3104582oim.75.1589980102232; Wed, 20 May 2020 06:08:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Wed, 20 May 2020 16:08:11 +0300 Message-ID: To: Jonathan Morton Cc: tcpm@ietf.org Content-Type: multipart/alternative; boundary="000000000000318db005a61417dc" Archived-At: Subject: Re: [tcpm] TCP Connection ID 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, 20 May 2020 13:08:25 -0000 --000000000000318db005a61417dc Content-Type: text/plain; charset="UTF-8" Hi all, The email from Joe got into the spam box, so I was able to find it only after your notice. Thank you. The Host Id presented in RFC7974 is a very different approach: it is client-side id generated at the moment of the SYN which should help to distinguish different hosts behind NAT. What I'm looking for is a connection id, generated at the server-side and sent back with a SYN/ACK, which is next mirrored by the client. It is not meant for host identification, but it can be used for connection identification by the middlebox under the same administrative control. And there is no need to have a 1:1 map id to a server, instead, each server should use randomized ids with encryption. And speaking about IPv6 Flow Label it's not working for IPv4 + it current implementation in Linux already has great use cases, so even in the world of IPv6 only I would prefer to keep it without overloading its functions. --000000000000318db005a61417dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

The email from=C2=A0Joe got int= o the spam box, so I was able to find it only after your notice. Thank you.=

The Host Id presented in RFC7974 is a very differ= ent approach: it is client-side id generated at the moment of the SYN which= should help to distinguish different hosts behind NAT.

<= /div>
What I'm looking for is a connection id, generated at the ser= ver-side and sent back with a SYN/ACK, which is next mirrored by the client= . It is not meant for host identification, but it can be used for connectio= n identification=C2=A0by the middlebox under the same administrative contro= l. And there is no need to have a 1:1 map id to a server, instead, each ser= ver should use randomized ids with encryption.

And= speaking about IPv6 Flow Label it's not working for IPv4=C2=A0+ it cur= rent implementation in Linux already has great use cases, so even in the wo= rld of IPv6 only I would prefer to keep it without=C2=A0overloading its fun= ctions.
--000000000000318db005a61417dc-- From nobody Wed May 20 06:51:05 2020 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 CEC3D3A09D3 for ; Wed, 20 May 2020 06:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 MSQYEsJAmjou for ; Wed, 20 May 2020 06:50:58 -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 824FA3A093C for ; Wed, 20 May 2020 06:50:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 3752F25A14; Wed, 20 May 2020 15:50:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1589982656; bh=6RPhthMb6Hxf9uIEz6o/HUXBXD82ZR1ht3traq+lmEc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=H5s25wCH9/lfQEyEQ9DC0z81zyXpCNC6s1hU4wanwmtI8jgNIQrL1GEctZssfT6QQ vzGleGiQc55EYNZgqDRsoQxw7e75ImlBRcDm+QUMYeR99ZU450QOzPNTvzQb3yq5Mh gLJ4OGHa7fdXCxQWaiiEvKbJBBCy46b2rRWO8LR8= 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 N48K5GTuImB9; Wed, 20 May 2020 15:50:52 +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; Wed, 20 May 2020 15:50:52 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 20 May 2020 15:50:52 +0200 From: "Scharf, Michael" To: Alexander Azimov , Jonathan Morton CC: "tcpm@ietf.org" Thread-Topic: [tcpm] TCP Connection ID Thread-Index: AQHWKsqs86rqHyR9cEi1zbGXKXlcIKiwilOAgAABaoCAAEyTgIAAKa2g Date: Wed, 20 May 2020 13:50:52 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DBFAC34@rznt8114.rznt.rzdir.fht-esslingen.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2DBFAC34rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] TCP Connection ID 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, 20 May 2020 13:51:01 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2DBFAC34rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleGFuZGVyLA0KDQpBcmUgeW91IGF3YXJlIG9mIFJGQyA3NDEzIChUQ1AgRmFzdCBPcGVu KT8NCg0KVGhlIHVzZSBjYXNlIGlzIGEgZGlmZmVyZW50LCBidXQgUkZDIDc0MTMgZGlzY3Vzc2Vz IGxvYWQgYmFsYW5jZXJzIGluIFNlY3Rpb24gNi4zLjQuDQoNCk1pY2hhZWwNCg0KRnJvbTogdGNw bSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWxleGFuZGVyIEF6aW1vdg0K U2VudDogV2VkbmVzZGF5LCBNYXkgMjAsIDIwMjAgMzowOCBQTQ0KVG86IEpvbmF0aGFuIE1vcnRv biA8Y2hyb21hdGl4OTlAZ21haWwuY29tPg0KQ2M6IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbdGNwbV0gVENQIENvbm5lY3Rpb24gSUQNCg0KSGkgYWxsLA0KDQpUaGUgZW1haWwgZnJvbSBK b2UgZ290IGludG8gdGhlIHNwYW0gYm94LCBzbyBJIHdhcyBhYmxlIHRvIGZpbmQgaXQgb25seSBh ZnRlciB5b3VyIG5vdGljZS4gVGhhbmsgeW91Lg0KDQpUaGUgSG9zdCBJZCBwcmVzZW50ZWQgaW4g UkZDNzk3NCBpcyBhIHZlcnkgZGlmZmVyZW50IGFwcHJvYWNoOiBpdCBpcyBjbGllbnQtc2lkZSBp ZCBnZW5lcmF0ZWQgYXQgdGhlIG1vbWVudCBvZiB0aGUgU1lOIHdoaWNoIHNob3VsZCBoZWxwIHRv IGRpc3Rpbmd1aXNoIGRpZmZlcmVudCBob3N0cyBiZWhpbmQgTkFULg0KDQpXaGF0IEknbSBsb29r aW5nIGZvciBpcyBhIGNvbm5lY3Rpb24gaWQsIGdlbmVyYXRlZCBhdCB0aGUgc2VydmVyLXNpZGUg YW5kIHNlbnQgYmFjayB3aXRoIGEgU1lOL0FDSywgd2hpY2ggaXMgbmV4dCBtaXJyb3JlZCBieSB0 aGUgY2xpZW50Li4gSXQgaXMgbm90IG1lYW50IGZvciBob3N0IGlkZW50aWZpY2F0aW9uLCBidXQg aXQgY2FuIGJlIHVzZWQgZm9yIGNvbm5lY3Rpb24gaWRlbnRpZmljYXRpb24gYnkgdGhlIG1pZGRs ZWJveCB1bmRlciB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sLiBBbmQgdGhlcmUgaXMg bm8gbmVlZCB0byBoYXZlIGEgMToxIG1hcCBpZCB0byBhIHNlcnZlciwgaW5zdGVhZCwgZWFjaCBz ZXJ2ZXIgc2hvdWxkIHVzZSByYW5kb21pemVkIGlkcyB3aXRoIGVuY3J5cHRpb24uDQoNCkFuZCBz cGVha2luZyBhYm91dCBJUHY2IEZsb3cgTGFiZWwgaXQncyBub3Qgd29ya2luZyBmb3IgSVB2NCAr IGl0IGN1cnJlbnQgaW1wbGVtZW50YXRpb24gaW4gTGludXggYWxyZWFkeSBoYXMgZ3JlYXQgdXNl IGNhc2VzLCBzbyBldmVuIGluIHRoZSB3b3JsZCBvZiBJUHY2IG9ubHkgSSB3b3VsZCBwcmVmZXIg dG8ga2VlcCBpdCB3aXRob3V0IG92ZXJsb2FkaW5nIGl0cyBmdW5jdGlvbnMuDQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2DBFAC34rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkUtTWFpbEZv cm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbGV4YW5kZXIsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFy ZSB5b3UgYXdhcmUgb2YgUkZDIDc0MTMgKFRDUCBGYXN0IE9wZW4pPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgdXNl IGNhc2UgaXMgYSBkaWZmZXJlbnQsIGJ1dCBSRkMgNzQxMyBkaXNjdXNzZXMgbG9hZCBiYWxhbmNl cnMgaW4gU2VjdGlvbiA2LjMuNC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IHRjcG0gJmx0O3RjcG0tYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QWxleGFuZGVyIEF6aW1vdjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSAyMCwgMjAy MCAzOjA4IFBNPGJyPg0KPGI+VG86PC9iPiBKb25hdGhhbiBNb3J0b24gJmx0O2Nocm9tYXRpeDk5 QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFt0Y3BtXSBUQ1AgQ29ubmVjdGlvbiBJRDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGVtYWlsIGZyb20mbmJzcDtKb2UgZ290IGludG8gdGhlIHNwYW0g Ym94LCBzbyBJIHdhcyBhYmxlIHRvIGZpbmQgaXQgb25seSBhZnRlciB5b3VyIG5vdGljZS4gVGhh bmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ VGhlIEhvc3QgSWQgcHJlc2VudGVkIGluIFJGQzc5NzQgaXMgYSB2ZXJ5IGRpZmZlcmVudCBhcHBy b2FjaDogaXQgaXMgY2xpZW50LXNpZGUgaWQgZ2VuZXJhdGVkIGF0IHRoZSBtb21lbnQgb2YgdGhl IFNZTiB3aGljaCBzaG91bGQgaGVscCB0byBkaXN0aW5ndWlzaCBkaWZmZXJlbnQgaG9zdHMgYmVo aW5kIE5BVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PldoYXQgSSdtIGxvb2tpbmcgZm9yIGlzIGEgY29ubmVjdGlvbiBpZCwgZ2VuZXJhdGVkIGF0IHRo ZSBzZXJ2ZXItc2lkZSBhbmQgc2VudCBiYWNrIHdpdGggYSBTWU4vQUNLLCB3aGljaCBpcyBuZXh0 IG1pcnJvcmVkIGJ5IHRoZSBjbGllbnQuLiBJdCBpcyBub3QgbWVhbnQgZm9yIGhvc3QgaWRlbnRp ZmljYXRpb24sIGJ1dCBpdCBjYW4gYmUgdXNlZCBmb3IgY29ubmVjdGlvbiBpZGVudGlmaWNhdGlv biZuYnNwO2J5DQogdGhlIG1pZGRsZWJveCB1bmRlciB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBj b250cm9sLiBBbmQgdGhlcmUgaXMgbm8gbmVlZCB0byBoYXZlIGEgMToxIG1hcCBpZCB0byBhIHNl cnZlciwgaW5zdGVhZCwgZWFjaCBzZXJ2ZXIgc2hvdWxkIHVzZSByYW5kb21pemVkIGlkcyB3aXRo IGVuY3J5cHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5BbmQgc3BlYWtpbmcgYWJvdXQgSVB2NiBGbG93IExhYmVsIGl0J3Mgbm90IHdvcmtpbmcg Zm9yIElQdjQmbmJzcDsmIzQzOyBpdCBjdXJyZW50IGltcGxlbWVudGF0aW9uIGluIExpbnV4IGFs cmVhZHkgaGFzIGdyZWF0IHVzZSBjYXNlcywgc28gZXZlbiBpbiB0aGUgd29ybGQgb2YgSVB2NiBv bmx5IEkgd291bGQgcHJlZmVyIHRvIGtlZXAgaXQgd2l0aG91dCZuYnNwO292ZXJsb2FkaW5nIGl0 cyBmdW5jdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2DBFAC34rznt8114rzntrzd_-- From nobody Wed May 20 10:32:09 2020 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 46EBE3A0B01 for ; Wed, 20 May 2020 10:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, MSGID_FROM_MTA_HEADER=0.001, MSGID_SHORT=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft3309700.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4WAQ5FismYN for ; Wed, 20 May 2020 10:32:05 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10hn2233.outbound.protection.outlook.com [52.100.155.233]) (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 728F93A0AFC for ; Wed, 20 May 2020 10:32:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jeu3oyRi+O7xbB20FypCWaWtXtnOcFwjvYpJPp5oZ6bdC3oo0GcsAuZtUJDm1tZTYNvmERiU01xzZehmwZSeT7XKMhM+UwMeTGENqcANkt0j/DKcJ9CS3n6AqKvqlTwpOXOlO54jSSFLfxl9enk1Xa8u9iQKfx4BlbKI0IqX1gPGbpAqLW9+TCXXS3giiyVT4sMji2CLKM28TZnRrOgbXeDOkOqxoPG+cytkssdQg8dyfjyxxyE0fBeIoBCMGKniA2J9TKHMzTzWCVd72++DziooYmee/w0WpAuxNhljUBM2G6myVzKg8Df9vckskcPV6Zgc7HfQWtyenSMJHXXfmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3LPCd7fQOyQRm2imIy5qUO697xRg0eR6z6RbPiWt6H4=; b=cvvgCVpkjnjSR11/kCC0dFL/hAgaYsk9Nh7OEvAjg3kABO4Ow+x76ttzAa8lk9Sw5Kk/J2fNqHK8q0dl3M0XQnWMuG02psmDYiVJmaOFhc6Rq7Xhpfi+RifwsPC12jzrfDIBTyrgWtvvzaPidyrXAQpCPQSYu8UZXhKFiaYYXNxye5MJqTq8MarpDGzz0+dYYjS1vb3BIrwr7aW1/QXJW4wq0NyN4SdeDy/GXwPdZZie5Ks4RyaMg4PfSw7Oa6T5aZMHqusignscaIFNX+jKVAPlMboqnEuqau4E6fmRb8FaJUWZkyns+eqeW5YbNP18u9SYwPmoy0aA8YMfK1cunw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=asomi.com; dmarc=pass action=none header.from=asomi.com; dkim=pass header.d=asomi.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT3309700.onmicrosoft.com; s=selector2-NETORGFT3309700-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3LPCd7fQOyQRm2imIy5qUO697xRg0eR6z6RbPiWt6H4=; b=r1hMngdfzRW87qp58DgOkrhXWx0HkuXEw5tPe7/p8eYzdkWPTnCjx01IKFt7eYcfcevmzQLVd/kkYEIWlSv++aGiHIbl0nSb8WiTmeGqxFdASt+YebUV930uTYIVGKXRKqLyhswVIUB1BhE8tG6tF1js09zAfe7HnmZYalCwoDk= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=asomi.com; Received: from SN6PR11MB3005.namprd11.prod.outlook.com (2603:10b6:805:d3::17) by SN6PR11MB2671.namprd11.prod.outlook.com (2603:10b6:805:60::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Wed, 20 May 2020 17:32:02 +0000 Received: from SN6PR11MB3005.namprd11.prod.outlook.com ([fe80::6522:bb06:f6d:4ede]) by SN6PR11MB3005.namprd11.prod.outlook.com ([fe80::6522:bb06:f6d:4ede%3]) with mapi id 15.20.3000.033; Wed, 20 May 2020 17:32:02 +0000 Date: Wed, 20 May 2020 12:32:00 -0500 From: cait To: Jonathan Morton , Alexander Azimov Cc: tcpm Message-ID: <@localhost> In-Reply-To: References: Content-Type: multipart/alternative; boundary="EdoMail5ec56990_5ed04a71_6850" X-ClientProxiedBy: DM6PR01CA0018.prod.exchangelabs.com (2603:10b6:5:296::23) To SN6PR11MB3005.namprd11.prod.outlook.com (2603:10b6:805:d3::17) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from email.client.edison.tech (2600:8803:400:74f:bdfc:27e5:8481:4dd4) by DM6PR01CA0018.prod.exchangelabs.com (2603:10b6:5:296::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.26 via Frontend Transport; Wed, 20 May 2020 17:32:01 +0000 X-Originating-IP: [2600:8803:400:74f:bdfc:27e5:8481:4dd4] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e8d16003-4749-492e-5440-08d7fce3b523 X-MS-TrafficTypeDiagnostic: SN6PR11MB2671: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 04097B7F7F X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DCvGOncPhsEiLY0rws26w1CYO+L/zXw1HuvasOCKeuPRciOZZjmZRjy8JSvrNId/1FRXQccSh78OJaSQvjGJxGXDm+/rnraeiuOW8xVP2sXQoh2OvE2KrypS8KySOO2hcOuRkrET4kdsUvq8xTxwkICvSFQlXaxpoNdwBMM29bfXIxlHk1Pj1xVNERaxDBdf9KJvjoCu0k3XpfOruOOBnn7+xDgUBpHw+ShmS0QcdKExwoa9+2Z0JhUS0xvu0Cwa7EsK3RGpfI31ByFqeX/7kRUqVaQe6Gn9cEw1CBfmAjG/d5Mg8rDt+6DHvNgwrg7y56b/U9fV1raUEkgBU41RbUYOoU1NP9pUgcey8myFdJsjIxRscMQ/r0rDtSpwQ/J7veSTw9J1RujisGUEpngDuQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3005.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(7916004)(136003)(366004)(39830400003)(396003)(376002)(346002)(8936002)(316002)(110136005)(53546011)(61793004)(66556008)(66476007)(6506007)(8676002)(86362001)(2906002)(52116002)(33964004)(44144004)(186003)(16526019)(4326008)(33716001)(966005)(6486002)(5660300002)(66946007)(6512007)(9686003)(508600001)(15920700027); DIR:OUT; SFP:1501; X-MS-Exchange-AntiSpam-MessageData: GJNdWA/Aa3slU96knUxm4jc6wzk59TUgW8wQs6OSKh+u2a/50vkSg+MEtKk5xy9p9N5giPQldhzE4vBXifP+CJeJYWsF3Y8J4XKxeCFmMIM97ayrJlcxK9Hg8JedKpQqKBpzGMreHkhY8Y8oOlWSzS+5ZmECYpHY+Fnfs4wv7+kNV9f3eKk0XdBnT9xXpmod8+1PAVYDq7r55fyVw9W226mRTJ8KRqn5Zh4TMzjj83zZsJt8e/2yVkpRHGz0FTm6czbVZ6GaokNBO9DSQVVee89/A37oVUGmt2+PpmMV/ipXhG4gKkWcOYmmjuwMdyNlm0Go1ac1KhvpkA0XUqq3sNgniUlC08hm36pU3wQqGetstxL1dMnr5eJunTmVsNnnTujyGwRUcb2XLH6kOiu0dB4209Mrxfi8+OO97aWNWWmLEUcuqPoYQpuL9cWEdpKCKbeH3vmF0JUDQBUsrD4T12Bk1bnfSTJQHf45jiI9vAsj//n6LC48Mga/ZRF2OTWhpwEMCsxmQ1Af1B/ZUTUmFJH8O9f/teSvHWl/pcZbVrs= X-OriginatorOrg: asomi.com X-MS-Exchange-CrossTenant-Network-Message-Id: e8d16003-4749-492e-5440-08d7fce3b523 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2020 17:32:02.6319 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a90e44c6-9570-49f9-9cdb-dff096fd98a3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HVcsanpArRB/2TX8tQFdqhtciIhu+hxwwLn5C4VrKULj1M3pfPA9aj9P2c0Q/o1k X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2671 Archived-At: Subject: Re: [tcpm] TCP Connection ID 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, 20 May 2020 17:32:08 -0000 --EdoMail5ec56990_5ed04a71_6850 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Read the caveats in the RFC that Joe cited. How would a server chosen direct index fair any better than client selected? > > On May 20, 2020 at 8:08 AM, Alexander Azimov wrote: > > > Hi all, > > > The email from Joe got into the spam box, so I was able to find it only after your notice. Thank you. > > > > The Host Id presented in RFC7974 is a very different approach: it is client-side id generated at the moment of the SYN which should help to distinguish different hosts behind NAT. > > > > What I'm looking for is a connection id, generated at the server-side and sent back with a SYN/ACK, which is next mirrored by the client.. It is not meant for host identification, but it can be used for connection identification by the middlebox under the same administrative control. And there is no need to have a 1:1 map id to a server, instead, each server should use randomized ids with encryption. > > > > And speaking about IPv6 Flow Label it's not working for IPv4 + it current implementation in Linux already has great use cases, so even in the world of IPv6 only I would prefer to keep it without overloading its functions. > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm > --EdoMail5ec56990_5ed04a71_6850 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Read the caveats in the RFC that Joe cited.= How would a server chosen direct index fair any better than client selecte= d?



On =
May 20, 2020 at 8:08 AM, Alexander Azimov <a.e.azimov@gmail.com> wrote: 

Hi all,

The email from Joe got into the spam box=
, so I was able to find it only after your notice. Thank you.
The Host Id presented in RFC7974 is a very different approach: =
it is client-side id generated at the moment of the SYN which should help t=
o distinguish different hosts behind NAT.

What=
 I'm looking for is a connection id, generated at the server-side and sent =
back with a SYN/ACK, which is next mirrored by the client.. It is not meant=
 for host identification, but it can be used for connection identification&=
nbsp;by the middlebox under the same administrative control. And there is n=
o need to have a 1:1 map id to a server, instead, each server should use ra=
ndomized ids with encryption.

And speaking about I=
Pv6 Flow Label it's not working for IPv4 + it current implementati=
on in Linux already has great use cases, so even in the world of IPv6 only =
I would prefer to keep it without overloading its functions.


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

 =20
 
 
=

--EdoMail5ec56990_5ed04a71_6850--


From nobody Wed May 20 10:53:00 2020
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 A20663A0C59 for ; Wed, 20 May 2020 10:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 v0Olpjt3OFZe for ; Wed, 20 May 2020 10:52:55 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D933A0C52 for ; Wed, 20 May 2020 10:52:55 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0AQ7fQiC6RCaMRUb2OPTGqydIE5ZXExNZnGar8h2DDU=; b=syh7txaIXBtSA27zcpr5ZgZFF UN1yFKWK46oqifNgGV9dtB0fl38Y7tvssKdpmoT4jXdXkFMPntr9mdOFnxTM5Jpj9B7NjcZZ1dfH1 yhppOOs0/9lH9oXYlZCC6X3Wwgky06nr6EN2S2mRtRnrLdPxjE0efly+ugSu+QKgH25MMjpMxxvMq B/mPOwOuOAZOVwlkAqIKjoVNi8aob0gGzKAkFx1A7VJOGQ3fohx1cV0PZ10xq5NUz/I+F7zuiKv3c tD5wRqu4P8Vt8HrI1v3ew8JwNxqGROo1caEDgudoFoGI9TthcXafWzewOPW7D/C5T9jr9kAee+ly3 Xx6r5QnEg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55569 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jbStd-002s0O-Rz; Wed, 20 May 2020 13:52:54 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_B33BF761-0149-4437-8123-99133C92B693"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: <@localhost>
Date: Wed, 20 May 2020 10:52:48 -0700
Cc: Jonathan Morton , Alexander Azimov , tcpm 
Message-Id: <8586FD82-CE31-4A28-BF98-B89C97300DA8@strayalpha.com>
References:    <@localhost>
To: cait 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] TCP Connection ID
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, 20 May 2020 17:52:58 -0000

--Apple-Mail=_B33BF761-0149-4437-8123-99133C92B693
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Right - I think that if RFC7974 doesn=E2=80=99t work for you, you=E2=80=99=
ll need to provide a much more precise description of what you=E2=80=99re =
seeking.

=46rom your description below, it=E2=80=99s not a connection ID you =
want; you really seem to be re-inventing cookies (something that lets =
the server re-establish state with a client BETWEEN connections, not =
just within one), and you want that cookie to govern how the middle box =
works.

Good luck with that. I think any decent security mechanism would (or =
should) prevent that.

Joe

> On May 20, 2020, at 10:32 AM, cait  wrote:
>=20
> Read the caveats in the RFC that Joe cited. How would a server chosen =
direct index fair any better than client selected?
>=20
>=20
>=20
>> On May 20, 2020 at 8:08 AM, Alexander Azimov > wrote:=20
>>=20
>> Hi all,
>>=20
>> The email from Joe got into the spam box, so I was able to find it =
only after your notice. Thank you.
>>=20
>> The Host Id presented in RFC7974 is a very different approach: it is =
client-side id generated at the moment of the SYN which should help to =
distinguish different hosts behind NAT.
>>=20
>> What I'm looking for is a connection id, generated at the server-side =
and sent back with a SYN/ACK, which is next mirrored by the client.. It =
is not meant for host identification, but it can be used for connection =
identification by the middlebox under the same administrative control. =
And there is no need to have a 1:1 map id to a server, instead, each =
server should use randomized ids with encryption.
>>=20
>> And speaking about IPv6 Flow Label it's not working for IPv4 + it =
current implementation in Linux already has great use cases, so even in =
the world of IPv6 only I would prefer to keep it without overloading its =
functions.
>>=20
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


--Apple-Mail=_B33BF761-0149-4437-8123-99133C92B693
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Right=
 - I think that if RFC7974 doesn=E2=80=99t work for you, you=E2=80=99ll =
need to provide a much more precise description of what you=E2=80=99re =
seeking.

=46rom your =
description below, it=E2=80=99s not a connection ID you want; you really =
seem to be re-inventing cookies (something that lets the server =
re-establish state with a client BETWEEN connections, not just within =
one), and you want that cookie to govern how the middle box =
works.

Good =
luck with that. I think any decent security mechanism would (or should) =
prevent that.

Joe

On May 20, 2020, at 10:32 AM, =
cait <cait@asomi.com> wrote:

Read the caveats in the RFC that Joe cited. How would a =
server chosen direct index fair any better than client =
selected?



On May 20, 2020 at 8:08 AM, Alexander Azimov <a.e.azimov@gmail.com> wrote: 

Hi all,

The email from Joe got into the =
spam box, so I was able to find it only after your notice. Thank =
you.

The Host =
Id presented in RFC7974 is a very different approach: it is client-side =
id generated at the moment of the SYN which should help to distinguish =
different hosts behind NAT.

What I'm looking for is a connection =
id, generated at the server-side and sent back with a SYN/ACK, which is =
next mirrored by the client.. It is not meant for host identification, =
but it can be used for connection identification by the middlebox =
under the same administrative control. And there is no need to have a =
1:1 map id to a server, instead, each server should use randomized ids =
with encryption.

And speaking about IPv6 Flow Label it's not working for =
IPv4 + it current implementation in Linux already has great use =
cases, so even in the world of IPv6 only I would prefer to keep it =
without overloading its functions.


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

 =20
 
 =

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

=

--Apple-Mail=_B33BF761-0149-4437-8123-99133C92B693--


From nobody Wed May 20 11:44:55 2020
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 486043A08C0 for ; Wed, 20 May 2020 11:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5kdB_bFaHBl for ; Wed, 20 May 2020 11:44:52 -0700 (PDT)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 7339A3A03F3 for ; Wed, 20 May 2020 11:44:52 -0700 (PDT)
Received: by mail-oi1-x22f.google.com with SMTP id l6so3862832oic.9 for ; Wed, 20 May 2020 11:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cqLUoLVk0WJ5NPTxQMWeDSVZSsBJYXtetV+YM9E1KiU=; b=Bc+ZERV+dUx0uS7VsdtwVDwX89F/g6LLhuF461mdkdc3Zai3JANHfo2r0wsdPp2JIc WW7UnEKnl4UsX6MEbpqfOhoRMK7PWp3yGMMZsPzQBMnL714Jhi50LCs+bGhnWIDTfKw1 EIjOLUB0cmVclWIKx6J1Br3LRn15urx4bWNweeQl/zY1kh1dzBxFF0Ynn8cktl/AuvU0 9NYKfHRV13RHP5B3qhrRDBtvDfyFLI91O+a7wALU23cnw1lDjsNHVLANTkbR+CSHow/t LFu9ND5naar1kfK7A9Tvfirh4K82CRMTTdIYKzylW2688SzCII+xhegb9KvXbKUNfi/o udAw==
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=cqLUoLVk0WJ5NPTxQMWeDSVZSsBJYXtetV+YM9E1KiU=; b=czqTH23Mic+XdcIRXciKL8qvRL1kgkjSQJoYcUmNvE03I+FSA3TAmjIrzbaAMbK80j EVokdAMAi9KZmtfr91m+8QSkQUC6YhuJ23eDo1gDKPpLhHXTEyyuuL+rFggsM1xioFLu iB4yECLy+rbMlkC29Q3/5fL2ldW2P6Z8Z/pL7RO3A1cn/qg9o1LxKgjwnHkB0yYp2+es i8XCCjX9GPXNySfBmUco1FNKth7dLzyJyfcpkPXiOILL9vzctyCliSXLnRVUyLzvZ9uX P+cq2SnIgHspxYbQKOea4gYBmb8zS0WhytcqKOjXi0GlNUpDM5BOKCGS3q4VuWSjze8R YEuA==
X-Gm-Message-State: AOAM531vuLzZ+QF2Np2q9AEuIxy925mDltVLUKbC7NPNWPsfWRLT7EVw LA+bhNv2D3criUWEzDyCf4iP2ur05ZctObSaN78=
X-Google-Smtp-Source: ABdhPJxoPG9XvNj5ywS77LcTikagw8gzLz4je2AJjZzUTfFfMtTOApyZTEZYrWF2Ir7njihoGeCMj85rzLVD0ZOS3MI=
X-Received: by 2002:aca:318f:: with SMTP id x137mr4317605oix.4.1590000291358;  Wed, 20 May 2020 11:44:51 -0700 (PDT)
MIME-Version: 1.0
References:    <8586FD82-CE31-4A28-BF98-B89C97300DA8@strayalpha.com>
In-Reply-To: <8586FD82-CE31-4A28-BF98-B89C97300DA8@strayalpha.com>
From: Alexander Azimov 
Date: Wed, 20 May 2020 21:44:39 +0300
Message-ID: 
To: Joseph Touch 
Cc: cait , Jonathan Morton , tcpm 
Content-Type: multipart/alternative; boundary="0000000000008f2c7205a618ca9e"
Archived-At: 
Subject: Re: [tcpm] TCP Connection ID
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, 20 May 2020 18:44:54 -0000

--0000000000008f2c7205a618ca9e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you all for the comments. I will combine my answers all-in-one reply.

Michael:
The mechanics of TFO has significant intersection, but with a certain
difference. The TFO is applied on the client src IP, while the connection
ID should depend on the server IP, which is invisible for the client. And
while TFO is just cookie (you can't retrieve the value since it was
truncated) connection ID should be reversible. And of course, the
Connection Id must be present in all packets except the first SYN.

Cait (I don't see your full name, sorry if I got it wrong):
Can you please clarify your comment? Are you speaking about IESG note? If
yes, I don't see how privacy concerns of host id are applicable in this
case.

Joseph:
If you read my suggestions as something cached between connection you got
it wrong. What I'm trying to discuss is an option similar to DSID in QUIC,
which is put in the unencrypted part of the header for packets sent from
the client to the server. The straightforward way is to apply AES on 128bit
block where the first 64 bits go from high bits server IP (real server IP,
not VIP) + random 64 bits/timestamp. The middlebox (L3 LB), knowing the
secret, will be able to retrieve real IP and make balancing without keeping
the state of the connection. Lack of space in TCP options might be a
problem for such an approach.



=D1=81=D1=80, 20 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 20:52, Joseph Touch=
 :

> Right - I think that if RFC7974 doesn=E2=80=99t work for you, you=E2=80=
=99ll need to
> provide a much more precise description of what you=E2=80=99re seeking.
>
> From your description below, it=E2=80=99s not a connection ID you want; y=
ou really
> seem to be re-inventing cookies (something that lets the server
> re-establish state with a client BETWEEN connections, not just within one=
),
> and you want that cookie to govern how the middle box works.
>
> Good luck with that. I think any decent security mechanism would (or
> should) prevent that.
>
> Joe
>
> On May 20, 2020, at 10:32 AM, cait  wrote:
>
> Read the caveats in the RFC that Joe cited. How would a server chosen
> direct index fair any better than client selected?
>
>
>
> On May 20, 2020 at 8:08 AM, Alexander Azimov 
> wrote:
>
> Hi all,
>
> The email from Joe got into the spam box, so I was able to find it only
> after your notice. Thank you.
>
> The Host Id presented in RFC7974 is a very different approach: it is
> client-side id generated at the moment of the SYN which should help to
> distinguish different hosts behind NAT.
>
> What I'm looking for is a connection id, generated at the server-side and
> sent back with a SYN/ACK, which is next mirrored by the client.. It is no=
t
> meant for host identification, but it can be used for connection
> identification by the middlebox under the same administrative control. An=
d
> there is no need to have a 1:1 map id to a server, instead, each server
> should use randomized ids with encryption.
>
> And speaking about IPv6 Flow Label it's not working for IPv4 + it current
> implementation in Linux already has great use cases, so even in the world
> of IPv6 only I would prefer to keep it without overloading its functions.
>
> _______________________________________________
> tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>

--=20
Best regards,
Alexander Azimov

--0000000000008f2c7205a618ca9e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you all for the comments. I will combine my ans=
wers all-in-one reply.

Michael:
The mech=
anics of TFO has significant intersection, but with a certain difference. T=
he TFO is applied on the client src IP, while the connection ID should depe=
nd on the server IP, which is invisible for the client. And while TFO is ju=
st cookie=C2=A0(you can't retrieve the value since it was truncated) co=
nnection ID should be reversible. And of course, the Connection Id must be =
present in all packets except the first SYN.

Cait (I don'=
t see your full name, sorry if I got it wrong):
Can you pleas=
e clarify your comment? Are you speaking about IESG note? If yes, I don'=
;t see how privacy concerns=C2=A0of host=C2=A0id=C2=A0are applicable in=C2=
=A0this case.

Joseph:=C2=A0
If you read my suggesti=
ons as something cached between connection you got it wrong. What I'm t=
rying to discuss is an option similar to DSID in QUIC, which is put in the =
unencrypted=C2=A0part of the header for packets sent from the client=C2=A0t=
o the server. The straightforward=C2=A0way is to apply AES on 128bit block =
where the first 64 bits go from high bits server IP (real server IP, not VI=
P) + random 64 bits/timestamp. The middlebox (L3 LB), knowing the secret, w=
ill be able to retrieve real IP and make balancing without keeping the stat=
e of the connection. Lack of space in TCP options might be a problem for su=
ch an approach.



=D1=81=D1=80, 20 =D0=
=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 20:52, Joseph Touch <touch@strayalpha.com>:
Right - I think that if RFC7974 doesn=E2=80=99t work for you, you=E2=
=80=99ll need to provide a much more precise description of what you=E2=80=
=99re seeking.

From your description below, it=E2=80=99s=
 not a connection ID you want; you really seem to be re-inventing cookies (=
something that lets the server re-establish state with a client BETWEEN con=
nections, not just within one), and you want that cookie to govern how the =
middle box works.

Good luck with that. I think any=
 decent security mechanism would (or should) prevent that.

Joe

On May 20, 2=
020, at 10:32 AM, cait <cait@asomi.com> wrote:

Read the caveats in the RFC that Joe cite=
d. How would a server chosen direct index fair any better than client selec=
ted?



On May 20, 2020 at 8=
:08 AM, Alexander Azimov <a.e.azimov@gmail.com> wrote: 

Hi all,

The email from=C2=A0Joe got into the spam bo=
x, so I was able to find it only after your notice. Thank you.
The Host Id presented in RFC7974 is a very different approach:=
 it is client-side id generated at the moment of the SYN which should help =
to distinguish different hosts behind NAT.

Wha=
t I'm looking for is a connection id, generated at the server-side and =
sent back with a SYN/ACK, which is next mirrored by the client.. It is not =
meant for host identification, but it can be used for connection identifica=
tion=C2=A0by the middlebox under the same administrative control. And there=
 is no need to have a 1:1 map id to a server, instead, each server should u=
se randomized ids with encryption.

And speaking ab=
out IPv6 Flow Label it's not working for IPv4=C2=A0+ it current impleme=
ntation in Linux already has great use cases, so even in the world of IPv6 =
only I would prefer to keep it without=C2=A0overloading its functions.


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

 =20
 
 
____________________________________________=
___
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm



-- 
Best regards,
Alexander Azimov


--0000000000008f2c7205a618ca9e--


From nobody Wed May 20 20:03:26 2020
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 51BE73A0A06 for ; Wed, 20 May 2020 20:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 1rv0Gt96SMJv for ; Wed, 20 May 2020 20:03:24 -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 07E843A0A02 for ; Wed, 20 May 2020 20:03:23 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XxFtUpLsovxBLncMKT/mCwza0qfe5VnnYKPy7p9oI9Q=; b=LCakj/1SgzjKbbCiKaqdjS6Ei lH2jOOSGo85ukCp29Xc3m3qCrSK8PLQFbhDyGLSX+EKlzih/j/dMOCuB2iMBC+VJLuIZqDkr8Fp+z zu71ZQRUCkK7u6wlbIJxub/HEy2laQoF8U2BAbUxc7rdGLpy0zQKbhmr3jhZ1OXtrcoBpfanTFT2L sXY5FJ4vhQb27vVyuJpfMbt0glsa/DVrWtkcoF/36u9hmy7ogigFGFW9FdhiifzPhj9q1MBubKBM8 Dd7XvcGRymoZ/dJz1NEiqRRB2gLpH3uVKjfoLS8TuGzCGw/FbUYZLMBUTAcI6LpC3m6M910BUsg5A l+Mm7kefA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56914 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jbbUH-001238-Rp; Wed, 20 May 2020 23:03:18 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_88D41AE7-96F4-4DE0-83D9-19F0F4AD7250"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: 
Date: Wed, 20 May 2020 20:03:13 -0700
Cc: cait , Jonathan Morton , tcpm 
Message-Id: <262EA977-B4AB-4E18-8B59-DEB80AB93CAE@strayalpha.com>
References:    <8586FD82-CE31-4A28-BF98-B89C97300DA8@strayalpha.com> 
To: Alexander Azimov 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] TCP Connection ID
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, 21 May 2020 03:03:25 -0000

--Apple-Mail=_88D41AE7-96F4-4DE0-83D9-19F0F4AD7250
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 20, 2020, at 11:44 AM, Alexander Azimov  =
wrote:
>=20
> Joseph:=20
> If you read my suggestions as something cached between connection you =
got it wrong. What I'm trying to discuss is an option similar to DSID in =
QUIC, which is put in the unencrypted part of the header for packets =
sent from the client to the server. The straightforward way is to apply =
AES on 128bit block where the first 64 bits go from high bits server IP =
(real server IP, not VIP) + random 64 bits/timestamp. The middlebox (L3 =
LB), knowing the secret, will be able to retrieve real IP and make =
balancing without keeping the state of the connection. Lack of space in =
TCP options might be a problem for such an approach.

You can do this by combining the existing TCP Host ID option (RFC 7974) =
with IP LSR.

You only really need:
	- a TCP option in the SYN and SYN-ACK (8-bytes using the RFC7874 =
variant) but not in later segments
	- IP LSR at the client
	- a middlebox that rewrites IP headers of SYN packets with LSR

Here=E2=80=99s how:

Servers are assigned two addresses each - one unique (P, Q, R, =E2=80=A6),=
 one common (let=E2=80=99s say =E2=80=9CX=E2=80=9D)
All servers are configured to forward

Clients send SYN to LSR X,X with TCP HID option with an empty value
	You need IP to have LSR because the middlebox should NEVER make =
a packet longer; it could mess up MTU discovery
	You need the TCP HID option by the rules of that option
LB middlebox picks a server (P) and rewrites the IP LSR X, X with the =
LSR P,X
	So load balancing happens only on SYNs
The SYN proceeds to server P, which performs LSR; in the process of =
forwarding, it accepts the packet at X
Server P needs to see the IP LSR P,X and extract P
Server P puts P in the SYN-ACK TCP HID option and sends it back to the =
client
	now that you receive the TCP HID option back, the client no =
longer needs to include it in future packets

The client sees P in the SYN-ACK option and configures that TCP =
connection to send all future packets with IP LSR P,X

At that point the middlebox doesn=E2=80=99t need to do anything anymore; =
everything is handled by the client, who has to keep state for the =
connection anyway.

This can work even with end-to-end TCP encryption or authentication. The =
only thing it needs is an outermost IP header whose LSR can be =
rewritten.

Joe=

--Apple-Mail=_88D41AE7-96F4-4DE0-83D9-19F0F4AD7250
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
May 20, 2020, at 11:44 AM, Alexander Azimov <a.e.azimov@gmail.com> wrote:

Joseph: 
If =
you read my suggestions as something cached between connection you got =
it wrong. What I'm trying to discuss is an option similar to DSID in =
QUIC, which is put in the unencrypted part of the header for =
packets sent from the client to the server. The =
straightforward way is to apply AES on 128bit block where the first =
64 bits go from high bits server IP (real server IP, not VIP) + random =
64 bits/timestamp. The middlebox (L3 LB), knowing the secret, will be =
able to retrieve real IP and make balancing without keeping the state of =
the connection. Lack of space in TCP options might be a problem for such =
an approach.

You can =
do this by combining the existing TCP Host ID option (RFC 7974) with IP LSR.

You only really need:
	- a =
TCP option in the SYN and SYN-ACK (8-bytes using the RFC7874 variant) =
but not in later segments
	- IP =
LSR at the client
	- a middlebox that rewrites IP =
headers of SYN packets with LSR

Here=E2=80=99s how:

Servers are assigned two =
addresses each - one unique (P, Q, R, =E2=80=A6), one common (let=E2=80=99=
s say =E2=80=9CX=E2=80=9D)
All servers are =
configured to forward

Clients send SYN to LSR X,X with TCP HID option with an empty =
value
	You need IP to have LSR because =
the middlebox should NEVER make a packet longer; it could mess up MTU =
discovery
	You need the TCP HID option by =
the rules of that option
LB middlebox picks a =
server (P) and rewrites the IP LSR X, X with the LSR P,X
	=
So load balancing happens only on SYNs
The =
SYN proceeds to server P, which performs LSR; in the process of =
forwarding, it accepts the packet at X
Server P =
needs to see the IP LSR P,X and extract P
Server P =
puts P in the SYN-ACK TCP HID option and sends it back to the =
client
	now that you receive the TCP HID =
option back, the client no longer needs to include it in future =
packets

The =
client sees P in the SYN-ACK option and configures that TCP connection =
to send all future packets with IP LSR P,X

At that point the middlebox doesn=E2=80=99=
t need to do anything anymore; everything is handled by the client, who =
has to keep state for the connection anyway.

This can work even with end-to-end TCP =
encryption or authentication. The only thing it needs is an outermost IP =
header whose LSR can be rewritten.

Joe
=

--Apple-Mail=_88D41AE7-96F4-4DE0-83D9-19F0F4AD7250--


From nobody Thu May 21 06:39:00 2020
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 9E7F13A0CBE for ; Thu, 21 May 2020 06:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 ieGFjX_LZ63z for ; Thu, 21 May 2020 06:38:56 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 E01163A0CBC for ; Thu, 21 May 2020 06:38:55 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id x14so1317196wrp.2 for ; Thu, 21 May 2020 06:38:55 -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=aKKv2wrmulnF4LJaddKc5bWJHL+V49d3A7ShHs6fb/U=; b=wU3ykg0jXo51RtQxCEnTycZ137RgahZT8EiREWk5qiOSpSLHQKc3iwDg50XB82ML+L YF4WDIqHcnlU1DzNwD3so5+gpH9zH5n7Ht3Zf3o3kVEtl9teOmlWeHKxxbFCzWdHzqrq lGsIsyDgPdbE/GR6jxo0LD+QG+ZUBGLShwB0P6GzKaalRNorvevlz13zM9K2IQScyQht GYZ4Hhqf1VcsCNeRosUUzcCSmy3ntLqRt6fwc/G/pLpZkRN7uM/ZDlNcdK8hkkKpA7k4 Rbx/PjCM/kVUsVnKdTg7dW7iZAA9k3xX74FQlLEGTFvQixxoUp26GZWBzVxLEK6LjMGU JDgQ==
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=aKKv2wrmulnF4LJaddKc5bWJHL+V49d3A7ShHs6fb/U=; b=LnK5A1HuOfCOvFemywwcFJjM92FWMfJ9neT+CI5AYkPeeBXJs1qL2THmW/CiWe/DkM Pk9BY9A6TSUD9aDnoW9q2of7t3br+ahrETrUddesox4dCQ1rJ8Q/hVwwCMtwk+a6zPFS XpRM4B6Ao066abhRZSCePhACwmq8mG0juKk0nsxOaj1nsHUUSNuXW5/LHEXV6yoaC3En yKxP9R+qhK5DgwATvke5jPe5sl+cA4t9XFH3Wb3hnzlPZGLaV9YkjggiC8sMs9da3Cvz lfIPybVNWLgr8lWGTblrFYr/wtXL8P3NNoTQzYTztbMHRh0vLowVLDijr81OlaYZ12Iu 0qxg==
X-Gm-Message-State: AOAM530ctYU5h6xGhBUYtrplJT9t//tr2/VsWuDgUbZv1aW2HyqFFp1K 6L/BFeDMGqP6Syt1KHD8BqLq9lRAiNPX4DsqrOfEUtcIvHYfhbZFBbie4Fw606SGWkfuplllyE/ Rsg==
X-Google-Smtp-Source: ABdhPJyXY+cfWczGaJPoJtTyohWtyM3t9UY/gM3C05PKlsVVi9iOQJzHQJyfOP5Afwz5MvEZ3oSw1Q==
X-Received: by 2002:adf:ea81:: with SMTP id s1mr320989wrm.424.1590068333774; Thu, 21 May 2020 06:38:53 -0700 (PDT)
Received: from host.dynamic.voo.be ([2a02:2788:484:b4f:55b0:f03f:8872:ae39]) by smtp.gmail.com with ESMTPSA id b19sm6960934wmd.26.2020.05.21.06.38.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2020 06:38:52 -0700 (PDT)
From: Olivier Bonaventure 
Message-Id: <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net>
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Thu, 21 May 2020 15:38:51 +0200
In-Reply-To: 
Cc: "tcpm@ietf.org Extensions" 
To: Alexander Azimov 
References:  
X-Mailer: Apple Mail (2.3445.104.14)
Content-Type: multipart/alternative; boundary="Apple-Mail=_130E1EC7-7EEB-40AC-BE84-44B1BA825776"
Archived-At: 
Subject: Re: [tcpm] TCP Connection ID
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, 21 May 2020 13:38:59 -0000

--Apple-Mail=_130E1EC7-7EEB-40AC-BE84-44B1BA825776
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"

Dear Alexander,

>=20
> As you all know L3 LB is a common element of today's cloud infrastructure=
. Its original design was based on the connection state that maps backend I=
Ps (real IPs) to connection. Recently there were several papers that were s=
uggesting the move to the stateless L3 LB, where the state (connection id) =
becomes the property of connection and it kept at the client, so the L3 LB =
can work without keeping state for every connection. As far as I understand=
, for QUIC it becomes native with destination connection ID in its header.
>=20
> I've seen suggestions for getting this functionality in TCP by overloadin=
g the Timestamps option or even TCP SEQ - can't say that such design looks =
good for me. I wonder was there an attempt to add connection id in the TCP =
options, and if it was - why it wasn't successful?

Overloading TCP sequence numbers or TCP timestamps to support this feature =
could lead to problems that are difficult to troubleshoot as there are midd=
leboxes that modify these fields.

The latest version of Multipath TCP (RFC8684) includes a feature to support=
 load-balancers. The connection is established via the load balancer that f=
orwards the SYN to a server and this server advertises its own address to t=
he client. This enables the client to stick the new subflows of the Multipa=
th TCP connection to this server and thus completely bypass the load balanc=
er. This is described in https://inl.info.ucl.ac.be/publications/making-mul=
tipath-tcp-friendlier-load-balancers-and-anycast.html 

Olivier
--=20


Disclaimer: https://www.tessares.net/mail-disclaimer/=20




--Apple-Mail=_130E1EC7-7EEB-40AC-BE84-44B1BA825776
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="ISO-8859-1"


Dear Alexander,


As you all know L3 LB is a common el=
ement of today's cloud infrastructure. Its original design was based on the=
 connection state that maps backend IPs (real IPs) to connection. Recently&=
nbsp;there were several papers that were suggesting the move to the statele=
ss L3 LB, where the state (connection id) becomes the property of connectio=
n and it kept at the client, so the L3 LB can work without keeping state fo=
r every connection. As far as I understand, for QUIC it becomes native with=
 destination connection ID in its header.

I've=
 seen suggestions for getting this functionality in TCP by overloading=
 the Timestamps option or even TCP SEQ - can't say that such design looks g=
ood for me. I wonder was there an attempt to add connection id in the TCP o=
ptions, and if it was - why it wasn't successful?

Overloading TCP sequence=
 numbers or TCP timestamps to support this feature could lead to problems t=
hat are difficult to troubleshoot as there are middleboxes that modify thes=
e fields.

The lat=
est version of Multipath TCP (RFC8684) includes a feature to support load-b=
alancers. The connection is established via the load balancer that forwards=
 the SYN to a server and this server advertises its own address to the clie=
nt. This enables the client to stick the new subflows of the Multipath TCP =
connection to this server and thus completely bypass the load balancer. Thi=
s is described in =
https://inl.info.ucl.ac.be/publications/making-multipath-tcp-friendlier-loa=
d-balancers-and-anycast.html

=

Olivier








--Apple-Mail=_130E1EC7-7EEB-40AC-BE84-44B1BA825776--


From nobody Thu May 21 08:47:31 2020
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 6DE203A00E1 for ; Thu, 21 May 2020 08:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtjFK4Pz8EgS for ; Thu, 21 May 2020 08:47:25 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 6A0AE3A011F for ; Thu, 21 May 2020 08:47:25 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id h7so5860898otr.3 for ; Thu, 21 May 2020 08:47:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jdP5fiMguVLYP/xQc41GQjPQZ6T/mABTXOO+7TtvTAo=; b=D5HrubtVhtk2deaLJTQ9sCDpjoIu0HYLsZWcNzM+aU++Tv8U8AM33aV0+L8OgOTCis xa969nXyA8nmSvmRAaFMf9Myg8DhpJsC0UqqjG43yOeTlWxiuq8VWBep5dpDS1pbCXWM xQj46g3LyVVcjctkAriFVj4YJcWb9xtSKA8+kM2U1ti8Rv0lsVn0/9YSVnaA7bH37XMY yHiLta9nyfYt5up/4FmLt4NIgV2/hyTAjh+g5Y1Rc6GPqiEpObgMItgWisF4uzJu9JHO PxQR92BaMXssoFmG6rqAUl/HnIvjefzkhvaWzTVA6FxqMwvxb4GSqtU7tu9dyEl4IMVA dgng==
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=jdP5fiMguVLYP/xQc41GQjPQZ6T/mABTXOO+7TtvTAo=; b=asJNtSk267Ze+Q/vZLZDCj4jaU9UxLudnzKm3CqYQAzQ1s9249mD2VDtR5RCgrVpYF AjkRt1sYLmPtSnCG6i6c0KEONLLa0mL+qkzRV1iq/YrgWvxYe1ESDlnQ9PTXhDLUWF5S CWnB+iuU101y73b3iTkdXiyY+lQ7KmQetXTOEKZJs+uFMBOpb4nfb1W0y1NFw9AYOwM9 iyE1Pl9WrR/mAQx17l4dvrPLxeeicxFx7cXqoNETJyDeWCVrZEi54WTf3gzlD8SK+1fX h/Yjhp4pq2pTMhzssI9WFyjBMPlqmLq3IlNPo70Z7ZJwYsjpDLv6kTlGrFYCyZm7pHIA eqCw==
X-Gm-Message-State: AOAM532QBc/kK102ZtJ78tQYGA7u933fDdipQsDi2xUrOTgaSKyuKc/X gTrnxhCCUdCyfIGF643/w7XzVa+GKoByWqVe+vPkKNUj
X-Google-Smtp-Source: ABdhPJw15FNPo8j6i3STB1Gb8+Pdofgp44r9egJ6rCKNqvmCePoVhp1oq5epJA/srXWcwO8UKkEkP1R1eNhLx9FaVko=
X-Received: by 2002:a05:6830:91:: with SMTP id a17mr6545081oto.27.1590076044455;  Thu, 21 May 2020 08:47:24 -0700 (PDT)
MIME-Version: 1.0
References:   <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net>
In-Reply-To: <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net>
From: Alexander Azimov 
Date: Thu, 21 May 2020 18:47:13 +0300
Message-ID: 
To: Olivier Bonaventure 
Cc: "tcpm@ietf.org Extensions" 
Content-Type: multipart/alternative; boundary="000000000000cbb45c05a62a6d54"
Archived-At: 
Subject: Re: [tcpm] TCP Connection ID
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, 21 May 2020 15:47:29 -0000

--000000000000cbb45c05a62a6d54
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone, here is another all-in-one reply.

Joseph:
As far as I understand you are suggesting to use IP LSR/RH which
SHOULD be turned
off by default (RFC7196). Besides, P and X, in your terms may belong to
different address families. It seems that you still have confusion on the
purpose of my proposal:

   - There is a browser, that sends a WEB-request. The request is sent to
   the virtual IP (VIP). The browser/OS is out of our control.
   - There is a load balancer inside the datacenter, which receives an SYN
   packet and needs to send it to the server with real IP. Normally it is d=
one
   via tunnel: IPIP or GRE. Both load balancer and server are under the sam=
e
   administrative control.
   - The idea is to introduce a connection id, that is generated by the
   server at the time of SYN/ACK and kept at the client for the time of TCP
   session, thus removing the need to keep the state at the load balancer.
   This brings advantages in the case of DDoS attacks, load drain from
   servers, and traffic rerouting between LB.


Oliver:
Thank you for the link! I was not aware of this paper. The option to
advertise VIP looks interesting, but seem to have limitations:

   - What if real server IP is IPv6 address while the client is working
   from IPv4 only network?
   - The attacker may learn the full list of backend servers, which can be
   used for DDoS attacks. The dynamic IP allocation for connections may wor=
k
   as a partial workaround, have you implemented it in the lab?
   - The load balancer still needs to keep states of the connections. But
   it wasn't the problem that was addressed in the paper.

Anyway, the connection id, as I see previously described, is a function on
top of real server IP, and with proper encoding/decoding it will be working
for Anycast when connection jumps from one to another LB. It should
be working for MPTCP case too.

PS: previously in this thread, I used the term L3LB, while in Oliver's
paper it is named L4 load balancer. I hope it hasn't brought additional
confusion.

=D1=87=D1=82, 21 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 16:38, Olivier Bona=
venture <
olivier.bonaventure@tessares.net>:

> Dear Alexander,
>
>
>> As you all know L3 LB is a common element of today's cloud
>> infrastructure. Its original design was based on the connection state th=
at
>> maps backend IPs (real IPs) to connection. Recently there were several
>> papers that were suggesting the move to the stateless L3 LB, where the
>> state (connection id) becomes the property of connection and it kept at =
the
>> client, so the L3 LB can work without keeping state for every connection=
.
>> As far as I understand, for QUIC it becomes native with destination
>> connection ID in its header.
>>
>> I've seen suggestions for getting this functionality in TCP by
>> overloading the Timestamps option or even TCP SEQ - can't say that such
>> design looks good for me. I wonder was there an attempt to add connectio=
n
>> id in the TCP options, and if it was - why it wasn't successful?
>>
>
> Overloading TCP sequence numbers or TCP timestamps to support this featur=
e
> could lead to problems that are difficult to troubleshoot as there are
> middleboxes that modify these fields.
>
> The latest version of Multipath TCP (RFC8684) includes a feature to
> support load-balancers. The connection is established via the load balanc=
er
> that forwards the SYN to a server and this server advertises its own
> address to the client. This enables the client to stick the new subflows =
of
> the Multipath TCP connection to this server and thus completely bypass th=
e
> load balancer. This is described in
> https://inl.info.ucl.ac.be/publications/making-multipath-tcp-friendlier-l=
oad-balancers-and-anycast.html
>
> Olivier
>
> ------------------------------
>
> Disclaimer: https://www.tessares.net/mail-disclaimer/
>
>
>

--=20
Best regards,
Alexander Azimov

--000000000000cbb45c05a62a6d54
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi everyone, here is another all-in-one reply.

Joseph:
As far as I understand you are suggesting to use =
IP=20

 LSR/RH which=C2=A0SHO=
ULD be=C2=A0turned off by default (RFC7196). Besides, P and X, in yo=
ur terms may belong to different address families. It seems that you still =
have=C2=A0confusion=C2=A0on the purpose of my proposal:
  • T=
here is a browser, that sends a WEB-request. The request=C2=A0is sent to th=
e virtual IP (VIP). The browser/OS is out of our control.
  • There is =
a load balancer inside the datacenter, which receives an SYN packet and nee=
ds to send it to the server with real IP. Normally it is done via tunnel: I=
PIP or GRE. Both load balancer and server are under the same administrative=
 control.
  • The idea is to introduce a connection id, that is generat=
ed by the server at the time of SYN/ACK and kept at the client for the time=
 of TCP session, thus removing the need to keep the state at the load balan=
cer. This brings advantages in the case of DDoS attacks, load drain from se=
rvers, and traffic rerouting between LB.

=

Oliver:
Thank you for the link! I was not aware of this pape=
r. The option to advertise=C2=A0VIP looks interesting, but seem to have lim=
itations:
  • What if real server=C2=A0IP is IPv6 address whi=
le the client is working from IPv4 only network?
  • The attacker may l=
earn the full list of backend servers, which can be used for DDoS attacks. =
The dynamic IP allocation for connections may work as a partial workaround,=
 have you implemented it in the lab?
  • The load balancer still needs =
to keep states of the connections. But it wasn't the problem that was a=
ddressed in the paper.
Anyway, the connection id, as I see pr=
eviously described, is a function on top of real server IP, and with proper=
 encoding/decoding it will be working for Anycast when connection jumps fro=
m one to another LB. It should be=C2=A0working for MPTCP case too.

PS: previously in this thread, I used the term L3LB,=
 while in Oliver's paper it is named L4 load balancer. I hope it hasn&#=
39;t brought=C2=A0additional confusion.

=D1=87=D1=82, 21 =D0=BC=D0=B0=
=D1=8F 2020 =D0=B3. =D0=B2 16:38, Olivier Bonaventure <olivier.bonaventure@tessares.net>=
:
Dear Alexander,


=
As you all know L3 LB is a common element of today's cloud infrastructu=
re. Its original design was based on the connection state that maps backend=
 IPs (real IPs) to connection. Recently=C2=A0there were several papers that=
 were suggesting the move to the stateless L3 LB, where the state (connecti=
on id) becomes the property of connection and it kept at the client, so the=
 L3 LB can work without keeping state for every connection. As far as I und=
erstand, for QUIC it becomes native with destination connection ID in its h=
eader.

I've seen suggestions for getting this functionality=C2=
=A0in TCP by overloading the Timestamps option or even TCP SEQ - can't =
say that such design looks good for me. I wonder was there an attempt to ad=
d connection id in the TCP options, and if it was - why it wasn't succe=
ssful?
=


Overloading TCP sequence numbers or TCP timesta=
mps to support this feature could lead to problems that are difficult to tr=
oubleshoot as there are middleboxes that modify these fields.
The latest version of Multipath TCP (RFC8684) includes a featur=
e to support load-balancers. The connection is established via the load bal=
ancer that forwards the SYN to a server and this server advertises its own =
address to the client. This enables the client to stick the new subflows of=
 the Multipath TCP connection to this server and thus completely bypass the=
 load balancer. This is described in=C2=A0https://inl.info.ucl.ac.be/publications/making-mu=
ltipath-tcp-friendlier-load-balancers-and-anycast.html

Olivier









-- 
Best regards,<=
div>Alexander Azimov


--000000000000cbb45c05a62a6d54--


From nobody Thu May 21 09:39:12 2020
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 956A03A08B6 for ; Thu, 21 May 2020 09:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 23RKX5VnpMfx for ; Thu, 21 May 2020 09:39:09 -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 2C4E03A08A7 for ; Thu, 21 May 2020 09:39:09 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OLq/PplZp3pt/3wFUny1qGTssGkwW593P721WxgPqG8=; b=RS9jz1PVdSEgds4mhCxH7B9SI vkuxKaD1UVsqoISBB8Y5bZZgV7udGtVmpB5APrBU+wqbO9LwCS7j++aez2jJDcEmkklkcdLFBg44t Y/c1N13LhKUUE8skgFtTlc8310JK2xItTxwyfLcYC+PtymPugLqtN2UM2WPt6NKV3sE74eQhdD5CZ uSCtWT7LMbYrhN52T0Q57SFtTs8a7CI9Ft1GBX5yCJ23Wlv8uk+cOWi+Yi9faraNhDbcZMRANQQL8 e7G4574XOOmCj4mU5iWTmLdN/nRwXE4ONHIAIl2Tcats/ZOHO7k4UzBHkV0v2QZsA+55rV2ivD0A9 HvU5jvbVA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58076 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jboDn-000WF6-Lz; Thu, 21 May 2020 12:39:08 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_E45BE9C6-7354-4BEA-B3E2-6EFB61009780"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: 
Date: Thu, 21 May 2020 09:39:02 -0700
Cc: Olivier Bonaventure , "tcpm@ietf.org Extensions" 
Message-Id: <2F963707-B6CF-40BE-8D95-7F2A2E7F3B09@strayalpha.com>
References:   <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net> 
To: Alexander Azimov 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] TCP Connection ID
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, 21 May 2020 16:39:11 -0000

--Apple-Mail=_E45BE9C6-7354-4BEA-B3E2-6EFB61009780
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On May 21, 2020, at 8:47 AM, Alexander Azimov  =
wrote:
>=20
> Hi everyone, here is another all-in-one reply.
>=20
> Joseph:
> As far as I understand you are suggesting to use IP LSR/RH which =
SHOULD be turned off by default (RFC7196).

There=E2=80=99s no mention of LSR in RFC7196. Perhaps you mean RFC7126 - =
in which case, yes - another blow to the flexibility of the Internet by =
BCPs that treat anything unexpected as an attack ;-(

> Besides, P and X, in your terms may belong to different address =
families.

You=E2=80=99re adding new constraints, but OK.

> It seems that you still have confusion on the purpose of my proposal:
> There is a browser, that sends a WEB-request. The request is sent to =
the virtual IP (VIP). The browser/OS is out of our control.
Then you wouldn=E2=80=99t be talking about TCP option anymore (options =
cannot be added en-route). You also wouldn=E2=80=99t be talking about =
MPTCP either - in general.
> There is a load balancer inside the datacenter, which receives an SYN =
packet and needs to send it to the server with real IP. Normally it is =
done via tunnel: IPIP or GRE. Both load balancer and server are under =
the same administrative control.
> The idea is to introduce a connection id, that is generated by the =
server at the time of SYN/ACK and kept at the client for the time of TCP =
session,
The server TCP sequence number and timestamps are the only things that =
most TCP clients already keep track of that the server has control ove).=20=


Both of those have other meanings and change during a connection, which =
means that the middlebox would have to keep state to track them. But you =
also said the middlebox doesn=E2=80=99t keep state.
> thus removing the need to keep the state at the load balancer. This =
brings advantages in the case of DDoS attacks, load drain from servers, =
and traffic rerouting between LB.

I see more clearly what you want, but no way to get there if the client =
browser/OS is unmodified.

Joe


--Apple-Mail=_E45BE9C6-7354-4BEA-B3E2-6EFB61009780
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On May 21, 2020, at 8:47 AM, Alexander Azimov <a.e.azimov@gmail.com> wrote:

Hi everyone, here is another all-in-one reply.

Joseph:
As far as I understand you are suggesting to use IP=20

 LSR/RH which SHOULD=
 be turned off by default =
(RFC7196).

There=E2=80=99s no mention of LSR in RFC7196. =
Perhaps you mean RFC7126 - in which case, yes - another blow to the =
flexibility of the Internet by BCPs that treat anything unexpected as an =
attack ;-(

 Besides, P and =
X, in your terms may belong to different address families. =


You=E2=80=99=
re adding new constraints, but OK.

It seems that you still have confusion on the =
purpose of my proposal:
  • There is a browser, that sends a WEB-request. The =
request is sent to the virtual IP (VIP). The browser/OS is out of =
our control.
Then you =
wouldn=E2=80=99t be talking about TCP option anymore (options cannot be =
added en-route). You also wouldn=E2=80=99t be talking about MPTCP either =
- in general.
  • There is a load balancer inside the datacenter, which =
receives an SYN packet and needs to send it to the server with real IP. =
Normally it is done via tunnel: IPIP or GRE. Both load balancer and =
server are under the same administrative control.
  • The =
idea is to introduce a connection id, that is generated by the server at =
the time of SYN/ACK and kept at the client for the time of TCP session, =

The server TCP sequence =
number and timestamps are the only things that most TCP clients already =
keep track of that the server has control ove). 

Both of those have other meanings and change =
during a connection, which means that the middlebox would have to keep =
state to track them. But you also said the middlebox doesn=E2=80=99t =
keep state.
  • thus=
 removing the need to keep the state at the load balancer. This brings =
advantages in the case of DDoS attacks, load drain from servers, and =
traffic rerouting between LB.
I see =
more clearly what you want, but no way to get there if the client =
browser/OS is unmodified.

Joe
=

--Apple-Mail=_E45BE9C6-7354-4BEA-B3E2-6EFB61009780--


From nobody Thu May 21 12:48:57 2020
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 155D03A0B84 for ; Thu, 21 May 2020 12:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2D6vhw3iEDD for ; Thu, 21 May 2020 12:48:52 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 1717F3A0B7F for ; Thu, 21 May 2020 12:48:52 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id f18so6449722otq.11 for ; Thu, 21 May 2020 12:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7TjHKTYeh+4M1YGoUrVbYq3znOdmn/m6SBwL0UOdELk=; b=lit618DvMORVyYBGcxD2bHz/MDzMCeZ/qzMCLveQhRDKrQc3xtOWVaG+2mgrbgvpry 4CYddSKBn0D5npfkrU0G5bf3jKxmU5EOk0GIOGQqFjnJO3blYIy85K6wZrr1OCd9b2fC 3xBVxVQz9J8R6jf7UXfnmCzQUHxtXCLW+RYccujRG2mExIS+iwMqI2brecr5SU4StJke OAFMnuQmU1L6oBWgRrgfdoniQd2q+gUg+8Ls2UyP6mpR8pPYeciBwasNHJ9834WMIXUa q5MXHmy171OIX8C8ycTaXxTrbueyh7APZi776m4iLA8Wb1X3ZBPWpKEykDiZSF8Lb5V+ yydQ==
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=7TjHKTYeh+4M1YGoUrVbYq3znOdmn/m6SBwL0UOdELk=; b=pe/W3kIJAd2MYTGzs6yCbMr8ryyJZvwHFeWNpZtieE/wQNyTqg6ozWHZO1K4ThNdOk +r9N5sjCx0iA957B9ZqO0Sf7I9ZqGGlhd6dlLtj6nyMME/PK5L+7ggHgx48K8qcDLmV0 +EtKXuKqzRJTnR1wz+5JkX506YppWVRLDn/CvddAuAO6w+YaTQJRr1k1rC70VtEa1VOK rJE5KXrJVm/DNqHbCde/kgGelyutHV53B5qJ6Nv/fFqZlggPW/hYDHb01ntA/7Fe8jS0 C7JJYru1QWKqd8rgUP1Xs9nKYMuF1rGPsfzX+lHVogXtvLa66z1snpNEatkrCeHRC248 wFgA==
X-Gm-Message-State: AOAM533zI+TEIUvv7tnDDwB8wlIAlMjLF+216CeTAVCJ+3kRrdpvn8cj 0SHFxO9lpKZ76ArmdQi3Ur8eVjQvp76dMjerWjqwXqEh
X-Google-Smtp-Source: ABdhPJy+2fSIb57nmdgaANtc3UY55uKmPtl0qkbKE/Gm32NTU9J3e8agTZqpzXqv+e4SAKf9EN02JjjsM9vCp6xgGuE=
X-Received: by 2002:a9d:1462:: with SMTP id h89mr8664100oth.18.1590090531200;  Thu, 21 May 2020 12:48:51 -0700 (PDT)
MIME-Version: 1.0
References:   <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net>  <2F963707-B6CF-40BE-8D95-7F2A2E7F3B09@strayalpha.com>
In-Reply-To: <2F963707-B6CF-40BE-8D95-7F2A2E7F3B09@strayalpha.com>
From: Alexander Azimov 
Date: Thu, 21 May 2020 22:48:39 +0300
Message-ID: 
To: Joseph Touch 
Cc: Olivier Bonaventure ,  "tcpm@ietf.org Extensions" 
Content-Type: multipart/alternative; boundary="00000000000045e2bc05a62dcdcb"
Archived-At: 
Subject: Re: [tcpm] TCP Connection ID
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, 21 May 2020 19:48:55 -0000

--00000000000045e2bc05a62dcdcb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Joseph,

Then you wouldn=E2=80=99t be talking about TCP option anymore (options cann=
ot be
> added en-route). You also wouldn=E2=80=99t be talking about MPTCP either =
- in
> general.
>
I believe that regular TCP options (not experimental) in general have
higher chances to be supported globally.

The server TCP sequence number and timestamps are the only things that most
> TCP clients already keep track of that the server has control ove).
>
> Both of those have other meanings and change during a connection, which
> means that the middlebox would have to keep state to track them. But you
> also said the middlebox doesn=E2=80=99t keep state.
>
That's the purpose of my proposal. To have a reverse function for
connection id that returns the real IP, so the load balancer doesn't need
to perform the connection tracking. Though you need to know the secret to
restore value(s), so it will not have negative security effects.


> I see more clearly what you want, but no way to get there if the client
> browser/OS is unmodified.
>
I've meant that OS/browser is out of administrative control. So you can't
rely on a proprietary software/agent on the client-side. But the open
standard may be successful especially taking into account that main OS
vendors are content providers at the same time, thus already trying to
solve the problem of LB in different ways.

The incremental deployment is crucial, but IMO it looks doable.

--=20
Best regards,
Alexander Azimov

--00000000000045e2bc05a62dcdcb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Joseph,

Then you wouldn=E2=80=99t be talking about TCP=
 option anymore (options cannot be added en-route). You also wouldn=E2=80=
=99t be talking about MPTCP either - in general.
I believe that regular TCP options (not experimental)=C2=A0in general have higher=
 chances to be supported globally.

The server TCP sequence number and timestamps are the only thing=
s that most TCP clients already keep track of that the server has control o=
ve).=C2=A0

Both of those have other meanings and c=
hange during a connection, which means that the middlebox would have to kee=
p state to track them. But you also said the middlebox doesn=E2=80=99t keep=
 state.
That's the purpos=
e of my proposal. To have a reverse function for connection id that returns=
 the real IP, so the load balancer doesn't need to perform the connecti=
on tracking. Though you need to know the secret to restore value(s), so it =
will not have negative security effects.=C2=A0
=C2=A0
I see more clearly what you want, but no way to get the=
re if the client browser/OS is unmodified.
I&#=
39;ve meant that OS/browser is out of administrative control. So you can=
9;t rely on a proprietary=C2=A0software/agent on the client-side. But the o=
pen standard may be successful especially taking into account that main OS =
vendors are content providers at the same time,=C2=A0thus already trying to=
 solve the=C2=A0problem of LB in different ways.

The incremental deployment is crucial, but IMO it looks doable.

-- 
Best regards,
Alexander Azimov


--00000000000045e2bc05a62dcdcb--


From nobody Fri May 22 21:10:34 2020
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 002AF3A0F29 for ; Fri, 22 May 2020 21:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.581
X-Spam-Level: 
X-Spam-Status: No, score=0.581 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 cGqq8LKs7rAx for ; Fri, 22 May 2020 21:10:31 -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 E5F4D3A0F27 for ; Fri, 22 May 2020 21:10:30 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Nxb7mEB6GVe+x5jbd3zKWcGuDoKugDQbi37r+Gy22us=; b=eLxZh7j6+vU+4wpQo8ztSklb9 dIcf3W211KkE2KUtMXOugaGvLRGcFnO1C1kTdDrwrI3XAlEO7AjmmIYQeV0xMelbLdNcNdpVQ8AGe zMXTdybytigqWWbDsaRC34ChuloMZ88fFrukq6pkGbvpuYfUQ9c/b6nDBJT1zHTyudQ0xjGrMxkWN Jn2F3amXlmkiatxAax98XY4FvVIA0ipaHIXw5IIq66fU2+hGlD2OvnNb8+9HRbtYGE2nw0VaxQtYN /CpwltXSrLd4sMj9FC58bz3OtAFbLgw1sBt5Ui/gbIdGwvPhKVkCDl7oAygcnumy4bhc5a8/veJ68 39w02k6uA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61709 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jcLUQ-003DtY-N5; Sat, 23 May 2020 00:10:30 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_071E8F0D-BB25-416C-BA4F-91C7EBF913D6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: 
Date: Fri, 22 May 2020 21:10:25 -0700
Cc: Olivier Bonaventure , "tcpm@ietf.org Extensions" 
Message-Id: 
References:   <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net>  <2F963707-B6CF-40BE-8D95-7F2A2E7F3B09@strayalpha.com> 
To: Alexander Azimov 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] TCP Connection ID
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, 23 May 2020 04:10:32 -0000

--Apple-Mail=_071E8F0D-BB25-416C-BA4F-91C7EBF913D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On May 21, 2020, at 12:48 PM, Alexander Azimov  =
wrote:
>=20
> I see more clearly what you want, but no way to get there if the =
client browser/OS is unmodified.
> I've meant that OS/browser is out of administrative control.

When (or if) you can formulate a clear, complete problem statement, let =
us know.

Joe=

--Apple-Mail=_071E8F0D-BB25-416C-BA4F-91C7EBF913D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On May 21, 2020, at 12:48 PM, Alexander Azimov <a.e.azimov@gmail.com> wrote:

I see more clearly what you want, but no way =
to get there if the client browser/OS is =
unmodified.
I've meant that OS/browser is out of =
administrative control.

When (or if) you can formulate a clear, complete problem =
statement, let us know.

Joe
=

--Apple-Mail=_071E8F0D-BB25-416C-BA4F-91C7EBF913D6--


From nobody Sat May 23 01:21:26 2020
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 589813A09AC; Sat, 23 May 2020 01:21:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: tcpm@ietf.org, martin.h.duke@gmail.com, tcpm-chairs@ietf.org, michael.scharf@hs-esslingen.de
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159022208414.1743.204990648174561592@ietfa.amsl.com>
Date: Sat, 23 May 2020 01:21:24 -0700
Archived-At: 
Subject: [tcpm] tcpm - New Meeting Session Request for IETF 108
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, 23 May 2020 08:21:25 -0000

A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group.


---------------------------------------------------------
Working Group Name: TCP Maintenance and Minor Extensions
Area Name: Transport Area
Session Requester: Michael Scharf


Number of Sessions: 2
Length of Session(s):  100 Minutes, 50 Minutes
Number of Attendees: 60
Conflicts to Avoid: 

 Technology Overlap: tsvwg quic taps tsvarea iccrg panrg webtrans masque






People who must be present:
  Yoshifumi Nishida
  Michael Tuexen
  Martin Duke
  Michael Scharf

Resources Requested:

Special Requests:
  
---------------------------------------------------------



From nobody Mon May 25 17:56:08 2020
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 569423A0891; Mon, 25 May 2020 17:54:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Liang Xia via Datatracker 
To: 
Cc: tcpm@ietf.org, last-call@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159045449615.13336.5105636835437605086@ietfa.amsl.com>
Reply-To: Liang Xia 
Date: Mon, 25 May 2020 17:54:56 -0700
Archived-At: 
Subject: [tcpm] Secdir last call review of draft-ietf-tcpm-rto-consider-14
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: Tue, 26 May 2020 00:54:57 -0000

Reviewer: Liang Xia
Review result: Ready

This document is good written, and no new security issues as it's a network
mechanism requirements BCP document.



From nobody Mon May 25 23:52:14 2020
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 A03423A0C0C for ; Mon, 25 May 2020 23:52:11 -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, SPF_HELO_NONE=0.001, 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 BvmEKJoUiwKm for ; Mon, 25 May 2020 23:52:08 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 677603A0C0A for ; Mon, 25 May 2020 23:52:07 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id l15so22781521lje.9 for ; Mon, 25 May 2020 23:52:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lruVfi/szerdsRCI0kbJ4SLgE635ieSrMsPhFF1HU/E=; b=nOiulWr8fTiA6lTY3z+oaBnupQr38/Sdh7Cp/DbFHPn01l7uPRwVHdmy2UeKDXumsO fiJSYmu2VVXuAloTzBxcnDJAVR1APMmPLditHDk1GUd7BDqf0Dg0hK7T4CT1rXuAUYYp VSZmGe9OpcqXdh0Ixhy3zUIeHiEYYLLIFpXHpGe/mFFZsoC6RQNaXRebW1EkREohE1zg xm5PY7X9WnJPbMwNibqkH5QLy3ZyjvEubFzqTZJF2DWo6g3ZyG4BED4EiG9rSFX3KH9g H/baG/8pkWWYO12uoSV5AmNGeHIK0HqOjwtdsrjQub7IizMKYPUYHeYHuKDE8T+xPGyc pkgA==
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:content-transfer-encoding; bh=lruVfi/szerdsRCI0kbJ4SLgE635ieSrMsPhFF1HU/E=; b=NBvTjPVrp4RJnbt0FIT6I6ZSetOBBV9iaXHr1386XJdPNUd2e/eUpKD5pfBOomSxLi ZZcMEU79UDOkFoVCRor27e0Kpvx/N7zjunh0CgnfdsjxywO/aIqMhuvhfXHJxgMBvnRo F2zJ7Ju3Fb2AKglCHnUcNbI9hjdX3w1/mxnI3c9N/QbkGC00BQWnwSwwKN0YYncSTWt2 eQWsQqJFSFegDPZg4A1swC/S3JQW2aY+lQyUFU7GnOKbRdLSoXKPDt4vcFNomvuJSMCH YQ0cMbj3cxuLJH9+S+7vvJh+RI404gLD8ioq2OuO4vXvKnri/ldX3ao2HNFxEGkZsDHF W0tw==
X-Gm-Message-State: AOAM53181m+iHprPuiLnC16a9ccXDXzdxvfeSO5n7oqZwAkNC1mB3mvs JqkHOm+wibT8UETpmZqxqdqn39956/yqzVfBP61bfdufwJKdUgzl2GU5j6JXOU5qo5Qu07eIs+s SuuO+xm3jye+k
X-Google-Smtp-Source: ABdhPJz8tBhBgZ/0pyOqV5E7UGHHiGxP+v2XW7+i5H45h9Jka/P17cpspLhpvFPfIdnMC4qigv2eB1iTCu4c3EV0a/4=
X-Received: by 2002:a05:651c:2c1:: with SMTP id f1mr12645210ljo.440.1590475926150;  Mon, 25 May 2020 23:52:06 -0700 (PDT)
MIME-Version: 1.0
References:   <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net> 
In-Reply-To: 
From: Olivier Bonaventure 
Date: Tue, 26 May 2020 08:51:40 +0200
Message-ID: 
To: Alexander Azimov 
Cc: "tcpm@ietf.org Extensions" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tcpm] TCP Connection ID
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, 26 May 2020 06:52:12 -0000

Alexander,

> As far as I understand you are suggesting to use IP LSR/RH which SHOULD b=
e turned off by default (RFC7196). Besides, P and X, in your terms may belo=
ng to different address families. It seems that you still have confusion on=
 the purpose of my proposal:
>
> There is a browser, that sends a WEB-request. The request is sent to the =
virtual IP (VIP). The browser/OS is out of our control.
> There is a load balancer inside the datacenter, which receives an SYN pac=
ket and needs to send it to the server with real IP. Normally it is done vi=
a tunnel: IPIP or GRE. Both load balancer and server are under the same adm=
inistrative control.
> The idea is to introduce a connection id, that is generated by the server=
 at the time of SYN/ACK and kept at the client for the time of TCP session,=
 thus removing the need to keep the state at the load balancer. This brings=
 advantages in the case of DDoS attacks, load drain from servers, and traff=
ic rerouting between LB.

Another possibility would be to place the connection id in the network
layer, see doi:10.1109/TNET.2018.2799242

> Oliver:
> Thank you for the link! I was not aware of this paper. The option to adve=
rtise VIP looks interesting, but seem to have limitations:
>
> What if real server IP is IPv6 address while the client is working from I=
Pv4 only network?

If your VIP is IPv4 and the server behind the LB only support IPv6,
then you need the packets to pass through the LB anyway

> The attacker may learn the full list of backend servers, which can be use=
d for DDoS attacks. The dynamic IP allocation for connections may work as a=
 partial workaround, have you implemented it in the lab?

We did some tests but did not deploy that on busy servers

> The load balancer still needs to keep states of the connections. But it w=
asn't the problem that was addressed in the paper.
>

Indeed. The main objective of the paper was to show how to efficiently
support MPTCP on load balancers


Olivier

--=20


Disclaimer: https://www.tessares.net/mail-disclaimer/=20




From nobody Wed May 27 10:18:23 2020
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 149603A0F58 for ; Wed, 27 May 2020 10:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.082
X-Spam-Level: 
X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 MoflJwbXxNJw for ; Wed, 27 May 2020 10:18: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 EC1EE3A0F55 for ; Wed, 27 May 2020 10:18:20 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rI3JMmSJByHX8dLuRNFvLlnzz+wI90jU/OpIMiDu38I=; b=4toISfSbKFaYjpe5I4CKeOYYM Hno5gwDiHF4bmLbN6ufYqpqxTudG6hDgIMffMIwpkFJeEAXdMWv0l5s2In7f9xfL8DEnHKSP+1tmf qtmuWQ0e5rAWDkpogg/c9zvuucG6Xs85bX6AB446AqsJ63yVkg2ZMRQaXdv6Py73v1C0I19Rbti1v StZQGU2qn+2yqcP/wzQCVYR/I48dBOKZLEn8ay83H+8Un/CMic2BI6k424ovey7euHtg8qi/PgibF nuI+mU+p/u0p7f2jBvMq/7x/rnQWqxVXxM3AmQ/ThlcLoKupF1cwy4xJCkV/1GM7ahMY1i+c8IijE 5WlnifMZA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53701 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jdzh2-002dFR-1z; Wed, 27 May 2020 13:18:20 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_F14C23DA-A79F-4E46-A63B-B086002E9A34"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: 
Date: Wed, 27 May 2020 10:18:15 -0700
Cc: Alexander Azimov , "tcpm@ietf.org Extensions" 
Message-Id: <9FF84BB4-6AA8-4C37-8B51-D4B87228FCF6@strayalpha.com>
References:   <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net>  
To: Olivier Bonaventure 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] TCP Connection ID
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, 27 May 2020 17:18:22 -0000

--Apple-Mail=_F14C23DA-A79F-4E46-A63B-B086002E9A34
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On May 25, 2020, at 11:51 PM, Olivier Bonaventure =
 wrote:
>=20
> Another possibility would be to place the connection id in the network
> layer, see doi:10.1109/TNET.2018.2799242

Not unless the network layer is establishing the connection, IMO.

In IP, connections are transport layer and above; they shouldn=E2=80=99t =
be buried elsewhere. (And no, a flow ID is not a connection ID, because =
one flow may represent multiple connections or one connection may use =
multiple flows).

Joe=

--Apple-Mail=_F14C23DA-A79F-4E46-A63B-B086002E9A34
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On May 25, 2020, at 11:51 PM, Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:

Another possibility would be to =
place the connection id in the network
layer, see =
doi:10.1109/TNET.2018.2799242

Not unless the network layer is establishing =
the connection, IMO.

In IP, connections are transport layer and above; they =
shouldn=E2=80=99t be buried elsewhere. (And no, a flow ID is not a =
connection ID, because one flow may represent multiple connections or =
one connection may use multiple flows).

Joe
=

--Apple-Mail=_F14C23DA-A79F-4E46-A63B-B086002E9A34--


From nobody Thu May 28 04:38:05 2020
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 9B1833A0DB2; Thu, 28 May 2020 04:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puIzeQNFEAll; Thu, 28 May 2020 04:37:57 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30099.outbound.protection.outlook.com [40.107.3.99]) (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 21ED63A0DAF; Thu, 28 May 2020 04:37:56 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GBZtyX/pTL86UupL8/4icKuY6ngTu4apQQhQ1U/+DKRBnDp/u/010wmite2PNMaGxkIoA4+oVO/rq9Tr8k+asOQxmnsVO2G/oznPhKz3GtsUnmUylmQvtukacLgq4+PbPCVIDV2nkHuLxFAUWqWdbQW6Aybg0mHOrDaochyYIHlD9yvOMWJXiGs0VYADjT6DtsV08bsaekd8rOKvTmJjGfaLu0CJUkVF0GD3AV1B89yKyiH9dClsz24F0P9cmC5N6f3UMBvBsPmrO9ZZshX6J4bFkJzhcwwRsj2xlwfnYPEoQsrXvxDjcD2zItWtt2e3DGQVwYskxwpp3unTvw3Z6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7c9Y1qC6rWUhjpqJp8AR3tZlBMWXbTmKDXNMgW7Q7UY=; b=Zb4jOjq+JHMooFzxQGL9CfxC9R4ADjRClUn7b0WnPZK66KNxLRkUfRhj0rYp1UrTTYKWZz21dAqyYzdeM90inhoR0bERNR9zjpR1WHJrVml1H65b1b6W8ivaunlqf87h9SIN9PhVbxIPvF6dtAIzM2ikqLLaj+uv/0EHPMmRNehw9CgbeuGCWDBP9YrCvkYlX/ihFD3dwsp48bibiCjNsJ06cZmWxMMZhmc0DR0IO+6bLyB4KqiwL1POkV9wINNqd6JbaOInaQs0mxQ/jfW0XjD+o2mvBEr5OZFadB1jA14BbAUdzwXQVGrF5W8uUcaVCQ/0aKzQDz7cUyuhpeqHKA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7c9Y1qC6rWUhjpqJp8AR3tZlBMWXbTmKDXNMgW7Q7UY=; b=VA28CmktsNBSl8gVclkFgmqrHUHbdjwNd7HX4Ll4+oKBFyWjrcj8VlKsQjgu0J+s8BxPzfibGissOkEKyLHtP+agRKwiO3rhp9BTANkmaX+NkdsPzgvdfMARb1EEr9zaTOfb3P5hzZm2whod+zXKYFMcjnWP4zKUZPR0JHywPkg=
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB7PR07MB5735.eurprd07.prod.outlook.com (2603:10a6:10:54::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.7; Thu, 28 May 2020 11:37:54 +0000
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4%7]) with mapi id 15.20.3066.007; Thu, 28 May 2020 11:37:54 +0000
From: tom petch 
To: "last-call@ietf.org" 
CC: "tcpm@ietf.org" , "draft-ietf-tcpm-rto-consider@ietf.org" , "tcpm-chairs@ietf.org" 
Thread-Topic: [tcpm] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
Thread-Index: AQHWLR8TwR0U4MaFY0Oh73nrwMQPbai9bZHJ
Date: Thu, 28 May 2020 11:37:54 +0000
Message-ID: 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>
In-Reply-To: <158981133458.2481.15195759097492819350@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [81.131.229.108]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 870813ee-ee02-484a-422b-08d802fb8f97
x-ms-traffictypediagnostic: DB7PR07MB5735:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0417A3FFD2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GvfeEuqu/ygcy0XuTIN5XalNPw4KvhbSBVhzYT/6e3jKshChhLMFVyJO6fafE09ZEQ9tfPtKeN9OuON3ICMMWRN71TM4yCc6/0uD9+XXOwxUjC9rHWbqs0yznvsLGaeHtf6a+cEQ9rezXJsWh1a/+hvHgAJQmOTgNHIz0lx5Sjma0YqVYywSjrN+MjHk/9s7zEO9pOUWkuSZJ1Egu7hjtPV3hkV8aMa69bfV3f6kt7BhpW7NAum3fOkkXaN/Y619vCXGWN3Mt5aD+4ZJBp+CCec5kLeYXmo4pioH+Jan0Z5d6w2vFYjdKa7r78iiAt1XMOo4p9lv2BB8OpsSGTq8kr9Si20M+Ikg8zKVfkBXHIHdil1P1k3eidG08hPZ34Bfy3eUk/B/UbukMw6gk/uJvw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DB7PR07MB5340.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(39860400002)(366004)(396003)(376002)(346002)(136003)(9686003)(26005)(86362001)(2906002)(8936002)(478600001)(66574014)(186003)(54906003)(316002)(6916009)(966005)(83380400001)(450100002)(66946007)(66476007)(64756008)(91956017)(7696005)(66446008)(33656002)(4326008)(76116006)(52536014)(8676002)(55016002)(71200400001)(5660300002)(66556008)(6506007)(53546011); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: yd6eBM7uz4VaInt2H9XaJhDwvJQ5PIhZ7T3gVS6TqsDifAcDpzqxU1wB4phJg4Mc3SiIF020jwT24Wc4W7wNIVKjveHQm0j1s1aRaMCtUwnQdTTzpfOkyO2UZYYz6KtZ2B3Jp1GXgfIrAfJNmoECpef6k8KC0BugA57Vby1egYCFgad2Qey8+YmDvFMUVa2RpmDlIUE0GOgP2HhSWJPEhaTDJp7cYhp2KVpPfqI6+LcNS0RH2JE6KOPvb2XTGOkYdGMvHtdo6RFycXNleC/IkZK4bwDv0NGoQxhr+rz2KjEZlaZUW6teSvsUGJWR6LFnOQn6OHC7F5KXf+VfxIaWg20msWHQo0mT/tzrgV118VKpXE+vWzKj5omgyCqfQo07JGwZXENZNQ2iVWClR5LaxwKSHYIjZMVxCl82x4rne/FzSfAK7C384D+8FSi9YwAXTda10Ss1peP7htZg2y0eGeigJUyc4SbKXB/y1d9sbwXW3IJW2sqQ95EddLIfNcyR
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 870813ee-ee02-484a-422b-08d802fb8f97
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 11:37:54.1247 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: K4ZxzoyUOld/vK9C9mZYw9cfjFFyxwPSt4D1FhbKeDIVLU5yzmMhpGW4i84L6hEDiETbspo3T/T3THxvaaYyQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5735
Archived-At: 
Subject: Re: [tcpm] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 28 May 2020 11:38:00 -0000

Looking at this takes me back.=0A=
=0A=
The format of the references is not one I have seen in a long time, likewis=
e the running footing, the front matter and the placing of the Abstract whi=
le Terminology is also from a bygone age.  Ah, I see that the I-D is a deca=
de old - all is explained but I do think that an update is called for.=0A=
=0A=
Tom Petch=0A=
=0A=
________________________________________=0A=
From: tcpm  on behalf of The IESG =0A=
Sent: 18 May 2020 15:15=0A=
To: IETF-Announce=0A=
Cc: tcpm@ietf.org; draft-ietf-tcpm-rto-consider@ietf.org; tcpm-chairs@ietf.=
org=0A=
Subject: [tcpm] Last Call:  (Requireme=
nts for Time-Based Loss Detection) to Best Current Practice=0A=
=0A=
=0A=
The IESG has received a request from the TCP Maintenance and Minor Extensio=
ns=0A=
WG (tcpm) to consider the following document: - 'Requirements for Time-Base=
d=0A=
Loss Detection'=0A=
   as Best Current Practice=0A=
=0A=
The IESG plans to make a decision in the next few weeks, and solicits final=
=0A=
comments on this action. Please send substantive comments to the=0A=
last-call@ietf.org mailing lists by 2020-06-01. Exceptionally, comments may=
=0A=
be sent to iesg@ietf.org instead. In either case, please retain the beginni=
ng=0A=
of the Subject line to allow automated sorting.=0A=
=0A=
Abstract=0A=
=0A=
=0A=
    Many protocols must detect packet loss for various reasons (e.g., to=0A=
    ensure reliability using retransmissions or to understand the level=0A=
    of congestion along a network path).  While many mechanisms have=0A=
    been designed to detect loss, protocols ultimately can only count on=0A=
    the passage of time without delivery confirmation to declare a=0A=
    packet "lost".  Each implementation of a time-based loss detection=0A=
    mechanism represents a balance between correctness and timeliness=0A=
    and therefore no implementation suits all situations.  This document=0A=
    provides high-level requirements for time-based loss detectors=0A=
    appropriate for general use in the Internet.  Within the=0A=
    requirements, implementations have latitude to define particulars=0A=
    that best address each situation.=0A=
=0A=
=0A=
=0A=
=0A=
The file can be obtained via=0A=
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/=0A=
=0A=
=0A=
=0A=
No IPR declarations have been submitted directly on this I-D.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
tcpm mailing list=0A=
tcpm@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/tcpm=0A=


From nobody Thu May 28 09:32:46 2020
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 0BAA23A0FF3; Thu, 28 May 2020 09:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, 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=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-vPAY_ogRQb; Thu, 28 May 2020 09:32:41 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60134.outbound.protection.outlook.com [40.107.6.134]) (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 27C3C3A1013; Thu, 28 May 2020 09:32:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i2wvV/GLKc2zrJtpP10TwnC4dLFnOlFmYTxPdbf1vsRnlUS64rXdhB4x2IlUgbp9Fm3ReOQ90bsF4TpDMKVNJlA344H/BcQcGGgK8OK1te4K2Mvwo4ZsiEYQpdbp0tXXoL9F821tYVCesB+ZFKMHgUIzHyefarLxeuI1eFBT/0muSF1xYiZ7dLHERqLBLONYR3rvfsLZLrJtVoqAG+40R4/Wgkh7fsg/e+Y4qw0/sPwlLZPLYcp3aB9nctxH55DOqMmOtwJiBKbB+jPGP+e6b2IQmyxTQnQPaSbjLnUOOwJs/t6I5UckQdPj3hT9enbGXv8YqxYn2aw63Wgib7qa6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jr4rHBSEYtqm35zF7BlowWt5VeIg2AzjrccxVgwmvnc=; b=QVv2XsVKk6icjY6xBv6HH+mPWS/cZ4ggrj3MpYkkI67jU+H3hEQ5GO/Yhr6m+So3eSnE1HnHaRtMU3q8WVcJRkTHPvOnpC7byUe7lDjuWgQkqF4gFR/QsYldf66/LhOZcv40sH4LVCU/S39i5Mxvb7QztP1UvpyNdEfKU8zgjbNtnMTurYlKihrH6i6vsuLvB6pg8y6r9peANCJGP08DOhh3u8Pu8CfH2JCUd7Xfg6R8a1xrR/cexjzy548AFoS0tpwD6y7E1aHTkOYMbV0azKWmw1UjmL4rCcaxNEYRJStuSA7z/UHin0tN90/FPBhRAVZx993/bJi/NE75zSoe+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jr4rHBSEYtqm35zF7BlowWt5VeIg2AzjrccxVgwmvnc=; b=v+RvDPJsSjDWPqMn2aV/7fWXXp6QVZNoRssmWhZKnXUCKFrTyrS+bNYT+hWTdD8stk/lqaJ13VldaN28sJCJFv6P1s66KCxBIxeJEGidKpUyrzszYMMheCznbrZ/WKZwAs9tXXAFOFa10gNq7Eg+gx28JsBpKfXxBCDXRHSP5W0=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB2781.eurprd07.prod.outlook.com (2603:10a6:801:d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.13; Thu, 28 May 2020 16:32:21 +0000
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3045.015; Thu, 28 May 2020 16:32:21 +0000
To: last-call@ietf.org
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> 
Cc: tcpm@ietf.org, draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
From: tom petch 
Message-ID: <5ECFE791.3050400@btconnect.com>
Date: Thu, 28 May 2020 17:32:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO3P123CA0008.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::13) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.65] (81.131.229.108) by LO3P123CA0008.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3045.17 via Frontend Transport; Thu, 28 May 2020 16:32:20 +0000
X-Originating-IP: [81.131.229.108]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 763b12d9-1b6b-4ba8-8498-08d80324b1d3
X-MS-TrafficTypeDiagnostic: VI1PR0701MB2781:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 0417A3FFD2
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: FXN03wlfXTYdMNYi6nrHCr5TEyrZwLqP1AoHtll1lKNxEvJbdMGRHoHEPDztzIQwDImcEZkktG503VDhcfmIc7axFVMl14AxFyaeewG1V/pNKZdkovriCnVkf0m83YoXiNb+sNzNeZDzooQU7tG6oC890SCwx3rHVU5iwCJKHUf+FlH+fRAsE82qgEavl1nPZ+X49MpIKoqTbCPn3LMBneRXpW5d5QpCDgsEORaq5ZjeGovdh/glwdyWVGohCDr/V9kDo5wQUDTfnXqjDXoh7k9mbf/sdoJD38SoiRRMAZyj4n9gsYBpj5ZRbyJDzuccyRucGc0B7O3dxyFzz8dn+CuUSeUl3LG+20kgYO5CGbXgE6l30wrLuf5uzXQa6WdC3hvfPX/OpsfNpbSqqFAmbw==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(346002)(376002)(396003)(366004)(136003)(39860400002)(87266011)(186003)(450100002)(26005)(4326008)(16526019)(478600001)(66476007)(966005)(956004)(66556008)(2616005)(83380400001)(66946007)(5660300002)(36756003)(6666004)(66574014)(16576012)(33656002)(6916009)(53546011)(2906002)(8676002)(6486002)(86362001)(8936002)(52116002)(316002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData: YwaY6Sdmg83S+qfzW6XSffcBRlCL/hkdXqhMqawcy7BX4mjDCz5B3OusPbRGNVYj72oWigCAsGu0RLL4bJP3Orv7GdL2o7JvkX9FNgLmQGR06hJou/TUtTDNes3ph0RRQ83szGNRXHg5rXaQPNZuCDv5J5MyCoTVZyYdN2YVVdn1he3+jCSdXu9/zm7iRIrgfqn1emZm+Ugse+OJqh0zw6aM9i2hWIRh44qJxMHcZX91SZs7R/4HqwKSgvsbPrXCLCGkIWRHWpG4n+JFM9ryFoizqHdJWtiVq6oDaHjWfNh7wF1OYIJ3vvO65G6Dhjjl2mYWBtghZtHc+u9B1BC0MWZs0zfAIPI87u6OQqV5KW0y0WqzftcLpSZ9YbgW8RI/PhPti4xDL8V2qLrfSpN+XGyo7im4TMJxZA/o6BnndiB7sqXLMXNuvPmcqTkIfC9Xj/IT1ULiXvV6Gf14DfrXq9vBrSsuUz2Q+RnUW74tm5g=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 763b12d9-1b6b-4ba8-8498-08d80324b1d3
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2020 16:32:21.4288 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: l2ZmqF3QyeYlgwT1+CRAXQCuK86UmcSWPJhB0G/r5+Adn87qjWo2vIbdg/ExlbkJYretbf6v9LljN+3K2Cfsig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2781
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 28 May 2020 16:32:45 -0000

The content of this I-D puzzles me, a bit as if an academic paper had
been removed from its context and allowed to float away.

It talks of  'Within the standards process ...' which the rest of the
I-D implies is the IETF Standards process but it then recommends a
minimum RTO of one second which would be a catastrophe for some IETF
protocols which must detect failure in 10 milli-second so that repair is
effected within 50.

There are many references to safety so I looked at the Security
Considerations to see what the dangers are; none.  I am unclear what
these references to safety mean. What is the danger, what is the threat?

" When this time period passes without delivery confirmation the sender
concludes the data was lost in transit...." or the response was lost or
the response was witheld.  I hope that you never get an e-mail delivery
confirmation from me because while the protocol includes it, I will
always configure my MUA to suppress it; breach of security.

"Some protocols use keepalives, heartbeats or other messages to exchange
control information."  I struggle to think of an example of this.  On
the other hand, it came as a surprise to one protocol designer that when
he removed the plug on his connection, literally, nothing happened.
Layer 2 did not tell layer 3, layer 3 did not tell layer 4 and the
application was blissfully unaware, typical of the IETF protocol stack.
Ok failure detection is out of scope but I see heartbeat as primarily
for that purpose and have recommended it on a number of occasions.  (In
a similar vein, some IETF protocols are simplex so the best that can be
done is to add a heartbeat so that the urgent alarm, when it comes, has
a better chance of getting through). I find it hard to draw a hard 
distinction between failure detection and
loss detection.

I am ignorant of the technology encountered in server farms nowadays but
wonder if there is a degree of spoofing there, of ACK being generated at a
front end giving an illusion of a shorter FT, like a recursive resolver
but more so.

Overall the flavour I have is a document about TCP over the
ever-unreliable IP and lacking more general application.  TCP already 
has a rich literature of documents about timeout.  Not wrong, but
likely to be useful to the designer(s) of a new layer four protocol.

Tom Petch

>> ________________________________________
>> From: tcpm  on behalf of The IESG
> 
>> Sent: 18 May 2020 15:15
>> To: IETF-Announce
>> Cc: tcpm@ietf.org; draft-ietf-tcpm-rto-consider@ietf.org;
> tcpm-chairs@ietf.org
>> Subject: [tcpm] Last Call: 
> (Requirements for Time-Based Loss Detection) to Best Current Practice
>>
>>
>> The IESG has received a request from the TCP Maintenance and Minor
> Extensions
>> WG (tcpm) to consider the following document: - 'Requirements for
> Time-Based
>> Loss Detection'
>>     as Best Current Practice
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
> final
>> comments on this action. Please send substantive comments to the
>> last-call@ietf.org mailing lists by 2020-06-01. Exceptionally,
> comments may
>> be sent to iesg@ietf.org instead. In either case, please retain the
> beginning
>> of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>      Many protocols must detect packet loss for various reasons (e.g.,
> to
>>      ensure reliability using retransmissions or to understand the
> level
>>      of congestion along a network path).  While many mechanisms have
>>      been designed to detect loss, protocols ultimately can only count
> on
>>      the passage of time without delivery confirmation to declare a
>>      packet "lost".  Each implementation of a time-based loss detection
>>      mechanism represents a balance between correctness and timeliness
>>      and therefore no implementation suits all situations.  This
> document
>>      provides high-level requirements for time-based loss detectors
>>      appropriate for general use in the Internet.  Within the
>>      requirements, implementations have latitude to define particulars
>>      that best address each situation.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/
>>
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>


From nobody Thu May 28 10:10:57 2020
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 015623A0484 for ; Thu, 28 May 2020 10:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 SVafli4zzjQp for ; Thu, 28 May 2020 10:10:53 -0700 (PDT)
Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 BA0A23A03F3 for ; Thu, 28 May 2020 10:10:49 -0700 (PDT)
Received: by mail-ot1-f54.google.com with SMTP id h7so2949783otr.3 for ; Thu, 28 May 2020 10:10:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=qwmXUTOzh3fhL3bOKWYU+4ss1wgLTWzK3taZ1EQytDM=; b=iIqdQipVJDFThgn28AuTQKiZt16SdEY/yqXBCwylg9Nten1g5q96IIy0GJjdFybFZh OTV7kbYswsVHrpTcneF78wxgdl+IzDFxpB/IA+2THqEj2Cne+Jh2gb1kzAYfQ/Rdtrr/ b7sIa2+T9q4lS4UgoJcCUI4fiAdelAB75XY8gIKkvvUbkpgBGDBpJjdfYSfae8SYBXQl B2aARrrEGtn+ov8LKTdSrM40ciJrxwY0FZwAMZollJyC47CTj71T/mLH9KxuhNPKAZN6 Q0m/MNzUKFcLVFC8WQ4qhHyqwuiXvMMuyDVA5tE4yzZavCNb4mfBuT0C7hSJC5PI9cSe gs0A==
X-Gm-Message-State: AOAM532TNiBJ/f19IiLIdoReq6Ybhe2EDwe+jzeeVL7TTutnhZlw8yEN yTjLPCDRyyF92dVvhFZW2OIMGkA2BKk=
X-Google-Smtp-Source: ABdhPJwo1gFvfXf3OeWn2IX/VVVTSAANSg505I9PmP1jPNy3nWU0szWXo+te5Ij6GQIjSM3nSEEY1w==
X-Received: by 2002:a9d:6a0a:: with SMTP id g10mr3054182otn.105.1590685849071;  Thu, 28 May 2020 10:10:49 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:3c1d:c19b:e6c9:7c4e]) by smtp.gmail.com with ESMTPSA id d123sm1990454oib.6.2020.05.28.10.10.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2020 10:10:48 -0700 (PDT)
From: "Mark Allman" 
To: "tom petch" 
Cc: last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider@ietf.org,  tcpm-chairs@ietf.org
Date: Thu, 28 May 2020 13:10:47 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <6759B038-D034-4B0B-930B-EE568C4E35AC@icir.org>
In-Reply-To: <5ECFE791.3050400@btconnect.com>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_B8E667F7-D0CA-428D-8F13-8AB8A8E5FAF7_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 28 May 2020 17:10:55 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_B8E667F7-D0CA-428D-8F13-8AB8A8E5FAF7_=
Content-Type: text/plain

I just want to quickly correct one thing here ...

[the draft] then recommends a minimum RTO of one second

(a) It DOES NOT say this at all.  The document does not specify ANY
    minimum RTO.  The document does says this:

        In the absence of any knowledge about the latency of a path,
        the initial RTO MUST be conservatively set to no less than 1
        second.

    But, as soon as there is some notion (e.g., a RTT measurement)
    then there is knowledge and this no longer applies.  I.e., this
    is for the startup case where we are beginning transmission into
    an unknown network path.

(b) If this is too hefty for some application, that's fine.  Do what
    we do now and get consensus to use something different.  Again,
    the document says:

        The correct way to view this document is as the default
        case.

        [...]

        The requirements in this document may not be appropriate in
        all cases and, therefore, inconsistent deviations may be
        necessary (hence the "SHOULD" in the last bullet).  However,
        inconsistencies MUST be (a) explained and (b) gather
        consensus.

    In other words, the worst case is the current case.

I am not entirely sure I understand the remaining points in the
review as it's pretty rambling to me.  Certainly we use heartbeats
(in things like SCTP) and control packets (think TCP zero window
probes or keep-alives).  The document is very simply saying that if
these are used in some fashion we can also use them to measure FT
information.  That seems pretty reasonable to me and I can't figure
out what your complaint about that is.  Perhaps you could try again
so my pea brain can understand the complaint?

Thanks!

allman
--=_MailMate_B8E667F7-D0CA-428D-8F13-8AB8A8E5FAF7_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXs/wlxEcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizvYDAJ0RRj1r/gJpEizl8B5aEsJq8lfxKQCgkVJZ
C0ycsHNPyeZxyLORtxJo23E=
=+Byn
-----END PGP SIGNATURE-----

--=_MailMate_B8E667F7-D0CA-428D-8F13-8AB8A8E5FAF7_=--


From nobody Fri May 29 04:30:04 2020
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 749AB3A0063; Fri, 29 May 2020 04:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, 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=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOSjLg0B_UoK; Fri, 29 May 2020 04:29:57 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2122.outbound.protection.outlook.com [40.107.21.122]) (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 488343A005C; Fri, 29 May 2020 04:29:56 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VVT4paWTElB4/Ym0dkxjZ1IkXIMLyszYVQXu8gF6lUtc0HfiYuX5v1+J4KFxM/ijn47lmaGJ6jtmP2dXaRuuzN9Hpa7gM5FubihGL2WNUbKDNgdL8BF49gTQ9TsfbbZ4pw4fR8rbpLq2yyvAHJpljvmASUjkNhUetwwIfB1sowqDx89CwLKyAIVJXP5sXZXEU/nHXy78+bhJ+0uRVw+3WMj/QGw0F0QuCmni1WOvWOAiiePP+xrVe+S8xgqk7BXsInro/EXoPNmziNtWmOEnmJGm5gHn9xK6wWZTmQuvp9fF4FVy0Y2HXPMHkwMen3blGZFBMcYy1RbHkUO8kLKgQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v2t7ly0r0vTMj+DAyNJZ1lucBgxJ+a9PMciA1nO42mY=; b=WLsdKoA3bvOcYb/k0gwobFsfdj4Rq0PiSUfFtr9Q8Vp1QGyQnIVoOhgt9CT8hoOz98L8+Wi7PBg+6Y6ofz8t7kqc+WpjKYM3msHX5lKj6q8hIyHqSnoYmMZQDvcVorcqKnYab9AfAZXtUuwXrZR6rBlEUkRvYtXLKWnQadW1UCpdTv9H/J3pF1hBzJlAp2+1RY5OW9IcY5Fff8DbgNt+Us8KYMY5XyKgBJ8rQnfdS4iHND6HOCh9wtbRLmQbinIR9WB17hJb+YJvhK9SlYKL3XF92KxeWkrvTxy6e5EZoqNS0ViyGOfexa3g45WeQ0yBLnHSJNOCNxKwg1q6Sgr/uw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v2t7ly0r0vTMj+DAyNJZ1lucBgxJ+a9PMciA1nO42mY=; b=tso499skU/MhyaV88u9dJedpkus2/ygKVzOSX/Hx8hO3gfNLgg0mAqcRkOYGlB4bJVAKNbORZJg20HFxYyVrqL1EFZsJtfT6UeVz4wiH9/FnwVxmY3KnjMMw6LfzL3WrM2iB0zyA/YEMkfsnA3tgJk1m9cY1Zw995MxNfZ34swQ=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB2797.eurprd07.prod.outlook.com (2603:10a6:801:e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9; Fri, 29 May 2020 11:29:54 +0000
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3045.015; Fri, 29 May 2020 11:29:54 +0000
To: Mark Allman 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu>
Cc: Last Call , tcpm , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
From: tom petch 
Message-ID: <5ED0F22E.1070402@btconnect.com>
Date: Fri, 29 May 2020 12:29:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO2P265CA0070.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::34) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.65] (81.131.229.108) by LO2P265CA0070.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3045.19 via Frontend Transport; Fri, 29 May 2020 11:29:53 +0000
X-Originating-IP: [81.131.229.108]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ae2c1456-3f46-44a1-2310-08d803c39bd0
X-MS-TrafficTypeDiagnostic: VI1PR0701MB2797:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 04180B6720
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: GxT4lAqpeL+rDZfv+/PmpMrsjPc2RWeoB7jWi0yyUNOLA6DwUBW3GOAbwqHgVHy6+87Suzpiy4anvFwZ31uqqdXi2sGkCzm5Axb9S1ITJhEc6MjI0YQ1SBNXiZjV4GVU13lOomxqtt+RkglFIpqiFS9Nq7WhMeGyzldl43Geaj3rmohOC9+1/Y33eYVnW6gsTGJWhILmea4aH0w3MG2XYD18Hf728Xo2GxZ957yFvhPDff7KgAAIVF0ky4mpVKxp54tugzJnmDES4s0CWch4/OO7Lk4Lxs2Knsu2qcPY/UxEcjkBGYxCPDkI+rrnPpwp+rb5p9jK3D/yTwm/OGAu5g==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(396003)(346002)(136003)(366004)(39860400002)(376002)(16576012)(316002)(54906003)(5660300002)(83380400001)(6486002)(86362001)(8676002)(4326008)(8936002)(33656002)(87266011)(36756003)(2616005)(956004)(6916009)(478600001)(66556008)(186003)(66476007)(66946007)(26005)(2906002)(16526019)(52116002); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData: 04hZT71ys8q2DvDkxAXLxltRR3ykdUYlWn135HYn/qzCJ6yuttMJDTz4TwrR/pilyOtLdgY29XUSWgsHuNhQ9mfCw61EfNQW+KoIgulH8p1WaIYK8BUWfGDmXJu5DZnLaaf5W+3TYNRfDB3vDdomgQThV5AWykN7TYESDAxvAswDqQX5Oboy8LsDG1gF5Y9nmLZ4j0NVN0J79iK1w01+I7B7ZYQzIkOSZvjINZSt8J57PMp21YlFqG+zdZvuCIJCLP3eR2kfTF2r6ExmU2cXD/xxgKPRVzfHCJjDwRFbI0lPxN4hlxDgEfn++bibjMTxlCeaFlCImPSqvGRBoVMyW4e4JAaulJk458FSFx36n+T05dc9jnND1bCbVuXLYLaWKyc8TtBGGDrgTGPD/+bXJhnFHFscr3eEIocckP46SGA8nMsiOjJ3+0fl28B/Bo4Qh5B7Na2Zoej2LPl0iFQMDOAYPJ/t5y7zk3vJ8ccXtpY=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ae2c1456-3f46-44a1-2310-08d803c39bd0
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2020 11:29:54.4688 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Nray/C6CkIlImpAbTHsp/r0N6hY7SGA60MOD3HD/jbem/W9qQXKtxXyDTGBOvXvi4bJPOnRN+Jc/AI/ikfZyrw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2797
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 29 May 2020 11:30:00 -0000

Mark

Yes, my comments ramble:-)  The underlying thread is that for me the
document lacks context, lacks assumptions, or at least ones explicit
enough for me to pick up.

When I got to
"Within the standards process"
I thought IEEE standards process? mmm no, but the absence of IETF is the
sort of detail that I find missing albeit trivial in this case.

I see an underlying assumption that the network is unreliable and that
the problem is packets discarded as a result of congestion.  A common
assumption but untrue in some cases.  If that is the basis of this I-D,
then I think that it needs spelling out up front.

Likewise, I see an assumption that the recipient will always generate an
acknowledgement when asked.  Again, untrue for some protocols so again an
assumption I would like to see stated.

Safety is mentioned many times; what is the danger?  I do not know and
would like to be told (congestive collapse?).

"protocols ultimately can only count on the passage of time without
delivery confirmation "
true for some networks, not true for others.  I do see a steady if small
increase in IETF protocols to detect and react to problems rather than
waiting for someone else - like TCP - to notice and do something so
again I am seeing an assumption.

Apologies for misquoting you on the figure of one second; yes you offer
a more nuanced guideline.  Yet again it makes me think this is about
e.g. web access with HTTP while other IETF protocols are dealing with
timescales an order or two of magnitude shorter.

So I am conscious that the I-D comes out of the TCPM WG  but it seems as
if it tries to be all encompassing; and I struggle to think of an
application of the I-D which is not TCP until some standards body 
develops a new
transport protocol; but even then it would only be applicable if the
underlying network had the assumed characteristics of IPv4.

Tom Petch

> ----- Original Message -----
> From: "Mark Allman" 
> Sent: Thursday, May 28, 2020 6:09 PM
>>
>> I just want to quickly correct one thing here ...
>>
>>> [the draft] then recommends a minimum RTO of one second
>>
>> (a) It DOES NOT say this at all.  The document does not specify ANY
>>      minimum RTO.  The document does says this:
>>
>>          In the absence of any knowledge about the latency of a path,
>>          the initial RTO MUST be conservatively set to no less than 1
>>          second.
>>
>>      But, as soon as there is some notion (e.g., a RTT measurement)
>>      then there is knowledge and this no longer applies.  I.e., this
>>      is for the startup case where we are beginning transmission into
>>      an unknown network path.
>>
>> (b) If this is too hefty for some application, that's fine.  Do what
>>      we do now and get consensus to use something different.  Again,
>>      the document says:
>>
>>          The correct way to view this document is as the default
>>          case.
>>
>>          [...]
>>
>>          The requirements in this document may not be appropriate in
>>          all cases and, therefore, inconsistent deviations may be
>>          necessary (hence the "SHOULD" in the last bullet).  However,
>>          inconsistencies MUST be (a) explained and (b) gather
>>          consensus.
>>
>>      In other words, the worst case is the current case.
>>
>> I am not entirely sure I understand the remaining points in the
>> review as it's pretty rambling to me.  Certainly we use heartbeats
>> (in things like SCTP) and control packets (think TCP zero window
>> probes or keep-alives).  The document is very simply saying that if
>> these are used in some fashion we can also use them to measure FT
>> information.  That seems pretty reasonable to me and I can't figure
>> out what your complaint about that is.  Perhaps you could try again
>> so my pea brain can understand the complaint?
>>
>> Thanks!
>>
>> allman
>>
>>


From nobody Fri May 29 05:45:28 2020
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 097E03A07F0 for ; Fri, 29 May 2020 05:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level: 
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 b3elXM3UcDYX for ; Fri, 29 May 2020 05:45:21 -0700 (PDT)
Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (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 CEF533A07EE for ; Fri, 29 May 2020 05:45:21 -0700 (PDT)
Received: by mail-oi1-f174.google.com with SMTP id m67so2436592oif.4 for ; Fri, 29 May 2020 05:45:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=+QQtJ1k8DwH2+OQ69dEC9VTkk2Tf5yHABAGS7aXFdp8=; b=io7hOZ8SJK7Tm77WBKnZ6aduQdR1ucCzr6e4ehLvJdQ+XyRvKvD6Qgx6mVLArTUmMo YN8rZogD/gjK+BTWqtq8edJgi8Ml/sQLq568ISbi3qp21Gli54mufeu+6wTfcMUxkhfQ 2SzgQ+hfRspRn2vnw3HBgrF6/Jz2eVbgyt+gU6+fRRE68bW5N3ArMP9rdsEdTadopiPq YJ5s1u82rUpDi5furte0mAHU8hfaQ8FP4eWn7gEslqcNlMcBwoqbZPkLGMV70YgmEZXU hNlS3K4YA1I66zu7QW2I8W19bicNxqbYAdPBYtOD3m4Rtmpcd2cOg/0AzAT33nbX/8tL eQrQ==
X-Gm-Message-State: AOAM53239xVZdxPQE1PEWh3ZO2bwZyJ9KTUlw21+RqUZZ3HJ27laoX/w DqiiotvkDJZptzoy36RTyV9xpA==
X-Google-Smtp-Source: ABdhPJxVuAPQOBc2vrSE27eiPXJtZkFRvWBAwWF9oePUn364r8NjPRoVJh83gH/XVvcYxcA62vYxkw==
X-Received: by 2002:aca:914:: with SMTP id 20mr5233861oij.50.1590756320944; Fri, 29 May 2020 05:45:20 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:4590:6f1a:5acc:ba6]) by smtp.gmail.com with ESMTPSA id l8sm2462087otr.7.2020.05.29.05.45.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2020 05:45:19 -0700 (PDT)
From: "Mark Allman" 
To: "tom petch" 
Cc: "Last Call" , tcpm , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
Date: Fri, 29 May 2020 08:45:17 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org>
In-Reply-To: <5ED0F22E.1070402@btconnect.com>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_0D02A8CB-ACEA-4DFD-9BE1-442A666A6F8B_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 29 May 2020 12:45:23 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_0D02A8CB-ACEA-4DFD-9BE1-442A666A6F8B_=
Content-Type: text/plain


Hi Tom!

I am going to re-arrange slightly and deal with the last one first.

> So I am conscious that the I-D comes out of the TCPM WG but it
> seems as if it tries to be all encompassing;

Yes; we have found the guidelines are broadly applicable.

> and I struggle to think of an application of the I-D which is not
> TCP until some standards body develops a new transport protocol;

SCTP, QUIC, DNS, ... all manner of UDP applications.  Several
things:

  - In fact, RFC8085 (on UDP usage) includes many of the same things
    (cribbed from this I-D in some cases, actually!).  So, I think
    your framing this as applying TCP guidance too widely is
    incorrect.

  - The WG chairs were conscious of this and explicitly got input
    from folks working in these other (non-TCP) areas, as well.

  - The WGLC was run in both tcpm and tsvwg.

So I do think this is quite a bit more widely applicable than TCP.
It did start its life as a TCP document, but grew in breadth as
folks have said "hey, that applies [here]" (e.g., most recently when
Jana noted this was quite applicable within QUIC).  It has been
developed and reviewed as pretty general for a while now.  I don't
think we're somehow trying to sneak something through that is
broader than it either should be or has been reviewed to be.

I'll say something quick about the rest of the things, but basically
I am happy to add bits of clarification and fix sloppy writing.

> When I got to "Within the standards process"

Will add "IETF".

> I see an underlying assumption that the network is unreliable and
> that the problem is packets discarded as a result of congestion.
> A common assumption but untrue in some cases.

If your network is reliable then I presume you won't be reading
documents about loss detection.  But, I dunno.

We can add a sentence to the intro to explicitly say we are
discussing unreliable networks if that helps.

> Likewise, I see an assumption that the recipient will always
> generate an acknowledgement when asked.  Again, untrue for some
> protocols so again an assumption I would like to see stated.

I don't think we *assume* this is *always* the case.  This is from
the document:

    Various mechanisms are used to detect losses in a packet stream.
    Often we use continuous or periodic acknowledgments from the
    recipient to inform the sender's notion of which pieces of data are
    missing.

Without details, there is an acknowledgment there that there are
different ways to detect loss other than continuous ACKs.  And, we
state "often we use" ACKs, which I think runs counter to your notion
that we "assume" "always".  So, I am not sure what you want here.

> Safety is mentioned many times; what is the danger?  I do not know and
> would like to be told (congestive collapse?).

Safety in a congestion, not security, sense.  I can add a quick
clarification on this.

> "protocols ultimately can only count on the passage of time
> without delivery confirmation " true for some networks, not true
> for others.

I struggle to think of a case where it doesn't apply.  There are for
sure cases where we code the stream so that we get probabilistically
damn close to ensuring delivery without a continuous stream of ACKs
for specific packets.  But, without some feedback ("delivery
confirmation") to the sender how could we ever be sure the data
arrived?

> I do see a steady if small increase in IETF protocols to detect
> and react to problems rather than waiting for someone else - like
> TCP - to notice and do something so again I am seeing an
> assumption.

I can't follow this.  I don't mean to disagree with your
characterization of IETF protocols, but I don't understand how
you're applying that statement to the document.

allman

--=_MailMate_0D02A8CB-ACEA-4DFD-9BE1-442A666A6F8B_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXtED3REcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizsqjAJ4nwyp4n1eqEzta67QznAoSL48nlQCfW66R
REjesYiC/KtnFAkNKx1DW5o=
=EK8O
-----END PGP SIGNATURE-----

--=_MailMate_0D02A8CB-ACEA-4DFD-9BE1-442A666A6F8B_=--


From nobody Fri May 29 08:03:00 2020
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 84FEE3A005C for ; Thu, 28 May 2020 10:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.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 H0r0Bbt7ae4T for ; Thu, 28 May 2020 10:09:44 -0700 (PDT)
Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 CC4683A005B for ; Thu, 28 May 2020 10:09:44 -0700 (PDT)
Received: by mail-oo1-xc36.google.com with SMTP id v3so1246121oot.1 for ; Thu, 28 May 2020 10:09:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=lA+o4012FIuRL9MlTHZJo1q8ICFy9+nEt6UqUBbZKxQ=; b=UX9oVGh+8kvODKcOW0uoCxPDiVlDIwYlLtxlZDjKWJivRNPkZMiwhVTtbXbnZPsPSJ zCsTzE1Fl9SICloKB83h/o32GDjlSOkM80rYyu5q4ajYi9+kgFb3U7VY+1AUhY8YHs2E 6WSqXl31jCryhXxpE0cI8NjJoUl6yS4zdSL0c/Sm8U9hgugEMKzDDwn9QnVhpmqfQpJE 0+uyg/TLB6LSZMMe1ewSZQqMGGStbdzIINcYwre9sDygmVVePAULISy1Fh84YwagAVki YFgZtOVxK9SfUptMMMooi2o+PwToMftorL/EG0cdEKbpdu9DfPNzhgIJx/TUF11N+iLd SfpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=lA+o4012FIuRL9MlTHZJo1q8ICFy9+nEt6UqUBbZKxQ=; b=N3ikiNtTIvj4sMKUDPjPyzAw8w1pebV6woV+p6rRTQRrS7sGkhvsecspiw9wc6lgt/ Fe5EKtybNCyGhmCtcN/dTKM4Asgp5rdW3hV8vWZ07MQnDH3Txe4tF25CVlzN332BfA+M H8ymlozkuGAhPalE8tg1ZgIst4Ivj0gaov2/b9+vTv2BqKqGQS5GXYzc6VCFxPDn1ayQ 7Da8yDGu8g3gbAxVPgAS3V1jfksTgh+KGX4LoC37K3oOnj3DTIn3Qn5jrTJFDzrGjCXr vfphKPZAv9wZxsqvEXBsXfSyVzMd3DlnJWiP27OGj7UxFeoBCWHw7SUMd1LynyznazKU hKEw==
X-Gm-Message-State: AOAM530r5JhKJgPsH97FM8M1HYDrOIfJnvO7C8N7uCT2GUr73UFn65nQ kGkKbbRtL8XST8h6I/A+xWjAdp9vyig=
X-Google-Smtp-Source: ABdhPJyrLQ6yQ7TuBn8u7VcXi+6tzQvHYnyQ8JScfz2FasLd0Z+XXzLv+6cvLbQ2B/A/B0HwOQJL4A==
X-Received: by 2002:a4a:381:: with SMTP id 123mr1364729ooi.85.1590685784043; Thu, 28 May 2020 10:09:44 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:3c1d:c19b:e6c9:7c4e]) by smtp.gmail.com with ESMTPSA id w2sm493574oon.36.2020.05.28.10.09.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2020 10:09:43 -0700 (PDT)
From: "Mark Allman" 
To: "tom petch" 
Cc: last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider@ietf.org,  tcpm-chairs@ietf.org
Date: Thu, 28 May 2020 13:09:41 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu>
In-Reply-To: <5ECFE791.3050400@btconnect.com>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_42FFD37B-5BE3-4C2A-A5FE-EEB540C6FC81_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
X-Mailman-Approved-At: Fri, 29 May 2020 08:02:59 -0700
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 28 May 2020 17:09:48 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_42FFD37B-5BE3-4C2A-A5FE-EEB540C6FC81_=
Content-Type: text/plain


I just want to quickly correct one thing here ...

> [the draft] then recommends a minimum RTO of one second

(a) It DOES NOT say this at all.  The document does not specify ANY
    minimum RTO.  The document does says this:

        In the absence of any knowledge about the latency of a path,
        the initial RTO MUST be conservatively set to no less than 1
        second.

    But, as soon as there is some notion (e.g., a RTT measurement)
    then there is knowledge and this no longer applies.  I.e., this
    is for the startup case where we are beginning transmission into
    an unknown network path.

(b) If this is too hefty for some application, that's fine.  Do what
    we do now and get consensus to use something different.  Again,
    the document says:

        The correct way to view this document is as the default
        case.

        [...]

        The requirements in this document may not be appropriate in
        all cases and, therefore, inconsistent deviations may be
        necessary (hence the "SHOULD" in the last bullet).  However,
        inconsistencies MUST be (a) explained and (b) gather
        consensus.

    In other words, the worst case is the current case.

I am not entirely sure I understand the remaining points in the
review as it's pretty rambling to me.  Certainly we use heartbeats
(in things like SCTP) and control packets (think TCP zero window
probes or keep-alives).  The document is very simply saying that if
these are used in some fashion we can also use them to measure FT
information.  That seems pretty reasonable to me and I can't figure
out what your complaint about that is.  Perhaps you could try again
so my pea brain can understand the complaint?

Thanks!

allman

--=_MailMate_42FFD37B-5BE3-4C2A-A5FE-EEB540C6FC81_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHgEARECADgWIQR2wAGDYhexl/6SqCRbKutazjIizgUCXs/wVRocbWFsbG1hbkBp
Y3NpLmJlcmtlbGV5LmVkdQAKCRBbKutazjIizkOwAJ4wCGaox8U5dFljRHE7FZlA
NJ3vPACgn5X2Bv15+gEUpgvaix2SIpOU68g=
=cmLS
-----END PGP SIGNATURE-----

--=_MailMate_42FFD37B-5BE3-4C2A-A5FE-EEB540C6FC81_=--


From nobody Sat May 30 04:27:03 2020
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 6A3643A090E; Sat, 30 May 2020 04:27:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stewart Bryant via Datatracker 
To: 
Cc: tcpm@ietf.org, last-call@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159083802039.5596.14695350463305243689@ietfa.amsl.com>
Reply-To: Stewart Bryant 
Date: Sat, 30 May 2020 04:27:00 -0700
Archived-At: 
Subject: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 30 May 2020 11:27:01 -0000

Reviewer: Stewart Bryant
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-tcpm-rto-consider-14
Reviewer: Stewart Bryant
Review Date: 2020-05-30
IETF LC End Date: 2020-06-01
IESG Telechat date: Not scheduled for a telechat

Summary:

I have concerns that there is inadequate scoping information provided in this
proposed BCP.

The authors are clearly focused on some L4 cases and some applications. I am
concerned that this document, if published as is, will result in excessive work
and delay if reviewers insist that it applies to many network infrastructure
cases. I am also concerned that past
 experience may not be a good guide to some new applications, particularly those
from the deterministic stable.

Major issues:

As far as I can see this text only applies to exchanges between applications
and network support applications such as DNS. I.e. this is targeted at layer 4
and above. Given the religious nature of BCPs in the eyes of some reviewers,
and to prevent endless explanations by those that design routing protocols, OAM
and other lower layer sub-system I think there needs to a scoping text in block
capitals at the at the very start of the documnet.

=========

      - The requirements in this document may not be appropriate in all
        cases and, therefore, inconsistent deviations may be necessary
        (hence the "SHOULD" in the last bullet).  However,
        inconsistencies MUST be (a) explained and (b) gather consensus.

SB> That can be quite an onerous obligation  and provide scope for endless
argument when reviewers are not domain experts in the protocol being
designed.

=======

          While there are a bevy of uses for timers in protocols---from
          rate-based pacing to connection failure detection and
          beyond---these are outside the scope of this document.

SB> I am not sure what that means for the applicability of this document.

=========

    (1) As we note above, loss detection happens when a sender does not
        receive delivery confirmation within an some expected period of
        time.  In the absence of any knowledge about the latency of a
        path, the initial RTO MUST be conservatively set to no less than
        1 second.

SB> This issue may be addressed by the scoping text, but 1s is no use
when you are trying to detect sub 50ms of packet loss in the infrastructure.

=============

    (3) Each time the RTO is used to detect a loss, the value of the RTO
        MUST be exponentially backed off such that the next firing
        requires a longer interval.  The backoff SHOULD be removed after
        either (a) the subsequent successful transmission of
        non-retransmitted data, or (b) an RTO passes without detecting
        additional losses.  The former will generally be quicker.  The
        latter covers cases where loss is detected, but not repaired.

        A maximum value MAY be placed on the RTO.  The maximum RTO MUST
        NOT be less than 60 seconds (as specified in [RFC6298]).

        This ensures network safety.

SB> This does not work in OAM applications.

Minor issues:

 "By waiting long enough that we are unambiguously
  certain a packet has been lost we cannot repair losses in a timely
  manner and we risk prolonging network congestion."

I have a concern here that the emphasis is on classical operation. We are
beginning to see application to run over the network where the timely delivery
of a packet is critical for correct operation of even SoL. As a BCP the text
needs to recognise that the scope and purpose of IP is changing and that
classical learning and rules derived from them may not apply.

Also if not ruled out of scope earlier we need to be clear at this point that
things like BFD have different considerations.

==========

      "- This document does not update or obsolete any existing RFC.
        These previous specifications---while generally consistent with
        the requirements in this document---reflect community consensus
        and this document does not change that consensus."

I think it needs to be clear that adherence to this RFC is not required for
minor updates and extensions to existing RFCs. Having seen minor routing
extension held up by security concerns related to underlying protocols rather
than the extension itself there is a lot of sensitivity on this point in some
quarters of the IETF.

========

It might be useful to make it clear that there are some applications that would
prefer no data to late data.

Nits/editorial comments:

The terminology section confuses ID-nits - I think it should be a section in
its own right later in the document.

The following nits issues need looking at

  == Missing Reference: 'RFC5681' is mentioned on line 377, but not defined

  == Unused Reference: 'RFC3940' is defined on line 515, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4340' is defined on line 519, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6582' is defined on line 540, but no explicit
     reference was found in the text



From nobody Sat May 30 04:35:37 2020
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 B7E3A3A0918; Sat, 30 May 2020 04:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, 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=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuf4tVFzXHpO; Sat, 30 May 2020 04:35:28 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2093.outbound.protection.outlook.com [40.107.21.93]) (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 95E5B3A0917; Sat, 30 May 2020 04:35:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B2PTGPo3okD5dfoAr6PsMo6Zjjc92l/wxAkMcdWHUoXHbZlixcUUZ+NJXmLqBLyVZRqJdsr6kNsGZKSU9BceOor9Mpw57wiiKQG6elVB7+JolJceUAIYxTCCVUrDJmtwJxYvg6vMrGMqsWPxWCojokUoPmZFHUWXrmJ0TiYNaVqjXqM4ZZwMmrH9DsOkSqLvqgY3EStzmJh7LaCQjduhwnDl2Wdffjk4jR21eNIRuDNsTkjQjudhoCD3k2IukRhiE+Qp5qkSxvaM9NnP2YCXvhpuwJZflwvu5LPD8F3ELdsWRnOAYt0qX1WrQiEGkUgxgJdk2NPpxZeJ0wC8GumsqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fOCKz2kOi38egCBOcc5yYUrIcGnCcCVU11U4SzCQCV8=; b=XoZHdktVpSd7HRCntdl0IOYueaoo3yNGrHQtj1LkLWw8B94dVqzOJws72P7zL/Ua+whdT13yES/+sEaDJih4+yOLbGD4bPWvcBLZNEROFbinCrOhuAIj4RGkl1ENYi8WWHp7GaH6hLWLrNgHOwJ9ScAUCecjwNNFFLpTdGN+3dcRk1HeZDY5qxo4dIn6OkuHnxC1CauempE4GuL3FAbmR0KFRAuCTDVn3A8P5WfjmPyyV1IFZoezbzdB89Orh3HKp/rrhYHgbHvEEY+qeR7Cc/v2gT5fazKurIh7qXk+GpR0vzpUgnmllJ5+0HLXU2boVyCv6jNXySBdYweNZKZ/0g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fOCKz2kOi38egCBOcc5yYUrIcGnCcCVU11U4SzCQCV8=; b=e1X/gMWGGxHzFFR/kB0AX2spk1j8DJYqVb90a+hCnQD/GaB2yFPkxVST3fBtNyLc6jRsfNsstv7A2GvDCiJw7LADybSptRqSqq3St00J5YT59d5Q61sV3gHqJ86+eyUpw70nP9dwkE55HvFsn3aJ5/7TnEpWuM6lN/6GLyxY/wc=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB2832.eurprd07.prod.outlook.com (2603:10a6:800:85::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.12; Sat, 30 May 2020 11:35:23 +0000
Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3066.010; Sat, 30 May 2020 11:35:23 +0000
To: Mark Allman 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org>
Cc: Last Call , tcpm , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
From: tom petch 
Message-ID: <5ED244F7.7030307@btconnect.com>
Date: Sat, 30 May 2020 12:35:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO2P265CA0138.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::30) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.65] (81.131.229.108) by LO2P265CA0138.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3000.26 via Frontend Transport; Sat, 30 May 2020 11:35:22 +0000
X-Originating-IP: [81.131.229.108]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d414c160-4989-412c-a1e0-08d8048d8a88
X-MS-TrafficTypeDiagnostic: VI1PR0701MB2832:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 041963B986
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Q/8A56DVNyA1SzoboYYGwsbu8Gwc6yE+O+hQn3u6HJuDdTFeCNao9C9Tj55Sn2RgABmZavX8T7D9zhW4jN3ZEToitgrWGxC3cvd7TdoX5u0Pd+zvTQtmjV2K1YGTjqvmXqaYHk1LNktYDILLcP9EY17FYvli5SkA5X1rT4fGOaYr7z8/hOZONVmn2kebnIOri2+Om3nZyJ1SI9cdu9Jgby1qAn86gRDSzav6AbEP4ALGtB52RRWgIRnkCqs2gmnzK6PPyHp5nsXfmvU5kVFJL7JY44WrqmBXeGZAv3Tf48YnR/MZQdRr/2McpLKlrvaPEgWWfnbArATm+2rk+FrBLQ==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(376002)(396003)(39860400002)(346002)(366004)(136003)(316002)(36756003)(16576012)(478600001)(956004)(87266011)(6486002)(33656002)(2906002)(66476007)(54906003)(66946007)(83380400001)(86362001)(66556008)(6916009)(52116002)(6666004)(4326008)(2616005)(5660300002)(8676002)(8936002)(186003)(16526019)(26005); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData: p2onv09f2/sCTG5CSLALqCdBlKWz8+0eIod0cAZemnfkQD3Kc86cg4NWMLvfJfY6W2VR49v7yPemh/cJIP8donYAfhbSEJULzHOR8B8fE1OnSueZxPX/603tZjQS1Eklxh7dKwL3FvtjVE3zI0TXsQI54z06jRJVNeVlzjHv74PH4mSU416M8AfMXFSN9aafFxM7JYz69Mnu4/UI7loRA67s2w87J32xA39vGjij8gLZ602EEYoSTcMb3KEzVx9A5cXCoYzftEG5epses7y5zfCnES5WXESBTXYYrlPbrk/LK5M8sdq75faVNbmbMU795PGwmMRXt+nrqdDGWmOb+pS1RplfJaBY8nWhEBVOBTJaKrdtcxBjoZHuoluDv8mN5YFP5oFIK0FRhAkRuLdIa14qFdJNESFtuqwfLn+D543yIb25bnaALA5PLwHVC8cwmbN+eeX0TCFilqO7AG1pfHGfzqitnVsqnLaMyimKH1o=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d414c160-4989-412c-a1e0-08d8048d8a88
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2020 11:35:23.7063 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Mt5F2cthM8LTUoLaHuYdTfgrHjpIwP2SYYqRw5oJOAmMMfgHYdCZqx7MR1fGHGhS0k5NbuB3v1S71bYV8t1XHw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2832
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 30 May 2020 11:35:33 -0000

> ----- Original Message -----
> From: "Mark Allman" 
> Sent: Friday, May 29, 2020 1:45 PM
>
>> Hi Tom!
>>
>> I am going to re-arrange slightly and deal with the last one first.
>>
>>> So I am conscious that the I-D comes out of the TCPM WG but it
>>> seems as if it tries to be all encompassing;
>>
>> Yes; we have found the guidelines are broadly applicable.
>>
>>> and I struggle to think of an application of the I-D which is not
>>> TCP until some standards body develops a new transport protocol;
>>
>> SCTP, QUIC, DNS, ... all manner of UDP applications.  Several
>> things:
>>
>>    - In fact, RFC8085 (on UDP usage) includes many of the same things
>>      (cribbed from this I-D in some cases, actually!).  So, I think
>>      your framing this as applying TCP guidance too widely is
>>      incorrect.
>>
>>    - The WG chairs were conscious of this and explicitly got input
>>      from folks working in these other (non-TCP) areas, as well.
>>
>>    - The WGLC was run in both tcpm and tsvwg.
>>
>> So I do think this is quite a bit more widely applicable than TCP.
>> It did start its life as a TCP document, but grew in breadth as
>> folks have said "hey, that applies [here]" (e.g., most recently when
>> Jana noted this was quite applicable within QUIC).  It has been
>> developed and reviewed as pretty general for a while now.  I don't
>> think we're somehow trying to sneak something through that is
>> broader than it either should be or has been reviewed to be.

  Mark
  This is good to hear but I wish that more detail of this was in the I-D.
  I have followed a number of Transport AD review of xxxx-over-UDP and it
  was always about the need for flow control but never with the sort of
  techniques that TCP uses, usually just a requirement for a statement on
  rate limiting by the sender so if there are xxxx-over-UDP which measure
  RTO and lost packets and act accordingly, then that would be excellent
  to hear about.  I know of none (and yes I am familiar with RFC8085) so
  including non-TCP examples would counter the impression I have got that
  this is TCP!   SCTP I have always seen as son-of-TCP and so not much
  different in this context.  QUIC I have yet to encounter.  As it stands,
  the example of DNS caching server stands out to me as an example of
  broader application, of the I-D in general; I would value more such
  concrete examples. And below ...


>> I'll say something quick about the rest of the things, but basically
>> I am happy to add bits of clarification and fix sloppy writing.
>>
>>> When I got to "Within the standards process"
>>
>> Will add "IETF".
>>
>>> I see an underlying assumption that the network is unreliable and
>>> that the problem is packets discarded as a result of congestion.
>>> A common assumption but untrue in some cases.
>>
>> If your network is reliable then I presume you won't be reading
>> documents about loss detection.  But, I dunno.

  No, I am being unclear.  It is the 'packets are lost due to congestion
  and that is THE problem' that I see as the unstated assumption for this
  and many IETF documents.  Is it correct? Often, perhaps, but I struggle
  to recall anyone testing the hypothesis and there is growing use of IETF
  protocols over different kinds of networks where the problem is e.g.
  interference and packet corruption so the recommended techniques will
  give the user a worse experience - the corrupt packet needs
  re-transmitting as soon as the interference is over and backing off the
  flow rate is bad news for the user.  And below...

>> We can add a sentence to the intro to explicitly say we are
>> discussing unreliable networks if that helps.
>>
>>> Likewise, I see an assumption that the recipient will always
>>> generate an acknowledgement when asked.  Again, untrue for some
>>> protocols so again an assumption I would like to see stated.
>>
>> I don't think we *assume* this is *always* the case.  This is from
>> the document:
>>
>>      Various mechanisms are used to detect losses in a packet stream.
>>      Often we use continuous or periodic acknowledgments from the
>>      recipient to inform the sender's notion of which pieces of data
> are
>>      missing.
>>
>> Without details, there is an acknowledgment there that there are
>> different ways to detect loss other than continuous ACKs.  And, we
>> state "often we use" ACKs, which I think runs counter to your notion
>> that we "assume" "always".  So, I am not sure what you want here.
>>
>>> Safety is mentioned many times; what is the danger?  I do not know
> and
>>> would like to be told (congestive collapse?).
>>
>> Safety in a congestion, not security, sense.  I can add a quick
>> clarification on this.

  Yes please, this is an example of what I generically refer to as a
  lack of context, that for me safety is usually something quite
  different in an I-D.  And below ..

>> "protocols ultimately can only count on the passage of time
>>> without delivery confirmation " true for some networks, not true
>>> for others.
>>
>> I struggle to think of a case where it doesn't apply.  There are for
>> sure cases where we code the stream so that we get probabilistically
>> damn close to ensuring delivery without a continuous stream of ACKs
>> for specific packets.  But, without some feedback ("delivery
>> confirmation") to the sender how could we ever be sure the data
>> arrived?
>>
>>> I do see a steady if small increase in IETF protocols to detect
>>> and react to problems rather than waiting for someone else - like
>>> TCP - to notice and do something so again I am seeing an
>>> assumption.
>>
>> I can't follow this.  I don't mean to disagree with your
>> characterization of IETF protocols, but I don't understand how
>> you're applying that statement to the document.

It comes back to the assumption of a unreliable network, unreliable for
any reason, not just congestion.  An alternative approach is to make the
network reliable and this I see as a strong interest of WG such as TEAS,
CCAMP, MPLS and such like.  A statement up front about the assumption of
unreliability would address this.

Tom Petch
>
>> allman
>>
>>


From nobody Sat May 30 11:06:31 2020
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 0D01F3A094C; Sat, 30 May 2020 11:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 C0aZO9brXrXv; Sat, 30 May 2020 11:06:28 -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 222D23A094A; Sat, 30 May 2020 11:06:27 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8BEB925A2F; Sat, 30 May 2020 20:06:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1590861981; bh=OYZeUtOoopTladdGtqXunBTTjYh1xqidtMqjadT1VC0=; h=From:To:CC:Subject:Date:From; b=ro9OspP/OkAjW3kqCMvLdAkixc/iOklTyR1fZ2RR7pmAAIV8anMvDZj6ac9MpXKcQ lLYfghlZMN9adx9y9VpW+4L6OcXwHYRLpYnzp5wVIOuMi2Y70A8TRVXo23VFZNcKvI Lxo0Q99gI6FCIi2/JSsdsFO0iKNu7Kxso6oVFyKE=
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 e0NkLK-rbeAa; Sat, 30 May 2020 20:06:20 +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; Sat, 30 May 2020 20:06:20 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sat, 30 May 2020 20:06:19 +0200
From: "Scharf, Michael" 
To: "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: WGLC for draft-ietf-tcpm-2140bis
Thread-Index: AdY2q5V4X+rIUW7ARceWWppze0a72w==
Date: Sat, 30 May 2020 18:06:19 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC2102A@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.48.164]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] WGLC for draft-ietf-tcpm-2140bis
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, 30 May 2020 18:06:30 -0000

Hi all,

The document "TCP Control Block Interdependence" (draft-ietf-tcpm-2140bis) =
is out there for a quite some time already. Given that there has been a bit=
 less activity on the list after the interim, let's use this opportunity to=
 finish one of our milestones...
=20
This e-mail starts a WGLG for the document draft-ietf-tcpm-2140bis. The WGL=
C will run until ***June 14***.

The intended status is an informational RFC. The current version of the doc=
ument can be found at:

https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05

Please review the latest version and please let us know any comments or sug=
gestions. TCPM needs reviews to ensure that the content is ready to move fo=
rward. Feedback supporting publication ("+1") is also very welcome.

Thanks

Michael, on behalf of the TCPM chairs


From nobody Sun May 31 11:54:19 2020
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 414F93A0BAE; Sun, 31 May 2020 11:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLO90YRNHvrY; Sun, 31 May 2020 11:54:11 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6D76B3A0BA1; Sun, 31 May 2020 11:54:10 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04VIs2Gc000540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 May 2020 14:54:04 -0400
Date: Sun, 31 May 2020 11:54:01 -0700
From: Benjamin Kaduk 
To: Mark Allman 
Cc: tom petch , last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
Message-ID: <20200531185401.GU58497@kduck.mit.edu>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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: Sun, 31 May 2020 18:54:13 -0000

On Thu, May 28, 2020 at 01:09:41PM -0400, Mark Allman wrote:
> 
> I am not entirely sure I understand the remaining points in the
> review as it's pretty rambling to me.  Certainly we use heartbeats
> (in things like SCTP) and control packets (think TCP zero window
> probes or keep-alives).  The document is very simply saying that if
> these are used in some fashion we can also use them to measure FT
> information.  That seems pretty reasonable to me and I can't figure

There was a quote from the document: "Some protocols use keepalives,
heartbeats or other messages to exchange control information."
A naive reading of this text is that it is discussing ways to exchange
control information, and giving specific examples of keepalives and
heartbeats as messages used to exchange control information (while admitting
the existence of other such messages).  This is as surprising to me as it
is to Tom -- keepalives and heartbeats do not, in my experience, contain
control information!

Your follow-up discussion suggests that the intent is to say that "some
protocols use regular/periodically/frequently exchanged messages, such as
for keepalives, heartbeats, or control-information exchange" and to
leverage that traffic for FT purposes.  I suggest that this be clarified in
the text of the document.

Thanks,

Ben