Date: Wed, 13 Feb 2013 15:48:57 +0100 From: Andre Oppermann <andre@freebsd.org> To: Lawrence Stewart <lstewart@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Message-ID: <511BA7D9.3050709@freebsd.org> In-Reply-To: <511BA29E.5050501@freebsd.org> References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13.02.2013 15:26, Lawrence Stewart wrote: > On 02/13/13 21:27, Andre Oppermann wrote: >> On 13.02.2013 09:25, Lawrence Stewart wrote: >>> The idea is useful. I'd just like to discuss the implementation >>> specifics a little further before recommending whether the patch should >>> go in as is to provide a stop gap, or we rework the patch to be a little >>> less specific in readiness for the future work I have in mind. >> >> 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. > > As a local hack, sure, a CC module would do the job assuming you were > happy to use a single algorithm as the base. John's patch transcends the > algorithm in use on a particular connection, so it has wider > applicability than a CC module. The algorithm is becoming somewhat meaningless when your goal is to have an open pipe and push data as fast as possible without regard to other traffic. NewReno, Cubic and what have you is becoming meaningless. > I would also strongly oppose the inclusion of such a module in FreeBSD > proper - it's the wrong way to implement the functionality. The patch as > posted is technically appropriate, though I'm interested in discussing > whether the public API should be tweaked to capture higher level goals > instead e.g. "low delay at all costs" or "maximum throughput". I strongly disagree. The patch is a hack. From the description John gave on his use-case I read that he would actually take more than just ignoring idle-cwnd-reset. And actually if I were in his situation I would use a very aggressive congestion control algorithm doing away with more than idle-cwnd-reset. > We could initially map "low delay at all costs" to a TCP stack meaning > of "disable idle window reset" and expand the meaning later (e.g. > relaxing the silly window checks as briefly discussed in the other thread). Ugh, if you go that far fork it, obtain a fresh protocol number and don't call it TCP anymore. >> 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. > > John already has the functionality he needs in this local tree - this > discussion is no longer about John per se, but rather about other people > who may want the functionality John has implemented. That's what I'm worried most about. So far no real "other people" have spoken out, only cheering from the sidelines. > We need to figure out how to provide the functionality in FreeBSD > proper, and a CC module is not the answer. I totally disagree. This functionality (removal) is not at all a part of TCP and should not be supported directly. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511BA7D9.3050709>