Date: Mon, 22 May 2006 23:14:58 +0800 From: mag@intron.ac To: Joshua Blanton <jblanton@masaka.cs.ohiou.edu>, Marcin Jessa <lists@yazzy.org>, Brian Candler <B.Candler@pobox.com>, Chuck Swiger <cswiger@mac.com> Cc: freebsd-net@freebsd.org Subject: Re: How to Quicken TCP Re-transmission? Message-ID: <20060522151822.8ACD0F11A3@smtp.263.net> In-Reply-To: <20060522135542.GC22140@mauser.ipx.ath.cx> References: <20060522115722.15918F1590@smtp.263.net> <20060522135542.GC22140@mauser.ipx.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you for your answers, Joshua, Marcin, Brian and Chuck.
Actually, I want to configure APACHE to distribute files (several
mega bytes large each) to any Internet visitor.
My server (host A) is served by a non-profitable Internet operator
in China. But most of Chinese Internet users (host B) are served by two
commercial Internet operators.
Between the non-profitable Internet operator and each commercial
Internet operator there is an about 2 Gbps interconnection. But China
has a large population, and those interconnections are heavily loaded.
I obtained the result "packet loss 30% and return delay 60 ms"
just by "ping -c 100 -s 1472 xxx.xxx.xxx.xxx". If an IP packet is
smaller as 20+64=84 bytes (PING's default), it will has much higher
possibility to pass the interconnections between Internet operators.
It seems that FreeBSD 6.1 kernel enables SACK (RFC 2018) by default
(net.inet.tcp.sack.enable: 1). And I keep it untouched.
Since I want configure general WWW service, probably I could not
request visitors to configure SCPS. It is really robust against lossy
data link such as communication between satellites and planets.
But above all, most of Internet users haven't enough computer skills.
I would like to understand how FreeBSD runs the TCP re-transmission
timer, especially its dynamic self-tuning mechanism. I am trying to
read /usr/src/sys/netinet/tcp* .
Should I really modify the value of "TCPTV_REXMTMAX" defined in
"/usr/src/sys/netinet/tcp_timer.h" ?
------------------------------------------------------------------------
From Beijing, China
Joshua Blanton wrote:
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060522151822.8ACD0F11A3>