Lars Eggert wrote: > > Interesting. Could I ask what RTMFP uses for congestion control? > > Lars (I'm not on the cryptography list, so my messages to there bounce, so I've removed it from the CC list)
RTMFP, like amicima's MFP, uses affirmative (and selective, not just cumulative) acknowledgments to know what data has been delivered to the far end, and a TCP-like congestion window scheme to control the send rate. Unlike TCP, the parameters for the AIMD adjustment vary depending both on the type/priority of traffic that is being sent from this node (smoother congestion response when sending things like voice, more aggressive when sending bulk data) and also on whether or not the far end is reporting that some other node is or is not sending high-priority traffic. (To explain the second part of that better, imagine that A is sending bulk data to B and C is sending realtime voice to B. One of the things that B tells A regularly is that B is currently receiving realtime traffic from "someone else"... this causes A to be more sensitive to loss, because (on an Internet where the end-links are congested and the core is usually unrestricted) the odds are almost 50:50 that loss on the A->B bulk data stream happened on B's downlink, and the polite thing to do is for A to make more room for the realtime traffic from C. Once C stops sending realtime data to B, the A-> congestion response reverts to normal sensitivity.) The ack and congestion response scheme also works properly with partially-reliable and unreliable delivery, as well as full (TCP-like) reliable delivery. And of course, once you have congestion control throttling, you get to have per-media-flow priority at send time, so we do that too. Matthew Kaufman _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
