Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
Below may not be directly related to the cause of the problem. But I think some window sizes in your mail need to be re-evaluated. > 11:29:54.961998 10.2.20.246.33060 > 10.2.224.182.8700: S > 1972343059:1972343059(0) win 5840 0,nop,wscale 2> (DF) > 11:29:54.983334 10.2.224.182.8700 > 10.2.20.246.33060: S > 2770690746:2770690746(0) ack 1972343060 win 33304 225781001,mss 1460,nop,wscale 1,nop,nop,sackOK> (DF) Since the TCP Window Scale options are exchanged, the window size field contains shifted value except SYNs. > 11:29:55.216634 10.2.20.246.33060 > 10.2.224.182.8700: . ack 14307 win 8192 > (DF) > > The connection is established and the receiver's TCP window quickly ramps > up to 8192. I think the real window size here is 8192 << 2 = 32768. > 11:29:55.707823 10.2.20.246.33060 > 10.2.224.182.8700: . ack 274527 win 16534 > (DF) > > Shortly thereafter the TCP window increases further to 16534. It remains > around 16534 for the next 5 minutes or so. I think the real window size here is 16534 << 2 = 66136. > 11:31:09.345250 10.2.20.246.33060 > 10.2.224.182.8700: . ack 38676603 win > 16534 (DF) > > A few minutes later it has finally caught up to present time and it starts > receiving smaller packets containing real-time data. The TCP window is > still 16534 at this point. I think the real window size here is 16534 << 2 = 66136. > 11:34:54.337167 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84402527 win > 15340 (DF) (sniop) > 11:34:54.628497 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84458619 win > 2355 (DF) > > This is where things start going bad. The window starts shrinking from > 15340 all the way down to 2355 over the course of 0.3 seconds. I think the real window sizes are 15340 << 2 = 61360 and 2355 << 2 = 9420. Hence, the right edges can be calculated as the following: 84402527 + 15340 << 2 = 84463887 84458619 + 2355 << 2 = 84468039 So, the window is not shrinked between those two lines. Sorry, I have not checked other lines. > 11:40:08.279678 10.2.20.246.33060 > 10.2.224.182.8700: . ack 134973263 win > 2355 (DF) > > Five minutes later the TCP window is still at 2355, having never recovered. I think the real window size here is 2355 << 2 = 9420. > As I mentioned earlier, I've seen it go as low as 181. I think the real window size is 181 << 2 = 724. Regards, Noritoshi Demizu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
> > Since the TCP Window Scale options are exchanged, > > the window size field contains shifted value except SYNs. > > Be careful, tcpdump may be tracking the window scale and reporting > scaled values. Seems unlikely since with a window scale of 2, and odd > window size would be impossible. I am sorry if tcpdump tracks the window scale option. But I think it is unlikely, because there are odd window sizes, as you pointed out. By the way, if tcpdump does not track the window scale option, the right edge (ack + real win) does not change between the following two ACKs. > 11:34:54.337167 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84402527 win > 15340 (DF) (259 ACKs are omitted here) > 11:34:54.611769 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84454467 win > 2355 (DF) The first line is the 37th ACK and the second line is the 295th ACK. ACK#37: ack=84402527 win=15340 right_edge=84463887 (= ack + win * 4) ACK#295: ack=84454467 win=2355 right_edge=84463887 (= ack + win * 4) And all ACKs later than ACK#295 has win=2355 (2355*4=9420). This may be a hint. But, sorry, I do not know the internal of Linux TCP. Regards, Noritoshi Demizu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
> By the way, if tcpdump does not track the window scale option, the right > edge (ack + real win) does not change between the following two ACKs. > > > 11:34:54.337167 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84402527 win > > 15340 (DF) > (259 ACKs are omitted here) > > 11:34:54.611769 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84454467 win > > 2355 (DF) > > The first line is the 37th ACK and the second line is the 295th ACK. > > ACK#37: ack=84402527 win=15340 right_edge=84463887 (= ack + win * 4) > ACK#295: ack=84454467 win=2355 right_edge=84463887 (= ack + win * 4) > > And all ACKs later than ACK#295 has win=2355 (2355*4=9420). > > This may be a hint. But, sorry, I do not know the internal of Linux TCP. I think there is a possibility that some middle-box does something, for example, some middle-box between the two machines does kinda traffic-shaping by tweaking the TCP window size field. Regards, Noritoshi Demizu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
