Re: [core] [tcpm] New draft: https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00
"Scheffenegger, Richard" <rs.ietf@gmx.at> Fri, 12 March 2021 20:39 UTC
Return-Path: <rs.ietf@gmx.at>
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 436BA3A1263; Fri, 12 Mar 2021 12:39:33 -0800 (PST)
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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 qnkORzpACx2K; Fri, 12 Mar 2021 12:39:31 -0800 (PST)
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 D7F653A1261; Fri, 12 Mar 2021 12:39:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615581567; bh=49uhzMNA+YOE3shfKcRSdLRuzm1LfutfQJ6PSXdVUIA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=hrogQD8Fv3g26xGqEuj9RiSN1U8bn69zzxxP7v4KbJGAxHWm+iJJY5Ie1+RCoplro tnWYa2pocpHx/b1Oasom5AfSfRd8u5m6bqG5epzBRjkFMMTpehjq5xldjaS3NDuRk8 DiRuXa6bZR9TYyMtLMKApoWCDsMXrBYCvj6UpKR8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.199] ([178.115.129.107]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M42jQ-1lKoZC3EWW-0008Mv; Fri, 12 Mar 2021 21:39:27 +0100
To: Neal Cardwell <ncardwell@google.com>
Cc: iccrg IRTF list <iccrg@irtf.org>, tcpm IETF list <tcpm@ietf.org>, core@ietf.org, lwig@ietf.org
References: <161529694562.32408.1003733576456029769@ietfa.amsl.com> <24aa2c28-41e3-6a14-7ffa-88418745c154@bobbriscoe.net> <a7980729-5c40-462c-fb47-7c87e459745e@gmx.at> <CADVnQymL50GA6CATY-i0fwn7a2fqfnkEyquCV4MEzDm3tOAnWQ@mail.gmail.com>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <5ecbb7fd-556b-2233-b35b-baec71a28b58@gmx.at>
Date: Fri, 12 Mar 2021 21:39:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <CADVnQymL50GA6CATY-i0fwn7a2fqfnkEyquCV4MEzDm3tOAnWQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:uRiC8Nk8xq1rgE8l8THaPJ6wAd6lR7G9zmQfnm5NRTTcxlyoU+y SHg7tAUbArAyw0VWqfXm9V8+n1aLKhMbuWA5xvRGKlYkVRDcto5VN17W178vOd0vW+Pfc5t wY3iBtYlo5mjH7N20ChPWwG8klYCt7PAxLF1TAMGqknZ+WnmSQ8utfAKXT9iXyWy2WZXkHn 1xoqYgShL+tGTdC4r0GNA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:W88di4rZv4I=:Au37d+75dwA9Gt7GXhSYlu hj0vzic8QR4KW2wQcV5netKm85OgUJH8gTt7sfJbvtLBi2azevVUOWUxczxft6MhwOcXnyWLi 0u9BxYTuf0WJb6WOztkFgFtJlUkH6C5XgIdueaaY/1+SxhZ/Q77a7jv/eIKmBma1yDJwAZ1bo R9c8xdSrsM8LxCmOx5mBDFmaDjBYGP2BuWe3FowWwkKASOu+u08kUmPfmWOLI6vOOVFXAqkc7 GdOXptPd4qimQYPeDZpkPSmL8n3CJ2uXLKGxCN7dybzos4q0clhCVjcLo7CCtBXZD5oJpwPIw w3JccyVKlS0VUEfTW62l+92fLz8Vz6bvgGs1Cbqb85vcImvVjIsvW4AEaNFqeO2qUqP625ohe k6asE6pJ/EtqBA9FJWHaWuHoZaQ9CYYs9cXlmTc7rvlOxwgeiwK2DND+8WY96fIK0IzlmPg6i 5LyAoz10Ert7MkvToTLfIzPum1806ZK6++/OxFjxwYIsAkh19ua9w9QUhRw02GS2XRpndJkLK q6cyq5+U5ulp6D01RoyXPTUC7XppHuCrjWFjA4Cg6tEZ15ZhXecctIOeT6EiBIYJAOgIH1r/m EHSsv9mSBbCZbrtrs8kCM1Sm8VxFLHwxb8J+pO/SUnTtMnZAIrvscbqsQ4VJyhDFnoA41hHnq I3VtDmSPXmI4p57E5Oz/N7rRxiiwZ32BOsyK3T1/E3S1yiCZn/9qsiWi33pEjbCpdOSVchQSp aQmHy4RIgDdO25lP4P7mqKptc7nqERW8BOc0d5Xs5El2cFoPXDaVb/pHQ5o4CMKjHVyxi68RA mKYjer2DMkvnEG2eNlzqHckntDldGLDFs3wUu4/MGu5dewgASE9AOcLw7TXusD6HH5Qv4Q7+v 8hIN81NVPUHTeUjk8Ckw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/1lEN79WXNcBCq5Hn49vc83KfPE0>
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" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 20:39:33 -0000
Hi Neal, I was specifically thinking about Linux, but my recollection as to when it first showed up there must have been skewed. The SACKPerf reference appears to be dead (only a copy on archive.org is available - I don't know if that is valid to quote instead of the link that I found all these years ago. https://web.archive.org/web/20150103014718/http://projects.itri.aist.go.jp/gnet/sack-bug.html In any case, the improvement described therein sounds as if some more limited form of lost retransmission detection was already present in Linux before that. (For single Hole/SACK Ranges). As I am not that intricately familiar with Linux, is my assesment correct that (at the time of ~2.6.24), CC would not be triggered anew when a lost retransmission is detected? If you have a suggestion for an appropriate text honoring all the prior work on Linux, I would be very grateful. I would also like to invite you to coauthor this document, if you want to help refine the text further. Also, I have a more aggressive mechanism, using a heuristic to differentiate between a SACK for an original segment vs. a SACK for a retransmitted segment, and using the latter to also engage LRD. As this variant does not rely on new data to be sent, it can also work at the end-of-stream, albeit with some potential misdetections of lost retransmissions (again superceded by TLP / RACK). However, I felt that the conservative mechanism is the proper starting point for now. Best regards, Richard Am 12.03.2021 um 19:26 schrieb Neal Cardwell: > > > On Fri, Mar 12, 2021 at 12:34 PM Scheffenegger, Richard <rs.ietf@gmx.at > <mailto:rs.ietf@gmx.at>> 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 <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 >
- [core] [tcpm] New draft: https://datatracker.ietf… Scheffenegger, Richard
- Re: [core] [tcpm] New draft: https://datatracker.… Neal Cardwell
- Re: [core] [tcpm] New draft: https://datatracker.… Scheffenegger, Richard
- Re: [core] [tcpm] New draft: https://datatracker.… Neal Cardwell