Subject: [quicwg/base-drafts] allow sending PADDING after receiving a non-ack-eliciting packet (#3135)

From: Marten Seemann <[email-masked]>
Date: Tue, 22 Oct 2019 19:18:21 -0700

#3104 changed the rules regarding what kind of packet an endpoint is allowed to send after receiving a non-ack-eliciting packet. The intention of that text used to be to prevent peers from getting stuck in an ACK-loop, but now the text says:

> An endpoint MUST NOT send a non-ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps which precede the received packet.

Among others, this means that once an endpoint receives a non-ack-eliciting packet, it's not allowed to send a packet containing only PADDING. This would be valuable for defeating traffic analysis. While it would be possible to hack your way out of this by sending a PING + PADDING packet, I'm not sure if this was the intention of #3104.

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

---

From: ianswett <[email-masked]>
Date: Wed, 23 Oct 2019 07:47:42 -0700

To me, the key phrase here is 'in response to'.  If you want to send PADDING for some other reason and the congestion controller allows it, then you can send 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/3135#issuecomment-545480106

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 Oct 2019 19:51:17 -0700

This feels editorial...

-- 
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/3135#issuecomment-548195085