W3CSysAdmin Team

General Network Requirements for W3C meetings

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 and irc access for effective use of the meeting time. Almost every meeting attendee will have a computer and desire a connection 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.

For larger meetings such as TPAC (Technical Plenary and Advisory Committee meeting) and AC (Advisory Committee), we will have a printed copy of this page for final review by on site technicians with them initially each section as a checklist.

See also AC A/V requirements and Antonio's informal checklist.

The following table describes the application scope for these guidelines:

type of event application scope
AC / TPAC We consider the following requirements to be strong requirements.
Workshops if the Workshop organizers conclude that general net access for participants is required, then they should conclude that this description states the requirements. We understand that in some situations, some requirements cannot be met. We will consider options in those cases.
Working Group meetings Please consider these as experiential guidelines that may help you prepare better for a network-enabled meeting.

The lack of meeting a single requirement is not intended to disqualify someone. If there are choices, we will use these criteria to guide us in making a choice.

Network Login

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 (WEP WPA 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 have used ESSID W3C many times in past events and often choose a regional name, for instance province the meeting is being held, as the password. We would like to know these in advance so we can communicate it to attendees.

Connection must support all common operating systems, and to the extent that a browser is used to register, all common browsers. Specifically, this includes Windows, Linux and MacOS. Browsers include (at least) Internet Explorer, Chromium, Firefox, Opera, Safari, and Lynx.

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.

Network medium and setup characteristics

The entire W3C Meeting area should be served by a single 802.11A/G/N "network", i.e. a single ESSID. If multiple access points are needed and provided, 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.

Bandwidth characteristics

The following table gives a relationship between number of attendees and minimum downstream and upstream capacity to the Internet that, from experience, we know is required to provide quality service for the applications used in our meetings. Whenever possible, we would prefer a dedicated service.

type of event number of participants minimum downstream capacity minimum upstream capacity
WG meeting 10-30 5 Mb/s 2.5 Mb/s
workshop 50-100 10 Mb/s 3 Mb/s
AC meeting 150-200 20 Mb/s 8 Mb/s
Tech Plenary 450-650 35 Mb/s 15 Mb/s

With smartphones and tablets we are often seeing people connecting two devices. Please double the number of attendees to know the number of devices likely to be connecting to the network.

QOS / Service interruption tolerance

We depend on SSH and other "private virtual network" technologies that are sensitive to interruptions in service. We also frequently require VoIP which cannot usefully tolerate service interruption. 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. A service interruption is defined as the inability to move any traffic between more than 20% of our users and the Internet.

Round-trip delay

The round trip-delay to irc.w3.org (Cambridge, Mass) as measured by ping should not exceed 150 ms. Thus satellite services are unacceptable.

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. DNS server requests for well-known sites should not exceed 100 ms.

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.

DHCP Server

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 participants indicated for the relevant meeting category.

DHCP leases should last for at least 1 hour.

IP Port Blocking

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 (6667), assorted tunneling (IPsec, SSH, SSL) and VoIP.


No proxying (HTTP, IP, or other) is acceptable.

Hard-wired connections (for VoIP boxes, dial-in calls)

If our request specifies it, we will need hard-wired connections for running a VoIP connection. Keeping this off the wireless network is advisable. We need assurances that 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.

Installation and testing

For W3C AC meetings and the Tech Plenary meetings, we require the final configuration be installed and operational 7 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 48 hours before the meeting, and SHOULD be operational 24 hours before the meeting. The vendor should demonstrate to us at that time a load test moving the required bandwidth.

Technical support during the event

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.

Other information to be provided to the network supplier

In our formal request, W3C or the meeting host will provide the following information:

Valid XHTML 1.0! Systems Team
$Revision: 1.86 $ of $Date: 2015-02-20 09:21:56 $