NDT-DEV email list created

[Aaron Brown <>]

Hey Peter,

On May 11, 2015, at 2:22 PM, Peter Boothe <> wrote:

Two other important things:

1. We have well-specified default arguments so that for each new argument, the no-argument version is identical to the original NDT. 

Yep, definitely. The defaults should be a single stream, 10 second TCP test with none of the other parameters set to anything.

2. We agree that the server is not responding saying "I can run your test" or "I can't run your test", it is instead saying "in response to your request, these are the tests I am willing to run, and here are the non-default parameters for each of those tests".  The server is performing capability negotiation with the client, and the server's response is the "take-it-or-leave-it" test parameters offered by the server to the client in response to the client's request.  The client can then either run the tests or close its connection.

So the model isn’t to deny any test, but to give them a different test and let them accept or reject it? e.g. if we put in maximum limit of say 30 seconds for a test, if someone requests a 60 second test, we just give them a 30 second test?

Looking at the test arguments under the auspices of capability negotiation and explicitly specifying the defaults helps ensure that it is easy for future servers to add (or drop) support for arguments, and that old clients never lose capabilities.

As a sidenote, it is going to be increasingly important for the server to be robust to client cancellation.  The websocket tests, if they do see significant uptake (as I hope they will), will enable a lot of new NDT clients, but those clients are likely to be more flaky (all of a sudden, anyone will be able to throw up a web page with a speed test and some Google ads on the side).  I'll have a pull request for you this week, hopefully, that helps increase server robustness as part of enabling NDT-over-SSL.  It is currently under internal review.

Yeah, I can’t vouch for the robustness of that portion of the code, so any improvements are greatly appreciated :)

Cheers,

Aaron

  -Peter

On Mon, May 11, 2015 at 10:16 AM, Aaron Brown <> wrote:

Hey Peter,

That looks reasonable to me. I’d been trying to avoid scheduling a test that the server couldn’t perform, but if the client immediately cancels, that’s probably not all that big of a deal.

Cheers,

Aaron

On May 8, 2015, at 5:36 PM, Peter Boothe <> wrote:

I think the right thing is for the server to respond with the tests and test parameters it accepted.  Then the client can decide whether that set of accepted parameters is okay or not.  This allows NDT to future-proof itself as more test parameters arrive (or depart).  So the test request message would be:

{

  “msg”: “v3.5.5”,

  “tests”: “54",

  “test_arguments”: {

      “2”: {     # TEST_C2S

          “duration”: 15,

          “streams”: 5

      },

      “4”: {     # TEST_S2C

          “duration”: 10,

          “streams”: 1

      },

      # requesting the TEST_STATUS test - no args == default args

      # requesting the TEST_META test - no args == default args

  }

}

and the response from an old server would be (in the second MSG_LOGIN message with the test ids):

{

   "msg": "2 4 16",

}

while the response from a new server (in the second MSG_LOGIN message with the test ids) would be:

{

   "msg": "2 4 16",

   "test_arguments": {
     "2": {

          “duration”: 15,

          “streams”: 5

      }

      "4": {

         “duration”: 10,

         “streams”: 1

      }

}

Then the client, if they don't like response, can just drop the connection.  Then old clients can contact new servers and vice-versa.

  -Peter

On Fri, May 8, 2015 at 3:39 PM, Aaron Brown <> wrote:

Hey Peter,

If a server can’t perform the requested test (e.g. it’s an old server, and can’t handle multiple streams), I want the client to be able to make a decision about what to do, and not be surprised when it suddenly gets a different set of tests than it requested. If those parameters aren’t critical to what the client wanted, it can retry without the parameters set, but there’s no sense in automatically performing a different test if it’s not doing what the client wanted to do.

Cheers,

Aaron

On May 8, 2015, at 3:32 PM, Peter Boothe <> wrote:

Isn't that what you want?  We want old clients to be able to make requests to new servers, and we want old servers to service requests from new clients.

Or do we not want old servers to service requests from new clients?

  -Peter

On Fri, May 8, 2015 at 11:41 AM, Aaron Brown <> wrote:

Hey Peter,

That had been my original thought, but I wanted to ensure that an older server would deny the tests if it didn’t support arguments. From looking through the code, it looks like it’d just blindly accept the test and ignore the arguments.

Cheers,

Aaron

On May 8, 2015, at 11:32 AM, Peter Boothe <> wrote:

I think that this idea is good in the generalities and wrong in the specifics.  In particular, the new format should be a superset of the old format.

{

  “msg”: “v3.5.5”,

  “tests”: “54",

  “test_arguments”: {

      “2”: {     # TEST_C2S

          “duration”: 15,

          “streams”: 5

      },

      “4”: {     # TEST_S2C

          “duration”: 10,

          “streams”: 1

      },

      # requesting the TEST_STATUS test - no args == default args

      # requesting the TEST_META test - no args == default args

  }

}

On Fri, May 8, 2015 at 9:51 AM, Aaron Brown <> wrote:

Hey Folks,

The current extended json login message is now just looks like this right:

{
   “msg”: “v3.5.5”,
   “tests”: “54"
}

There’s a MultiplePorts branch that is doing multiple streams, along with interval snapshots and some other features. Given that the new tests accept test parameters (e.g. “c2s duration”, “snapshot delay”, etc), my thought is to change the extended login message some:

{
  “msg”: “v3.5.5”,
  “requested_tests”: {
      “2”: {     # TEST_C2S
          “duration”: 15,
          “streams”: 5
      },
      “4”: {     # TEST_S2C
          “duration”: 10,
          “streams”: 1
      },
      “16”: {},   # requesting the TEST_STATUS test
      “32”: {},   # requesting the TEST_META test
  }
}

If a client requested an unknown test argument, then the server would deny the request. Assuming the client doesn’t care about the extended parameters, it could just send the old request style, or it could send the new request style with no requested options. Existing servers would simply deny the test since there’s no “test” option included.

What do folks think?

Cheers,
Aaron

--

Peter Boothe |  | ᴹ̶LAB | http://measurementlab.net

--

Peter Boothe |  | ᴹ̶LAB | http://measurementlab.net

--

Peter Boothe |  | ᴹ̶LAB | http://measurementlab.net

--

Peter Boothe |  | ᴹ̶LAB | http://measurementlab.net