Messages in this thread | | | Date | Wed, 15 Dec 1999 20:16:47 +0200 | From | Nimrod Mesika <> | Subject | TCP delayed ack problem |
| |
The following is from a tcpdump of an ftp transfer. An ftp client running on Linux 2.2.12 kernel is downloading a file from a Solaris 2.51 host. The client is named 'nimrodm' and the server 'bones'.
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/
| |