Date: Mon, 22 May 2006 09:55:42 -0400 From: Joshua Blanton <jblanton@masaka.cs.ohiou.edu> To: mag@intron.ac Cc: freebsd-net@freebsd.org Subject: Re: How to Quicken TCP Re-transmission? Message-ID: <20060522135542.GC22140@mauser.ipx.ath.cx> In-Reply-To: <20060522115722.15918F1590@smtp.263.net> References: <20060522115722.15918F1590@smtp.263.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--CblX+4bnyfN0pR09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline mag@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 --CblX+4bnyfN0pR09 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEccLe1dp8qWK2G7QRAkaCAJ9z9bt0RAdkRZQen3i/c1s3qXpbfgCg9PCi X6EZXdvniooSh0D5ZJLsffs= =VvKo -----END PGP SIGNATURE----- --CblX+4bnyfN0pR09--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060522135542.GC22140>