Re: [tsvwg] Re draft-kuhn-tsvwg-careful-resume-00

Dave Taht <dave.taht@gmail.com> Mon, 27 March 2023 04:52 UTC

Return-Path: <dave.taht@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 B9CF6C151B06 for <tsvwg@ietfa.amsl.com>; Sun, 26 Mar 2023 21:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 g5m2X0Q4XeGj for <tsvwg@ietfa.amsl.com>; Sun, 26 Mar 2023 21:52:46 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 372D5C14CEFA for <tsvwg@ietf.org>; Sun, 26 Mar 2023 21:52:45 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id j18-20020a05600c1c1200b003ee5157346cso6469255wms.1 for <tsvwg@ietf.org>; Sun, 26 Mar 2023 21:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679892763; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SFvUmyFWzrkDasY/1R3di/4CrWBNr7SKONQNVG6IBqU=; b=GANzL0yph72Qme6944UvbhGlefjTUb1sg0q27wNs73HW9mJtOD/Gtqce8yUu5PDzaa s7YT/LQSWL2EYrHnBW3EYK68DZlUgIY3T7ps4HX2aPutTg4akOZ+1lfGAw7i6O5ELcLO UzTGdVTRDN19B2i7lekkHq7d/j+ExoCPJz82gdaJMj4RKoreISmymzdw6cVlehzQmVU8 wcJaHs1KaVBdNxbsRLAb+t1itmCH8w1JuB0bJ4DFFw5o1EWF3Yl39+pVrN6a++i/Ve9L uQW/2O5d6HPGytTo1KcYYLbH6M1Nw4OTn34OmTNZGJ1QMeeHM/XujD6LkHfFbabyL7Yl Kfeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679892763; 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=SFvUmyFWzrkDasY/1R3di/4CrWBNr7SKONQNVG6IBqU=; b=O0kJq2ObnggmgFtBRBQ/vX32PTrK7/Y9zZk62EPH3Iq7Me8zD9oslqUT1NkQ4IQE1O OJSR9jVF7rSOmD5iaFu+DIjtcBNsI7OcFMz/bClogm3H36naj6qIWoKSuH6Zn1e2lK/E QP5SBak1iqsVLOvt917vK+AVtRmrtXKs7eEqMoKpQh0bpmuLatOaAFB5ilmeeKwBt+FK isSGhCyIwukJ1ZG6c9QaszkjIAHRinWw7wcnTCVqpr7Zn5Oi6JjXzTSCJOkJcVJujW3Z C3pBb/uWWdAtcAKfimu8wHEn/9QSROpN5B+uV5tkcjNOXVktQoJN6JYLx+cwnSpRjqY1 3FJg==
X-Gm-Message-State: AO0yUKUuuGY4Yb+pZiul0vp08afYhtejpE0lEl5kqeq3hukEAuyuP9j4 OSUSkWR96jmm7krgtwm16REn01l3/DMF1Ye3UzI=
X-Google-Smtp-Source: AK7set8dhVcdl5rJnSzqQlinBIHJqcLhilh9XNLryzg8WlMLtIORr9emj1IS12CfhoKcGWodbuOc1da0Rb7uOuJ8ehU=
X-Received: by 2002:a05:600c:2312:b0:3ed:ffb1:c540 with SMTP id 18-20020a05600c231200b003edffb1c540mr2239877wmo.0.1679892763166; Sun, 26 Mar 2023 21:52:43 -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: Dave Taht <dave.taht@gmail.com>
Date: Sun, 26 Mar 2023 21:52:30 -0700
Message-ID: <CAA93jw6oty2+cmomRM+fJzVmHfqcO7m+ESNZ=xLj5MAsLY8SFg@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>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "emile.stephan@orange.com" <emile.stephan@orange.com>
Content-Type: multipart/mixed; boundary="0000000000006930f805f7da8359"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mtTA5twahGTqBY9JrDBcrWiOeHU>
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: Mon, 27 Mar 2023 04:52:50 -0000

Occasionally, I feel a (perhaps mistaken) urge to throw real data into a
conversation like this.

Attached are two plots taken this morning of uploads from a starlink
terminal. The cubic plot shows cubic actually functioning properly (for a
change, it usually doesn't), as for the BBRv2 plot and its decay in
throughput over time, I have no idea what it really means, and the sudden
doubling of inherent latency at the tail end (even idle) I have a hard time
figuring out what exactly would have changed on the path.



On Sun, Mar 26, 2023 at 8:47 PM 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”.
>
>
>

-- 
https://www.youtube.com/watch?v=tAVwmUG21OY&t=6483s
Dave Täht CEO, TekLibre, LLC