comments on QUIC Recovery -24.

G Fairhurst <> Thu, 14 November 2019 11:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41E67120019 for <>; Thu, 14 Nov 2019 03:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0GAx7hUdJpn8 for <>; Thu, 14 Nov 2019 03:18:58 -0800 (PST)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id 0A42F1200A3 for <>; Thu, 14 Nov 2019 03:18:57 -0800 (PST)
Received: from G-MacBook.local (unknown []) by (Postfix) with ESMTPSA id 0A9421B0022C; Thu, 14 Nov 2019 11:18:51 +0000 (GMT)
Message-ID: <>
Date: Thu, 14 Nov 2019 19:18:49 +0800
From: G Fairhurst <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "" <>, gorry Fairhurst <>
Subject: comments on QUIC Recovery -24.
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Nov 2019 11:19:01 -0000

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 

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 

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