TCP-Friendly Window-based Congestion Control (TFWC)

TCP-Friendly Window-based Congestion Control (TFWC)

Soo-Hyun Choi (together with his advisors) introduce TCP-Friendly Window-based Congestion Control (TFWC) [Choi 2006][Choi 2009].

This is based upon ACK clocking, sent using an ACK vector (to allow missing packets).

The claim is that TFWC is much fairer than TFRC when competing TCP flows and it is simple to implement in applications (in their case: VIC and RAT)

† Code for TFWC over VIC can be found at http://tfwc.sourceforge.net/download.html Links to an external site.


Slide Notes

Soo-Hyun Choi, Design and Analysis for TCP-Friendly Window-based Congestion Control, University College London, Department of Computer Science, October 10, 2006 http://www.cs.ucl.ac.uk/staff/S.Choi/pubs/transfer_report.pdf Links to an external site.

Soo-Hyun Choi and Mark Handley, Designing TCP-Friendly Window-based Congestion Control for Real-time Multimedia Applications, Slides from their presentation at the 7th PFLDNeT, May 2009. http://www.hpcc.jp/pfldnet2009/Program_files/3-3.pdf Links to an external site.


Transcript

[slide477] Another approach, which Choi proposed, is his TCP-friendly window-based congestion control. And so instead, what he looks is at ACK-clocking. So he sends an acknowledgement vector to acknowledge the missing packets. So instead of sending one indication, he sends instead a bit vector showing which particular packets were missing. Why does that do better? Because you can actually see that instead of there being one segment missing, and now I go into the full back-off by dividing in half, if I see that 80% of the packets made it successfully and there are only a few lost, what do I do? I transmit again the ones that are missing and I continue on. There's no reason to back-off enormously. So he claims that this is a better case. And that's actually been used in both VIC and RAT, the audio tool that I mentioned yesterday from UCL.