MAT-WG proposal for WLAN measurements on RIPE Atlas
MAT-WG, thankyou for giving me the opportunity to present on "The Value of WLAN Measurements for the R&E Community" at the Measurement and Tools Working Group at RIPE69. You can find my presentation and stenography logs at: https://ripe69.ripe.net/presentations/91-eduroam-and-Atlas-RIPE69.pdf https://ripe69.ripe.net/archives/steno/40 To progress this work within the RIPE NCC Atlas development team I'd like your input into the following five (5) points: #1: For "opt-in" WLAN measurements to be enabled on RIPE Atlas As a point of clarification (and reiterated by Daniel Karrenberg) the intention is that ALL v3 probes will be capable of WLAN measurements - but measurements will ONLY be turned on by a probe host. #2: WLAN measurements will support associating to an "open" or 802.1X protected network for the purposes of performing a measurement As an active monitoring network the Atlas probes WILL NOT scan and report on all/available SSIDs. It will ONLY associate with EXPLICITLY defined SSIDs listed in the measurement. For eduroam quality purposes the success/failure of an 802.1X associations is initially the most interesting part of the measurement in determining whether sites are correctly deploying this service. There will be results related to the authentication process. #3: Any measurements performed over the wireless interface are aligned with a request to associate/authenticate to a particular network. The wireless interface will be connected only for particular tests bundled with the association to an SSID. All other tests will be performed via the wired interface as is currently the case. #4: The schedule for implementation will be determined by the RIPE NCC R&D team ...but hopefully your support for this work will allow them to prioritise this work while not jeopardising the other commitments the team has made to the community. #5: This proposal is inline with your understanding of "WiFi measurements" on the Atlas roadmap I'd be particularly interested in your feedback on whether you thought that the WiFi Measurements listed in the http://roadmap.ripe.net/ripe-atlas/ would accomplish the above or something completely different. My feeling from the room was that the above was largely accepted. I'd appreciate those that voiced their support to also do this on the mailing list again. If there's any confusion I'm willing to clarify further. Thanks, -Brook -- =================================================== Brook Schofield, Project Development Officer GÉANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991 www.géant.org <http://www.xn--gant-bpa.org>
Hi Brook, This looks like a great. The certificate/port checks/NAT checks would be very useful. Other things that could probably be reported easily for diagnostics are 2.4Ghz vs 5Ghz, link speed, signal. I read https://ripe69.ripe.net/archives/steno/40/ - we do drop our NREN test user into a blackhole vlan, but would change that for this test! Cheers,
Brook Schofield <schofield@terena.org> 27/11/2014 13:52 >>> MAT-WG,
thankyou for giving me the opportunity to present on "The Value of WLAN Measurements for the R&E Community" at the Measurement and Tools Working Group at RIPE69. You can find my presentation and stenography logs at: https://ripe69.ripe.net/presentations/91-eduroam-and-Atlas-RIPE69.pdf https://ripe69.ripe.net/archives/steno/40 To progress this work within the RIPE NCC Atlas development team I'd like your input into the following five (5) points: #1: For "opt-in" WLAN measurements to be enabled on RIPE Atlas As a point of clarification (and reiterated by Daniel Karrenberg) the intention is that ALL v3 probes will be capable of WLAN measurements - but measurements will ONLY be turned on by a probe host. #2: WLAN measurements will support associating to an "open" or 802.1X protected network for the purposes of performing a measurement As an active monitoring network the Atlas probes WILL NOT scan and report on all/available SSIDs. It will ONLY associate with EXPLICITLY defined SSIDs listed in the measurement. For eduroam quality purposes the success/failure of an 802.1X associations is initially the most interesting part of the measurement in determining whether sites are correctly deploying this service. There will be results related to the authentication process. #3: Any measurements performed over the wireless interface are aligned with a request to associate/authenticate to a particular network. The wireless interface will be connected only for particular tests bundled with the association to an SSID. All other tests will be performed via the wired interface as is currently the case. #4: The schedule for implementation will be determined by the RIPE NCC R&D team ...but hopefully your support for this work will allow them to prioritise this work while not jeopardising the other commitments the team has made to the community. #5: This proposal is inline with your understanding of "WiFi measurements" on the Atlas roadmap I'd be particularly interested in your feedback on whether you thought that the WiFi Measurements listed in the http://roadmap.ripe.net/ripe-atlas/ would accomplish the above or something completely different. My feeling from the room was that the above was largely accepted. I'd appreciate those that voiced their support to also do this on the mailing list again. If there's any confusion I'm willing to clarify further. Thanks, -Brook -- =================================================== Brook Schofield, Project Development Officer GÉANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 ( tel:%2B31%2020%20530%204488) Fax +31 20 530 4499 ( tel:%2B31%2020%20530%204499) Mob +31 65 155 3991 www.géant.org ( http://www.xn--gant-bpa.org) Mae'r e-bost hwn ac unrhyw ffeiliau atodedig yn gyfrinachol ac at sylw'r unigolyn neu'r sefydliad a enwir uchod. Bydd unrhyw farn neu sylwadau a fynegir yn perthyn i'r awdur yn unig ac ni chynrychiolant o anghenraid farn Coleg Sir Gâr. Os ydych chi wedi derbyn yr e-bost hwn ar gam, rhowch sylw i'r gweinyddwr ar y cyfeiriad canlynol: postmaster@colegsirgar.ac.uk Cysidrwch yr amgylchedd - a oes wir angen argraffu'r ebost hwn? This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Coleg Sir Gâr. If you have received this email in error please notify the admin istrator on the following address: postmaster@colegsirgar.ac.uk Please consider the environment - do you really need to print this email?.
Hi Simon, Atlas probes do not support 5Ghz. Victor Naumov R&D RIPE NCC On 11/27/14, 3:35 PM, Simon Palmer wrote:
Other things that could probably be reported easily for diagnostics are 2.4Ghz vs 5Ghz, link speed, signal.
Actually it doesn't support 2.4GHz either :-) but at least the v3 hardware can - if the community agree that #1 in my proposal is a a good idea. I'm sure a future hardware platform for RIPE Atlas (v4, v5) will support 5GHz while mainting the competitve pricing of the current hardware. -Brook On 27 November 2014 at 16:04, Viktor Naumov <vnaumov@ripe.net> wrote:
Hi Simon,
Atlas probes do not support 5Ghz.
Victor Naumov R&D RIPE NCC
On 11/27/14, 3:35 PM, Simon Palmer wrote:
Other things that could probably be reported easily for diagnostics are 2.4Ghz vs 5Ghz, link speed, signal.
-- =================================================== Brook Schofield, Project Development Officer GÉANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991 www.géant.org <http://www.xn--gant-bpa.org>
Hi,
I'm sure a future hardware platform for RIPE Atlas (v4, v5) will support 5GHz while mainting the competitve pricing of the current hardware.
Picking up on this: we're always on the lookout for potential new hardware generations, and we are testing new devices as we learn about them. Recently we checked out the ASUS WL-330NUL and the Edimax BR-6258 Mini. While these are small and sexy enough (like the v1/v2 probes were; it looks like we basically invented the form factor (*) :-), their hardware is too constrained for our purposes. Please let us know if you know about new devices that we should evaluate. The primary requirements are price (should be off-the-shelf, most likely), capabilities (RAM and local storage needs 32MB minimum, the more the better) and form factor (see the above candidates; home router sized boxes are not really ideal). Regards, Robert (*) interesting historical artefact from our archives: the attached image is the "concept art" of how a probe could look like, dated mid-2010
Hi,
On 09 Dec 2014, at 10:52, Robert Kisteleki <robert@ripe.net> wrote:
Hi,
I'm sure a future hardware platform for RIPE Atlas (v4, v5) will support 5GHz while mainting the competitve pricing of the current hardware. Please let us know if you know about new devices that we should evaluate. The primary requirements are price (should be off-the-shelf, most likely), capabilities (RAM and local storage needs 32MB minimum, the more the better) and form factor (see the above candidates; home router sized boxes are not really ideal).
Have you looked at the Vocore? http://vocore.io Jeroen.
This thread seems to have gone off track and started to talk about a platform for RIPE Atlas v4 hardware. While I encourage that discussion I'm wondering if anyone has any comments on WLAN authentication testing and tests being run over the /current/ Atlas platform? Anything left out in my 5 points below? -Brook On 27 November 2014 at 17:52, Brook Schofield <schofield@terena.org> wrote:
MAT-WG,
thankyou for giving me the opportunity to present on "The Value of WLAN Measurements for the R&E Community" at the Measurement and Tools Working Group at RIPE69.
You can find my presentation and stenography logs at: https://ripe69.ripe.net/presentations/91-eduroam-and-Atlas-RIPE69.pdf https://ripe69.ripe.net/archives/steno/40
To progress this work within the RIPE NCC Atlas development team I'd like your input into the following five (5) points:
#1: For "opt-in" WLAN measurements to be enabled on RIPE Atlas
As a point of clarification (and reiterated by Daniel Karrenberg) the intention is that ALL v3 probes will be capable of WLAN measurements - but measurements will ONLY be turned on by a probe host.
#2: WLAN measurements will support associating to an "open" or 802.1X protected network for the purposes of performing a measurement
As an active monitoring network the Atlas probes WILL NOT scan and report on all/available SSIDs. It will ONLY associate with EXPLICITLY defined SSIDs listed in the measurement.
For eduroam quality purposes the success/failure of an 802.1X associations is initially the most interesting part of the measurement in determining whether sites are correctly deploying this service. There will be results related to the authentication process.
#3: Any measurements performed over the wireless interface are aligned with a request to associate/authenticate to a particular network.
The wireless interface will be connected only for particular tests bundled with the association to an SSID. All other tests will be performed via the wired interface as is currently the case.
#4: The schedule for implementation will be determined by the RIPE NCC R&D team
...but hopefully your support for this work will allow them to prioritise this work while not jeopardising the other commitments the team has made to the community.
#5: This proposal is inline with your understanding of "WiFi measurements" on the Atlas roadmap
I'd be particularly interested in your feedback on whether you thought that the WiFi Measurements listed in the http://roadmap.ripe.net/ripe-atlas/ would accomplish the above or something completely different.
My feeling from the room was that the above was largely accepted. I'd appreciate those that voiced their support to also do this on the mailing list again. If there's any confusion I'm willing to clarify further.
Thanks,
-Brook -- =================================================== Brook Schofield, Project Development Officer GÉANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991 www.géant.org <http://www.xn--gant-bpa.org>
-- =================================================== Brook Schofield, Project Development Officer GÉANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991 www.géant.org <http://www.xn--gant-bpa.org>
On 2014-12-10 13:59, Brook Schofield wrote: [...]
Anything left out in my 5 points below?
Maybe :-) What would be the management model for those probes? I presume that both the "eduroam" operators would want to have access to the probes' data (and management?) as well as the organisations where the probes are plugged in. Which may bring the issue of a *simple* shared access and/or management capability back to the table.
-Brook
Wilfried.
On 2014-12-10 17:23, Wilfried Woeber wrote:
What would be the management model for those probes? I presume that both the "eduroam" operators would want to have access to the probes' data (and management?) as well as the organisations where the probes are plugged in.
The idea is that the probe that will/may do wifi (such as eduroam) in the future has to first function as a regular probe, ie. connected over a wired connection, working properly, have a host, etc. *Then* the host can allow wifi measurements on the probe. This also allows existing hosts to opt-in into such measurements.
Which may bring the issue of a *simple* shared access and/or management capability back to the table.
No, not really. It'd be bad is someone else other than the host could manage this. Regards, Robert
participants (6)
-
Brook Schofield -
Jeroen van der Ham -
Robert Kisteleki -
Simon Palmer -
Viktor Naumov -
Wilfried Woeber