[RFC] Implementing an additional TCP congestion control algorithm (TCP-PR) - communication and organisation.

[Richard Sailer]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150812/bea7a1a1/attachment.bin