>If the data is dropped it cannot be acked. Acking earlier data does not make
>any sense, because the other end cannot do anything more than to retransmit,
>and it should do that anyways even when we send no ack. What Alan said is that
Yes. It was plain wrong to send duplicate acks because that way I was
risking to start the fast-retransmit algorithm that suppose that acked
data gets queued in the receiver.
>Also disabling header prediction is not required (the user may eat the buffer backlog
>and everything could be fine again when the next retransmit arrives)
Agreed.
Index: tcp_input.c
===================================================================
RCS file: /var/cvs/linux/net/ipv4/tcp_input.c,v
retrieving revision 1.1.2.23
diff -u -r1.1.2.23 tcp_input.c
--- tcp_input.c 1999/03/07 20:00:23 1.1.2.23
+++ tcp_input.c 1999/03/07 22:31:17
@@ -65,9 +65,6 @@
* to 3 * pmtu before going to
* deadlocking. This will also improve
* transfer throughput.
- * Andrea Arcangeli: Always send back an ack even if we
- * have to reject the incoming packet
- * because our rcvbuf is full.
*/
#include <linux/config.h>
@@ -1519,19 +1516,11 @@
* shrink something if possible. -arca
*/
if (prune_queue(sk) < 0)
- {
/*
* Bad: we aren't been able to shrink the out of
- * order queue so we _must_ drop the packet. But
- * we send an ack back to the other end so the
- * sender will see our rcv_nxt. This way if the dropped
- * packet was out of order the sender will be able
- * to start fast retransmit. -arca
+ * order queue so we _must_ drop the packet.
*/
- tp->delayed_acks++;
- tcp_enter_quickack_mode(tp);
return 0;
- }
}
ret = tcp_data_queue(sk, skb);
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/