Re: tcp across physical layers with burst blackouts?

Andi Kleen (ak@muc.de)
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/