Polycom V2IU 4350 user manual Downstream Traffic Management

Configuring the V2IU 4350

clocked out at the WAN link’s full rate LESS the bandwidth currently being used for high-priority (voice) data. High-priority data is clocked out at the WAN’s full link rate. Any long-lasting burst condition in low-priority data will cause these packets to be delayed and, if necessary, dropped.

Downstream Traffic Management

Since the 4350 is the final transmitting device for WAN traffic in the upstream direction (LAN to WAN) it is easy to see how its QoS mechanisms can be applied to traffic it is transmitting to guarantee sufficient bandwidth for voice traffic. We have control over how packets are handed to the WAN interface.

In the downstream direction (WAN to LAN) we are installed at the receiving end of a service provider link and therefore have no control over the amount of voice or data traffic being sent to us over the WAN interface. How then can we still guarantee the quality of in-bound voice traffic when it is entirely possible for an FTP session, for example, to consume the vast majority of downstream bandwidth?

Fortunately this is possible by shaping on both the egress LAN and egress WAN ports of the 4350 appliance and leveraging the congestion avoidance mechanisms built into TCP. Essentially, data packets received by the 4350’s WAN interface at a rate that exceeds the T1’s bandwidth LESS the bandwidth used for active voice calls are delayed (then dropped if necessary) before being forwarding on to its LAN interface. Similarly, data traffic sent back to the 4350 for transmission to the WAN are also delayed (as described in the above section). This results in the WAN-based devices following the rules of TCP/IP congestion avoidance and slowing down their transmit rate. This technique is quite effective in practice, as end stations usually reduce their transmit rate before VoIP signaling has completed for new call setup.

For example consider the scenario where there are no voice calls over a WAN link and multiple FTP sessions are consuming all available bandwidth:

1.A new call request is received by the 4350 from the WAN.

2.All signaling messages for the call are classified as voice traffic and therefore prioritized for transmission to the LAN before servicing the inbound FTP data.

3.RTP traffic (the voice data within an ongoing VoIP session) is similarly classified as voice traffic and treated with priority.

4.FTP data is buffered (or dropped) by the 4350 and return data, including the FTP ACKs, are also delayed. This results in a throttling of the transmit rate by the (far-end) FTP hosts, reducing overall WAN bandwidth consumption.

Generally, excessive UDP traffic must be shaped in the service provider network, as UDP does not provide congestion avoidance mechanisms. The exception to this is in the case of RTP UDP-based messages for voice traffic.

3 - 73