RE: Clearwire May Block VoIP Competitors
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jared Mauch Sent: Wednesday, March 30, 2005 7:06 PM To: Paul Vixie Cc: nanog@merit.edu Subject: Re: Clearwire May Block VoIP Competitors
On Wed, Mar 30, 2005 at 11:32:33PM +0000, Paul Vixie wrote: 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..
That's interesting. . . where's the intersection of the packet size curve and the latency curve? I mean, where would you set it, and can you offset some of that with fragmentation and intervleaving? I'm outside of that "very few people," but I could imagine wanting dynamic control--one packet size (latency) for a certain calling plan (calls within the LAN, maybe even to anywhere on my network if I control end-to-end QoS, and local calls) but another for long distance.
- jared
Lee
Thus spake "Howard, W. Lee" <L.Howard@stanleyassociates.com>
That's interesting. . . where's the intersection of the packet size curve and the latency curve?
Many equipment vendors allow you to specify the number of ms of data to include in each packet while others require you to specify byes; I'll assume the former here since the latter is just a linear relation. Toll-quality voice requires a one-way latency of under ~125ms including any processing inside the endpoints. Increasing the packet size inherently adds delay on the transmit side. Then you have the obvious network latency. Finally, the receive side will have a buffer to smooth out jitter in the network; most vendors' equipment is now adaptive, so the jitter buffer might be anywhere from 10-50ms. To keep under budget, at least one of these factors must be minimized. Unfortunately, the public Internet has substantial jitter and high coast-to-coast latency, so often the only factor under your control is the transmit buffer. OTOH, if you're going across a network with decent QoS or within the same general area of the country, you can afford a larger transmit buffer without risking the "walkie talkie" effect.
I mean, where would you set it, and can you offset some of that with fragmentation and intervleaving?
F&I is a technique for reducing jitter on slow, congested links like the last mile to a customer. It's often combined with a priority queue, since the latter is not enough on such links (but is on faster ones). Neither has much to do with the (tiny) sizes of voice packets. S
participants (2)
-
Howard, W. Lee
-
Stephen Sprunk