Date: Mon, 28 Mar 2005 06:27:56 -0500 From: Chip Mefford <cpm@well.com> Subject: Re: Clearwire May Block VoIP Competitors

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Robert Bonomi wrote: |>From owner-nanog@merit.edu Sat Mar 26 12:37:15 2005 |>Date: Sat, 26 Mar 2005 13:35:31 -0500 |>From: Eric Gauthier <eric@roxanne.org> |>To: "Fergie (Paul Ferguson)" <fergdawg@netzero.net> |>Cc: nanog@merit.edu |>Subject: Re: Clearwire May Block VoIP Competitors |> |> |> |>>http://www.advancedippipeline.com/news/159905772 |>> |> |>"...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 90Kbps |>(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* bursty. | 'Average' data rate for a any single user is probably in the range of 1%-3% | 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 'upstream' | 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 those | 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.

Well,

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.