Testing both up and down simultaneously would be a nice option

[dtaht]

Only the flent rrul test attempts to test both up and down at the same time. Testing either up or down in series is genuinely useful, but most networks do not actually have everyone downloading, only, and then uploading only, but a mix of the two.

So being able to optionally fire off a test in both directions at the same time would be quite revealing as to what happens to many researchers in the field.

[robertodauria]

Thoughts from a "what happens to the data downstream" point of view:

• Currently each measurement uses a single TCP flow, for which the server generates a UUID that's also the "primary key" to identify a measurement in BigQuery => 1 measurement = 1 TCP flow = 1 BigQuery row
• If we just change the client to connect to both the /download and /upload endpoints at the same time, there will be two separate TCP flows and two BQ rows, that we need to identify as a "single measurement" of a different type somehow
• Throughput and latency will likely be very different if up+down happen at the same time, and these results will end up in the same BQ table as the "upload only" and "download only" results, without a clear way to identify/filter them

I suspect this isn't something we can implement at the client level, but would require to design an extension to the ndt7 protocol and that M-Lab treats the archival data differently in the pipeline.

Coincidentally, we are working on a multi-stream testing protocol these days and the problem of grouping several TCP flows under a single "measurement" entity is one that we are going to solve. This new protocol will basically support what you are proposing here from day one.

[dtaht]

Yes, it would end up having to be a different test type, so as to keep your data straight.