Ken, I'm commenting as I go along. You've already seen
some of this in PM. Thought I'd post it here as well, for
discussion purposes.
This relates to the Sounding Board article at:
soundingboardmag.com
titled: "Routers For Real-Time Applications Go To Bat
in 1999"
Parallel Processors, Small-Packet Handling, Classifiers and
VPN Queuing Describe Voice-Friendly Next-Gen
Machines By Peter Lambert
-----
"Older routers are becoming the bottleneck," says David
Greenblatt, chief operating officer for IDT Corp. VoIP
services subsidiary Net2Phone Inc. "Even at 30 percent
utilization, they just have too many packets to look at."
It has a familiar ring, doesn't it? In fact, the overwhelming
assemblage of what exists on the Internet today resembles,
from a functional perspective, the legacy wares to be found
in central office switching rooms. Stuff that is still useful for
what it was intended for, but useless for emerging
implementations.
In the case of the 'net, it's even more problematic from an
overall orchestration standpoint, because of the number of
locations and business organizations (ISPs, ITSPs, etc.) that
would need to synchronize their efforts in order to upgrade.
Upgrading, itself, becomes an elusive proposition,
financially, philosophically and logistically.
-----
"Do maintain wire speed for small voice packets,
typically 64 to 80 bytes per packet, router-forwarding
processors must process millions more packets per second
(pps) than for larger data file transfers."
This statement represents a recurring theme throughout the
article. ATM wirespeed using much smaller packets, cells,
would have fit like a glove here, one would think, but there's
more to it, making such an observation overly simplistic. But
in principle, there is an argument to be made there.
-----
From the article:
Evslin, chairman, CEO and founder of international VoIP
interexchange carrier (IXC) ITXC Corp., insists that such
constant "sniffing," combined with careful selection of
redundant service provider exchange points and minimized
routing hops, already are producing relatively consistent
VoIP quality even over the public Internet, where no one
provider controls every router.
"We have to continuously map all the connections to know
which is most reliable," Evslin says. "That includes
monitoring call duration and call completion, because if
there's high packet loss or jitter, people hang up earlier and
call durations go down, typically indicating something is
going on in terms of router network congestion. Then we
have multiple ISP terminations, so we can go around the
congestion."
That sounds like Evslin's attempts at keeping the hogs from
running wild are noble, but how long can he keep sniffing out
routes and making manual adjustments around the universe?
The problem gets larger, not smaller, as time goes by -
without some overriding initiative to stem it.
-----
Evslin goes on:
... he concedes that, "in next-generation routers, we
need not only larger capacity, but also better feedback from
routers themselves, including those not in our network. We
get that information in a crude way with [router test] pings
and trace routes, but it would be simpler if the router told us
how busy it is, rather than leaving us to deduce it."
Sounds like the backward and forward notification
processes inherent in ATM and FR, as well. Can you tell
he's an ex-Bellhead? [smiles]
-----
In reading the next couple of paragraphs, where NT speaks
about stripping off voice packets and assigning them to VPN
queues, to be sent out via VCs, I'm reminded of the original
discussions of broadband packet voice and data going back
to the mid-80s. Not quite with the same resolution that we
are now speaking, because they didn't have the historical
perspective to go by, but oh, what a pain it was to get
through those queuing algorithms that were so accurately
projected to be needed in this space, eventually. It's coming
to pass. The model I'm referring to, by the way, did not use
IP as its foundation. It was a loose theorization seen as an
advancement over X.25 (perhaps a precursor to Frame
Relay, which debuted at speeds too low for this initially),
mostly what I would now consider the precursor to today's
(tomorrow's?) ATM and Integrated Services IP.
-----
An obvious challenge that presents itself when reading this
article is the enormity of the task that ITSPs must face when
forecasting their resource requirements. If they are an
adjunct operation to a larger ISP, then that's one thing, and
they can almost depend on getting allocations of bandwidth
and routing resources on the fly.
But if they are a standalone one stop shop for all forms of
'net traffic, they must be able incredibly astute at predicting,
and procuring accordingly, bandwidth and the necessary
shelf modules to carry a plethora of services, the mix of
which will almost invariably affect their performance in
unpredictable ways.
Here's where real time network health and policy software
comes in handy, if you've got it. But who's got it, where it's
working as advertised? And what are the caveats going in?
It seems that is what NT and others are saying they are
shooting for, in any event. But it seems like it'll always be a
game of catch up, trying to keep the hogs in their pen.
-----
I guess the author agrees with using the tools I've mentioned:
But first, VoIP carriers and their customers need several
fundamental routing tools to determine quality thresholds:
distributed processors, classification engines and some
ability to create dedicated, pseudo-switched paths for
priority traffic.
-----
Don't you get the impression that an ITSP's buying more
horse power in an isolated way simply improves their own in
house nodal processing burden, while at the same time they
may be forcing down more of a burden to adjacent
providers that they can handle? This is the sense I got when
reading the graf about GST purchasing a Juniper. Incredibly
fast on prem, but what does the downstream guy do with it
once they receive it?
These conditions tend to create an unspoken kind of class
structure among peers and upstreams, something like the
hierarchical one that it is intended to supplant in the old
PSTN. I say the old, because traditional voice switching has
become amazingly flat since the first divestiture. This has
been aided greatly by point to point trunk groups over fiber
optic facilities that are now far less expensive than they were
then.
It's not unusual today to have Class 5 switches in the PSTN
(and their tandems) in an East Cost city talking directly with
those on the West Coast, in a manner which I would
describe as "flat," whereas the PSTN's five-class method
was once plagued with up-the-ladder-down-the-ladder
stages of handoffs from end to end. The 'net, on the other
hand, seems to have started off flat, and must now resort to
hierarchies due to scaling issues.
I suppose that this could be attributable to its displacement
of the former in some ways, and since their models are
opposite in so many other fundamental ways, why should
hierarchical considerations be different?
What seems obvious, is that a Juniper class router would be
best served by peering directly to another one in its own
class, or one slightly lower or higher in horsepower and
protocol likeness and capabilities, rather than it speaking
directly with a Model 2705 running at T1 speeds.
-----
I thought that this paragraph was particularly telling in the
price performance category:
"My current Cisco router can give me only 785,000
packets per second at $240,000 for my typical
configuration," Hensley says. "Extreme can give me the same
configuration for $125,000 with 48 million packet- per-
second performance."
Similarly, because it is optimized for wire-speed
performance at 64-byte packet sizes, Redstone's RX1400
edge router claims 1.2 million pps over each OC-12 (622
megabits per second [mbps]) backbone port.
Wow, that's got to get someone's notice, I'll bet.
------
The remainder of the article was extremely interesting, and I
recommend it to all. The parts in the closing sections were
highly focused on QoS, VPNs, ATM and impact of
parameter variability on real time services. Some great
reading.
But in reading it this evening, I couldn't help but reflect back
on my post which immediately precedes this one, i.e.,
gauging the relevance of all of this stuff presently.
Regards, Frank Coluccio
|
