Voice Jitter After an IPTV Turn-Up on a Shared Uplink
A 7750 SR-7 aggregates a business VPN and a new IPTV service onto one 10 Gb/s network uplink. The business SAP carries 120 Mb/s of VoIP marked DSCP EF and 600 Mb/s of best-effort data. The IPTV SAP carries 300 Mb/s of multicast mapped to forwarding class H2. After the IPTV turn-up, VoIP p95 latency rises from 35 ms to 170 ms and jitter from 4 ms to 40 ms, although the uplink averages only 62% utilization. Queue statistics show that all business traffic, including EF-marked VoIP, enters SAP ingress queue 1; the IPTV stream uses queue 5. The network egress EF queue has low occupancy, and the port scheduler uses default weights. The operations team wants to raise the uplink speed, but the design review questions whether the real fault is capacity.
1. Explain why the EF marking is not protecting VoIP and identify the QoS architectural points that must be checked before adding uplink capacity.
Read the worked answer
EF is a DSCP marking, not a queue assignment. On Nokia IP routers, treatment is decided by the QoS policy applied at each point: SAP ingress classification maps match criteria to a forwarding class and profile, which map to an ingress queue; network ingress and egress policies map to network queues and MPLS EXP; schedulers decide service order. The queue statistics show the business SAP has no explicit match for VoIP, so the default BE/queue 1 applies and VoIP shares a queue with 600 Mb/s of data. The low EF egress queue is misleading: the packets are not being placed in EF at ingress, and even a low-occupancy queue can wait if the scheduler does not serve it. At 62% average utilization, raw capacity is not the first suspect; the IPTV H2 burst can create scheduler contention.
2. Propose a remediation sequence, including policy changes and verification.
Read the worked answer
First create a SAP ingress QoS policy with an IP criterion for the VoIP source or destination subnet and DSCP EF, mapping to FC EF, profile in, queue 2, and high priority; keep business data in BE or AF and IPTV in H2. Assign it to the business SAP and check the default FC for unmatched traffic. Then verify the SAP egress policy has an EF queue with suitable CIR and CBS, and that the network QoS policy maps EF to the network EF queue and EXP. Configure the port scheduler so EF has strict or high-priority service while H2 and BE get weighted service; avoid making H2 strict if it can starve voice. Verify with ingress and egress queue counters, per-FC statistics, and a controlled IPTV burst while measuring latency and jitter. Change one layer at a time so the improvement can be attributed.
3. If VoIP still suffers after classification, what scheduler or queuing interaction could explain it despite low EF queue occupancy?
Read the worked answer
Low queue occupancy only says the queue is not building; it does not say packets are served promptly. If EF packets wait behind H2 or BE in the port scheduler, the EF egress queue can stay shallow while latency rises. Check the scheduler hierarchy: SAP ingress scheduling to the fabric, port scheduler level and weight, and any H-QoS parent rate. Also check whether reclassification at network ingress moves EF to another FC. If the EF queue is served at a low weight, increase its priority or reserve bandwidth; if H2 is strict, cap it with a shaper. Measure queue delay, not just depth.