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

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

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

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

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

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.

Linux kernel implementation Linux 2.6.20 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

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

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

Timing of packets

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

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

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

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

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

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

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

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 2.6.23 so results not directly comparable to previous results

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

WAND Network Research Group Department of Computer Science The University of Waikato Private Bag 3105 Hamilton, New Zealand www.crc.net.nz www.wand.net.nz www.waikato.ac.nz