TCP DELAY

TCP DELAY

[Latha B lingaiah]

Hi,

While transfering a 42MB file, there seem to be a TCP
delay between the kernels 2.4.7 and 2.4.18.

Here are some data :-

In 2.4.7 kernel :

43843584B in 4.486s = 9.77342e+06B/s = 9544.36KB/s =
9.32066MB/s

In 2.4.18 kernel :
 43843584B in 3.711s = 1.18145e+07B/s = 11537.6KB/s =
11.2672MB/s

I am looking at the reason behind the delay in 2.4.7
kernel. Any comments on this?



PS: Please CC me with reply, as i am not subscribed to
the list.

thanks,
latha

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

Re: TCP DELAY

[bert hubert]

On Sun, Oct 20, 2002 at 11:56:00PM -0700, Latha B lingaiah wrote:
> Hi,
> 
> While transfering a 42MB file, there seem to be a TCP
> delay between the kernels 2.4.7 and 2.4.18.

Don't do such short measurements, 4.5 seconds is no way to do statistics.
TCP/IP does not start out at full speed but takes some time to find the
right speed.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

Re: TCP DELAY

[Rogier Wolff]

On Mon, Oct 21, 2002 at 08:58:39AM +0200, bert hubert wrote:
> On Sun, Oct 20, 2002 at 11:56:00PM -0700, Latha B lingaiah wrote:
> > Hi,
> > 
> > While transfering a 42MB file, there seem to be a TCP
> > delay between the kernels 2.4.7 and 2.4.18.
> 
> Don't do such short measurements, 4.5 seconds is no way to do statistics.
> TCP/IP does not start out at full speed but takes some time to find the
> right speed.

If all you do is repeatedly transfer small files of only 42Mb, the
difference of 18% between 3.7 and 4.4 seconds is quite measureable. 

But you should measure the difference more than once, but I suspect
that this was indeed done.....

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

Re: TCP delay, SMTP errors

[Ramin Alidousti]

Nathan,

I also saw two replied to your question, one was about the reverse
lookup of your client and the other was the ident query. Both are
valid possibilities. What does tcpdump show?

BTW, the NAT is not doing anything weird here as the same NAT would
be applied to your non-TCP packets which, you say, are not showing
any delay..

Ramin

On Tue, Jun 11, 2002 at 08:54:25AM -0700, Nathan Cassano wrote:

> 
> Ramin wrote:
> 
> > First you have to find out what the reason of this delay is. Eg, is
> this
> > because of the load on the server or the client or is it because of
> the
> > poor layer 2 medium (lots of collisions...) or any other reason.
> The load on the our switch is low. 99% idle on the firewall, and 90% on
> the internal web server, both dual PIII's.
> 
> > Are you here implying that the delay is because of the NAT'ed
> architecture?
> That is my suspicion. I recall Linux NAT doing this type of thing
> before.
> 
> > What does a simple ping show delay-wise?
> Nothing irregular, all the ping times are the same.
> 
> > What is the routing to and from that external host? Is it asymmetric?
> Static routing, one external network device.
> 
> > What happens if you connect to this external host from the external
> interface of the firewall itself?
> > Are you still experiencing delays?
> Yes, the same delay is present connecting from the firewall.
> 
> > Is this only happening with TCP or all types of packets would have the
> same delay?
> Doing DNS queries using the dig program to our external DNS server is
> fast. It seems
> to be a delay in sending initial TCP data. 

RE: TCP delay

[Nathan Cassano]

Okay folks,
	I've narrowed this problem down a bit. There is a delay between
the firewall and the external network when I telnet to ports 23 or 25 on
any host on the external network. The weird thing is that port 22 (ssh)
will give me a quick response. My only thought is that the state
tracking is slow when allowing packets back in.

I have confirmed that DNS is working A and PTR on all hosts tested.

Below is the relevant parts of the firewall boot script.

/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_state
/sbin/modprobe ipt_REJECT
/sbin/modprobe ipt_MASQUERADE

# Disable Smurf amplifier attacks
/bin/echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 

# Disable ICMP redirect acceptance. ICMP redirects can be used to alter
your routing 
# tables, possibly to a bad end. 
/bin/echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects 

# Don't accept source routed packets. Attackers can use source routing
to generate 
# traffic pretending to be from inside your network, but which is routed
back along 
# the path from which it came, namely outside, so attackers can
compromise your 
# network. Source routing is rarely used for legitimate purposes. 
/bin/echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route 

# Enable bad error message protection. 
/bin/echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 

###########################################
#
# Setup iptables rules
#

# Set all default Chain Policies to DROP

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

# Allow unlimited traffic on the loopback interface. 

$IPTABLES -A INPUT  -i lo -j ACCEPT 
$IPTABLES -A OUTPUT -o lo -j ACCEPT 

# Setup packet mangling for services

$IPTABLES -A OUTPUT -t mangle -p tcp --dport 22 -j TOS --set-tos
Minimize-Delay
$IPTABLES -A OUTPUT -t mangle -p tcp --dport 23 -j TOS --set-tos
Minimize-Delay
$IPTABLES -A OUTPUT -t mangle -p tcp --dport 80 -j TOS --set-tos
Minimize-Delay
$IPTABLES -A OUTPUT -t mangle -p tcp --dport 25 -j TOS --set-tos
Minimize-Delay

# Create chain targets segregated by the ethernet device's INPUTs and
OUTPUTs

$IPTABLES -N EXT_INPUT
$IPTABLES -N EXT_OUTPUT

# Direct traffic to go to their matching device input or output chain
targets

$IPTABLES -A INPUT -i $EXT_IFACE -j EXT_INPUT
$IPTABLES -A OUTPUT -o $EXT_IFACE -j EXT_OUTPUT

# Allow inbound connections to external device that are already
established
$IPTABLES -A EXT_INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow outbound traffic from external device
$IPTABLES -A EXT_OUTPUT -s $EXT_IP -j ACCEPT