Messages in this thread | | | Date | Fri, 10 Dec 1999 15:13:43 -0800 | From | Zachary Amsden <> | Subject | Re: tcp across physical layers with burst blackouts? |
| |
Peter Samuelson wrote:
> 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/
| |