Subject: [quicwg/base-drafts] Recording the conditions that produce BLOCKED (#452)

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Apr 2017 22:20:37 -0700

It's possible that we don't care about the reliability of BLOCKED, but there is an inherent problem with the frame.

The quality of a signal like this is either in being able to capture the conditions that lead to it being generated, maybe in terms of looking at traces.  Or, it can be useful hollistically: by aggregating reports over a large set you can determine whether a change to flow control tuning was successful.

A sender of BLOCKED is currently obligated to retransmit lost BLOCKED frames.  That achieves the latter goal reasonably well, but it does little for the former because the state of the connection when BLOCKED was generated is unlikely to be the same when it is eventually retransmitted.  Even on the first transmission, the receiver of a BLOCKED frame still has to do quite a lot to work out what the state of the sender might have been.

BLOCKED would be more useful if it reported the limit that caused it to be generated.  That would also solve #451.

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