lkml.org 
[lkml]   [1999]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectTCP 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/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.024 / U:32.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site