Hello, I'm Richard Sailer and I've started implementing an alternative congestion control algorithm for linux, capable of maintaining high throughput during persistent packet reordering (TCP-PR). Before continuing my learning and work I want to send a coordinative mail to the netdev list to: * Ask whether this algorithm is wanted in general and will be merged * To synchronize and communicate my work with the other subsystem developers and maintainers. And this organisational and communication-specific part is where I need help, the technical part is fine so far. I have been unsure for long and put quite some effort in writing the following mail (see next section), including letting several colleagues review it. It would be a great help for me, if you could (even if just shortly) review the mailtext and tell me your opinion. Please do not answer the questions in the mail, they're somehow meant as discussion starters for the netdev list. And I have two questions regarding organisation: 1. I usually GPG sign all my Mails for work or academica. I recognised most netdev users don't. Which behaviour is correct? Should I sign my Mail? 2. Is directly asking for a mentor appropriate? Since I'm quite used to reading literature, documentation or source code and figuring things out myself this would mean little effort in "parenting" :p. It would mostly boil down to review my code once a week or less and consulting me on design designs (like tradeoffs), since I would try to ask as less as possible and cause as less extra work as possible. == The Mail == Subject: Implementing an additional alternative TCP congestion control algorithm (TCP-PR) Hello, I'm Richard Sailer and I want to implement and maintain an additional congestion control algorithm for linux, capable of maintaining high thourghput during persistent packet reordering (TCP-PR). The main purpose of this mail is to organize, synchronize and communicate this work *before* I start the coding, to avoid a situation and patch, you and I would be unhappy with. == About me == I'm a 23 year old computer science student and programmer, living and studying in Augsburg, germany. Also I'm working for an IT company in munich as a freelancer. I've specialized on reading, understanding and maintaining existing legacy code. Sadly the most legacy code I'm currently dealing with is written in perl. I would describe myself as a diligent, perfectionistic and slow programmer. I like and use unixoid operating systems for several years now. I've been interested in computer networking for a long time and therefore chose my bachelor thesis on multipath tunneling (other name: osi layer 3 link aggregation). During my experiments I observed that these aggregation produces severe packet reordering and several TCP implementations available dealt quite bad with it. (details see next section). After searching for reordering robust TCP variants I discovered TCP-PR and a implementation for linux 2.4.18. == About TCP-PR == TCP-PR is an alternative congestion control algorithm. Since it doesn't use DUPACKs at all to detect packet loss, packet reordering has no big impact on the goodput. This way the following 2 things can not happen: 1. out-of-order ACK segments get recognized as DUPACKs - these mean spurious retransmit and reducing of cwnd 2. out-of-order data segments won't trigger sending of DUPACKs - actually even if this happens the sender just ignores these DUPACKs therefore a sender-side only implementation of TCP-PR is sufficient. But therefore all packet losses have to be detectet by timeouts, which means different timeout definitions and handling mechanisms have to be applied. Mainly this means that any timeout reduces cwnd to cwnd/2 instead of setting it to 1. Also RTO adjustment is callculated differently. While all this may sound like big changes from TCP Cubic or New Reno, during algorithm design, a great amount of work was invested in making TCP-PR behave throughput-fair to other TCP variants on the same network. This has also been validated by excessive ns-2 simulations. The exact results of these simulations as well as further details of the timeout definitions and other aspects of the algorithm can be found in the original paper at: www.ece.ucsb.edu/~hespanha/published/366Bohacek.pdf If requested I'm happy to describe more details of tcp-pr, it's algorithm and RTO definitions. Also a closer discussion and comparison to TCP Cubic or New Reno (with or without adjusted DUPACK settings set in /proc/ ) is possible but I wanted to keep this first mail (relatively) short. == Some Questions == 0. In general, is this congestion control algorithm of interest for you? Does it have a fair change of beeing merged, assumed: * I provide a clean and documented implementation * I apply all adjustments and improvements requested 1. From reading netdev-FAQ.txt I assume I should use *net-next* as my base for coding and testing. Is this correct? 2. Is *testing* my patches against net-next kernels sensible? Or should I use the torvalds or stable tree for sound tests? 3. I'm currently using paravirtualized Xen VMs for most of my virtualization needs. Is using Xen PV for testing my TCP extension a good idea? I think it's not problematic but I'm not entirely sure. 4. Do you prefer to get this whole patch via Email or by somehow interacting with a git repository? I think setting up a git repository would make a continuous review process before finally merging easier, which I would like. If I set up a repository mirror, is there any webinterface or server side software you would prefer or recommend. I suppose you don't like using github for that purpose. 5. In the documntation file networking/tcp.txt there is a section called: How the new TCP output machine [nyi] works. =========================================== Is the [nyi] still true? The file says: "last updated february 2008". Can I rely on this information or is it better to look elsewhere and/or in the source code? If during my work and reading/understanding the relevant code, I would update this and perhaps other documentation I stumble uppon is this something appreciated or wanted? 6. I'm currently reading "practical C programming" and severeal of the doc files in the kernel repo. Are there any further books you would recommend for me? I have already read "Unix Network Programming" by stevens, and own a copy of Tanenbaums "Computer Networks" and "Operating Systems" books. Thanks -- Richard