lml,
I'd like to comment on some of you points, and expand on them a bit.
Let's sidestep the VPN issue you brought up for a moment, and even
demonstrate where such a consideration might be avoided in certain
scenarios, or at least where some alternative approaches might be
desirable on the parts of the cable operators.
"My understanding is that in order to get VoIP to work confidently it
must be routed over a VPN to ensure priority in routing of smaller sized
voice packets that get would otherwise be subordinated to routing of
larger sized data packets. To me this means diminished QoS for the data
portion of the network, which IMHO, is particularly vulnerable when we
consider VoIP over shared HFC pipe, particularly the co-axial
portion."
Granted, anytime you invoke QoS features for one class of service, by
definition, you are limiting bandwidth and other resources to all other
classes of service on the same facility, by some proportionate measure.
Voice, however, utilizes so little bandwidth, in comparison to the other
modes of traffic you might be concerned with during Internet access, for
example, so as to be virtually nonexistent in its weighting.
" I just think rollout of VoIP over HFC will be slow in coming. The
cablecos & T will be careful not to kill the commonly perceived "goose
that laid the golden-egg" - broadband access for data, though I personally
believe this perception to be "fool's gold," preferring DSL & VDSL over
the short & longer term, respectively."
In the meantime, I'm of the opinion that there already exists plenty of
"head room" (required bandwidth) on most DSLs and HFCs to support
VoIP in the last mile. It's the greater cloud coverage, and all of its moving
parts in the middle, that still needs most of the work done for VoIP to be
fully successful. OR, no additional work done at all in the middle, and
more at the edge and the end points, depending on your perspective and
which variant of I-phone you are philosophically aligned with.
Assuming that we are talking about the most popular version, VoIP using
H.323, etc, even if prioritization methods must be used, it can be
supported at this time. Explanation follows.
-----
VoIP should not be considered exclusively as an end to end solution.
Indeed, it isn't even being used that way (end to end) today, where it is
commercially available through ITSP offerings of the phone to phone
variety.
Where Phone to Phone ITSPs are concerned, only the mid spans at
this time use VoIP transport protocols, and the remainder of the
connection, on both sides, is switched.
Instead, VoIP is used as a means of substituting packets for traditional
WAN voice channels. It substitutes the bandwidth-hogging PCM carrier
coded voice channel which requires 64 kb/s, with that of a compressed
voice algorithm encapsulated in IP, requiring of only between 5.x and 13
kb/s. Typically, 8 kb/s can be used as a loaded figure, rendering it 8 x
more efficient on the surface than a POTS DS0, which stands for Digital
Signal at Level 0 (for the benefit of others).
If you take into account only those periods when speech is actually
being ported, then this figure jumps up considerably, without any fancy
footwork. This is due to idle time dynamics caused by pauses in speech,
listening periods, and other factors.
The greater the size of the carrying container (a T1, for example, versus
a DS0), the greater the resulting proportionate efficiencies that can be achieved.
Still talking ITSPs on the WAN,
In this sense VoIP is key to allowing the ITSPs to compete over the
WAN where they would otherwise be forced to use the more expensive
PCM based alternative in the end-to-end connection. While they do in
fact use VoIP in the middle of the overall connection, however, they still
depend on the last mile, or the tail sections, to be provisioned by the
ILEC's facilities through traditional switched means.
Now, let's leave POTS for a moment, and turn this model upside down
for Cable TV's HFC. Something that would not be so unusual to imagine,
if you were familiar with the folklore and cultural separations which have
historically existed between these to communities. [grins]
-----
If is utilized for its bandwidth optimization capabilities, it can be seen as a
means of conserving rare upstream bandwidth on HFC systems, as well.
It needn't go any further. To examine this properly would require
examining the alternatives, which at this time usually consist of either
reselling the ILEC's services or stuffing DS0s into a 6 MHz video channel.
We'll talk about the latter here, since this is what the MSOs are doing,
and compare it to the VoIP tail section approach as an alternative.
The switched mode. Using QAM and QPSK schemes in order to encode
switched mode voice usually yields 260 switched grade voice channels
(DS0s) per segment, per channel. If this doesn't say anything else, it
should demonstrate the perils of resegmenting outside plant, and the need
to maintain smaller segment sizes with increasing percentages of uptake
for voice. But I digress once again.
-----
The tradeoff in the last mile between switched and VoIP would depend in
part on what that video channel would be worth to the operator if it were
instead used for program services. The actual difference notwithstanding,
it could be appreciable, in comparative terms.
VoIP, on the other hand, when viewed as a form of transport between the
customer location and the head end only, could easily support this number
of talkers. And more. And VoIP would do it without sacrificing the video
channel. VoIP would instead depend on the 5-42 MHz band of
frequencies, and ride between the cracks and crevices of cable modem
data. Could prioritization be given to voice? Certainly. Will it? Don't
know of any doing this at this time, but I don't see why not.
-----
After receiving this voice content at the head end in the form of VoIP
packets, that's where it would stop. As opposed to sending it out onto the
WAN in native VoIP form (in which case we find the problems you
cited). For the purposes of this post, however, it's converted back to
traditional switched mode voice while still at the head end, using
transcoders, so that it is communicable with the outside PSTN world.
It's Business as usual from that point out, and as such, avoids many of the
still-perilous areas that make VoIP unacceptable for the most part, at this
time.
The section between the customer and the head end could in many ways
be "controlled" to allow uncongested throughput for VoIP packets. On
such controlled pipes, one can hardly tell without knowing what they were
doing, the differences between VoIP and the switched modes of voice.
It's soon becoming that the only time you will need to worry about the
vagaries of Internet like behavior when using VoIP techs is when you start
negotiating multiple hops in routed domains, circuitously seeking paths
due to congested paths and overworked routers, and other anomalous
conditions peculiar to unconditioned internetworking domains. Not,
however, when you have a pipe that can be controlled.
If we were to the send the subscriber's VoIP voice to more extended
reaches, i.e., over the greater Internet, or even sending it out as H.323
through gateways, the same could not be said with any assurances at this
time, unless the ISP's backbone had ample controls associated with it.
Another factor that would discourage the cable ops from going with VoIP
at this time is that is is still a very kludgy proposition for them to be getting
into, mixing more disciplines than many of them are prepared to negotiate
at one time. And then there are always those OSS issues that Denver
alluded to earlier that would only compound matters.
The 'net itself may eventually yield the same level of clarity and visibility
for VoIP as controlled IP backbones or intranets, but not anytime soon,
at least not with any predictability in a universal sense.
For the purpose of conserving bandwidth in the last mile, therefore, and
without penalty of other detrimental effects such as sacrificing video
channels, VoIP may be used to some advantage in HFCs, if an operator
so chose.
Regards, Frank Coluccio |
