On Fri, 2 Sep 2005, Noritoshi Demizu wrote:
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 <nop,nop,timestamp 226080473 99717814> (DF)
(259 ACKs are omitted here)
11:34:54.611769 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84454467 win 2355 <nop,nop,timestamp 226080721 99717841> (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.
Oh, it's absolutely possible (even likely) that the application was slow
between 11:34:54.337167 and 11:34:54.611769 and data kept accumulating in
the socket buffer. The real problem is not the shrinking of the window,
but the fact that it never increases back to normal once the socket buffer
is emptied.
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.
Not really: the tcpdump is taken on the very box that generates the acks
with the shrinking window, so it can't possibly be affected by any shaper.
Unless the shaper is the Linux kernel itself...
-Ion
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
