Subject: [quicwg/base-drafts] Remove *BLOCKED frames (#1063)

From: Lars Eggert <[email-masked]>
Date: Tue, 23 Jan 2018 02:07:03 +0000 (UTC)

As discussed in the hallways at the MEL interim, `BLOCKED`, `STREAM_BLOCKED` and `STREAM_ID_BLOCKED` are not **REQUIRED**. An implementation must track and issue credits based on observed consumption of the respective resources.

These frames therefore don't have much use other than arguably allowing some simpler debugging of flow control crediting. IMO that is not a strong enough reason to keep them in the core protocol. (A deployment could put them in a private version and do A/B testing, for example.)

CC @mcmanus 

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 22 Jan 2018 19:06:53 -0800

This is, incidentally, the exact reason that BLOCKED was removed from HTTP/2.  It was a candidate to become an extension, but no one ever re-submitted it as a separate draft.

-- 
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/1063#issuecomment-359660248

---

From: ianswett <[email-masked]>
Date: Mon, 22 Jan 2018 19:08:45 -0800

I'll reiterate the statement that the BLOCKED frame has been extremely useful for debugging and monitoring for performance regressions, so I still think it's very important for good real-world performance.

-- 
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/1063#issuecomment-359660668

---

From: Lars Eggert <[email-masked]>
Date: Tue, 23 Jan 2018 03:20:57 +0000 (UTC)

@ianswett the point is was trying to make is that one could deploy a private version of QUIC that had these frames (and otherwise was IETF QUIC) and do this monitoring?

-- 
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/1063#issuecomment-359663493

---

From: Marten Seemann <[email-masked]>
Date: Tue, 23 Jan 2018 03:23:53 +0000 (UTC)

We once discussed (in Tokyo?) to introduce a generic debug frame, which implementations could use to send arbitrary debug data.
The question is if BLOCKED frames are only useful for client <-> server within one implementation, or also between different implementations. @ianswett, thoughts?

-- 
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/1063#issuecomment-359664041

---

From: ianswett <[email-masked]>
Date: Tue, 23 Jan 2018 03:26:14 +0000 (UTC)

I'd like to see it in all implementations, but I'd likely be happy with a generic debug frame with different error codes for different cases?

-- 
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/1063#issuecomment-359664384

---

From: Lars Eggert <[email-masked]>
Date: Mon, 22 Jan 2018 20:12:35 -0800

I'd be OK with this *iff* we make it such that is is skippable (i.e., has a length field in a known position)

-- 
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/1063#issuecomment-359671079

---

From: grmocg <[email-masked]>
Date: Sun, 28 Jan 2018 02:12:12 +0000 (UTC)

Echoing and expanding Ian's comments-- I've had to debug issues with deployments of H2 at multiple sites across different companies because of issues with flow control that would or could have been automatically fixed with BLOCKED frames. It would be a mistake to get rid of this functionality or to make it less attractive to send.

-- 
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/1063#issuecomment-361032352

---

From: Lars Eggert <[email-masked]>
Date: Sun, 28 Jan 2018 05:36:41 +0000 (UTC)

They are already NOT REQUIRED, so you can't depend on them being there (or even depend on them being sent consistently if they are sent).

-- 
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/1063#issuecomment-361039824

---

From: grmocg <[email-masked]>
Date: Sun, 28 Jan 2018 06:12:39 +0000 (UTC)

True-- I agree they're currently NOT REQUIRED and one can't depend on them being there.

If we consider the parts of the protocol which are effectively optional regardless of current text, this would also be true of compression (it cannot effectively be required if the size can be mandated to be zero), PING, and various other parts. In practice, these parts will be widely implemented.

I think of BLOCKED in the same way: Though it cannot effectively be required, I expect many implementations will both send it and use it in ways which will be beneficial. 

Could it be done as an extension? Yes, as you point out, it isn't required, and thus it isn't the end of the world if it becomes one.
I believe that it offers significant benefit, very low complexity, and would be included in more implementations if not an extension.

I also think it'd be a good idea to mandate its being sent as REQUIRED after certain timeouts as these are often indicative of deadlocks or bugs, and would enable detection of these conditions with much higher probability.

-- 
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/1063#issuecomment-361041081

---

From: ianswett <[email-masked]>
Date: Mon, 29 Jan 2018 07:58:37 -0800

I believe the main reason to not make it required was because we believed it was unenforceable.

Otherwise, I think it should be required.

That being said, it feels odd we're now consuming 3 different frame types for debug frames.  If we wanted to add a debug frame to QUIC with an enum specifying types of issues and a details string, that would also be fine I believe, since we could track it the same way.  But I think the real issue here is that some people think BLOCKED is extremely useful, based on using it(or not being able to) in past debugging, and others think it's useless.

-- 
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/1063#issuecomment-361291507

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jan 2018 17:44:56 +0000 (UTC)

@grmocg, I think those examples are a little bit disingenuous.  There's obviously no requirement to generate PING frames, but handling them is part of compliant ACK generation.  A header compressor could specify a dynamic table size of zero and dramatically simplify their QCRAM implementation, but that doesn't mean they don't have to be able to decode the instructions, Huffman coding, static table, etc.  And so on.  It's true that there are things which an implementation can choose to shortcut and simplify, either during initial coding or because they don't see the incremental dev time as worthwhile.

However, are there other things in the protocol which are entirely optional both to generate and to consume?

-- 
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/1063#issuecomment-361326283

---

From: grmocg <[email-masked]>
Date: Tue, 30 Jan 2018 04:24:59 +0000 (UTC)

I hope I'm not being disingenuous.

It is, as Ian suggests, unenforceable. I believe that is true of the other parts that I suggested as well: No-one who sets a dynamic table size of zero must interpret any QCRAM opcode other than literals.

The text around PING says MUST generate pong and that the connection will timeout, but doesn't say MUST timeout for either party. The data itself must be ack'd, but there is no limit on when, except for potentially within the timeout. Arguably, this is an issue that should be raised (the PONG MUST be generated immediately as part of the next packet allowed by congestion control).

I'd argue we should do something similar with BLOCKED-- after a timeout, if flow control is preventing other forward progress, it MUST be sent, similarly to how PONG MUST be sent after a different timeout

-- 
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/1063#issuecomment-361473430

---

From: janaiyengar <[email-masked]>
Date: Tue, 30 Jan 2018 06:09:26 +0000 (UTC)

These are extremely useful signals, and are still the first symptoms we look for when a connection stalls. That they aren't in H2 is a mistake, and I'd like for us to not repeat it here. I agree with @ianswett that having a DEBUG frame may be fine, but I'd make this required. We have things that we can't enforce but require anyways -- for example, congestion control. We can require this.

-- 
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/1063#issuecomment-361487322

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Jan 2018 07:30:20 +0000 (UTC)

If we require them, it becomes possible to not do credit-based FC and instead rely on the *BLOCKED frames to be sent. That is not a huge issue (as some of you know, I had incorrectly assumed that's what was possible already). But DEBUG seems a misleading name for such a 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/1063#issuecomment-361500703

---

From: ianswett <[email-masked]>
Date: Tue, 30 Jan 2018 06:28:48 -0800

Yes Lars, you could use BLOCKED to drive flow control updates, but you'd be constantly losing an RTT, so hopefully one would never deploy such an implementation?

-- 
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/1063#issuecomment-361609438