Messages in this thread | | | Subject | Re: tcp across physical layers with burst blackouts? | From | Andi Kleen <> | Date | 11 Dec 1999 14:22:09 +0100 |
| |
zamsden@cthulhu.engr.sgi.com (Zachary Amsden) writes:
> 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/
First I would like to state that the TCP_KICK patch was only meant as a bandaid (copied from KA9q), not a well designed solution for anything. Sometimes it is useful though.
> > 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.
2.3 has a kind of that already: the NET_XMIT_DROP, NET_XMIT_CN etc. return flags defined for hard_xmit. They are not yet used by TCP though, although some experiments were tried.
2.0 does one optimization for modem type connections that 2.2+ has lost. Because of the way the retransmit queue was handled by IP TCP never queued a packet twice into a device queue on retransmit. It seems to help often. It was planned to use the flags for similar optimization.
Currently it is a bit too late though for such things for 2.4.
-Andi
-- This is like TV. I don't like TV.
- 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/
| |