Re: TCP window updates [Was: PROBLEM: Sending mail-attachment]

Andrea Arcangeli (andrea@e-mind.com)
Tue, 9 Mar 1999 01:24:25 +0100 (CET)


On Mon, 8 Mar 1999, Matthias Moeller wrote:

As first thanks for the analysis of the code.

>I had real deadlocks because of this and the bug in cleanup_rbuf(),
>the reveiver did not advertise increased windows. Okay, with Daves
>fix the receiver now does that but these ACKs could be dropped by
>the network.

Agreed. I can't see any mechanizm to avoid the deadlock if the ack gets
dropped.

I think the point is that we should set the probe0 timer even if the
sending-window is not 0. This should be the timeout that the rfc1122 that
you quoted yesterday talks about.

>Or it could be fixed in tcp_do_sendmsg() (The stuff with copied and
>queue_it, queue_it is always 1 for small write() sizes. So _no_ data
>will get on the wire an the PROBE0 timer will _not_ be started).

What looks to me wrong is that in the queue_it case (the queue_it case
should deal with resembling iovect in full-mss-sized packets) we are not
setting the probe0 timer in tcp_send_skb.

So to have always a probe0 timer pending when we are only queueing data I
think we should do this as you suggested:

Index: tcp_output.c
===================================================================
RCS file: /var/cvs/linux/net/ipv4/tcp_output.c,v
retrieving revision 1.1.2.12
diff -u -r1.1.2.12 tcp_output.c
--- tcp_output.c 1999/03/08 13:27:44 1.1.2.12
+++ tcp_output.c 1999/03/08 23:30:28
@@ -177,7 +177,7 @@
/* Queue it, remembering where we must start sending. */
if (tp->send_head == NULL)
tp->send_head = skb;
- if (!force_queue && tp->packets_out == 0 && !tp->pending) {
+ if (tp->packets_out == 0 && !tp->pending) {
tp->pending = TIME_PROBE0;
tcp_reset_xmit_timer(sk, TIME_PROBE0, tp->rto);
}

But I am not 100% sure this is enough to make sure to always have a probe0
timer pending if there's some data pending not yet transmitted and we are
waiting for a window update before transmitting data.

If it's wrong, if somebody would let me know _why_ is wrong it would be
very interesting to me. Thanks.

Another thing that make me ill ;) is the fact that tcpdump screw up things
while your proggy is running on the loopback device. Now I am going to
debug _why_ this happens.

Here an example:

01:22:08.669493 localhost.1029 > localhost.3334: S 846173315:846173315(0) win 31072 <mss 3884,sackOK,timestamp 89653 0,nop,wscale 0> (DF)
01:22:08.669493 localhost.1029 > localhost.3334: S 846173315:846173315(0) win 31072 <mss 3884,sackOK,timestamp 89653 0,nop,wscale 0> (DF)
01:22:08.669547 localhost.3334 > localhost.1029: S 844580933:844580933(0) ack 846173316 win 31072 <mss 3884,sackOK,timestamp 89653 89653,nop,wscale 0> (DF)
01:22:08.669547 localhost.3334 > localhost.1029: S 844580933:844580933(0) ack 846173316 win 31072 <mss 3884,sackOK,timestamp 89653 89653,nop,wscale 0> (DF)
01:22:08.669587 localhost.1029 > localhost.3334: . ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.669587 localhost.1029 > localhost.3334: . ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.669739 localhost.3334 > localhost.1029: . 1:3873(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.669739 localhost.3334 > localhost.1029: . 1:3873(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.669781 localhost.1029 > localhost.3334: . ack 3873 win 27200 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.669781 localhost.1029 > localhost.3334: . ack 3873 win 27200 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670064 localhost.3334 > localhost.1029: . 3873:7745(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670073 localhost.3334 > localhost.1029: . 7745:11617(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670064 localhost.3334 > localhost.1029: . 3873:7745(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670098 localhost.1029 > localhost.3334: . ack 7745 win 27104 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670073 localhost.3334 > localhost.1029: . 7745:11617(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670098 localhost.1029 > localhost.3334: . ack 7745 win 27104 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670123 localhost.3334 > localhost.1029: . 11617:15489(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670131 localhost.3334 > localhost.1029: . 15489:19361(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670123 localhost.3334 > localhost.1029: . 11617:15489(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670146 localhost.1029 > localhost.3334: . ack 15489 win 23232 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670131 localhost.3334 > localhost.1029: . 15489:19361(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670146 localhost.1029 > localhost.3334: . ack 15489 win 23232 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670170 localhost.3334 > localhost.1029: . 19361:23233(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670178 localhost.3334 > localhost.1029: . 23233:27105(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670187 localhost.3334 > localhost.1029: . 27105:30977(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670170 localhost.3334 > localhost.1029: . 19361:23233(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670203 localhost.1029 > localhost.3334: . ack 23233 win 19360 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670178 localhost.3334 > localhost.1029: . 23233:27105(3872) ack 1 win 31072 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670222 localhost.1029 > localhost.3334: . ack 30977 win 15488 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670203 localhost.1029 > localhost.3334: . ack 23233 win 19360 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670222 localhost.1029 > localhost.3334: . ack 30977 win 15488 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670290 localhost.1029 > localhost.3334: . ack 38721 win 11616 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670308 localhost.1029 > localhost.3334: . ack 46465 win 7744 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670290 localhost.1029 > localhost.3334: . ack 38721 win 11616 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670308 localhost.1029 > localhost.3334: . ack 46465 win 7744 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.670361 localhost.1029 > localhost.3334: . ack 54209 win 3872 <nop,nop,timestamp 89653 89653> (DF)
01:22:08.678085 localhost.1029 > localhost.3334: . ack 57501 win 580 <nop,nop,timestamp 89654 89653> (DF)
01:22:08.678123 localhost.3334 > localhost.1029: P 54209:57501(3292) ack 1 win 31072 <nop,nop,timestamp 89654 89653> (DF)
01:22:08.678085 localhost.1029 > localhost.3334: . ack 57501 win 580 <nop,nop,timestamp 89654 89653> (DF)
01:22:08.678123 localhost.3334 > localhost.1029: P 54209:57501(3292) ack 1 win 31072 <nop,nop,timestamp 89654 89653> (DF)
01:22:08.678157 localhost.1029 > localhost.3334: . ack 57501 win 580 <nop,nop,timestamp 89654 89654> (DF)

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/