Re: comments on QUIC Recovery -24.

[Ian Swett <[e-mail]>]

Thanks for the review Gorry.  I'll try to fix the editorial issues in a PR
tonight and then file issues for the non-editorial comments or comments I'm
not sure how to resolve.

On Thu, Nov 14, 2019 at 6:19 AM G Fairhurst <[e-mail]> wrote:

> QUIC Recovery
>
> I have comments on QUIC Recovery -24. These sets of come join two parts,
> this is the first. I hope most of the comments below are easy to resolve:
>
> Section 3, Para 1 last sentence. This sentence is true from the sender
> perspective, but the monotonic increase is not necessarily true at the
> receiver.
>
> Section 3.1.2, Para 1
> /is declared is acknowledged/
> - maybe would be easier to read as /is declared as acknowledged/.
>
> Section 3.1.2, Para 1
> /QUIC will do it correctly once/
> - There is an inference that TCP does not, and I would argue with that,
> because TCP measures the TCP loss recovery, that is often a larger
> interval than it could have been had TCP been designed differently, but
> this document is not a thesis on TCP. I would like to suggest / QUIC
> will appropriately reduce once/ as a more neutral text.
>
> Section 3.1.6, Para 1
> /allowing a peer to maintain a more accurate/ is I think an unnecessary
> judgment on TCP again, it would be fairer to say/allowing a peer to
> maintain an accurate/
>
> The term /host delay/ appears several times, but there is no discussion
> of hosts, only endpoints. The term host delay seems odd, can we call it
> endpoint delay or perhaps even “ACK delay” which I think is closer to
> the field used for this later in the spec?
>
> Section 4.1, final sentence
> /Ensuring that RTT estimates retain sufficient history is an open
> research question/
> - This is fine for an IRTF experiment, but really rests very
> uncomfortably in a standards track specification. I suggest this alone
> is not sufficient. An alternate could be to set some bound here that at
> least mitigates this - which could otherwise result in odd pathologies.
>
> Somewhere there is this (it's in several places):
> /smoothed RTT = latest RTT/
> - This needs to cite an RFC.
> - I'm not a huge fan of just assigning a RTT (without taking account of
> the variance) as a starting timeout. We've in the past been caught so
> many times with things being slightly or vastly different when the next
> flow starts and simply assigning the value seems like it could be the
> wrong thing to do.
>
> Section 4 pseudo code uses both Ack_Delay and ack_delay, I don’t
> understand the difference.
>
> Section 5
> This uses /ack/ and /ACK/
> - is there a difference?
>
> Section 5.1.
> /was sent long enough in the past/
> - This isn’t clear, please improve the text here to explain what is
> intended.
>
> /sent later was delivered, while …. /
> - Text should be improved. I suggest /while/ is reworked to avoid the
> inference these occur in parallel.
>
> Section 5.1.1
> There is no minimum dupack threshold specified. Why not? I could be
> persuaded that the recommendation was for 3, and that more is possible,
> but when would less than 3 fit with current other recommendations in the
> RFC series ?
> - also mentioned in B.1
>
> Also 5.4 final sentence
> - section 6 (last para -1) reads like this is intended as one “probe”
> packet, XXX what does RACK do in this cased with respect to CC?
>
> Section 5.3, final sentence:
> /may never be/
> - seems like it would avoid all possible ambiguity in whether this is
> allowed by using /could/.
>
> /Sending two packets on a PTO expiration increases resilience…/
> - and arguably doubles the non-congestion-controlled load.
>
> Section 6.1
> /endpoints are permitted to experiment/
> - This is much more than intent of RFC8311. The intent was that the IETF
> can publish experimental specs for other behaviours. That’s not the
> same, and I think the wording needs to be modified a little to reflect
> the actual consensus of the RFC.
>
> Section 6.2
> /anytime/any time/
>
> Section 6.9
> - the new text on pacing seems to be heading in the correct direction,
> but I don’t really understand how the congestion window will be managed
> if pacing is used and the connection becomes application-limited. The
> basic TCP spec would respond aggressively reducing the window; cwv would
> loosen this; what does QUIC say when pacing *is* used.
>
> Section 7.3
> /as having being marked/ should I think be /as having being CE-marked or
> lost/
> - add loss.
>
> section A.1 para 2.
> - I suggest text is added that mentions the actual reordering could be
> larger and how QUIC handles this.
>
> Section A4 - could the initialisation be clearer? - e.g. showing initial
> values for RTT etc.
>
>