This is a proposal to change the ndt7 protocol specification. It has been discussed with @bassosimone (original author of the ndt7 spec) at m-lab/ndt7-client-go#75.
Currently, both TCPInfo and AppInfo are optional fields for a Measurement object. When the client is uploading, the sender-side rate is overestimated due to buffers and data still "in transit" at the end of the measurement period. To get an accurate rate, the client must rely on Measurement messages periodically sent by the server. However, an ndt7 server today can be compliant without implementing TCPInfo nor AppInfo, which would make the clients blind to how much data has been actually received by the server and unable to show a meaningful rate to the user.
ndt-server currently sends TCPInfo only, which provides network-level byte count, and that's what our clients use. However, there is a significant asymmetry in what clients show: when downloading, the rate is computed at the application level -- (size of WS payloads / elapsed time) while when uploading the rate is computed at the network level -- (bytes received by the server / elapsed time). Clients cannot generally access TCPInfo metrics (most of our measurements come from Javascript-based implementations) so using a network-level rate for the download is not an option, but we can be consistent by showing application-level measurements in both tests.
Making AppInfo mandatory in the spec for counterflow messages (and adding it to ndt-server) would solve both these problems, guaranteeing that the clients get at least one source of accurate measurements and that we're not mixing apples and oranges by providing rates computed at different levels of the OSI model.
This is a proposal to change the ndt7 protocol specification. It has been discussed with @bassosimone (original author of the ndt7 spec) at m-lab/ndt7-client-go#75.
Currently, both
TCPInfoandAppInfoare optional fields for a Measurement object. When the client is uploading, the sender-side rate is overestimated due to buffers and data still "in transit" at the end of the measurement period. To get an accurate rate, the client must rely on Measurement messages periodically sent by the server. However, an ndt7 server today can be compliant without implementingTCPInfonorAppInfo, which would make the clients blind to how much data has been actually received by the server and unable to show a meaningful rate to the user.ndt-server currently sends
TCPInfoonly, which provides network-level byte count, and that's what our clients use. However, there is a significant asymmetry in what clients show: when downloading, the rate is computed at the application level --(size of WS payloads / elapsed time)while when uploading the rate is computed at the network level --(bytes received by the server / elapsed time). Clients cannot generally accessTCPInfometrics (most of our measurements come from Javascript-based implementations) so using a network-level rate for the download is not an option, but we can be consistent by showing application-level measurements in both tests.Making
AppInfomandatory in the spec for counterflow messages (and adding it to ndt-server) would solve both these problems, guaranteeing that the clients get at least one source of accurate measurements and that we're not mixing apples and oranges by providing rates computed at different levels of the OSI model.