Date: Sun, 22 Mar 2009 21:58:30 GMT From: Andre Oppermann <andre@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 159636 for review Message-ID: <200903222158.n2MLwUAA029619@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=159636 Change 159636 by andre@andre_t61 on 2009/03/22 21:58:15 Update comments and add notes. Affected files ... .. //depot/projects/tcp_new/netinet/tcp_output.c#6 edit Differences ... ==== //depot/projects/tcp_new/netinet/tcp_output.c#6 (text+ko) ==== @@ -162,7 +162,7 @@ * header and to determine whether we have to send a * window update. * - * NB: rwin is already scaled. + * NB: rwin is already downscaled. */ rwin = tcp_rcv_wnd(tp, so); @@ -173,7 +173,7 @@ * RFC2581: Restart window. * * XXXAO: Use a decaying algorithm. It's not useful - * to have cwnd to drop of a cliff. + * to have cwnd to drop of a cliff. See RFC2861. */ if (tp->snd_nxt == tp->snd_una && (ticks - tp->t_rcvtime) >= max(tp->t_rxtcur, tcp_min_idle)) { @@ -259,7 +259,17 @@ goto send; if (SEQ_LT(tp->snd_lastack, tp->snd_nxt) && !(tp->t_flags & TF_DELACK)) goto send; - if (tp->t_flags & TF_DUPACK) { + /* + * For a duplicate ACK to be acceptable it must not carry any + * data nor update the window. This is a serious problem for + * bi-directional data transfer. While we are sending dup-ACKs + * we can't send any data. With SACK the distinction is much + * simpler as any segment carrying SACK information is automatically + * a duplicate ACK (if the ack value didn't move forward). The + * question whether the other implementations see it the same way. + */ + if ((tp->t_flags & TF_DUPACK) && tp->snd_dupack > 0 && + (tp->t_flags & TF_SACK_PERMIT)) { len = 0; goto send; } @@ -554,7 +564,7 @@ /* * NB: len > 0 means we sent this much data w/o error. - * error == 0 means we sent at least a single segment w/o error. + * error == 0 means we sent everything w/o error. * * XXXAO: Avoid unconditional writes to the tcpcb. */ @@ -775,6 +785,14 @@ * 2. NewReno RFC3782 * 3. Limited transmit RFC3042 * 4. SACK tells us where to send how much data RFC3517 + * 5. TCP congestion window validation RFC2861 + */ + /* + * The moment we receive a duplicate ACK everything freezes. + * No more new data is sent except for those allowed by limited + * transmit. + * The fast recovery algorithms start their work by the third + * duplicate ACK. */ }
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903222158.n2MLwUAA029619>