1. Ian McDonald, Richard Nelson
Application-level QoS : Improving Video Conferencing Quality through Sending the Best Packet Next
Ian McDonald, Richard Nelson

2. Introduction Aim is to improve audio reception over video
Why send packets when we know they will be of no use?
Why send packets in order at the transport level?
Use the information of priority and RTT at the transport level to send the best packet next

3. Use of DCCP Standards track RFC
Has unreliable sessions and pluggable congestion control
Designed to replace UDP for multimedia apps
Available in Linux
Use CCID3 which is TFRC (TCP Friendly Rate Control)
* CCID3 is more like a sine wave for congestion control, rather than saw tooth which is TCP
* CCID3 uses a timer rather than ACK clocking

4. Testing setup
Captured traces from Ekiga, Skype, MSN. Traffic was nearly all UDP. Applications used congestion control on top of UDP.
Created model based on these and wrote a program to play/record this model using DCCP to compare standard vs send best packet next (not trying to model congestion control in Skype/Ekiga/MSN)
Created programs to track time differences between machines and analyse results
* In our model we did not replicate UDP congestion control

5. Packet timing * P is processing (server and client) * Q is queue time
* N is network time

6. SBPN1 algorithm
Expiry time is packet creation time plus allowed delay (200 ms in testing).
Packet has a priority – 2 is audio, 3 is video
Check expiry time on transmit, taking into account half of rtt. Discard if it has expired, or will expire in transit.
200 msecs is an arbitrary number and is within ITU guidelines
rtt is round trip time. We use half rtt as this is one way delay. We are assuming symmetric network links but this could be adjusted if needed. DCCP only tracks RTT so would need external source.

7. Linux kernel implementation
Linux plus patches to meet TFRC performance
Control data sent through sendmsg – expiry time, priority and method
Kernel stores information in priority queue and DCCP already tracks RTT
At time of transmission check for best packet to send and discard any expired packets
This implementation was done by work from Lulea being worked on by WAND research and then merged into the kernel via a kernel maintainer. Since then it has been largely driven by the University of Aberdeen

8. Testing setup Netem is the equivalent for dummynet Can do delay, loss
Synchonise time between boxes

9. Testing with loss - 80 ms RTT, queue length 5
We use loss as congestion control reacts to loss
Explain axis
Bars are 95% confidence intervals
Results worse with SBPN then normal
Opposite of what we want
Note – audio is higher than video as audio packets are sent at intervals where video packets are sent in chunks. This applies to all results

10. Timing of packets

11. Being penalised for not sending
Sending rate X = max(min(X_calc, 2 * X_recv), s/t_mbi) (s = packet size, t_mbi = 64)
X_recv is updated at least once per RTT
If no sending for a period, then X plummets
Need to transmit whenever possible
sbpn2 sends a packet if expired if it is the only one in queue

12. Testing with loss - SBPN1 vs SBPN2 - 80 ms RTT, queue length 5
SBPN2 is better than SBPN1 but not better than unmodified DCCP (removed for clarity reasons)
vertical is improvement

13. Difference in on time arrival - 80 ms RTT, queue length 5
explain axis
This graph shows for unmodified DCCP that a substantial proportion of packets arrive out of time
with sbpn1 virtually no data arrives late so shows that it is taking effect
with sbpn2 video packets act as network fillers to keep connection from slowing too much

14. Unmodified DCCP vs SBPN2 - 80 ms RTT, queue length 5
Explain axis
Use with two competing TCP flows on constrained link rather than loss. TCP flows are TCP New Reno as TFRC is based on the performance of tbis
Previous test is more resembling mobile link where loss does not indicate congestion always
More closely resembles link such as home or at a business

15. Unmodified DCCP vs SBPN2 - 80 ms RTT, queue length 32
With queue length 32 we see more significant results as larger queue to work with
A better improvement in audio with less degradation in audio

16. Unmodified DCCP vs SBPN2 - 30 ms RTT, queue length 5
Showing with a shorter RTT

17. Unmodified DCCP vs SBPN2 - 150 ms RTT, queue length 5
Showing with a longer RTT

18. Unmodified DCCP Faster Restart - 80 ms RTT, queue length 5
This shows that faster restart did not deliver a statistically significant result
Run on Linux so results not directly comparable to previous results

19. Future work/Conclusion
Conclusion – a real improvement in on time audio reception and can be implemented on server only
Tradeoff between bandwidth and improvement – penalised for not sending expired data
Future – more complex algorithms, increased sending of expired packets to use bandwidth
Look at time of bandwidth changing

20. WAND Network Research Group
Department of Computer Science
The University of Waikato
Private Bag 3105
Hamilton, New Zealand