locked
FTP and TCP timestamp option issue RRS feed

  • Allgemeine Diskussion

  • This posting is more an issue than a question, but hopefully you can help.

    When performing a FTP download from a remote FTP server, in some scenarios the download performance went very low. Digging into the details, we identified the root cause of this problem.

    If the Windows 7 (FTP client) has TCP receiver window as well as TCP timestamp option enabled and if the server does not implement the TCP timestamp option, the receiver window does not increas 16kB although window scaling is enabled.

    Enabling the timestamp option on the FTP server lets the receiver window at the client side increase. In more detail:

    Setup

    • Windows 7 Professional Client
    • Client: TCP network parameters: TCP timestamp option enabled, receiver windows scaling option: normal
    • Server: TCP network parameters: TCP timestamp option disabled, receiver window scaling enabled
    • Make sure that the RTT between client and server is large enough that the bandwidth delay product exceeds 65kB.

    Task

    • Download a large file (>10MB) from the remote ftp server using any ftp client (e.g. IE, smartftp, ftp of the CLI, wget32)
    • Trace the communication with wireshark or network monitor

    Observe

    • The client SYN packet includes the options on timestamp and windowscaling with some scaling factor
    • The server SYN.ACK packet includes also the windows scaling option with some scaling factor but no timestamp option
    • Check the receiver advertised window from the client at the connection end (e.g., tcptrace), it does not exceed 16kB.
    • Performing the same setup with timestamp enabled at the server, the receiver advertised window exceeds 16kB.

    Findings

    • This behaviour only occurs with FTP; HTTP and other protocols are not affected
    • It occurs in both scenarios, active as well as passive FTP.

    Any response or comment on this behaviour would be appreciated,

    with best regards, sg



    Montag, 16. Januar 2012 11:21

Alle Antworten