> -----Original Message-----
> From: Peter Godman [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 24, 2002 1:20 PM
> To: [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
