Subject: [quicwg/base-drafts] Deduplication window suggested by RFC 4303 is insufficient (#3692)

From: Kazuho Oku <[email-masked]>
Date: Sun, 24 May 2020 20:40:59 -0700

[Section 12.3 of the transport draft](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-12.3-11) requires deduplication, delegating the details to RFC 4303. I am not sure if that is enough.

IIUC, the difference between RFC 4303 and QUIC is that in case of QUIC, packets are sent using multiple paths.

Consider the case of a client connect through Wi-fi, probing a 3G network. The latency of Wi-fi could be much shorter, and the bandwidth could be high. In such case, the requirement on the deduplication window becomes high: the window needs to cover packet numbers across multiple PTOs (where PTO is calculated from the RTT of the Wi-fi).

I do not think that this case is covered by RFC 4303.

IMO, we need to at least clarify this corner case exists, otherwise, we might end up seeing servers not responding to probes sent on cellular networks, and clients failing to migrate due to that failure.

-- 
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/issues/3692

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 24 May 2020 23:01:56 -0700

As a fix, I think we should remove reference to RFC 4303, and state that an endpoint SHOULD be capable of deduplicating packets that are received across more than half the largest RTT that the endpoint intends to support.

-- 
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/issues/3692#issuecomment-633392953

---

From: Martin Thomson <[email-masked]>
Date: Sun, 24 May 2020 23:36:18 -0700

I agree that RFC 4303 is showing its age here.  32 packets is probably woefully inadequate here.  But there is an additional insight that is important: you need to drop all packets older than the oldest packet you are individually tracking or you are vulnerable to duplication attack.  It's a little awkward restating that.

It's not obvious that you need to allow for an increase of half of the difference between the current min_rtt and some maximum value either, so it is worth saying that.  Noting that the collective packet rate on all paths affects any limit is similarly non-intuitive.

The nice thing about this is that the most obvious packet-tracking structures (aside perhaps from those that are subject to DoS) are not susceptible to this problem.  For instance, many people are tracking ranges and limiting the total number of ranges.  If you do that, you only run into problems after the number of slow probes sent within one of these extra-long round trip times exceeds the number of ranges the receiver is tracking.  Most implementations are tracking more ranges than there are packets in an initial congestion window, so you won't get issues.

-- 
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/issues/3692#issuecomment-633404227

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 24 May 2020 23:50:49 -0700

> I agree that RFC 4303 is showing its age here. 32 packets is probably woefully inadequate here. But there is an additional insight that is important: you need to drop all packets older than the old…

Regarding the insight, I agree that we need to state that. We can site RFC 4303 as part of that attempt, even though we need to refrain from suggesting that the design document in RFC 4303 works for QUIC.

As you state, the practical advice we'd better provide is that an endpoint can retain ranges of packets. The number of ranges that an endpoint should retain is questionable, but hopefully, endpoints would make a sensible choice.

-- 
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/issues/3692#issuecomment-633409284

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 18:27:21 -0700

Closed #3692 via #3696.

-- 
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/issues/3692#event-3376003158