The Long Beach Internet Telephony� Conference and EXPO
in October 2003 was a successful show in more ways than one. The event was
met with much enthusiasm from the exhibitors as well as the attendees who
packed into the Exhibit Hall hungry to learn about the newest VoIP
technologies. For our team, working behind the scenes, it was a great
learning experience in what it takes to assemble a network on the show
floor with connectivity to the Internet that can handle the traffic
generated from the exhibitors showcasing their products as well as Wi-Fi
connected attendees surfing the Web and checking e-mail.
Well, we came away from that show with a few lessons learned. For one
thing, southern California has a more pleasant climate than Connecticut
(although admittedly I don�t mind the opportunity to ice skate on the
pond across from my house in winter). I also learned that English seems to
be a second language in the area (time to start watching Spanish
channels). But humor aside, there were a number of lessons learned setting
up the network at the event.
When it comes to provisioning Internet connection for a trade show, there
are a multitude of issues to consider. These range from the selection of
the ISP based on reputation and price to hooking up individual nodes to
the network and having them operating in short order. The pace of
operation in a trade show is much more demanding than that in the office.
Deadlines are tighter, resources are more restricted, and not the least,
prices are inflated. One of the main challenges of getting an Internet
connection installed is finding an ISP that would undertake that task. We
needed -- at a minimum -- a full capacity T1 line. Anything short of that
(such as Cable or DSL) would have been unable to deliver the quality and
the upload/download bandwidth that the users would expect. Here are the
steps we took to make the network infrastructure at Internet Telephony
Conference & EXPO a success.
� Months prior to the show, we contacted multiple ISPs to gauge
availability and pricing for a T1 circuit. Reality came crashing down when
we actually couldn�t find anyone willing to supply the circuit. Here is
the reason why: When it comes to business installations, most ISPs like
long contracts of one- to three-year terms. This guarantees a stream of
revenue for a fixed period of time resulting in a high profit margin for
them. As most locations in the ISPs� territories are already wired and
much of their operations are automated, ISPs can quickly recoup the setup
and configuration cost of a circuit and the remaining monthly payments
from the customers are mainly profit. Our requirements were obviously for
a duration of a week and hence the reluctance of the ISPs to work with us.
The only ISP that finally agreed to our terms was the local Telco whose
terms included both setup and tear-down charges as well as a full
month�s subscription. But in the end, the Hotel, where the event was
held, approached us with a fair proposal and we had a deal.
� Many hotels and convention centers are already wired to the Internet
and they have discovered a lucrative business model by reselling their
connections to event organizers. This may sound like a win/win situation
but in many cases it is far from it. Many of these locations have inflated
pricing, limited bandwidth, limited IP addresses, and limited access
ports. To make matters worse, many have overzealous firewalls with login
requirements and timeouts that slow down the response times and inhibit
efficient network usage. Considering these issues, it was with some
trepidation that we started to plan out our network with the hotel staff.
We were assured that our concerns with regards to reliability and
efficiency will be addressed.
� Arriving onsite, a few days prior to the opening of the event, we
began crimping and laying down network cables while the Exhibit Hall came
to life at dizzying speed. The connection to the Internet was established
flawlessly and the network was ready to serve.
A few exhibitors expressed concern that a T1 bandwidth may be too
inadequate to satisfy the traffic generated by all the users. Naturally we
were concerned with the same issue and that is why we had the network
under tight scrutiny for any signs of stress. And such signs became
apparent in one instance.
In one instance, the network suddenly and without warning slowed to a
crawl. Using our tools we were able to quickly identify the source of the
problem. Apparently a user was flooding one of the Wi-Fi hubs that was set
up at a distant location thereby causing the network degradation. Once the
node was removed from the network, everything was back to normal.
Our biggest fear was the latest string of exploits gripping Microsoft
products. It would take one unpatched (or worse, pre-infected) node to
bring down the whole network. During the February Internet Telephony
Conference & EXPO in Miami we were indeed stung with such problem. Our
investigation determined the cause of a severe network packet loss to be
the much feared SQL Server worm, known as the Slammer. One of the
exhibitors had a server with an unpatched version of SQL Server. Overnight
the server had been compromised by the Slammer worm and proceeded to flood
the network. Fortunately we identified and neutralized the node (by
applying the appropriate patch) before many of the participants even had
woken up.
This time around we were delighted that not a single node was compromised.
The network performed admirably and received high marks on its ability to
support many VoIP calls as well as other activities without a problem. We
also knew that the laws of statistical distribution would be on our side.
In other words not all users required the available bandwidth
simultaneously.
One item that is missing in our arsenal is a bandwidth shaper.
Unfortunately bandwidth shaping is not exact science and it is best
applied to protocols rather than individual nodes. It also requires a fair
amount of computing muscle as it involves intense calculations. We decided
that our resources are best spent identifying and eliminating rogue nodes
than to allocate discrete bandwidths to certain protocols. In the end we
would have still needed to monitor the network for stress anyhow.
Nevertheless, if you have experience with bandwidth shaping, I would love
to receive your feedback. I am especially looking for cost-effective,
easily configurable shapers that can limit bandwidth per node (IP
address).
The next INTERNET TELEPHONY Conference & EXPO is happening from February 11-13, 2004 in Miami, FL. For more information, visit the Web site.
Robert Vahid Hashemian provides us with a healthy dose of reality
every other month in his Reality Check column. Robert is Webmaster for
TMCnet.com -- The Authority on CRM, VoIP, Communications, Call Centers,
Teleservices, Wi-Fi and Biometrics. He is also the author of the recently published
Financial Markets For The Rest Of Us. He can be reached at [email protected].
[ Return To The January
2004 Table Of Contents ]
|