Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.reston.ans.net!surfnet.nl!swsbe6.switch.ch!scsing.switch.ch!news.rccn.net!master.di.fc.ul.pt!usenet
From: Pedro Roque Marques <roque@di.fc.ul.pt>
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: 13 Jul 1996 22:45:09 +0100
Organization: Faculdade de Ciencias da Universidade de Lisboa
Lines: 44
Sender: roque@oberon.di.fc.ul.pt
Message-ID: <x7ivbrddzu.fsf@oberon.di.fc.ul.pt>
References: <4paedl$4bm@engnews2.eng.sun.com>
<31DC8EBA.41C67EA6@dyson.iquest.net> <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>
NNTP-Posting-Host: oberon.di.fc.ul.pt
Mime-Version: 1.0 (generated by tm-edit 7.69)
Content-Type: text/plain; charset=US-ASCII
X-Newsreader: Gnus v5.2.25/XEmacs 19.14
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:45126 comp.unix.bsd.netbsd.misc:4031 comp.unix.bsd.freebsd.misc:23500
>>>>> "J Wunsch" == J Wunsch <j@ida.interface-business.de> writes:
J Wunsch> Pedro Roque Marques <roque@di.fc.ul.pt> wrote:
>> Like i mentioned in a previous post BSD style timers tend to be
>> cheaper but they are less correct than what one would normally
>> desire. One of the finest remarks i've heard on this issue was
>> "if most of the times the retransmit timer won't expire, why
>> set it in the first place ?" the tought part is that when the
>> timer expires with want it to expire with the greatest
>> precision you can achieve.
J Wunsch> Sorry for my ignorance, network code is arguably not my
J Wunsch> field of knowledge. What's the (user-visible) drawback
J Wunsch> of the current scheme? I do know that the BSD TCP code
J Wunsch> sometimes suffers from poor recovery behaviour on lossy
J Wunsch> lines (packet loss >~ 50 %, as it can often be observed
J Wunsch> on transatlantic or transpacific links). Is this what
J Wunsch> you mean?
TCP itself as a very poor behaviour if you have > 50% packet loss on a
link. By design TCP assumes that links (physical links) have a low packet
loss rate and that packet loss in a connection is due to congestion
(which is in fact the problem in transoceanic connections). The timers
come into play to when does a host detect the loss of it's own
packets. When it doesn't receive an ack from the peer more than
rtt + 4 mdev (where rtt is the smoted round trip time and mdev the
medium deviation) it assumes the packet was lost due to
congestion. The "problem" with BSD timers is that the timer as a 500
ms granularity (since slow_timeout is called every 500 ms) so the
detection of a packet loss is imprecise. If your timer happens to
timeout at t+1 ms and the slow_timeo function did run at t ms you will
waste 499 ms. This is a potential problem whenever you have a packet
loss. Statistically i guess you can say that it will waste an average of
250ms on packet loss. Now, if you do have more than 3 packets in a
window fast_retransmit can detect and retransmit the lost packet
without the connection stalling, but if you don't, and usually you
don't on a transoceanic connection (because a second loss can occur
when the connection is still doing slow start in the result of a
former loss), the impact can be nasty.
regards,
Pedro.