RE: Clearwire May Block VoIP Competitors
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Robert Bonomi Sent: Monday, March 28, 2005 7:05 AM To: nanog@merit.edu Subject: Re: Clearwire May Block VoIP Competitors
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.
Depends on the codec. Yes, most people default to G.711, but my experience with G.729 and header compression has been good, and closer to 12Kbps. I definitely agree that it's much more symmetrical than web traffic, and could therefore mess with someone's capacity planning. Denying traffic that doesn't conform to your engineering is one response. Re-engineering is another. Do what you will with your network, I know what I'd do with mine. Lee
the bigger issue with 802.11 and VoIP is that wireless ethernet tends to be half duplex whereas codecs tend to run both directions at once. who's getting good service over 802.11 using G.711 or G.729? (no fair if your wireless handset has its own proprietary halfdup codec, i'm talking real SIP here.) -- Paul Vixie
On 30 Mar 2005, Paul Vixie wrote:
the bigger issue with 802.11 and VoIP is that wireless ethernet tends to be half duplex whereas codecs tend to run both directions at once. who's getting good service over 802.11 using G.711 or G.729? (no fair if your wireless handset has its own proprietary halfdup codec, i'm talking real SIP here.)
hmm running g711 on a wifi handset or a lan phone with wifi bridging in the middle results in decent quality. at 2x80kbps vs 11mbps or 54mbps there should be plenty room for both directions to communicate without too much delay Steve
On Wed, Mar 30, 2005 at 11:32:33PM +0000, Paul Vixie wrote:
the bigger issue with 802.11 and VoIP is that wireless ethernet tends to be half duplex whereas codecs tend to run both directions at once. who's getting good service over 802.11 using G.711 or G.729? (no fair if your wireless handset has its own proprietary halfdup codec, i'm talking real SIP here.)
you didn't ask for the size of the wireless network(1), in my experience i've not had any (major) problems with this, the key is to insure that the packets are somehow QoS'ed at the edge, even if your provider won't do QoS to you, you can do some neat artifical QoS on your upstream/uplink interfaces.. What i've done is rate-limit TCP inbound to be around 75-80% of the link speed to force things to back-off and leave space for my UDP packet streams. I think one of the major problems is that very few people know how to, or are capable of sending larger g711 frames (at increased delay, but more data per packet) because they can't set these more granular settings on their systems.. this means you have a lot higher pps rates which I think is the problem with the radio gear, it's just not designed for high pps rates.. big thing i've noticed in operational experience is that not all 802.11 handsets handle AP roaming seamlessly, some want to disconnect then re-dhcp for what is the same ssid/network domain. - jared (1) - i'm speaking for a single-ssid network with more than one AP that covers long-distance clients at 1Mb/s speeds on 802.11b (250meter+ one way) -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Wed, Mar 30, 2005 at 07:05:44PM -0500, Jared Mauch wrote: [...]
I think one of the major problems is that very few people know how to, or are capable of sending larger g711 frames (at increased delay, but more data per packet) because they can't set these more granular settings on their systems.. this means you have a lot higher pps rates which I think is the problem with the radio gear, it's just not designed for high pps rates..
So, how are the WISP folk dealing with VOIP traffic as it becomes a larger piece of their customer's traffic? Does anyone have a way to force a given VOIP endpoint to use larger data frames? Or are the WISPs forced to deal with with a shredded business plan because their gear is optimized for large packets? (Or am I simply missing something?) Or do you write a TOS that says: "Customer is not allowed to send and receive lots of small packets quickly?" :-)
On Wed, Mar 30, 2005 at 08:19:40PM -0700, John Osmon wrote:
On Wed, Mar 30, 2005 at 07:05:44PM -0500, Jared Mauch wrote: [...]
I think one of the major problems is that very few people know how to, or are capable of sending larger g711 frames (at increased delay, but more data per packet) because they can't set these more granular settings on their systems.. this means you have a lot higher pps rates which I think is the problem with the radio gear, it's just not designed for high pps rates..
So, how are the WISP folk dealing with VOIP traffic as it becomes a larger piece of their customer's traffic? Does anyone have a way to force a given VOIP endpoint to use larger data frames? Or are
2610(config-dial-peer)#codec g711ulaw ? bytes Specify number of voice data bytes per frame <cr> 2610(config-dial-peer)#codec g729r8 bytes ? Each codec sample produces 10 bytes of voice payload. Valid sizes are: 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200, 210, 220, 230, 240. My Hitachi WIP-5000 also lets me set this locally on the handset but it uses the delay between packets instead of size.. The Cisco ata-186 can set this as well: # ----------------------------------------------------------------------------- # Parameter: NumTxFrames # Access Code: 35 # Value Type: Integer (1 - 6) # # Description: Transmit frames per packet. # # The frame size for each G.711 and G.729 data packet is 10 ms. # The frame size for each G.723 data packet is 30 ms. # # Examples: To obtain 60 ms of G.723 audio, set the value to 2 (=60/30). # To obtain 120 ms of G.723 audio, set the value to 4 (=120/30). # To obtain 20 ms of G.711 audio, set the value to 2 (=20/10). # # Note: Cisco recommends using the default value of 2. NumTxFrames:2 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Wed, 30 Mar 2005, Howard, W. Lee wrote:
planning. Denying traffic that doesn't conform to your engineering is one response. Re-engineering is another. Do what you will with your network, I know what I'd do with mine.
I could be 1) over simplifying, 2) misunderstanding, the problem, but all of the networks that make up 'the Internet' are really just private networks. there is nothing that says any of these private networks have to transport all bits in all streams from end to end, yes? Given that, certainly some networks might choose to NOT transport VOIP or HTTP or BitTorennt across their networks. There are market reasons why this will, or could, eventually force them to re-evaluate their practices or face the consequences. I don't find it shocking at all that ISP-Y decides to block VOIP, especially if they have their own VOIP service offering. It might not be the BEST plan in the long run for them, but certainly it makes some sense to them... Just don't use their network(s), and complain to their support organization(s) about the failures on their networks. -Chris
participants (6)
-
Christopher L. Morrow -
Howard, W. Lee -
Jared Mauch -
John Osmon -
Paul Vixie -
Stephen J. Wilcox