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

[Dave Taht <[e-mail]>]

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 [e-mail] <[e-mail]>
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=
> [e-mail]> 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