[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VOIP Peering Questions
Trunking (available in asterisk, perhaps others) can help this
situation, but the same argument applies .. you have to determine what
your limit is even with trunking ..
On Wed, 2004-05-26 at 06:48, Mark R. Lindsey wrote:
> On May 25, 2004, at 9:55 PM, Jere Retzer wrote:
> > - Does anyone have any technical suggestions on implementing VOIP
> > peering
> > across a layer 2 Internet exchange?
>
> RTP flows are unresponsive to congestion; i.e., if they have to compete
> with TCP (*), you can expect two effects:
> 1> unfairly-depressed TCP throughput
> 2> loss in your RTP streams
>
> What's typically done is QoS using class-based queueing in both the IP
> routers and in the L2 equipment. You'll need to convince your L2 gear
> to classify RTP as better-than-best-effort -- i.e., 802.1p
> classification, probably with 802.1q VLAN tagging on the frames from
> your exchange customers.
>
> There's another issue that's trickier for an exchange: admission
> control of the RTP flows. Normal Internet traffic handles congestion
> gracefully (thanks VJ for the CWND), but RTP doesn't.
>
> Assuming all traffic flows through the same gear, the RTP traffic needs
> to get a premium service so that it doesn't have to compete.
> Corresponding somewhat to the two points above,
> 3> every RTP stream slows *all* non-RTP throughput, for a given output
> queue
> 4> RTP doesn't degrade gracefully in the presence of RTP congestion
>
> This last point could be a real issue, particularly so if you have
> rate-limited the RTP class or if you just have more RTP flows going
> through a link than the link can handle. At some point, you have to
> determine the number of RTP flows you intend to handle through each
> link, and somehow enforce that limit. If peer A can send as many as 150
> RTP streams to peer B, then you have to effectively "reserve" that
> bandwidth for those flows.
>
>
> (*) TCP and things made to work well in a TCP-friendly environment are
> responsive to congestion; e.g., streaming audio even sent over UDP can
> reduce its bit-rate in the presence of congestion. By contrast, RTP
> flows are unresponsive -- then they drop packets, then it just sounds
> bad, but generally they don't attempt to slow down.
>
> ---
> Mark R. Lindsey
> ECG, Inc. http://www.e-c-group.com/
> Office: 229-244-2099x2207; Mobile: 229-630-5553
>
>
> --
> To unsubscribe send a message to voip-peering-request@psg.com with
> the word 'unsubscribe' in a single line as the message text body.
> An archive is at <http://psg.com/lists/voip-peering/>.
--
Todd Fries .. todd@fries.net
_____________________________________________
| \ 1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX)
| "..in support of free software solutions." \ 1.700.227.9094 (IAXTEL)
| \ 250797 (FWD)
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt
--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.