Re: [quicwg/base-drafts] Better duplicate detection (#3696)

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



> @@ -3204,9 +3204,15 @@ response to further packets that it receives.
 A receiver MUST discard a newly unprotected packet unless it is certain that it
 has not processed another packet with the same packet number from the same
 packet number space. Duplicate suppression MUST happen after removing packet
-protection for the reasons described in Section 9.3 of {{QUIC-TLS}}. An
-efficient algorithm for duplicate suppression can be found in Section 3.4.3 of
-{{?RFC4303}}.
+protection for the reasons described in Section 9.3 of {{QUIC-TLS}}.
+
+Endpoints that track individual packets for the purposes of detecting duplicates
+might accumulate excessive state.  The data required for detecting duplicates

I considered that, but I don't feel like a recommendation is necessary.  It's the natural implementation strategy because of how we structured ACK frames, so there is enough bias there.  But it crosses somewhat over from "here are the pitfalls" into "here is how you build a stack" too much for me.

> @@ -3204,9 +3204,15 @@ response to further packets that it receives.
 A receiver MUST discard a newly unprotected packet unless it is certain that it
 has not processed another packet with the same packet number from the same
 packet number space. Duplicate suppression MUST happen after removing packet
-protection for the reasons described in Section 9.3 of {{QUIC-TLS}}. An
-efficient algorithm for duplicate suppression can be found in Section 3.4.3 of
-{{?RFC4303}}.
+protection for the reasons described in Section 9.3 of {{QUIC-TLS}}.
+
+Endpoints that track individual packets for the purposes of detecting duplicates
+might accumulate excessive state.  The data required for detecting duplicates
+can be limited by maintaining a minimum packet number below which all packets
+are immediately dropped.  In setting a minimum packet number endpoints might
+need to account for large variations in round trip time that could significantly
+delay packets, especially if a peer migrates to or probes a different network
+path; see {{migration}}.

I see how you might pick on probing exclusively.  I'll remove migration and just identify probing.

s/have/need means the same to me.  It's 6919 language of a different form :)

-- 
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/3696#discussion_r430161554