Skip to Content.
Sympa Menu

ndt-dev - Re: [ndt-dev] extending the extended login message

Subject: NDT-DEV email list created

List archive

Re: [ndt-dev] extending the extended login message


Chronological Thread 
  • From: Aaron Brown <>
  • To: Peter Boothe <>
  • Cc: "<>" <>
  • Subject: Re: [ndt-dev] extending the extended login message
  • Date: Mon, 11 May 2015 20:10:28 +0000
  • Accept-language: en-US
  • Authentication-results: google.com; dkim=none (message not signed) header.d=none;


On May 11, 2015, at 4:01 PM, Peter Boothe <> wrote:

On Mon, May 11, 2015 at 3:42 PM, Aaron Brown <> wrote:
  1. 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?

Yes!  It a client requests an hour-long test, then the server will say "I offer you this 30 second test instead, take it or leave it".  Similarly, if we later discover that some other parameter of the tests requests is prone to abuse, then we can change the set of allowable parameters and the server can make sure it never offers a test outside of those parameters.  An extreme example of this is old-style servers which will always respond with the empty arguments message, which means "only the defaults for everything".  If, despite the fact that the client would prefer some fancy new stuff, the defaults are okay for that client, then the new client can run old-style tests with the old-style server.

In order to have this work, it is important to establish from the beginning that clients be robust to the server responding with a modified set of arguments.  Otherwise, we and others will create brittle clients, and NDT server development will have all of the attendant maintenance headaches that come from brittleness in clients we do not control.

That seemed rather odd coming from a BWCTL background where there’s more variability in the “meaning” of a test/parameters (e.g. "I’d like a 10 second UDP test at 500M”, “Sure, I can do a 10 second TCP test.”, or “I’d like to schedule a throughput test within the next 5 minutes”, “Sure, I can work you in 10 minutes from now”), but it’s probably not a big deal if the granted test completely breaks the logic of what’s being asked for.

Cheers,
Aaron




Archive powered by MHonArc 2.6.16.

Top of Page