CINXE.COM

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Network requirements for W3C meetings — checklist</title> <link rel="stylesheet" href="https://www.w3.org/StyleSheets/activities.css" /> <link rel="stylesheet" href="https://www.w3.org/StyleSheets/generic-navbar-1.css" /> <style> ul.checklist { list-style: none; } ul.checklist li:before { content: '□ '; } </style> </head> <body> <p><a href="/"><img src="/Icons/WWW/w3c_home" alt="W3C" border="0" /></a><a href="/Systems"><img src="/Icons/WWW/sys" height="48" width="212" border="0" alt="SysAdmin Team" /></a></p> <h1>General Network Requirements for W3C TPAC and AC meetings</h1> <p>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.</p> <p>See also <a href="https://lists.w3.org/Archives/Team/w3t-archive/2007Feb/0310.html">AC A/V requirements</a></p> <h2>Checklist</h2> <p><a href="/2015/02/20-hostnetworkchecklist.html">Formal checklist</a> to be completed by quoting venue networking engineers.</p> <h2>Network Login</h2> <p>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.</p> <p>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.<br> 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.<br> 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.</p> <p>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).</p> <p>In case that a browser is used to register:</p> <ul> <li>The registration delay must not be above 3s under the heaviest expected simultaneous login load.</li> <li>The login form and process must have <a href="https://validator.w3.org/">valid markup</a> and must also conform to the <a href="/TR/WCAG/">WAI Web Content Accessibility Guidelines (WCAG)</a>. The login form must be accessible to people with disabilities, in order to ensure autonomous login.</li> <li>There should be no password. If there is one, in order to minimize the impact of having to repeatedly type in a password each time a user logs in, the login process must allow the browser to memorize the password using mechanisms such as cookies or be compliant with other browser mechanisms that record the login form data.</li> </ul> <p>Network logins should not time out in under 12 hours, even if the system is disconnected and reconnected during that period.</p> <h2>Network medium and setup characteristics</h2> <p>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.</p> <h2>Bandwidth characteristics</h2> <table class="centered" border="1" style="margin-left: auto; margin-right: auto"> <thead> <tr> <th>type of event</th> <th>number of participants</th> <th>number of devices*</th> <th>minimum downstream capacity</th> <th>minimum upstream capacity</th> </tr> </thead> <tbody> <tr class="treven"> <td>AC meeting</td> <td>100-180</td> <td>250-450</td> <td>100 Mb/s</td> <td>30 Mb/s</td> </tr> <tr class="trodd"> <td>TPAC</td> <td>500-650</td> <td>1250-1625</td> <td>300 Mb/s</td> <td>150 Mb/s</td> </tr> </tbody> </table> <p> <p>*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).</p> <h2>QOS / Service interruption tolerance</h2> <p>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.</p> <p>Ideally connectivity is provided by multiple load balanced lines from different carriers.</p> <h2>Traffic Shaping/Rate Limiting</h2> <p>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.</p> <h2>Round-trip delay</h2> <p>The round trip-delay to irc.w3.org (Cambridge, Massachusetts, USA) as measured by ping should not exceed 120 ms.</p> <p>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</p> <p>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.</p> <p>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.</p> <h2>DHCP Server</h2> <p>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.</p> <p>DHCP leases should last for at least 1 hour.</p> <h2>IP Port Blocking</h2> <p>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.</p> <h2>Proxying</h2> <p>No proxying (HTTP, IP, or other) is acceptable.</p> <h2>Hard-wired connections</h2> <p>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.</p> <h2>Installation and testing</h2> <p>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.</p> <p>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.</p> <h2>Technical support during the event</h2> <p>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.</p> <p>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.</p> <p>The network administrator must be readily available the first day of meetings in case there are problems.</p> <h2>Other information to be provided to the network supplier</h2> <p>In our formal request, W3C or the meeting host will provide the following information:</p> <ul> <li>The class of meeting (WG, WS, AC, TPAC) and expected number of attendees</li> <li>Coverage: describe the physical areas where we expect the network to be reachable, such as the names of conference rooms, hall, meeting rooms; which rooms require hard-wired connections, which only wi-fi.</li> <li>A floor plan with access points provided.</li> <li>Access point capacity and load balancing mechanisms. <li>QOS / Service interruption tolerance: Penalty clauses for service interruptions.</li> <li>If hard-wired connections are needed, the specific days, the usage (VoIP?), and how many connections will be required.</li> </ul> <hr /> <address> Vivien Lacourba, for the <a href="/People/functions/systeam">W3C Systems Team</a><br> $Revision: 1.97 $ of $Date: 2019/09/27 18:44:56 $ </address> </body> </html>