Our general requirement is to provide the event attendees with wireless Internet access for a wide variety of laptop computers and devices, using 802.11A/G/N connections, throughout the duration of the event. W3C meetings rely heavily on Web, IRC, VoIP and other access for effective use of the meeting time. Almost every meeting attendee will have a computer, smart phone and perhaps a tablet they will desire a connection for throughout the meeting. It is vital that our meeting participants not experience any delay in obtaining or using Internet access at any time during the meeting.
See also AC A/V requirements
Formal checklist to be completed by quoting venue networking engineers.
We desire open connections, not requiring special registration procedures. Experience has shown that individual registrations are quite problematic in such large quantity, especially when the meeting is attempting to first convene, due to simultaneous requests.
If a network login is required we prefer to do so at wireless networking
level (WPA2) and not have users need to go to a browser to
login.
Both the ESSID (network name) and password should be short
and easy to communicate and remember.
We prefer an ESSID with the prefix "W3C" and a per event specific suffix eg "TPAC2015", "W3C-TPAC2015"
as a full example. For the password (which will be at least 8 chars long) we often choose a regional name, for instance the province the meeting is being held.
W3C will provide the desired ESSID and password to the network provider at least 1 month in advance of the event so we can communicate it to attendees.
Connection must support all common operating systems, and to the extent that a web browser is used to register, all common browsers. Specifically, this includes Windows, Linux and MacOS. Browsers include (at least) Chrome, Internet Explorer, Firefox, Safari, Opera, and Lynx (a text-based web browser).
In case that a browser is used to register:
Network logins should not time out in under 12 hours, even if the system is disconnected and reconnected during that period.
The entire W3C Meeting area should be served by a single 802.11A/G/N "network", i.e. a single ESSID. Connections must be maintained as clients switch between access points. That is, this requires having a single, common DHCP server standing behind all the access points.
| type of event | number of participants | number of devices* | minimum downstream capacity | minimum upstream capacity |
|---|---|---|---|---|
| AC meeting | 100-180 | 250-450 | 100 Mb/s | 30 Mb/s |
| TPAC | 500-650 | 1250-1625 | 300 Mb/s | 150 Mb/s |
*With smartphones and tablets we are often seeing people connecting two or more devices (we used a 2.5 factor to approximate the number of max devices).
We depend on SSH, VPNs and other "private virtual network" technologies that are sensitive to interruptions in service. We also frequently require VoIP which cannot usefully tolerate service interruption without dropping calls. Therefore, we require a guarantee that in any hour there will be no more than two service interruptions of longer than 2 seconds, and no interruptions longer than 10 seconds.
Ideally connectivity is provided by multiple load balanced lines from different carriers.
To ensure no infected computer or individual user consumes an excessive percent of available bandwidth, there should be a per device throttle to prevent network hogs.
The round trip-delay to irc.w3.org (Cambridge, Massachusetts, USA) as measured by ping should not exceed 120 ms.
The round trip-delay to other popular sites as measured by ping should not exceed 100 ms. eg. google.com, github.com, w3c.github.io
From our experience, the DNS server is often responsible for the biggest delay when the access to this server is limited or overloaded, regardless of the available bandwidth.
The above two round-trip delays describe our preferences for situations where there is a choice. There is room for give and take in the discussion with the host / network providers.
See the above table for number of simultaneous connections required. The DHCP server should be configured to provide enough IP addresses to accommodate the largest number of devices indicated for the relevant meeting category.
DHCP leases should last for at least 1 hour.
While most of our users understand not to overtax the system with p-to-p transfers, we would like the ability to block certain IP protocols. Other than protocols we explicitly block, all other protocols must pass unfettered, specifically including irc (6665, 6667, 6697), assorted tunneling (IPsec, SSH, SSL) and VoIP.
No proxying (HTTP, IP, or other) is acceptable.
If our request specifies it, we will need hard-wired connections for audio/video conferencing and/or live broadcasting of the event. Keeping this off the wireless network is advisable. We need assurances those connections at 90 Kb/s of UDP packets will not tax the system at any point. Our experience suggests that problems can occur in this area unless tested thoroughly ahead of time.
For W3C AC meetings and TPAC meetings, we require the final configuration be installed and operational 2 days before our meeting. The vendor must demonstrate to us at that time a load test moving the required bandwidth.
For smaller meetings, the service SHOULD be operational 24 hours before the meeting. The vendor should demonstrate to us at that time a load test moving the required bandwidth.
For the larger two meeting categories, the W3C Systems Team will designate a responsible contact person. That person must be provided in advance the contact information for the network provider's primary support contact.
The meeting organizers need to have contact information for at least the local network administrator and, if they are handled by the same entity, the upstream provider for the duration of the event.
The network administrator must be readily available the first day of meetings in case there are problems.
In our formal request, W3C or the meeting host will provide the following information: