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

[Nicolas Kuhn <[e-mail]>]

Hi,

Sorry for my late reply. Thank you so much for your comments and questions.
I have added everything as issues in the GITHUB repo to not lose track of
how the questions have been reflected in the document updates.
https://github.com/NicoKos/resume_connection

I have already fixed the various nits.

Kind regards,

Nico

On Wed, Mar 15, 2023 at 7:05 PM Border, John <[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.
>
>
>
NK : Indeed. The values should be dynamics and may change during the
connection. This should be discussed in the draft.

>     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.)
>
NK : We need to improve that in the document to have a clear separation
between the description of the phases and the proposed guidelines and
requirements. Thank for spotting this!

>
>
>     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.
>
NK : How safe should we be in the retreat phase ? We may want to discuss it
but wanted to be "very" safe in the current version of the draft as the
server just identified that something has changed in the path.

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