Expose MTU via stats

[vasilvv]

Currently we provide a bandwidth measurement, but it includes framing overhead, making it hard to use for applications.

In general, we should be able to approximate the overhead as MTU - maxDatagramSize, so knowing the MTU would be helpful.

[wilaw]

Discussed at TPAC:
Expose MTU via stats#615
JIB explained why we need a MTU stat.
Eric - first reaction, fine, however, estimatedSendrate should be saying this is how much of your data can get across this pipe. Shouldn’t we tell you the estimated bandwidth that is useful for you? We should adjust estimateSendrate.
Cullen - wouldn't the right number differ with small or large packets?
Eric - we agree that it’s really complicated
Lucas - not strong opinion, what overhead are we talking about? Thresholds jump around. People shouldn’t rely precisely on this data.
Mirja - what is the use case here?
Eric - our estimatedSendRate is a hint to which you can set your encoder. Is exposing current MTU a privacy feature?
Harald - if MTU has a surprising value, it’s good to know.
David - is this worth the agony? It’s always going to be slightly off.
JIB - not hearing too much support for caring.
Mirja - rename to max?
Eric - we could adjust estimateSendRate and do the math for users.
Conclusion: no consensus. Need to readdress issue in bi-weekly calls.

[jan-ivar]

Meeting:

• Can we state the estimatedSendRate excludes overhead instead? I.e. a payload number.
• IOW include the overhead in the calculation to return an estimate of the ceiling without it
• This should address the concern and not need a new stat