North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Clearwire May Block VoIP Competitors
- From: Robert Bonomi
- Date: Mon Mar 28 07:07:05 2005
> Date: Mon, 28 Mar 2005 06:27:56 -0500
> From: Chip Mefford <email@example.com>
> Subject: Re: Clearwire May Block VoIP Competitors
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Robert Bonomi wrote:
> |>From firstname.lastname@example.org Sat Mar 26 12:37:15 2005
> |>Date: Sat, 26 Mar 2005 13:35:31 -0500
> |>From: Eric Gauthier <email@example.com>
> |>To: "Fergie (Paul Ferguson)" <firstname.lastname@example.org>
> |>Cc: email@example.com
> |>Subject: Re: Clearwire May Block VoIP Competitors
> |>"...In what the company claims is an effort to preserve the performance
> |> of its pre-standard WiMAX network, Clearwire says it reserves the right
> |> to prohibit the use of a wide range of bandwidth-hungry applications, a
> |> list that apparently includes VoIP as well as the uploading or
> |> downloading of streaming video or audio, and high-traffic Web site
> |> hosting."
> |>Hrm... Isn't a VoIP call realtively low bandwidth?
> | "*ALL* things are relative." <grin>
> |> I haven't studied
> |>this, but Vonage's site seems to imply that the maximum data rate is
> |>(http://www.vonage.com/help_knowledgeBase_article.php?article=190). I
> |>typically see speeds greater than this from my web browser...
> | There's a big difference. web browser activity is typically *very*
> | 'Average' data rate for a any single user is probably in the range of
> | of the burst peaks.
> | VoIP, on the other hand, has an "average" utilization that
> approximates 50%
> | of the burst rate. In _both directions.
> | I suspect that that latter factor is a fair part of the "problem". That
> | the cable company has allocated fairly limited bandwidth for the
> | direction (from the customer to the head-end). That that 'available'
> | bandwidth is *grossly* over-subscribed, on the "presumption" that traffic
> | in that direction would generally be "small", and "infrequent". When
> | assupmtions get violated, _everything_ goes to h*ll. <wry grin>
> | Not just for 'he who' commits the violation, but everybody else who is
> | sharing that over-subscribed link.
> Since I run an ISP that is very small time,
> has (at this time) only a single T1 upstream,
> all my "subscribers" are wireless clients,
> I guess if I have more than 2 subscribers,
> I am over subscribed?
I'd be willing bet that you do over-subscribe. That's how virtually _every_
provider makes it's money. Selling more downstream bandwidth than it has
upstream bandwidth. "On the presumption" that not everybody will be using
_all_ the bandwith they 'bought' at the same time.
Dunno where you got the 'more than 2 subscribers' bit as defining over-
subscribed. Unless you mis-read/mis-interpreted my remark about "50%
utilization" for VoIP data. Active VoIP transmission is about 80kbps.
on average, somebody is talking about half the time, and listening the
other half the time. so you get an "average" of about 40kbps. In each
direction. 50% of the 'burst' level. For web traffic, the burst peaks
(going downstream) may be a lot higher. but the _average_ traffic level
for a customer is a much smaller percentage of the peak level. the bursts
are, in effect, much more extreme. And, of course, the upstream traffic
is usually 'as nothing', compared to the downstream direction. Unless
you've got customers running servers, that is.
I'd be surprised if 'requests' from a web client averaged 400 bps for an
average customer. Or 1% of a typical VoIP conversation.
If somebody designed their system with asymmetric allocation of bandwidh
resources between the upstream and downstream direction -- based on the
presumption of web-like traffic; VoIP traffic is wildly contrary to
'expectations'. And performance can "go to h*ll". Not only for the
VoIP caller, but for everybody else, too.
It's not necessarily a result of "bad" network design. Just the usual
case of "the world changed out from under you".
Implementing the necessary engineering changes, "to make things work right
again", can take a while, and cost beaucoup dollars. Which means it may
not be _feasable_ to do it, at the price-point of the present service.