From nobody Fri Mar 12 10:27:07 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866943A1A41 for ; Fri, 12 Mar 2021 10:27:02 -0800 (PST) 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 uHszHqDWX0wv for ; Fri, 12 Mar 2021 10:27:01 -0800 (PST) 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 EAD263A1A48 for ; Fri, 12 Mar 2021 10:27:00 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id j4so2062038uan.1 for ; Fri, 12 Mar 2021 10:27:00 -0800 (PST) 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=iBJnp2vm+Ts9Y38eXAtTjNfqCakQUrPprUYehZYdI7I=; b=dDqQ/BkzDxBEZAtEXC8nQHiyT4YB/cOAs4sSHVZeoae1wnIHMZ1jU3yaM33FxcCADE OsA0mCQ1RYp2TuMii2L6CAkhLt/9ScAYB4VjKS+3v5Bf2CGx6+UPRmVRJObOCjfEnYf0 xEHpiLWPXUu/NkZ6zgje4Jw47fUgZV1p0neDzsMkBEd2gruNmfe6y2JGOBG32GCJom1G 2pzxBQWkCDZBFrd3nc4rSB/NA+Q+cqH1KvyqpC4ObFZO6zaJHyq/hAv2/Q+T7g1WNAu+ NlH7ijcb4eP2uBcbKVhgCoBrEXOEfcOMpdMuTbjut9VyNlMk7GjrxTDhzIozbuc7JlYN 2eUA== 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=iBJnp2vm+Ts9Y38eXAtTjNfqCakQUrPprUYehZYdI7I=; b=S9niGhoQIUD6D+yaxUCx1e/SI7IfCihtnYqu0Lt6ONZ6Ki9XHzy7CDH+NEmkA22bgM sJ1wjyPzluvdfMGHOEpNs8ug6A/cmbiPtRwZbSIerzqp3ORGD//gjKn9gDHvDajctPt3 1CrNhAwvr18gjjnh3jmfHaTkzqRsXx4hMybYqnWnHjh4eYoNXR0ZrAT/pmWZBfeRonbY 5YUepM8RcQ6+OzEif65qQgQW9Fr990NJDcVSEl3NnTspYVSZp4n2VtjRBAsWiorO07oQ t+LNHojlR9X2UeVWfvUfG8LCj6zCieZd4JOQZL0DSHzjkFrW+f+6bWuMHCus44Ix8hzn e92w== X-Gm-Message-State: AOAM5337xP+l3C5Qu3/xmu2swWT5Zk476xKFjIoL1sHbw7q4q3916H0p aLDq1WJ8HcpY/Ql9ybe3z3xaN8WSPjAFASMPkL0xNw== X-Google-Smtp-Source: ABdhPJz5A4uSnih5eD0mGnbSNZZ1QWJ6qXdH4IgFp9YYO3/xsDl1zTSQ9GufCJM+Zs2A0lODcwcH8O/g83XNU+KSXlY= X-Received: by 2002:ab0:382:: with SMTP id 2mr10114030uau.46.1615573617698; Fri, 12 Mar 2021 10:26:57 -0800 (PST) MIME-Version: 1.0 References: <161529694562.32408.1003733576456029769@ietfa.amsl.com> <24aa2c28-41e3-6a14-7ffa-88418745c154@bobbriscoe.net> In-Reply-To: From: Neal Cardwell Date: Fri, 12 Mar 2021 13:26:39 -0500 Message-ID: To: "Scheffenegger, Richard" Cc: iccrg IRTF list , tcpm IETF list , core@ietf.org Content-Type: multipart/alternative; boundary="000000000000980f7c05bd5b0b01" Archived-At: Subject: Re: [core] [tcpm] New draft: https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 18:27:03 -0000 --000000000000980f7c05bd5b0b01 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 12, 2021 at 12:34 PM Scheffenegger, Richard wrote: > Hi, > > After some discussion, I got convinced to formally submit a draft, > explicitly describing a simple lost retransmission detection mechanism > to prevent RTO when a retransmission is lost. > > While full featured stacks can address this issue within the RFC series > already by using TCP RACK, on a more constrained platform where only > SACK support is viable but not RACK, this mechanism may be an > interesting alternative. > > Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is > included, as it may be the case that current implementations which > recover from lost retransmissions may not actually use this as a > subsequent congestion control signal, and retain the ssthresh / cwnd > from the initial loss recovery - and it is certainly debatable, if > a single, or two engagements of a CC reaction is in order. > > The mechansim described is very conservative (another CC reaction, and > requires more data to be sent, to have high confidence when > retransmitting a prior retransmission). > > https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 > > (The graph in the appendix needs some overhaul, as PRR is becoming > standard). > Thanks for the ID! Indeed this could be a useful algorithm to document for nodes too constrained to run RACK. You mention in the ID that there is a TCP stack that "started using LRD more than two decades ago." Just curious: is that FreeBSD? This approach sounds similar to (a) the improvement in the paper that your informative references cite as [SACKPerf], and similar to (b) the algorithm added in Linux 2.6.24 in 2008 in tcp_mark_lost_retrans() (later removed in the era of RACK). And it seems perhaps (a) and (b) are roughly the same thing, since the [SACKPerf] paper mentions their idea was incorporated into Linux 2.6.24? But I wasn't sure what the relationship is. I did not see [SACKPerf] mentioned in the body of the ID. Would it be possible to add some text in the ID that mentions [SACKPerf] and clarifies the relationship of the ID to the [SACKPerf] paper and Linux code? best regards, neal --000000000000980f7c05bd5b0b01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 12, 2021 at 12:34 PM Sche= ffenegger, Richard <rs.ietf@gmx.at= > wrote:
Hi,<= br>
After some discussion, I got convinced to formally submit a draft,
explicitly describing a simple lost retransmission detection mechanism
to prevent RTO when a retransmission is lost.

While full featured stacks can address this issue within the RFC series
already by using TCP RACK, on a more constrained platform where only
SACK support is viable but not RACK, this mechanism may be an
interesting alternative.

Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is
included, as it may be the case that current implementations which
recover from lost retransmissions may not actually use this as a
subsequent congestion control signal, and retain the ssthresh / cwnd
from the initial loss recovery - and it is certainly debatable, if
a single, or two engagements of a CC reaction is in order.

The mechansim described is very conservative (another CC reaction, and
requires more data to be sent, to have high confidence when
retransmitting a prior retransmission).

https://datatracker.ietf.org/do= c/html/draft-scheffenegger-tcpm-lrd-00

(The graph in the appendix needs some overhaul, as PRR is becoming
standard).

Thanks for the ID!

Indeed this=C2=A0could be a useful=C2=A0algorithm to docume= nt for nodes too constrained to run RACK.

You mention i= n the ID that there is a TCP stack that "started using LRD more than t= wo decades ago." Just curious: is that FreeBSD?

This approach sounds similar= to (a) the improvement in the paper that your informative references cite = as [SACKPerf], and similar to (b) the algorithm added in Linux 2.6.24 in 20= 08 in=C2=A0 tcp_mark_lost_retrans() =C2=A0(later removed in the era of RACK= ). And it seems perhaps (a) and (b) are roughly the same thing, since the= =C2=A0[SACKPerf] paper mentions their idea was incorporated into Linux 2.6.= 24? But I wasn't sure what the relationship is.

I did not see [SACKPerf] ment= ioned in the body of the ID. Would it be possible to add some text in the I= D that mentions [SACKPerf] and clarifies the relationship of the ID to the= =C2=A0[SACKPerf] paper and Linux code?

=
best regards,
neal

--000000000000980f7c05bd5b0b01--