Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 May 2006 11:24:02 -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:  <20060522152402.GD22140@mauser.ipx.ath.cx>
In-Reply-To: <courier.4471D572.00004381@intron.ac>
References:  <20060522115722.15918F1590@smtp.263.net> <20060522135542.GC22140@mauser.ipx.ath.cx> <courier.4471D572.00004381@intron.ac>

next in thread | previous in thread | raw e-mail | index | archive | help

--ieNMXl1Fr3cevapt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

mag@intron.ac wrote:
>     Actually, I want to configure APACHE to distribute files (several
> mega bytes large each) to any Internet visitor.
>=20
>     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.

Unfortunately, if your loss is caused by congestion, there really
isn't anything you can do (ethically) to make it run faster.  Any
changes that you would make to your TCP stack would result in
reducing usable bandwidth for every other user of the network.  It
really isn't fair to make any changes at all...

>     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=3D84 bytes (PING's default), it will has much higher
> possibility to pass the interconnections between Internet operators.

Now, it is possible that your loss isn't really 30% - if these links
are as overloaded as you say, I'm sure ICMP Echo packets are dropped
with much more frequency than other packets, to help reduce
congestion.

>     It seems that FreeBSD 6.1 kernel enables SACK (RFC 2018) by default
> (net.inet.tcp.sack.enable: 1). And I keep it untouched.
>=20
>     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.
>=20
>     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" ?

I think perhaps the only solution is to learn to live with the slow
upload times, or find a provider that can guarantee better service.

--jtb

--ieNMXl1Fr3cevapt
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)

iD8DBQFEcdeS1dp8qWK2G7QRAnG7AKCE/VBIdZROPrVXGUVVyqrcEQj8rQCgsdqD
rd/JOR5T9uq624UwnRlYO+Q=
=NLcL
-----END PGP SIGNATURE-----

--ieNMXl1Fr3cevapt--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060522152402.GD22140>