- This topic has 22 replies, 1 voice, and was last updated 23 years, 9 months ago by
.
-
Posts
-
This is a much needed web page. Thanks for attempting to define some of the concepts and protocols for VOIP. I would like to see some sort of Traffic shaping calculator here.
Most of my previous troubles with VOIP dealt with that issue. Getting out of the switch to the network seems to create a bottleneck at times.
Thanks for listening,
Bernie.Hi Bernie,
Thanks for your note. But, I’m not sure what you mean by traffic shaping. It’s not a term I’ve come across before. Something to do with the traffic profile throughout a day?
If you can give me a bit more info, then I’d love to get something build.
Thanks.
Traffic shaping comes from the data IP world. It is basically a method of providing QoS on an IP data network through protocol and/or application prioritization, queuing, and TCP windowing. If the backbone transport protocol supports CoS, this would also be part of QoS, though not technically a part of traffic shaping.
Thanks for the explanation Rich. It’s something we’ll need to research further. A white paper on this subject sounds good. A calculator will be more of a challenge because it requires real, tangible formulae, and there’s not much of that about…
…but that’s the challenge 🙂
Thanks.
The problem with doing calculations with VoIP is that it shares it’s space with other data traffic. Traffic shaping is fundamental to the whole thing, as voice traffic should normally be given the highest priority thru the network. Blocking is not really the issue in an IP network, packet loss and delay are!
So what I would like to see is the abilty to calculate the bandwidth to provide a given CoS, during the Busy Hour, whereby say no more than x% of the packets are delayed more than y mS. Where the Busy Hour is based on both voice and data traffic.
If you need some useful source data, suggest that you talk to people like NetReality or RAD as they have products collecting realtime traffic data on VoIP now! networks now!
Hi Michael,
Thanks. I agree that it’s going to be a difficult job. The values involved are not easy to quantify.
Here’s the sort of thing I had in mind to start with: We are thinking of expanding on the Erlang B traffic calculator on our main site. This works out how many lines are required for a given busy hour traffic.
This can be translated to required bandwidth (taking IP/UDP/RTP headers into account), to give a bandwidth value. Header compression can then also be taken into account, although this seems a little more vendor specific.
I don’t agree that blocking isn’t an issue. I don’t think it’s good enough just to send as many calls as possible through an IP network until quality is compromised.
The approach that some vendors are taking is to apply Admission Control to the edge of a network. Rather than limiting the bandwidth allocated to voice, it limits the number of discreet voice calls which can be accepted before an alternative route is selected (eg. PSTN).
Considering the number of discreet voice paths which a network can accept is certainly easier for voice specialists (like to) to get our head round.
I agree that data comes into the picture as well, but I haven’t really worked out a way of factoring that in. I’d like to though. Do data planning engineers use any models similar to the Erlang models which us voice boys use?
In the short term at least, companies will be migrating their existing private voice networks onto their IP data networks, so the trick will be able to work out in advance whether their IP network has the capacity to take the voice traffic, or if it does not, then to calculate how much additional bandwidth is required. I guess that the nearest thing I can think of to the Erlang in the data world is the TRIB (transfer rate of information bits), and is a measure of the effective quantity of information over a circuit vs. time!
However, I am not sure that this will help, because data traffic is not so time critical as voice. Some data traffic is more so than others, eg: real-time data such as that for air traffic control would need to be delivered ASAP whereas email could be left for hours without too much inconvenience. This is where traffic shaping comes in. You can hold back on the email and give the ATC high priority. Most data traffic models use some form of queuing technique to smooth out the traffic flows. I am not sure that you need to get into this as there are a lot of organisations that specialise in it already. What I would like is to be able to input the info. from my data traffic tools into your voice traffic tool. This could be to input the maximum data bandwidth required during the data busy hour and the maximum data bandwidth required during the voice busy hour. Then should be able to compute the bandwidth required for voice and data combined. BTW – admission control works OK when the network is only being used for voice. The problem is that to get maximum benefit most companies want a converged network. On some of the products I have worked on, they have been capable of routing voice traffic onto the PSTN if the IP network is unavailable, however if there is huge packet loss and/ or latency then they continue to connect calls to the IP network!
I don’t want to understate the problem, but it seems to me the problem still comes back to QoS. The user should be able to choose the QoS he can accept for voice traffic. If that level is constantly being monitored by either a front end black box or by the router itself, it could then generate a busy signal to the PBX/voice control device whenever the QoS is exceeded. This would then cause any new traffic to overflow to the PSTN.
In this fashion, one would never need to calculate how much bandwidth is available. Of course, until the router vendors step up to the plate, or some black box is developed to do this, we still need a way to calculate it, even if it’s just the amount of overflow.
Michael:
I note your comments, particularly on the problem with Admission Control – makes sense. I hadn’t heard of TRIB, but as you say, prioritising different types of traffic is going to tend to smooth out traffic, and make the bandwidth requirements hard to estimate.
Then along comes voice, and it is assigned the highest priority of all traffic. So perhaps voice would be the main factor in determining bandwidth.
Well, I’m still learning (can you tell :-), and I appreciate your input.
Paul:
I guess you’re right, but measuring QoS in objective terms must be difficult. Also, delivering on ‘best efforts’ is something that us ‘bell heads’ have trouble coming to terms with. As overflow facilities cost money, network designers would be looking to quantify there costs.
It’s not just networks we’re trying to converge; there are two different ways of thinking 😉
On reflection, I think that RTP provides some sort of QoS feedback mechanism, so it must be measureable to some degree.
So Grade of Service in the circuit switched world becomes QoS in the VoIP world and number of trunks becomes bandwidth! Sounds good to me! One other point, in your bandwith calculations you will need to take into consideration the voice compression algorithm that is to be used. But I guess that you knew that already?
Well, I’m not saying my idea is the best, but it’s the way some vendors are suggesting networks are planned.
Yes, we’ll be taking voice compression into account. G.729 seems to be standard(ish) across the wide area network at least. It’s an 8kbps algorithm, but there is a large overhead in wrapping the payload in IP, UDP and RTP.
I’m interested in what effect Silence Suppression has on quality and bandwidth, but I think I’ll start another thread about that.
I’m not sure what coding scheme LAN PBXs use. Without the constraints on bandwidth which exist on the WAN, I guess full 64kbps would be reasonable. Anyone know what happens in practice?
Answer to LAN PBX:
Within LAN, most of LAN pbx are using standard G711. With header, you get a good 80kbits/sec on the LAN. You’d better use FastE switched LANs otherwise collisions on a shared 10meg can severely impact quality.
Bye
StéphaneDelivering QoS in a IP network is difficult as there are few tools to provide end to end control. RSVP is one solution but still does not provide real control. Access control using gatekeepers appears to be the way of controlling traffic entry to the network. There is a requirement not only to protect voice traffic in a voip environment from data but also protect voice from voice. Gateways in their current state are not quite intelligent enough to provide a complete solution to QoS.
One other consideration is VoIP over Frame Relay circuits. Frame Relay encapsulation adds about 8k to the final outcome
- The forum ‘Voice over IP’ is closed to new topics and replies.
