lkml.org 
[lkml]   [1999]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: tcp across physical layers with burst blackouts?
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.057 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site