Re: Re draft-kuhn-quic-bdpframe-extension-01

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

I have already fixed the various nits.

Kind regards,

Nico

On Tue, Mar 14, 2023 at 7:04 PM Border, John <[e-mail]> wrote:

>
>
> Some comments and questions…
>
>
>
> Since the idea for BDP Frame is to extend the QUIC protocol, is an
> Intended Status of Informational the right choice?
>
>
>
NK : Good question. I do not know honestly.

> The BDP Frame document is very oriented towards being used by Careful
> Resume method.  I assume this is on purpose.  (I had always envisioned it
> being used more generically that but have no other specific use case in
> mind at this point.)
>
>
>
NK : Indeed, careful resume is a companion draft. This link should be made
clearer in the documents.

> Minor…  In the Introduction, add a very short summary as to what the hash
> mentioned in Step 1 is used for.
>
>
>
> In Section 3.1, re Saved BB…  If using bytes_in_flight Is not recommended
> what is recommended?
>
>
>
NK : This depends a lot on the congestion control that is exploited. I am
not sure that we can reach a consensus on what this parameter could be in a
generic manner.

> In Section 3.1.1, it is not entirely clear what the difference is between
> using BDP_FRAME and activating the optimization.  Is the idea to allow
> saving the CC values at the sender without sending them in a BDP_FRAME to
> the receiver and the use of saved CC values is the optimization?
>
>
>
NK : Will clarify in updates of the document.

> I assume, in Section 3.2 re the first sentence in the third paragraph that
> the mechanism for identifying that it is the same receiver is being left
> independent from the specification of BDP-FRAME.  Or is this referring to
> the Endpoint Token discussed in Section 3.3.1 in which case maybe that
> section should be pointed to?
>
>
>
 NK : Will clarify in updates of the document.

> Re Section 3.2.2…  I cannot find anything clearly labeled Rationale #N
> except in the appendix.  The solutions are in Section 6.1.  (If referencing
> the appendix for the rationale number is the intent, maybe it should not be
> in an appendix but at least a reference to the table should be mentioned.)
> And, in any case, in the appendix, there is no Rationale #1.
>
>
>
NK : Will clarify in updates of the document.

>
>
> John
>
>
>
>
>
> Nits and readability enhancements…
>
>
>
> In the Abstract and again in the Introduction, change the first use of
> “CC” to “Congestion Control (CC)”.
>
>
>
> In the Abstract…  “amde" should be “made”.  “This CC parameters” should be
> “The CC parameters”.
>
>
>
> In the Introduction, Step 2… “portuon” should be “portion”.  “premitted"
> should be “permitted”.
>
>
>
> Change the first use of “BDP” to “Bandwidth-Delay Product (BDP)” or
> “bandwidth-delay product (BDP)”.  I think the first standalone use is in
> Section 1.1.
>
>
>
> The first statement in the third paragraph of Section 1.1 is a sentence
> fragment.
>
>
>
> In Section 3.1, the description of the Hash says that value is derived
> from “other” CC parameters.  The phrasing could be interpreted as being
> values outside of those inside the BDP_FRAME, i.e. from the sender’s own
> information, or other values within the BDP_FRAME.  Rephrase to make it
> clear which.
>
>
>
> Really nitty…  In Section 3.1 Saved BB, the second statement is a fragment.
>
>
>
> In Section 3.1 Save RTT, the third sentence is essentially the same as the
> second sentence.
>
>
>
> In Section 3.1.1, for value 1, remove the duplicate “the”.
>
>
>
> In the first sentence of Section 3.2.1, “it could also” should be just
> “could also”.
>
>
>
> In the second bullet of Section 3.3, “likeability” should be
> “linkability”.  Also, the Note at the end of Section 3.3 seems like it
> should be part of Section 3.3.1.
>
>
>
> In the second paragraph of Section 3.3.1…  “observable eavesdroppers”
> should be “observable to eavesdroppers”.  The last sentence is essentially
> a duplicate of the second sentence.  “provideing" should be “providing”.
>
>
>
> In the first sentence of the second paragraph of Section 3.3.2, ”stroing”
> should be “strong”.
>
>
>