Aaahhh, the new packet metropolitan-area network - a panacea if ever there was one. It brings the "Ethernet solves everything" proposition to the metropolitan area. According to one service provider, you can simply pick your speed - from 1M to 1,000M bit/sec, sign on the dotted line, get handed an RJ-45 interface and, voil , "optical dial tone."
Putting aside the awkward question of how a copper interface delivers optical anything, let's explore the more important question, which is, how do they deliver services? Without the benefit of ATM or circuits of any kind, it looks a little bit like magic - black magic.
So, here are some questions to ask potential service providers to make them earn their keep and keep them honest:
Bandwidth definition: You've signed up for 50M bit/sec service on a Fast Ethernet port that will accept data at twice that rate (and cannot be "clocked" to a lower speed). Does that mean you get 50M bit/sec, on average, over every second? (That would mean a half-second burst at full-line rate followed by an equal-length pause would be deemed acceptable.) Or is your 50M bit/sec of throughput calculated differently? This is the most important question you can ask your prospective MAN service provider. While you might only think of it as buying "50M bit/sec" bandwidth, it is really 50M bit/sec per second per "X" unit of time.
The difference between having a 50M bit service delivery averaged over a second (or fraction thereof), a minute, a day or a week has a major impact on the actual bandwidth you have available when you need it. And, don't forget, they can't weasel out of this question. If service providers can't define the time element, they can't define the service. Time is the sine qua non of this bandwidth equation.
Bandwidth policing: To be sure, surges exceeding your allocated bandwidth will occur - and might occur with some frequency. What will your service provider do with the excess traffic that enters the pipe? (Hint: The answer is "discard.")While the rep might go on about queues and priorities, remember that LAN switches are NOT traffic shapers. Yes, they do have queues - but, in general, not very deep ones.
When LAN switches come under siege, they do a quick triage-and-trash. They discard the packets they are unable to forward. Don't forget that even a relatively minuscule amount of packet loss can have a devastating impact on end-user response time as the affected sessions freeze waiting for the packets that never come and then attempting to recover the wounded sessions.
Cross-customer bandwidth policing: Ultimately, your packets will travel over your service provider's MAN infrastructure interleaved among those of other MAN customers. Given that your service provider's switches, at best, have eight hardware queues, how do they control and allocate bandwidth for, say, 88 customers? Do they groom seven and let all the rest get dumped into the eighth queue?
Granular Bandwidth Control: Inside any company's logical pipes, all traffic usually is not created equal. Suppose you have four classes of traffic (control, delay sensitive, transactions and file transfer) that must receive the appropriate relative priorities. If all your traffic is mapped into one queue across your service provider's MAN, how will you handle class of service?
Service-level agreement management: How will your service provider report to you? What will you know about peaks and averages, as well as the packet discard rates and latency of the service provider's network?
And make sure they prove their answers. Mere claims count for nothing.
Tolly is chairman and CEO of Tolly Research. Tolly also is founder, president and CEO of The Tolly Group. He can be reached at firstname.lastname@example.org