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.