Add support for number of window update frames sent

[carl-mastrangelo]

In additional to the total amount of Window sent, it would be useful to know the granularity of the window size. A case where this would be useful is a misbehaving client that may send window in response to each data frame. A million window update frames of one byte each is interestingly different than a single window update frame of a million bytes.

Pretty much any case where the number of Window Update frames is high would be helpful in explaining why a connection/stream is slow.

[Lukasa]

@carl-mastrangelo How would you envision this information being presented?

[carl-mastrangelo]

@Lukasa Something like the number of window updates sent between probing the remote point twice. It wouldn't be exact, but it would allow the inquirer to find out if there were lots of window updates between the last time sampled and the current time sampled.

The impetus was based on a conversation with @louiscryan on what some light weight signals were to detect why a stream/connection was slow. Sending lots of small window updates (like 1 byte updates) is a common failure, that we (gRPC) have at one point run into.

[Lukasa]

So while that's do-able, it does represent a request to track substantially more state than would ordinarily be tracked, I think. I can't speak for all implementers, but certainly my implementations don't track this kind of information.

Essentially, it changes the behaviour of this to stop being a "tell me what's going on right now" and to become a bit more "tell me what's been going on". Asking implementations to keep historical data makes me a bit nervous: done incautiously it risks being a DoS vector.

[louiscryan]

@Lukasa Totally agreed that we should be extremely cautious about maintaining historical state, that said some historical state is absolutely crucial to understanding the behavior of flow control in an implementation.

For example the total amount of flow control window received per-connection and the total number of bytes written over the lifetime of that connection are necessary to understand how many bytes the implementation thinks it can make available to it's streams. Given that we're not going keep state for streams that have been completed there's no other way to get this information.

[Lukasa]

Is the information obtained by polling the URI sufficient this purpose?