Date: Tue, 24 Sep 2002 15:56:53 -0700 From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com> To: "'Peter Godman'" <pete@isilon.com>, freebsd-net@freebsd.org Subject: RE: NewReno implementation questions. Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C2B06B5@XCH-NW-27.nw.nos.boeing.com>
next in thread | raw e-mail | index | archive | help
> -----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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6938661A6EDA8A4EA8D1419BCE46F24C2B06B5>