How to Quicken TCP Re-transmission?

[Joshua Blanton]

mag at intron.ac wrote:
>     I want to transmit data between host A and host B. The link between
> these two hosts is really bad: PING reports 30% packet loss and about
> 60 ms return delay. This means if timed out for 1 second, the data must
> have been lost.
>     I keep "net.inet.tcp.rexmit_min" and "net.inet.tcp.rexmit_slop"
> untouched. But TCPDUMP tells me that if some data are lost,
> re-transmission will be done 64 seconds after last transmission!
>     How to quicken TCP re-transmission?
>     How to tune "net.inet.tcp.rexmit_min" and "net.inet.tcp.rexmit_slop"?

Is this a point-to-point link between the two hosts, or is there a
network between them?  If there is a network, you can't necessarily
provide a hard bound on the upper limit of RTT (although if it's a
small intranet of some sort, it may be reasonable to compute
one)...  If it's a point-to-point link, that's a whole different
story.  :-)  I'm assuming, from your email, that the loss is
corruption-based and not congestion-based - is this true?

If it is a point-to-point link, SCPS (as previously mentioned) might
provide the sort of solution you need.  If it's not a point-to-point
link, you'll just have to live with really crappy performance - as
another poster said, TCP doesn't like packet loss at all.

If there's a point-to-point link, but you need to be able to get out
beyond the next hop, you might consider configuring a proxy on
either end of the link.  This proxy would have to terminate all
connections on either side, and use a less-corruption-affected
protocol across the bad link.

One thing to note - you probably don't want to tune the *minimum*
retransmission timeout, but rather the *maximum* retransmission
timeout...  What's happening is that your TCP senders are not
getting reliable RTT samples, and so every timeout is doubling the
RTT estimate until it's finally bounded by 64s.  If you lower that
maximum bound, you can reduce the penalty of timeouts - but with a
30% loss rate there's *no* way you'll ever get TCP to do anything
other than timeout every other packet.

--jtb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20060522/4883d237/attachment.pgp