Return to BSD News archive
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!fu-berlin.de!zrz.TU-Berlin.DE!news.dfn.de!news.ruhr-uni-bochum.de!news.rhrz.uni-bonn.de!mpifr-bonn.mpg.de!fs1.mpifr-bonn.mpg.de!souva
From: souva@aibn58.astro.uni-bonn.de (Ignatios Souvatzis)
Subject: Re: TCP latency in the presense of RFC1323 (Was: Re: TCP latency)
In-Reply-To: Pedro Roque Marques's message of 18 Jul 1996 18:01:58 +0100
Message-ID: <SOUVA.96Jul20142626@aibn58.astro.uni-bonn.de>
Sender: news@mpifr-bonn.mpg.de
Nntp-Posting-Host: aibn58
Reply-To: isouvatzis@astro.uni-bonn.de
Organization: Radioastronomisches Institut der Universitaet Bonn, Bonn, FRG
References: <4paedl$4bm@engnews2.eng.sun.com> <4rlf6i$c5f@linux.cs.helsinki.fi>
<31DEA3A3.41C67EA6@dyson.iquest.net> <Du681x.2Gy@kroete2.freinet.de>
<31DFEB02.41C67EA6@dyson.iquest.net>
<4rpdtn$30b@symiserver2.symantec.com>
<x7ohlq78wt.fsf@oberon.di.fc.ul.pt>
<Pine.LNX.3.91.960709020017.19115I-100000@reflections.mindspring.com>
<x74tnfn35s.fsf@oberon.di.fc.ul.pt>
<4s33mj$fv2@innocence.interface-business.de>
<4sbrcr$rqd@enomem.lkg.dec.com>
<SOUVA.96Jul16132215@aibn58.astro.uni-bonn.de>
<x7g26pa41l.fsf@oberon.di.fc.ul.pt>
Date: Sat, 20 Jul 1996 12:26:26 GMT
Lines: 58
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45904 comp.unix.bsd.netbsd.misc:4125 comp.unix.bsd.freebsd.misc:24064
In article <x7g26pa41l.fsf@oberon.di.fc.ul.pt> Pedro Roque Marques
<roque@di.fc.ul.pt> writes:
Where talking about completly different things. RFC 1323 changes the
precision of the input to rtt (and rto) estimatives. We are talikng about
the internal software timer that has to go off when rto msecs have elapsed
since a unacked send or {random(0,200) in BSD, delay_ack_estimate in Linux}
has elapsed since the receive of a segment.
Ok, understood.
Also actually the input is only better if
a) you have broken messurements (Linux pre 2.0 had)
b) you retransmited the segment
Ignatios> (Assuming that no other part of the networking code
Ignatios> violates layering).
Is layering a "good thing" (TM) ? :-)
This is not the question.
The protocols are _defined_ to be layered. If some intermediate
transport (e.g. PPP) breaks this in its implementation for whatever
reasons --- and, as of tcp/ip header compression, I know there are
good reasons to break the layering --- it has to make sure that it
reconstructs the upper layer 100%.
Now, some old CISCO software, some KA9Q systems and some (today
probably old) Linux systems are known to damage TCP header option
fields, leading to very bad rfc1323 performance, while at least the
usual bad WAN tcp/ip performance is achieved when switching rfc1323
off.
All such cases I personally (where, only 1level indirect, that is I
personally know the end systems and their maintainers) know about just
use the Linux / KA9Q box as an intermediate router, with PPP used on
the line. As the Linux box isn't a TCP endpoint, it has nothing to do
with the RTT measurement etc, and the TCP stream should not be
affected by the broken RTT measurements you mention above for old
Linux, as this is a TCP only part of the kernel.
However, _some_ unlayered part of the Linux' networking system
implementation must have (had, I hope) some other problem. The only
part I can think of is PPP's (or SLIP's; I'd guess they share the
code) Van Jacobsen TCP/IP header compression. So I really would like
to know if people are aware of the problem, and have - maybe- fixed
it, so that, should I be connected one day to a Linux box as router
and experience the problem myself, can point its maintainer to the
newer kernel version.
Regards,
Ignatios Souvatzis
--
Ignatios Souvatzis (also ignatios@cs.uni-bonn.de)
"HIFI-Geräte müßten Steckplätze wie Computer haben. Dann könnte man sich das
Gehäuse nach dem Design aussuchen und die Technik nach Leistung..."
craven@rlyeh.muc.de