re: implementing web apps on MSOs' cable facilities
Darlene, I posted the following on the ATHM thread. Since this discussion is taking place in some many places now, three different threads including this one, I decided to post it here, as well.
-------from: Message 12181785
Jay Lowe asked:
"Can you comment on the ability of @Home technology to deploy web
processes closer to the user? Can @Home generically deliver
distributed server capacity?"
You ask if ATHM can accommodate web apps, with a focus on their
caching and other deep architectural server elements. Perhaps, but I see
some splintering needed in the MSOs clustering schemes where their data
model is concerned, where individual server devices would need to be
placed at the outermost points, closest to the user, if the present system
could accommodate it at all. This would sit in contrast to regional servers
next to existing caching, where multiple head ends share a common set of
resources. The impact of this would be considerable from a support and
logistics standpoint, given current HFC designs, and there is more to
consider before we get this far.
Before we look into the core, I'd have to examine the edge and their (the
MSOs) access platforms, and here's where I see the first signs of
architectural unfriendliness if we are discussing going beyond the status
quo of what is, and what is not, achievable, given popular assumptions
and recent utilization trends.
If the web apps you are referring to (i.e., those which substitute for the
executables which normally reside on the desktop) were the only
challenge then there would be no problem. But this is not the case.
When evaluating this possibility one must also take into account the other
things going on in the local distribution plant, namely the normal traffic
levels (see next para) and the amount of traffic that is pent up but
currently discouraged, and then assess the aggregate picture.
ATHM's residential service offerings already preclude sustained
commercial (read so-ho) use, requiring that end users refrain from
extended file transfers and other applications demanding of prolonged
bandwidth utilization, such as those which will be inevitable in the near
future. Streaming video and audio from content providers comes to mind
here. This constraint may have been lifted momentarily (I don't know
what the last waffle state on this issue is, it goes back and forth based on
public tolerance and outcry), but its need is clear when you look at the
traffic utilization trajectories which point to the horizon.
Cable has enormous capacity potential, enormous, if it is fashioned
properly. That is, if its network architecture takes into account the new
realities of a photonic universe and designs to the parameters of these
new realities, as opposed to merely pyrrhically fulfilling yesterday's
dreams.
But the constraints imposed by current DOCSIS implementations, if not
upgraded, are going to put a serious crimp in this potential for a long time
to come, unless the tail sections in the loop and the CMTSs (cable
modem termination systems at the head ends) are re-groomed, as in the
way T's Salt Lake City fiber pilot suggests they should be.
Also, and assuming that the decision is reached to follow through with
this form of re-grooming --which would reduce the shared user domain
from over 500 homes passed in many cases (sometimes thousands)
down to something under 80 homes-- then one must also take into
account the costs and the amount of time that would be required to effect
said changes which are needed to even make a difference when
considering the installed base, and the existing growth projections.
Many systems are not even half way complete under the old model. So,
how long would it take the MSOs to change their plans midstream and
adapt to a new model? A very long time.
This time frame would be measured in terms of up to another 5 years (to
redo what it's taken a comparable period to only partially complete in the
old model) in order to make a noticeable dent.
Unfortunately, the MSOs are split, in favor of legacy, on the need for
such improvements as was amply demonstrated by a joint interview with
the CTOs of T, Cox, Adelphia and TWX the other day. Some of these
guys are looking to DOCSIS 1.1 as a form of final beatitude which
transcends suffering, in fact.
Even where promise is voiced by those in favor of upgrading, it's a long
way off. So, in my view the capacity that currently exists will suffice for
the status quo, with some edging-in by some streaming apps, but I don't
see any chance for "at work" kinds of utilization or full streaming apps
anytime soon. If the foregoing apps (so-ho and streaming content, to
name just two) are precluded or discouraged (even if only tacitly by not
building out more capacity), then I must also wonder how the web apps'
contention for capacity will unfold. I can only surmise that the powers
that be will say, 'not now.'
Or, they might roll the dice if competitive pressures mount (or if they are
blinded by their own denial), and go forward with it. Who knows.
------
With this backdrop of application tensions vying for capacity already,
what does downloading executables and ordinary services -such as
printing and backing up - across the shared loop, portend? I am left to
wonder. I also see this as an opportunity for new players to indulge in
some serious encroachment with new fiber-to-the-home or curb
architectures, who don't share the same anachronistic dreams and memes
as many of today's MSOs.
Regards, Frank Coluccio |
