On 02/14/13 05:37, Adrian Chadd wrote: > On 13 February 2013 02:27, Andre Oppermann <an...@freebsd.org> wrote: > >> Again I'd like to point out that this sort of modification should >> be implemented as a congestion control module. All the hook points >> are already there and can readily be used instead of adding more special >> cases to the generic part of TCP. The CC algorithm can be selected per >> socket. For such a special CC module it'd get a nice fat warning that >> it is not suitable for Internet use. >> >> Additionally I speculate that for the use-case of John he may also be >> willing to forgo congestion avoidance and always operate in (ill-named) >> "slow start" mode. With a special CC module this can easily be tweaked. > > There are some cute things that could be done here - eg, having an L3 > route table entry map to a congestion control (like having an MSS in > the L3 entry too.)
This is an area I've thought about and would form the basis for an interesting applied research project. On a related tangent, we (CAIA) also have some ongoing research looking at using different CC algorithms per subflow of a multipath TCP connection. > But I'd love to see some modelling / data showing competing congestion > control algorithms on the same set of congested pipes. Doubly so on > multiple congested pipes (ie, modelling a handful of parallel > user<->last-mile<->IX<->various transit feeds with different levels of > congestion/RTT<->IX<->last mile<->user connections.) You all know much > more about this than I do. :-) There is quite a bit of relevant literature out there. You could start with some of the stuff CAIA has had a hand in (e.g. [1]) and follow the citation trail from there... Cheers, Lawrence [1] http://caia.swin.edu.au/urp/newtcp/papers.html _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
