Re: TCP capture effect (was Re: Linux TCP impotency)

[Andi Kleen <ak@suse.de>]

On Mon, May 14, 2001 at 04:15:12PM -0500, Samuel Meder wrote:
> I'm seeing a similar effect myself. When I use all my available sdsl
> bandwidth (say doing a bulk data transfer), DNS lookups will often
> time out. This is with the default buffer settings/2.4.4. 

The problem is that the DNS resolver in glibc has a too low setting
for retransmits before giving up (4-5 or so only, it's also a big problem
together with dynamic IP and dial-on-demand where the socket address rewriting
needs some time) Fix is to change glibc to retransmit more often and 
recompile it or alternatively use a local dns proxy that does more aggressive
retransmits (that won't fix the low timeout though)

> I'm curious about this effect so I've been trying to find information
> on this and while I can find lots of information on the Ethernet
> capture effect there doesn't seem to be anything on the TCP capture
> effect. Could someone point me at an explanation of this effect?

I also don't know that term, but the basic problem is that TCP only slows
down when its packets are dropped. Packets are dropped when a device queue
fills, and when one sender is much faster than the other the faster sender
often wins the race, while the packets of the slower one get dropped.
[this is a rough simplification; there have been many books and papers
written on queueing in the internet]

One problem is for example that Linux's default queue length is good
for ethernet, but not slower or higher latency links.
You can try to tune it using ifconfig device txqueuelen <number>. 
Try values between 5-30, default is 100.

DSL also has very asymetric bandwidth, if you're saturating e.g. the uplink
channel completely acks in the other direction will also have a hard
time to get through.

-Andi