Re: [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00
Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com> Tue, 28 March 2023 00:52 UTC
Return-Path: <nicolas.kuhn.ietf@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30913C15155C for <tsvwg@ietfa.amsl.com>; Mon, 27 Mar 2023 17:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhax8iPmRg_f for <tsvwg@ietfa.amsl.com>; Mon, 27 Mar 2023 17:52:48 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FC8C151552 for <tsvwg@ietf.org>; Mon, 27 Mar 2023 17:52:48 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id r84so6520986oih.11 for <tsvwg@ietf.org>; Mon, 27 Mar 2023 17:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679964767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gmK/f7GrWOGioxFhh4CmCjtre1zoNvkvAQlurUtRTeo=; b=naqvfdxi7dktrm5LWEKjOITmPXWhH5PDJDJwb7xch6/wYyTG+JrvBbljN4qWIFfKHc wbJIALW/xpCfVEmvXDQTpKYEXqkXoilK8vsDUYJJVYGTiQaMIb7krCGrFib5KLf2ChrJ mmiircy1tiPSEI1QdbCEgdRk6Ye2ykHsZn0ITvn1cKFisCL77r8SbcPf9bEppX/zFDIq JiL1AqWn20dqdCtNTI/RmV4qYEMvr/VmqX+3/3XZCnQG5sEQDii1IUVsEgQU2/Wn3BaG XI6qTlHd66YC6OavL5C2LjF2BDKrTCs/p3C2h9BhRT9n8MzGWmenJlfKv4l9RrzIlw2Z MA7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679964767; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gmK/f7GrWOGioxFhh4CmCjtre1zoNvkvAQlurUtRTeo=; b=uMkCjm6jIyICr3FsjqW5ywjWih7RZ2LE+uC9tjtknFqmwFsxdoB52LqLYzt37jYwxv 6SAxlKSs2KF96p7AjQe4GjSD5wFwvGK0qhLO75otucVWM8++OkVZwJtB3goerAD+OpZe EiJ/SvnE/yrZU8bR7lqY1c1UJxeLN6D+ZtW5iR7eHefiMBp0m5661JiGPKZvlln/CuEw 8SG80yavyOpuMsqckmYu20hLIm08V0wLA59qYb7Q7r4KLTSDOF1PWOi4JHXT/tVgGxF4 YViD2+Cv84YbvR3TRd1P2YHGieE2vxipDdoC3cUzCwptELztfl3+PsNPrPNlF5TFGVvf m9dA==
X-Gm-Message-State: AO0yUKWcb/v1uEl48n8scb10lEOMB0NCzlYO2GBTF5mKpYuocefNWdWO UWbibHGO3GUMXjxaVBh8m7bMN0kKfJHV/U2HYVM=
X-Google-Smtp-Source: AK7set93io8UqOPwVtUvbIlS+bfNonLpROoqO9lwuuhnYkJJNDU27dDzAilqhXynG6wVZ7LEVSuoBysIm0Ek15MLWEA=
X-Received: by 2002:aca:6508:0:b0:384:420d:6671 with SMTP id m8-20020aca6508000000b00384420d6671mr4434441oim.5.1679964767054; Mon, 27 Mar 2023 17:52:47 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB3647649C6147ED39171099A590BF9@MN2PR11MB3647.namprd11.prod.outlook.com> <89E3EBAE-2F68-483E-8DE9-CCE2D676CC37@strayalpha.com>
In-Reply-To: <89E3EBAE-2F68-483E-8DE9-CCE2D676CC37@strayalpha.com>
From: Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>
Date: Tue, 28 Mar 2023 02:52:35 +0200
Message-ID: <CAL0D2oSsqOqXn2QPs4oKXAPs-XTkVM4oXJTnPAvY4xBwOKt6oA@mail.gmail.com>
To: "touch@strayalpha.com" <touch@strayalpha.com>
Cc: "Border, John" <John.Border=40hughes.com@dmarc.ietf.org>, "Gorry Fairhurst (gorry@erg.abdn.ac.uk)" <gorry@erg.abdn.ac.uk>, "emile.stephan@orange.com" <emile.stephan@orange.com>, Christian Huitema <huitema@huitema.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/related; boundary="0000000000002d046505f7eb4716"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/XpZesn-RYzdtEgjfzCROacVFhEI>
Subject: Re: [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2023 00:52:52 -0000
Thanks for this pointer ! Will read and at least include in the SoA of the current document : https://github.com/NicoKos/resume_connection/issues/66 Cheers, Nicolas On Mon, Mar 27, 2023 at 5:47 AM touch@strayalpha.com <touch@strayalpha.com> wrote: > FWIW, there is some long lost past work in this area for TCP: > > [image: preview.png] > > draft-hughes-restart-00 > <https://www.ietf.org/archive/id/draft-hughes-restart-00.txt> > Text Document · 43 KB > <https://www.ietf.org/archive/id/draft-hughes-restart-00.txt> > <https://www.ietf.org/archive/id/draft-hughes-restart-00.txt> > > — > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com > > On Mar 15, 2023, at 11:05 AM, Border, John <John.Border= > 40hughes.com@dmarc.ietf.org> wrote: > > > I think we need little bit of discussion around the fact that RTT and > BB can also vary during a connection, especially a long-lived connection, > not just from one connection to the next. Therefore, the saved RTT and BB > values should be the RTT and BB near the end of the connection rather than > earlier in the connection. This might require that the values be save (and > possibly sent in a BDP_FRAME) multiple times as things change. > > In Section 3, when I got to the Retreat Phase description, I paused > because it seemed like more is needed. I later found that more in Section > 4.5. I think it would be helpful, for all of the phases, to put pointers > to the sections which have more discussion about them. (Or maybe a blanket > pointer to Section 4 for more details at the front of Section 3.) > > Re Section 4.4 and Section 4.4.1… I think half of the capacity should > be a good choice (although I am still thinking about it). (Might need to > be variable based upon some to be defined criteria.) But it probably needs > to take into account the capacity when compared to the IW. > > > John > > > > Minor comments and nits… > > In the second sentence of the third paragraph of the Abstract… “allowing > then to” should be “allowing them to”. > > In the first sentence of the Introduction… “there” should be “their”. > > Re Section 1.2… > In the second sentence, delete the duplicate “could”. > Add “is different” to the first clause of Example 1. > > In the first sentence of Section 1.3… “secion" should be “section”. > > In Section 1.3.1… Mention that this is a GEO satellite example. Might be > useful to explicitly state that the difference is the longer slow start > time without the method. > > Re Section 3… > In the first sentence, remove the first occurrence of the word “through” > and change “uit” to “it”. > In the last sentence for the Observe Phase description, delete the word > “are”. > In the Reconnaissance Phase description, “currnetly" should be “currently” > and “iniial” should be “initial”. And, the sentence “The sender is send > iniial [sic] data, limited by the Initial Window.” needs rephrasing. > In the second sentence of the Unvalidated Phase description, “This phase a > rate…” should be “This phase allows a rate…” (or something like that). > In the third sentence of the Retreat Phase description, “re-initialised” > should be “re-initialise”. > > In the title of Section 4.1, “Determing” should be “Determining”. > > In the first sentence of Section 4.3, “irelevant" should be “irrelevant”. > > In the third bullet of Section A.1, “it should an interface…” should be > “it should include an interface…”. Except, the last statement of the third > point about what the sender should ensure re the Endpoint Token indicates > the “should” should be a “must”. > > >
- [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00 Border, John
- Re: [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00 Nicolas Kuhn
- Re: [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00 touch@strayalpha.com
- Re: [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00 Dave Taht
- Re: [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00 Nicolas Kuhn
- Re: [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00 Nicolas Kuhn