As you can see, TCP is ack'ing *three* packets at with one ack packet.
RFC1122, states two different requirements:
4.2.3.2 A TCP SHOULD implement a delayed ACK,....and in a stream of
full-sized segments there SHOULD be an ACK for at least every second
segment.
4.2.2.20 In general, the processing of received segments MUST be
implemented to aggregate ACK segments whenever possible. For example, if
the TCP is processing a series of queued segments, it MUST process them
all before sending any ACK segments.
Obviously Linux complies with the second (MUST) and chooses to ignore
the first (SHOULD). This, however, leads to poor performance on lines
with high delay-bandwidth product. Is it possible to make this behaviour
configurable?
==== tcpdump ===
:18.204 nimrodm > bones: . 1:1(0) ack 15493 win 30660 (DF) [tos 0x8]
:18.275 bones > nimrodm: . 15493:16385(892) ack 1 win 24820 (DF)
:18.276 bones > nimrodm: . 16385:17845(1460) ack 1 win 24820 (DF)
:18.277 bones > nimrodm: . 17845:19305(1460) ack 1 win 24820 (DF)
:18.402 bones > nimrodm: . 19305:20765(1460) ack 1 win 24820 (DF)
:18.403 bones > nimrodm: . 20765:22225(1460) ack 1 win 24820 (DF)
:18.406 bones > nimrodm: . 22225:23685(1460) ack 1 win 24820 (DF)
:18.407 bones > nimrodm: . 23685:24577(892) ack 1 win 24820 (DF)
:18.408 bones > nimrodm: P 24577:26037(1460) ack 1 win 24820 (DF)
.. and here is the triple-ack:
:18.478 nimrodm > bones: . 1:1(0) ack 19305 win 30660 (DF) [tos 0x8]
:18.604 nimrodm > bones: . 1:1(0) ack 22225 win 30660 (DF) [tos 0x8]
.. and again:
:18.609 nimrodm > bones: . 1:1(0) ack 26037 win 30660 (DF) [tos 0x8]
=====
Another issue is delayed acks (and aggregation of acks) during slow
start. 'tcp_input.c' specifically states that Linux ack's each segment
to make the sender enlarge its congestion window as fast as possible.
However, for some reason, this does not always work, as the following
example demonstrates:
:50.519 bones > client: P 1:1461(1460) ack 1 win 24820 (DF)
:50.720 client > bones: . 1:1(0) ack 1461 win 30660 (DF) [tos 0x8]
:50.922 bones > client: . 1461:2921(1460) ack 1 win 24820 (DF)
:50.924 bones > client: P 2921:4381(1460) ack 1 win 24820 (DF)
.. and now the client acks two packets with one ACK packet:
:51.125 client > bones: . 1:1(0) ack 4381 win 30660 (DF) [tos 0x8]
Again, on lines with large delay-bandwidth product, this impacts
performance (especially with short transfers).
Any ideas? Is this behaviour fixed with 2.3.x kernels?
-- Nimrod.
-
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/