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?
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.) 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? 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? 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? 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. 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".
