From owner-freebsd-hackers Mon Oct 2 05:20:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA14239 for hackers-outgoing; Mon, 2 Oct 1995 05:20:00 -0700 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA14200 for ; Mon, 2 Oct 1995 05:19:33 -0700 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA23487 for hackers@freebsd.org; Mon, 2 Oct 1995 13:25:34 +0100 From: Luigi Rizzo Message-Id: <199510021225.NAA23487@labinfo.iet.unipi.it> Subject: Unreliable internet and RTT estimation code in BSD To: hackers@freebsd.org Date: Mon, 2 Oct 1995 13:25:34 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2622 Sender: owner-hackers@freebsd.org Precedence: bulk This is a followup to my previous posting on high packet losses (10..60% and more) which I am experiencing between Europe and the US. My first thought was that such a large loss rate should almost completely defeat the algorithms used by TCP to determine the RTT, to the point that ftp-ing a file larger than 100K takes a huge amount of time if it succeeds at all. To see what was going on, I have modified netstat on my FreeBSD 1.1 system to show the values of rtt/srtt/ rttvar from the tcp protocol control block (a simple one-line addition to inet.c in the BSD netstat sources: in protopr() I added the line printf("rtt/srtt/rttvar %7d/%7d/%7d ", tcpcb.t_rtt, tcpcb.t_srtt, tcpcb.t_rttvar); I then started an ftp connection from overseas with hash marks on, and, while the transfer proceeds (*very* slowly), netstat shows the following numbers (these are not regular samples; I ran netstat every few seconds by hand): rtt srtt rttvar comment ------------------------ 3 8 2 beginning of the connection. some 50KB go 5 8 2 through. 8 8 2 11 8 2 17 8 2 no data are flowing. 22 8 2 2 0 3 perhaps a packet or two have been sent. 17 0 3 0 0 3 5 0 3 86 0 3 0 0 3 ... 0 0 5 the transfer seems to have blocked; but pinging the remote host still gives about 50% success. I get these numbers for a couple of minutes. ... here I was typing this message 25 15 3 and after, this is what i get. ... 0 15 3 again, no data are flowing. 0 0 6 and to my surprise, srtt goes back to 0! ... 0 23 6 and then up to 23... ... 0 0 24 and then back to 0 again! There are two things which surprise me: 1) srtt goes to 0 so quickly, and stays there for some time, despite the fact that the actual rtt is large; 2) rtt stays at 0 while no data are exchanged (and there should be pending data/acks somewhere). I am not very familiar with the way RTT is estimated and it implementation in the BSD code (I guess I'll have to study it); however, the above numbers look wrong to me. So I was wondering about the existence of studies on the performance of the RTT estimation code in the BSD implementation of TCP, especially in presence of large packet losses. Any pointers and comments are mostly appreciated. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ====================================================================