Subject: PING frame behavior

From: Alek Storm <[email-masked]>
Date: Sat, 19 Apr 2014 14:55:33 -0700

Hi all,

The current PING frame language is a bit vague. I'd appreciate
clarification on the following issues (and I'd be happy to open a pull
request incorporating the answers into the spec).

1. Are PING frame receivers obligated to respond with PING+ACK?
2. Must the PING+ACK payload be identical to that of the original PING?
3. May the sender generate additional PING frames before the first is ACK'd?
4. May intermediaries forward PING frames?

I have my own opinions on the best answers to the above, of course, but I'm
new around here, and I'd like to know more about the original intention of
the PING frame first, in case I've misunderstood something.

Thanks,
Alek

---

From: David Krauss <[email-masked]>
Date: Sun, 20 Apr 2014 10:50:11 +0800

> 2. Must the PING+ACK payload be identical to that of the original PING?

From the spec: “Receivers of a PING frame that does not include an ACK flag MUST send a PING frame with the ACK flag set in response, with an identical payload.”

If you don’t want a reply but only side-band communication, you may send a PING with ACK pre-set. The spec defines behavior for this case and does not mention a protocol violation.

> 3. May the sender generate additional PING frames before the first is ACK’d?

Why not? There’s no state. Also, the other end can’t reliably tell the difference.

> 4. May intermediaries forward PING frames?

Where would they get forwarded? End-to-end would be nice, but without a stream ID you can usually only go one hop. The spec leaves a little ambiguity, which seems OK to me.

Come to think of it, was end-to-end, stream-wise PING considered and rejected for a particular reason? I guess it would tend to flood origin servers that are usually cached, so that’s a major vulnerability.

---

From: Alek Storm <[email-masked]>
Date: Sat, 19 Apr 2014 20:13:05 -0700

On Sat, Apr 19, 2014 at 7:50 PM, David Krauss <[email-masked]> wrote:

> From the spec: “Receivers of a PING frame that does not include an ACK
> flag MUST send a PING frame with the ACK flag set in response, with an
> identical payload.”
>

Oh, wow. I cannot believe I missed that when reading the spec. Thanks for
the correction!

If you don’t want a reply but only side-band communication, you may send a
> PING with ACK pre-set. The spec defines behavior for this case and does not
> mention a protocol violation.
>

Good point. I suppose the amount of resources an endpoint has to commit to
answering a PING frame is trivial.

> Where would they get forwarded? End-to-end would be nice, but without a
> stream ID you can usually only go one hop. The spec leaves a little
> ambiguity, which seems OK to me.
>
> Come to think of it, was end-to-end, stream-wise PING considered and
> rejected for a particular reason? I guess it would tend to flood origin
> servers that are usually cached, so that’s a major vulnerability.
>

My thoughts exactly, with the exception that clearer language prohibiting
PING forwarding would be nice.

Thanks,
Alek

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 11:08:22 -0700

> Where would they get forwarded? End-to-end would be nice, but without a stream ID you can usually only go one hop. The spec leaves a little ambiguity, which seems OK to me.

Exactly right.  There's no language on the point because it can't
possibly go anywhere.

> Come to think of it, was end-to-end, stream-wise PING considered and rejected for a particular reason? I guess it would tend to flood origin servers that are usually cached, so that’s a major vulne…

That's the nature of the protocol.  You can't make any assumptions
about connectedness of any given hop.  The best liveness test is an
HTTP request, preferably a safe one, set Cache-Control according to
your requirements.