Subject: [quicwg/base-drafts] Clarify PADDING vs PING frames (#838)

From: Igor Lubashev <[email-masked]>
Date: Thu, 05 Oct 2017 10:36:33 -0700

At this point, it looks like the semantics of PADDING and PING frames are identical -- both take exactly 1 byte, both cause ACKs, both count for congestion control, both have no other effect on transport.  Are there any differences (like PING must be ACKed immediately, while PADDING can be ACKed after a delay)?

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

---

From: Patrick McManus <[email-masked]>
Date: Thu, 05 Oct 2017 17:44:06 +0000 (UTC)

why would padding be acked at all? It has no semantic value... (the text is admittedly not clear on this, but it seems like the right resolution.)

-- 
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/838#issuecomment-334539674

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 05 Oct 2017 10:45:35 -0700

I am also looking for a justification for ACKing PADDING.  It was asserted in Seattle that PADDING is ACKed, hence this issue.

-- 
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/838#issuecomment-334540098

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Oct 2017 18:01:55 +0000 (UTC)

See also #837.  I think that the prohibition on generating ACK in response to ACK doesn't also exclude PADDING.  That's something we need to discuss more.

-- 
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/838#issuecomment-334544711

---

From: ianswett <[email-masked]>
Date: Thu, 05 Oct 2017 18:58:21 +0000 (UTC)

I believe PADDING either needs to count for congestion control or not.  If it counts towards congestion control, then it needs to generate ACKs, because otherwise it would never be removed from byte_in_flight and you could get congestion blocked.

I would be concerned about not counting padding towards bytes in flight.  As mentioned before, the only reason ACK only packets are excluded is to avoid the connection from stalling.

-- 
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/838#issuecomment-334560054

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 05 Oct 2017 19:23:16 +0000 (UTC)

@ianswett, why are you worried about not counting PADDING for congestion control?  Are you worried that someone may accidentally add 1KB of padding (because they want all of their packets to be same-sized, for example)?  If so, it is especially as important NOT to ACK PADDING (because you can have the always-pad implementation on both sides of the connection).

-- 
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/838#issuecomment-334566550

---

From: ianswett <[email-masked]>
Date: Thu, 05 Oct 2017 21:57:37 +0000 (UTC)

My number one concern is that if PADDING counts for congestion control, it must be acked.  If it does not count for congestion control, it should not be acked.

I lean towards making PADDING count, because I'd prefer to keep the ACK_FRAME as the only exception.

-- 
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/838#issuecomment-334603585

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 06 Oct 2017 18:01:38 +0000 (UTC)

> I lean towards making PADDING count, because I'd prefer to keep the ACK_FRAME as the only exception.

Fair enough. Then if there a difference between between PING and PADDING frames? I.e. should we keep both (and why, if we do)?

-- 
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/838#issuecomment-334828163

---

From: ianswett <[email-masked]>
Date: Fri, 06 Oct 2017 18:41:54 +0000 (UTC)

As it stands now, I think we should get rid of one.  But given #837 is also open, I think it makes sense to reach some consensus on what we want the behavior of padding(and ACKs) to be before changing anything in the spec?

If I have time, I'll try to write up an email summarizing the issue and send it to the mailing list.

-- 
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/838#issuecomment-334837810

---

From: dkg <[email-masked]>
Date: Fri, 06 Oct 2017 15:17:08 -0700

I lean in the direction of making PADDING not count (and not require an ACK), because i'd like both sides to be able to pad packets that would otherwise be ACK-only without inducing a feedback loop.

That would distinguish PADDING from PING as well.

Another alternative (voiced by @ekr at the interim, possibly facetiously) was to allow/encourage the use of ACK frames as padding in general.

Or, we could allow ACK frames to be arbitrarily large, which would let us use them both as ACK and as PADDING -- that would also let us get rid of PADDING.

-- 
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/838#issuecomment-334883289

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 06 Oct 2017 15:48:37 -0700

I'd like to keep PADDING distinct from ACK, for applications where ACK is harder to do (i.e. unidirectional flows). Unless I'm misunderstanding and the suggestion is to send ACK for padding when it is not really acking anything.

As to PING vs PADDING, I think I remember some old text, where PING solicited a response PING (aka PONG). That could make it distinct from PADDING but the current text doesn't include that concept. 

-- 
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/838#issuecomment-334887739

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 06 Oct 2017 17:47:32 -0700

ACK as PADDING may be technically possible, but I would hate us doing so. First, it is a hack for which there is no good reason (we have enough frame numbers). Second, it is marginally more expensive to process an ACK frame than to skip a PADDING frame.

-- 
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/838#issuecomment-334899097

---

From: Christian Huitema <[email-masked]>
Date: Mon, 09 Oct 2017 17:10:44 +0000 (UTC)

PADDING should be a no-op as far as ACK strategy is concerned. If the sender wanted the packet to be acked, they could swap one of the PADDING bytes for a PING.

-- 
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/838#issuecomment-335221001

---

From: janaiyengar <[email-masked]>
Date: Fri, 13 Oct 2017 13:13:32 -0700

I really like @huitema's idea of sending a PING (which is a one-byte frame) to elicit an ACK. If we do that though, I don't think we want to leave it to implementations... this should be mandated, since it's congestion control behavior that we want to mandate. 

We don't want implementations to be more aggressive when using PADDING, which means we want to mandate counting them towards congestion control, which means they need to be ackable.

So, as I'm thinking about this, I'm getting convinced that what we really want is to pad with PING frames. Basically, both PING and PADDING are one-byte frames, and we can add as many of them as we want in a packet. We want both to elicit an ack. I don't see any behavioral difference between these two. We can also require that we count PING frames towards congestion control if we don't already.

-- 
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/838#issuecomment-336556006

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 13 Oct 2017 13:40:14 -0700

@janaiyengar, so this means no padding for ACK-only frames is allowed (because if both sides do that, we have an ACK+PING ping-pong).  I am not saying this is bad, if one can pad in crypto layer.  I know that some people will bring up privacy as a reason to pad ACK-only frames somewhere.

-- 
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/838#issuecomment-336561686

---

From: ianswett <[email-masked]>
Date: Fri, 13 Oct 2017 20:42:49 +0000 (UTC)

Padding in the crypto layer is still padding and hence bytes on the wire.  I think we should have a consistent story for padding, regardless of whether it's in QUIC or in TLS, rather than treating TLS padding as an entirely different beast.

-- 
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/838#issuecomment-336562212