Accurate Metrics

[Stebalien]

Now that transports do stream multiplexing/encryption, it's impossible to externally track bandwidth metrics.

Proposal: Introduce an (optional) interface that transports can implement to internally (and more accurately) track bandwidth usage. Transports that use the transport upgrader will get this for free but transports like QUIC will have to implement this manually.

type BwStats struct {
	TotalIn, TotalOut int64
	RateIn, RateOut   float64
}

type MeteredConn interface {
	Conn
	BandwidthStats() BandwidthStats
}

If a transport Conn doesn't implement this interface, the Network will fallback on tracking bandwidth usage by summing the bandwidth across all open streams over the connection.

Open question: How will we disable this? Can we just make it fast enough that we don't care (go-flow-metrics is pretty damn fast)? Global flag (yuck!).

[marten-seemann]

What is the problem here with QUIC? Why is it not ok to sum over the streams?
Do you want to include ACKs and other control frames in the bandwidth measurement? Or distinguish between goodput and throughput?

[Stebalien]

Do you want to include ACKs and other control frames in the bandwidth measurement?

Yes. I'd like to measure the total bandwidth (including control, crypto, etc.). (I guess to be accurate for TCP we'd have to ask the OS).

[marten-seemann]

I guess to be accurate for TCP we'd have to ask the OS.

That’s correct. Furthermore, we’d have to specify at which layer we draw the boundary (does the TCP header count? The QUIC header? The UDP header? What about IP itself?).

Or to rephrase my question, under which circumstances does summing up over all streams give us a result that would make us act in a different way than if we measured the total bandwidth (however we end up defining it)?

[Stebalien]

Or to rephrase my question, under which circumstances does summing up over all streams give us a result that would make us act in a different way than if we measured the total bandwidth.

Good point. Summing is probably sufficient.

I know we have some users billing based on the network statistics but, really, billing for effective bandwidth is probably better anyways. I'm not even sure if we can get accurate measurements from the OS as we'd need to include retransmissions, etc.