Open vasilvv opened 2 months ago
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.
Meeting:
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.