WGLC comments: draft-ietf-quic-recovery-29

[Gorry Fairhurst <[e-mail]>]

This is a WGLC review of draft-ietf-quic-recovery-29. This version of 
the specification seems mature, and this email includes some WGLC 
comments, preceded by some things that I think are issues.

(Editors I could raise a set of github issues for the issues, please 
advise how you would like to proceed).

Best wishes,

Gorry

ISSUE:

8.2. Traffic Analysis
/Packets that carry only ACK frames can be heuristically identified by 
observing packet size. Acknowledgement patterns may expose information 
about link characteristics or application behavior. Endpoints can use 
PADDING frames or bundle acknowledgments with other frames to reduce 
leaked information./
- I think this needs a warning: This could also increase the return path 
traffic, which for asymmetric paths could impact the performance of the 
forward path or of other flows that share a restricted return path.

ISSUE:

/Re-ordering could be more common with QUIC than TCP, because network 
elements cannot observe and fix the order of out-of-order packets./
- They can if they add network-layer sequence numbers, as some 
tunnels/encaps for example can... This seems like an odd statement. Is 
it necessary? If so, please explain more.

ISSUE:
/When a loss or ECN-CE marking is detected, NewReno halves the 
congestion window, sets the slow start threshold to the new congestion 
window, and then enters the recovery period./
- The requirement is that TCP needs to reduce after CE, The RFC series 
does not now say it needs to halve, it could for example follow the 
reduction method specified in RFC8511. e.g. /When a loss or ECN-CE 
marking is detected, the sender must reduce the cwnd. NewReno halves the 
congestion window, sets the slow start threshold to the new congestion 
window, and then enters the recovery period. [RFC8511] specifies an 
alternate cwnd reduction./

ISSUE:
Similar comment in 8.3:
/Though congestion controllers generally treat reports of ECN-CE 
markings as equivalent to loss [RFC8311], the exact response for each 
controller could be different. /
- This does not seem correct. Could I suggest:
/Congestion controllers respond to reports of ECN-CE by reducing their 
rate. Markings can be treated as equivalent to loss [RFC3168], but other 
responses can be specified (e.g. [RFC8511]) [RFC8311]. /

ISSUE:
In B.5,
           // Congestion avoidance.
           congestion_window += max_datagram_size * acked_packet.size
               / congestion_window
- is this calculation correct? I was thinking of what might happen when 
the PMTU is large and the sender generates a sequence of small packets… 
would this result in overestimating cwnd?

ISSUE:

/Endpoints SHOULD use an initial congestion window of 10 times the 
maximum datagram size (max_datagram_size), limited to the larger of 
14720 or twice the maximum datagram size./

- I would like to revist this. We talked in Montreal and at that time I 
understood the equivalence to TCP for the case where a large MSS was 
supported by the path, as per RFC6928. I have since revisited this topic 
and would like to suggest the present IETF advice for TCP is in fact 
wrong for the large initial MSS case, and that this draft should not 
perputate that mistake for QUIC. The issue comes when IW is initialiased 
for a path with a very large PMTU, but that PMTU is not in fact 
supported by the path.

- (i) I observe the TCP case where the path does actually support the 
large PMTU, and a receiver advertises an appropiately large MSS. The 
path then uses the large MSS naturally and all is OK, but stands the 
risk of (ii) below, since the path might not be the same as a previous 
case.

- (ii) if the receiver interface supports a large MTU, and the the 
receiver advertises a large MSS, but the sender does not have a large 
MTU, the advertised large MSS changes the IW, and can vastly increase 
the number of packets in the initial window. This was not intended. It 
should not happen by default and can cause congestion and increase 
latency. This is wrong.

- (iii) if the receiver interface supports a large MTU, and the the 
receiver advertises a large MSS, the sender has a large MTU, but the 
path does not support this large PMTU. Sending with the large MSS causes 
packet loss (or possibly IP-Frag if that was allowed). This was not 
intended, and may well predjudice performance. Retransmission with a 
more appropiate PMTU does not change the IW, which then sends too many 
segments/packets. For TCP it would probably have resulted in a RTO and 
collapsing cwnd. This can cause congestion and increase latency. This is 
wrong.

... So why was this was not seen as a real-life problem. I think the 
advice in RFC6928 should have considered the impact of PMTU failure, but 
I conclude it doesn't normally hurt TCP. At the time this was written, 
few interfaces really did support more than a 1500B MTU (it may still be 
so), and MSS was often effectively limited by the server (sometimes by 
config). For servers that did advertise a larger MSS, or where the path 
supports less than 1500B, then MSS-clamping by routers along a path 
would often have triggered. Still, the sender would normally receiver 
only a feasible advertised MSS.

... QUIC is different :-). There is no middlebox intervention for MSS 
clamping - therefore QUIC is unable to avoid (iii), and likely would be 
impacted by (ii). I therefore suggest that QUIC chooses either to 
eliminate the /or twice the maximum datagram size./ clause, **or** 
provides a requirement that if this datagram size is not confirmed, then 
the IW needs to be limited to 14720 B.

... Finally, I would expect QUIC to perform better if it were to set up 
the connection, and then immediately probe for the larger size, since 
DPLPMTUD is anyway needed to utliise a larger PMTU and avoid 
blackholing. However, I don't think we need to explain this in the ID.

---

NiT:
/ACK delay/ /Ack Delay/  and /ack delay/ are both used, it seems the 
/ACK/ is more consistent with other usage.

NiT (Missing word):
/and are expected to at least as useful in QUIC/and are expected to be 
at least as useful in QUIC/

REF:

/When a PTO timer expires, the PTO backoff MUST be increased, resulting 
in the PTO period being set to twice its current value. The PTO backoff 
factor is reset when an acknowledgement is received, except in the 
following case./
- Please consider a reference to draft-ietf-tcpm-rto-consider-16, which 
provides BCP on use of timers?

The life of a connection that is experiencing consecutive PTOs is 
limited by the endpoint's idle timeout.
- what does /life/ mean here?

/send an Initial packet in a UDP datagram of at least 1200 bytes./
- At what layer is the datagram size measured? Should this be a datagram 
with /payload 1200 bytes/?

/Peers can also use coalesced packets to ensure that each datagram elicits /
- A cross reference would be valuable to the section on /coalesced packets/

/If the sender wants to elicit a faster acknowledgement on PTO, it can 
skip a packet number to eliminate the ack delay./
- Explain: this causes the sender to see an out of order packet, which 
eliminates the ACK delay.

/limited to the larger of 14720/
- Please add the word /bytes/?

/Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets 
that might have arrived before the peer had packet protection keys to 
process those packets. Endpoints MUST NOT ignore the loss of packets 
that were sent after the earliest acknowledged packet in a given packet 
number space./
- Can you clarify what is intended by the word /ignore/? This is in a 
section on CC, so I was hoping that the word ignore meant that the 
endpoint did not need to make a CC change, otherwise it MUST update the CC?

/7.7. Probe Timeout
Probe packets MUST NOT be blocked by the congestion controller. /
- Can you clarify what is intended by the word /blocked/? I was assuming 
the transmission was not constrained by the congestion controller?
- Would these packets consume flow credit, i.e. are they also not flow 
controlled?

7.8. Persistent Congestion
- Could you add text explaining what happens? I think I understand, but 
to be clear. If the persistent congestion persists, then I think the 
congestion is not further reduced, but I would expect the PTO to 
back-off the interval between packets exponentially, is that true? -

Are  appendix A and B normative or informative?

Section A.5.  On Sending a Packet; and section A.6.  On Receiving a 
Datagram. If the intention is to talk about datagrams in A.6, can A.5 
explain that packets are sent in datagrams?

Sections A.8, A.9, A.10  seem to be sender functions. It would perhaps 
avoid doubt to state this.