Date: Tue, 24 Sep 2002 13:19:54 -0700 (PDT) From: Peter Godman <pete@isilon.com> To: freebsd-net@freebsd.org Subject: NewReno implementation questions. Message-ID: <Pine.BSF.4.21.0209241311090.24387-100000@isilon.com>
next in thread | raw e-mail | index | archive | help
While looking at why packet loss was so disastrous in the application I'm
working on, I noticed an oddity in a CURRENT snapshot taken in January,
which I believe is the same today. Basically, there's some ack handling
code that looks like:
if (SEQ_LEQ(th->th_ack, tp->snd_una)) {
if (tlen == 0 && tiwin == tp->snd_wnd) {
/* dupack handling code */
...
} else {
tp->t_dupacks = 0;
}
So what this seems to say to my untrained eye is that we should reset the
dupacks, i.e. leave newreno fast recovery, if non-ack-only traffic comes
from the other end. However, that the remote side decided to send data
seems unrelated to whether we have successfully completed recovery and
consequently don't need to retransmit in response to partial acks.
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.
Thanks
Peter Godman
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?Pine.BSF.4.21.0209241311090.24387-100000>