PERFORCE change 159636 for review

[Andre Oppermann]

http://perforce.freebsd.org/chv.cgi?CH=159636

Change 159636 by andre at 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.
 	 */
 
 }