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
_______________________________________________
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"
