From owner-freebsd-net Tue Sep 24 15:57:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 590E237B401 for ; Tue, 24 Sep 2002 15:57:30 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A03DC43E75 for ; Tue, 24 Sep 2002 15:57:29 -0700 (PDT) (envelope-from thomas.r.henderson@boeing.com) Received: from slb-av-02.boeing.com ([129.172.13.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA08905; Tue, 24 Sep 2002 17:57:28 -0500 (CDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id PAA06780; Tue, 24 Sep 2002 15:57:27 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g8OMvPO11040; Tue, 24 Sep 2002 15:57:26 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Sep 2002 15:57:24 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C2B06B5@XCH-NW-27.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "'Peter Godman'" , freebsd-net@freebsd.org Subject: RE: NewReno implementation questions. Date: Tue, 24 Sep 2002 15:56:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > -----Original Message----- > From: Peter Godman [mailto:pete@isilon.com] > Sent: Tuesday, September 24, 2002 1:20 PM > To: freebsd-net@freebsd.org > Subject: NewReno implementation questions. > I appreciate any and all advice about this code and whether this is > desirable behaviour for some reason I haven't thought of. I > will triple > check RFC 2852 to see whether and if so why this is > prescribed behaviour. > You can find this in RFC 2581. Duplicate acks are defined as acks that are sent immediately upon receipt of out-of-order data, hence implying that they are data-less (the Net/3 code back to Reno has defined dupacks this way). Then, fast retransmit is defined as: "The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost." RFC 2582 for NewReno is based on 2581 with addition of "recover" and partial ack handling. However, in the FreeBSD code, the counter t_dupacks is also used as a record of whether the sender entered and is leaving recovery mode-- this causes problems such as the case you described. Jeffrey Hsu has been working on a fix for the general problem of overloading the t_dupacks counter like this. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message