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

[Nicolas Kuhn <[e-mail]>]

Thanks for the feedback !
We also add previously implemented and evaluated the BDP FRAME extension
over an emulated environment and real SATCOM system :
https://arxiv.org/pdf/2112.05450.pdf
There are also plans for further evaluating the different approaches
discussed in the draft.

Regarding your starlink terminal scenario, with end-to-end evaluations it
may not be easy to understand what is happening. It could be a change of
GW, radio link protocols, change in ISL (if any!).

Cheers,

Nico

On Mon, Mar 27, 2023 at 6:53 AM Dave Taht <[e-mail]> wrote:

> 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
>