[...]

>Given the new callout mechanism we have, has anyone looked at
>making it possible to set the various TCP timeouts on a per-socket
>basis?

hi Darren,

I think we should not do this.  If we let users tweak the timeouts,
rather than following the normative TCP behaviour (for, e.g., RTT
estimators), then users can trick our our TCP into generating
non-TCP-like network flows. That's generally a Bad Thing.

There's also work in the research literature which says that
increasing the resolution of the existing timeouts (5Hz, 2Hz)
can have a negative nett affect on TCP performance.
I honestly dont recall if that is obsoleted by New-Reno.

>If not, does anyone have any thoughts on problems, gotchas, etc,
>about making it possible to set different timeouts per-socket ?

I think the first step is to figure out which options it's safe to let
users change, and which it isn't.  100Hz-1Khz keepalives, or
artificially-tweaked retransmit timers, may be OK on a gigabit LAN; in
other circumstances, they aren't.

My take (if you want it, as someone who's hacked TCP algorithms to
work better on very-wet-string media) is that the current
state-of-the-art is such that we shouldn't do this just yet. we should
leave this to people willing and capable of hacking the source code
for their TCP :-), and who are then responsible to their lab/upstream
provider/ISP/whatever for any TCP traffic which isn't TCP-like.


All that said, there's always the tsvwg draft on TCP-rate-control...