Clarify the semantics of stats and their relationship to QUIC connection

[vasilvv]

Currently we have a lot of stats like bytesSent that refer to "QUIC connection". That's poorly defined in cases when (1) we're doing pooling, or (2) we're doing HTTP/2. We should clarify the semantics for those, and/or remove those that appear to be not particularly useful.

[jan-ivar]

Good catch. It looks like the term "QUIC connection" is isolated to the sections about stats.

I suspect we want s/QUIC connection/WebTransport session/ here.

That way, if I create two WebTransports A and B, they'll report independent numbers, regardless of whether they were pooled or not, and I can add them together if I want pool totals.

The alternative would be that pooled transports return identical stats, which doesn't seem very useful.

[jan-ivar]

Meeting:

• packets are not attributable to sessions
• packet loss for individual sessions is not useful, because loss detection and congestion control is generally connection level
• poorly worded stats discovered numOutgoingStreamsCreated and numincomingStreamsCreated: incoming and outgoing terms refer to server created or client created, not direction of travel
• there's no bytes lost
• Do we need bytes at connection level, session level or both? And do they include framing overhead?
• Do we remove all stats above smoothRtt? Or do we remove some from pooled connections?
• might be worth having some stat to say there's loss on the connection
• big reason for stats is to detect network problems.
• options: remove, attribute correctly to connection or session, naming fixes, adding bytes lost? packets/bytes sent, lost and acked
• group triage:

  unsigned long long bytesSent; // CONNECTION LEVEL
  unsigned long long packetsSent; // CONNECTION LEVEL
  unsigned long long packetsLost; // CONNECTION LEVEL (RFC9002 has loss definition)
  unsigned long long bytesLost; // CONNECTION LEVEL NEW
  unsigned long numOutgoingStreamsCreated; // (numClientCreatedStreams) REMOVE
  unsigned long numIncomingStreamsCreated; // (numServerCreatedStreams) REMOVE
  unsigned long long bytesReceived; // CONNECTION LEVEL
  unsigned long long packetsReceived; // CONNECTION LEVEL

• I.e. two WebTransport objects A and B that are pooled return same numbers for CONNECTION LEVEL ones?
• Consider s/bytesSent/connectionBytesSent/
• We previously agreed estimatedSendRate (which is forward prediction) was OK to share on pooled connections. Do we feel the same for these stats?
• there's also network state partitioning in most browsers

[wilaw]

TPAC meeting - https://www.w3.org/wiki/WebTransport/Meetings2023#WebTransport_TPAC_meeting_-_Seville_2023TPAC - and https://docs.google.com/presentation/d/1PzshEzs8GPeoYvVboi-9D0n8ZtXBZHuM7uZe1blahSk/edit#slide=id.g27bc4bd45e1_0_188 - no objection to implementing changes, desire to keep both packets and bytes, no objection to sharing data across pooled connections.