Subject: [quicwg/base-drafts] Handling of duplicate packets (#1405)

From: Magnus Westerlund <[email-masked]>
Date: Thu, 31 May 2018 01:03:54 -0700

Packet duplication sometimes occur and it has a potential for affecting the ECN counter for what markings that arrive within a connection. Thus, it would be good if the requirements on how a QUIC implementation handle packets that are detected as duplicates. 

There also appear that there are current text in the transport draft that makes assumption about handling of duplicate packets:

6.10.4.1.  Detecting a Stateless Reset

   A client detects a potential stateless reset when a packet with a
   short header either cannot be decrypted or is marked as a duplicate
   packet.

The other mention of packet duplication, also pointing to an action that is this:

6.8.3.2.  Handling Address Spoofing by an On-path Attacker

   An on-path attacker could cause a spurious connection migration by
   copying and forwarding a packet with a spoofed address such that it
   arrives before the original packet.  The packet with the spoofed
   address will be seen to come from a migrating connection, and the
   original packet will be seen as a duplicate and dropped.

These two pieces appear to indicate that packet duplicates should:
   1. Be detected by receiver, at least within the window of PN between highest seen and some window into the past. 
  2. The packet marked as duplicate
  3. Duplicate are dropped, but only after having been somewhat processed (see 6.10.4.1).

To my understanding the smallest window a receiver could have for tracking packets, is what is in ACKs that hasn't been ACKed yet. But that could be extremely short into the past, which could be short in time, compared to the expected re-ordering or packet life time in the network. Independently of window size, if a packet would arrive with a PN that is prior to the current window the receiver have, the receiver has discard the state for the packet number, and thus can't determine if it was ACKed or not, and thus needs to be discarded without further processing. Is that correctly assumed. 

Thus, it would be good if these assumptions and needed functionality was collected in its own paragraphs somewhere in the specification. 

>From an ECN perspective, the current thinking is that the ECN marking of a duplicate will simply be ignored. We want to avoid adding duplicates in the counter, as it will increase the uncertainty of the validation of the correct marking. 

-- 
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/1405

---

From: Mike Bishop <[email-masked]>
Date: Thu, 31 May 2018 17:19:27 +0000 (UTC)

I think the logic is that, if the packet number appears to be a duplicate, you don't attempt decryption and treat it as if decryption failed.  Packets where decryption fails get checked as potential Stateless Resets, then discarded.

Of course, if that's not stated explicitly somewhere, it ought to be....

-- 
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/1405#issuecomment-393607492

---

From: Mike Bishop <[email-masked]>
Date: Thu, 31 May 2018 17:21:42 +0000 (UTC)

As to detection of duplicates further back, you're correct that *if* you discard that state, you won't be able to detect duplicate packets.  An implementation that receives a packet older than it can identify then has a choice:  Either it discards the packet, or processes it.  Processing a duplicate packet is merely sub-optimal, not fatal, since each frame inside should also be recognized as superfluous.

-- 
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/1405#issuecomment-393608227

---

From: ianswett <[email-masked]>
Date: Thu, 31 May 2018 12:32:57 -0700

Mike is right about discarding duplicate packets, and I thought that text existed, but I can't find it.

-- 
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/1405#issuecomment-393651575

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 May 2018 16:13:39 -0700

We can probably crib something from DTLS.  The usual method is to maintain a bitvector for the last N packets, and to drop anything that appears to be before that vector starts.  The point about stateless reset is a good one, and one I discovered when implementing it.  It's highly likely that a stateless reset will appear to be a duplicate.

One thing we need to observe is that we won't be checking that the packet is a true duplicate, only that we've (probably) seen the (apparent) packet number before.

Another thing here is that packets that are ECN marked, but not authenticated, might be carrying a valid congestion signal, but we drop those too.  Think about the usual background radiation on the Internet that passes through a congested link on its way to you.  I don't think that we need to worry about that though.

-- 
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/1405#issuecomment-393711328

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 31 May 2018 23:47:33 +0000 (UTC)

> One thing we need to observe is that we won't be checking that the packet is a true duplicate, only that we've (probably) seen the (apparent) packet number before.

:+1:

I would like to argue that, the QUIC protocol needs to and will have idempotency against receiving and processing duplicate packets, and that checking for a duplicate should not be a requirement of the protocol.

Regarding the effect to ECN, I tend to think that processing of duplicates at an endpoint is an orthogonal issue to ECN, because both ECN-CE-marked and non-marked packets have the chance of binge dropped or duplicated.

IMO, the requirement in ECN support should be to state that the ECN counters (i.e. ECN(0), ECN(1), ECN-CE) must be updated _prior to_ processing the packet (e.g., decryption, duplicate detection). Then, the sender can get the most information for adjusting the congestion control.

-- 
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/1405#issuecomment-393716871

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 May 2018 18:29:06 -0700

The problem with processing ECN before decryption is that you get double-counting if packets are duplicated.  And that happens.  The ECN PR specifically says that you need to detect and discard duplicates to avoid this.

Also, the ECN feedback is based on counting of packets sent vs. those that are acknowledged, so counting ECN-marked chaff would inflate and likely distort the signal.

There is probably a way in which processing ECN signals before decryption could improve signal, but I think that's a different design to what has been proposed.

-- 
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/1405#issuecomment-393731522

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 31 May 2018 19:52:36 -0700

> The problem with processing ECN before decryption is that you get double-counting if packets are duplicated. And that happens. The ECN PR specifically says that you need to detect and discard dupli…

Yes. I am arguing against that statement, because I do not want to see endpoints being required to detect duplicates.

> There is probably a way in which processing ECN signals before decryption could improve signal, but I think that's a different design to what has been proposed.

Exactly.

My argument is based on my opinion that the current proposal is not optimal in sense that it loses the signal that was carried in one of the duplicated packets (one that is being delivered later), while requiring the endpoint to detect duplicates, which IMO is unnecessary.

Consider the case where an endpoint receives two packets that are duplicate, one with the CE bit set and the other one without. The signal sent by the approach used in the PR will depend on the order of the delivery of the two packets. If the packet with the CE bit set is delivered first, the sender will notice more congestion than is should, because the fact that the second packet did not have the CE bit set will not be notified. If the packet without the CE bit set is delivered first, the sender will notice less congestion than it should, because the fact that the second packet did have the CE bit set will not be notified.

The reason why such issue exists is because you process the packet before updating the counter. I am saying that it might be worth reconsidering the approach, _especially if_ we are going to be required to detect duplicates on the endpoint as a byproduct of the approach.

-- 
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/1405#issuecomment-393743048