> The idea is to allow a manual "kickstart" to a TCP connection, and to
> bind this to an SSH key sequence. (*Automated* quick link recovery in
> problematic without messing up congestion avoidance. *Manual* recovery
> is conceptually similar to hitting "STOP" then "RELOAD" in Netscape,
> i.e. it sometimes works wonders and you can't stop people from trying
> it, one way or another, anyway.)
>
> I didn't try the patches but they look good on (virtual) paper.
>
> Peter
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
If you do have a blackout type line, careful tuning of TCP will allow you to
automate recovery more efficiently than a user sitting there banging
reconnect. The problem with this approach is right now TCP doesn't get any
hints about the type of connection you may have. In the case discussed here, I
believe the situation is as follows:
User has a network connection that occasionally "blacks out", dropping all
traffic to the adapter.
So the entire device is blacked out. In that case, a flag in the device to
indicate "I'm flaky and like to disappear every once in a while" could hint to
TCP to change it's retransmission strategy.
If you have a single connection that is dying somewhere beyond your local
device, this approach doesn't work, unless you allow routes to specify hints as
well. However, in this case, you can't be guaranteed that you aren't suffering
from congestion somewhere before your "blackout" point, so congestion avoidance
would be quite complicated.
-- Zachary Amsden zamsden@engr.sgi.com (650) 933-6919 09U-510 Core Protocols- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/