Re: [quicwg/base-drafts] Don't store or retransmit PATH_RESPONSE frames, avoid buffering (#2729)

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.

The MUST NOT store 

> @@ -1721,7 +1721,12 @@ it can associate the peer's response with the corresponding PATH_CHALLENGE.
 ## Path Validation Responses
 
 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by
-echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.
+echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame,
+unless it has PATH_RESPONSE frames buffered for the same destination connection
+ID and wishes to limit memory consumption.

I don't think this addition is necessary.  QUIC does not require or suggest that PATH_RESPONSE be buffered, so an implementation would simply send or queue subsequent PATH_RESPONSE frames, as it should. Memory considerations are much larger with data, and I would argue that memory pressure due to too many PATH_CHALLENGEs isn't interesting.

> @@ -1721,7 +1721,12 @@ it can associate the peer's response with the corresponding PATH_CHALLENGE.
 ## Path Validation Responses
 
 On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by
-echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.
+echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame,
+unless it has PATH_RESPONSE frames buffered for the same destination connection
+ID and wishes to limit memory consumption.
+
+An endpoint MUST NOT store or retransmit a PATH_RESPONSE frame, as a new

I prefer @kazuho's rewording here: "And endpoint MUST NOT send more than one PATH_RESPONSE in response to a PATH_CHALLENGE frame, as a new ..."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2729#pullrequestreview-244067541