comments on QUIC Recovery -24.
G Fairhurst <firstname.lastname@example.org> Thu, 14 November 2019 11:19 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E67120019 for <email@example.com>; Thu, 14 Nov 2019 03:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([188.8.131.52]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GAx7hUdJpn8 for <firstname.lastname@example.org>; Thu, 14 Nov 2019 03:18:58 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A42F1200A3 for <email@example.com>; Thu, 14 Nov 2019 03:18:57 -0800 (PST)
Received: from G-MacBook.local (unknown [184.108.40.206]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0A9421B0022C; Thu, 14 Nov 2019 11:18:51 +0000 (GMT)
Date: Thu, 14 Nov 2019 19:18:49 +0800
From: G Fairhurst <firstname.lastname@example.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
To: "email@example.com" <firstname.lastname@example.org>, gorry Fairhurst <email@example.com>
Subject: comments on QUIC Recovery -24.
Content-Type: text/plain; charset=windows-1252; format=flowed
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:email@example.com?subject=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 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.