Use server-side measurements during upload test #75
Conversation
Pull Request Test Coverage Report for Build 153
💛 - Coveralls |
| // Upload comes from the client-side Measurement during the upload test. | ||
| // The upload rate comes from the receiver (the server). Currently | ||
| // ndt-server only provides network-level throughput via TCPInfo. | ||
| // TODO: Use AppInfo for application-level measurements when available. |
There was a problem hiding this comment.
If the spec does not explain in a clear enough way what "when available" means, then I think it may be worth clarifying the spec. The underlying source of concern is that, when you have some L4 connection terminator, you are not really speaking with the server at TCP level. So the server may assume the bandwidth is much higher so that, basically, at the end of the day, you very seldomly receive any useful AppInfo data.
This issue is basically the head-of-line blocking issue with TCP that IIUC should be fixed with QUIC (which, however, may have other issues that we don't know yet).
There was a problem hiding this comment.
To further clarify, I just wanted to provide historical content around why the spec says SHOULD but not MUST. I am now wondering whether perhaps we should further explain why it's SHOULD and not MUST explicitly.
There was a problem hiding this comment.
If there is an L4 terminator, and the server does not get a Measurement object as often as we would like, should the client still include AppInfo in its Measurements? I think none of the clients, nor the server, currently does that.
I don't think there's any harm in including AppInfo with server measurements, either. If the client is able to get some Measurements (and thus, TCPInfo), it will also be able to get AppInfo. If no counterflow message can go through, the clients cannot display the rate in any case -- unless we keep client-side measurements as a fallback for such a situation.
Summarizing my understanding here -- please let me know if it's wrong:
- During the download measurement, the client's counterflow messages might not get to the server in case there is an L4 terminator on the path. The server can still use its own
TCPInfo(specifically, the acked bytes which are hard to falsify) to calculate the rate. The client will just use the number of bytes received / elapsed time. - During the upload measurement, the server's counterflow messages might not get to the client. In this case, the client does not have TCPInfo (nor AppInfo) to show the rate at which it's uploading.
- If there's no L4 terminator on the path, adding
AppInfois beneficial in every case, since it allows both client and server to know application-level rates at the receiver. - If there's an L4 terminator, and measurement messages can't go through, adding
AppInfodoes not make things worse than they are.
Is that correct? If so, I think the AppInfo object should be treated as mandatory, at least for our reference server and clients. I'm not sure if we should change the spec, but it seems to me that since both TCPInfo and AppInfo are optional that would mean that a server can potentially not give any feedback to the client during the upload by design, and that feels wrong.
There was a problem hiding this comment.
We discussed this further in private with @robertodauria and concluded that the spec SHOULD (<- no pun intended) be modified to say that "the server MUST send AppInfo during the upload [...]" and further explain why this information is important in the interest of accurate app-level data collection at the sender. Because the sender (i.e., the client) can always piggy-back ACKs for the data from the server to the client, I see much less of a head of line blocking hazard for counter-flow messages so, IIUC, they should also arrive ~timely.
|
I have updated all the unit tests and likely fixed a few in the process ( |
Just use t.Error()
There was a problem hiding this comment.
Reviewable status:
complete! 1 of 1 approvals obtained (waiting on @bassosimone)
cmd/ndt7-client/main.go line 278 at r1 (raw file):
Previously, bassosimone (Simone Basso) wrote…
We discussed this further in private with @robertodauria and concluded that the spec SHOULD (<- no pun intended) be modified to say that "the server MUST send AppInfo during the upload [...]" and further explain why this information is important in the interest of accurate app-level data collection at the sender. Because the sender (i.e., the client) can always piggy-back ACKs for the data from the server to the client, I see much less of a head of line blocking hazard for counter-flow messages so, IIUC, they should also arrive ~timely.
Is this also planned for a future PR?
There was a problem hiding this comment.
Reviewable status:
cmd/ndt7-client/main.go line 278 at r1 (raw file):
Previously, stephen-soltesz (Stephen Soltesz) wrote…
Is this also planned for a future PR?
It's documented on an issue (m-lab/ndt-server#358) -- implementing this change likely means two PRs, one to modify the spec and one to actually add AppInfo to the object sent by ndt-server.
Once we have AppInfo, I plan on changing the client(s) again to use it.
For download test, prefer measurements of bytes confirmed received by client For upload test, prefer measurements of bytes confirmed recevied by server See also: m-lab/ndt7-client-go#75
This change makes the client compute the upload rate via the
TCPInfoobjects periodically sent by the server.Client-side measurements had been used in the initial implementation since counterflow message processing wasn't implemented yet (see #38) and server-side measurement were not available.
Ideally this should use
AppInfoto consistently compute application-level rates in both download and upload, butAppInfoisn't currently sent by ndt-server. For now, showing a server-side network-level measurement is better than a client-side application-level measurement which will be overestimated on slow links (see #74).This change is