Stats API Requirements

[shampson]

While discussing the stats PR, we began to discuss requirements for a stats API. I'd like to continue and document those requirements here so we can make sure we design the proper stats API.

A comment from @vr000m:

At the high level,

1. I do not want to traverse getStats to figure out the relationship, if that was explicit somewhere then the getStats could be called on the individual objects. That would avoid get back a mega object.
2. want to getStats through the lifecycle of the object.

I think one thing Varun called out is that he doesn't want stats appearing or disappearing without a stats API being aware. A stats library needs to be aware of all stats. For example a stream being created/destroyed. A few quick ideas doing this for QUIC stream stats (or any other lower level object):

• exposing the stream stats in higher level WebTransport object (similar to ORTC model)
• events new stats with an object creation
• stats returned by WebTransport object includes current streams so you can pull stats from them as well

[jan-ivar]

Step 3 in getStats still says "If the URL scheme associated with transport is not quic-transport, reject p with NotSupportedError and return p." - even though we don't support quic-transport anymore, which means this method always rejects now.

So we need to discuss what to do with this API.

[jan-ivar]

So we need to discuss what to do with this API.

To be discussed in #206.

[jan-ivar]

Reopening, to discuss the stats API shape separately.

[vr000m]

What is the summary of discussion so far? is there a link to an email archive or PR?

[wilaw]

@vr000m - Meeting notes are stored on the wiki at - https://www.w3.org/wiki/WebTransport . Click to the particular meeting you are interested in. We have full recordings and transcripts linked with each meeting archive.

[jan-ivar]

I think we have general idea of shape now, with connection-level and aggregate stream stats off of wt.getStats() and we're discussing per-stream-level stats off of readable.getStats() and writable.getStats() that will mostly contain byte progress counters in #372.

Neither of those approaches should be difficult to traverse, nor should stats disappear (one caveat: the per-stream stats are meant for long-lived streams, for short-lived ones we have aggregate stats at the connection level).

We have 5 other issues on stats so I think we can close this one.