Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

TCP Fast Open

 

Exchanging Data More Efficiently Using TCP Fast Open

TCP Fast Open (TFO) is an update to TCP that saves up to one full round-trip time (RTT) over the standard three-way connection handshake during a TCP session. TFO support is for MS-MPC and MS-MIC.

The standard three-way connection handshake involves three sets of send and receive messages between two hosts and the following exchange of SYN (synchronize) and ACK (acknowledgement) packets:

  1. Host A sends a TCP SYN packet to Host B. Host B receives it.

  2. Host B sends a SYN-ACK packet to Host A. Host A receives it.

  3. Host A sends an ACK packet to Host B. Host B receives it.

In standard TCP, although data can be carried in SYN packets, this data cannot be delivered until the three-way handshake is completed. TFO removes this constraint and allows data in SYN packets to be delivered to the application, yielding significant latency improvement.

The key component of TFO is the Fast Open Cookie (cookie), which is a Message Authentication Code (MAC) tag generated by the server. The client requests a cookie in one regular TCP connection, then uses it for future TCP connections to exchange data during the handshake.

The TFO option is used to request or to send a TFO cookie. When a cookie is not present or is empty, the option is used by the client to request a cookie from the server. When the cookie is present, the option is used to pass the cookie from the server to the client or from the client back to the server.

The following list outlines how the client requests a TFO cookie:

  1. The client sends a SYN with a TFO option that has the cookie field empty.

  2. The server generates a cookie and sends it through the TFO option of a SYN-ACK packet.

  3. The client caches the cookie for future TFO connections.

Thereafter, the two devices perform a TFO exchange:

  1. The client sends a SYN with data and the cookie in the TFO option.

  2. The server validates the cookie:

    • If the cookie is valid, the server sends a SYN-ACK acknowledging both the SYN and the data.

      The server then delivers the data to the application.

    • Otherwise, the server drops the data and sends a SYN-ACK acknowledging only the SYN sequence number.

The rest of the connection proceeds like a normal TCP connection. The client can repeat many TFO operations once it acquires a cookie (until the cookie is expired by the server). Thus, TFO is useful for applications in which the same client reconnects to the same server multiple times and exchanges data.

Configuring TFO

In this topic, the three modes of TCP Fast Open (TFO) are described and examples given. The case of using NAT with TFO is also covered.

Three Modes for TFO

No configuration is required to use TFO. TFO is enabled by default. In default mode, all TFO packets are forwarded by the service PIC. Besides the default, there are two other modes for TFO that you configure through the CLI:

  • Drop TFO—If this mode is set, no TFO packets are forwarded.

  • Disable TFO—If this mode is set, any SYN or SYN ACK packet carrying TFO, data, or both, will be stripped of the TFO and the data before being forwarded.

The TFO option is enabled per service set. The service set can be either a next-hop service set or an interface-style service set. Following is an example interface-style service set configuration:

In this instance, TFO is enabled by default (no TFO configuration). The output for the show services service-sets statistics tcp command is as follows:

user@host> show services service-sets statistics tcp

If you drop TFO enabled packets, you have the following configuration and output:

user@host> show services service-sets statistics tcp

If you strip the TFO option, the configuration and output change accordingly:

user@host> show services service-sets statistics tcp

Using NAT and TFO

If NAT is configured in the service set and you are using TFO, you should configure address-pooling paired (APP). APP allows a private IP address to be mapped to the same public IP address from a NAT pool for all its sessions.

If you do not configure APP, NAT can give a different IP address to the client from the same NAT pool than the one it sent to the server before. The server does not recognize the IP address, drops the TFO option, and replies with SYN ACK and the data the client sent is not acknowledged. Therefore, even though the connection is successful and no packet is lost, the benefit of TFO is lost. But if client comes back with the same IP address, the server recognizes it and acknowledges the data. Therefore, always enable APP with a high mapping timeout value with TFO.

To configure APP:

  1. Configure APP:
  2. Configure a high mapping timeout value:

Configuring Fragmentation Control for MS-DPC and MS-PIC Service Interfaces

Two configuration options are available to prevent excessive consumption of computational CPU cycles on a services PIC caused by the handling of large numbers of fragmented packets. Such fragment handling can be exploited in DOS attacks. The fragment-limit option establishes a maximum number of fragments for a packet. When this number is exceeded, the packet is dropped. The reassembly-timeout specifies the maximum time from the receipt of the first and latest fragments in a packet. When the number is exceeded, the packet is dropped.

To configure fragmentation control for MS-DPC and MS-PIC service interfaces:

  1. In configuration mode, go to the [edit interfaces interface-name services-options hierarchy level.
  2. Configure the fragment limit.
  3. Configure the reassembly timeout.

Tracing Services PIC Operations

Tracing operations track all adaptive services operations and record them in a log file. The logged error descriptions provide detailed information to help you solve problems faster.

By default, no events are traced. If you include the traceoptions statement at the [edit services adaptive-services-pics] or [edit services logging] hierarchy level, the default tracing behavior is the following:

  • Important events are logged in a file called serviced located in the /var/log directory.

  • When the file serviced reaches 128 kilobytes (KB), it is renamed serviced.0, then serviced.2, and so on, until there are three trace files. Then the oldest trace file (serviced.2) is overwritten. (For more information about how log files are created, see the System Log Explorer.)

  • Log files can be accessed only by the user who configures the tracing operation.

You cannot change the directory (/var/log) in which trace files are located. However, you can customize the other trace file settings by including the following statements:

You include these statements at the [edit services adaptive-services-pics traceoptions] or [edit services logging traceoptions] hierarchy level.

These statements are described in the following sections:

Configuring the Adaptive Services Log Filename

By default, the name of the file that records trace output is serviced. You can specify a different name by including the file statement at the [edit services adaptive-services-pics traceoptions] or [edit services logging traceoptions] hierarchy level:

Configuring the Number and Size of Adaptive Services Log Files

By default, when the trace file reaches 128 kilobytes (KB) in size, it is renamed filename.0, then filename.1, and so on, until there are three trace files. Then the oldest trace file (filename.2) is overwritten.

You can configure the limits on the number and size of trace files by including the following statements at the [edit services adaptive-services-pics traceoptions] or [edit services logging traceoptions] hierarchy level:

For example, set the maximum file size to 2 MB, and the maximum number of files to 20. When the file that receives the output of the tracing operation (filename) reaches 2 MB, filename is renamed filename.0, and a new file called filename is created. When the new filename reaches 2 MB, filename.0 is renamed filename.1 and filename is renamed filename.0. This process repeats until there are 20 trace files. Then the oldest file (filename.19) is overwritten by the newest file (filename.0).

The number of files can be from 2 through 1000 files. The file size of each file can be from 10 KB through 1 gigabyte (GB).

Configuring Access to the Log File

By default, log files can be accessed only by the user who configures the tracing operation.

To specify that any user can read all log files, include the file world-readable statement at the [edit services adaptive-services-pics traceoptions] or [edit services logging traceoptions] hierarchy level:

To explicitly set the default behavior, include the file no-world-readable statement at the [edit services adaptive-services-pics traceoptions] or [edit services logging traceoptions] hierarchy level:

Configuring a Regular Expression for Lines to Be Logged

By default, the trace operation output includes all lines relevant to the logged events.

You can refine the output by including the match statement at the [edit services adaptive-services-pics traceoptions file filename] or [edit services logging traceoptions] hierarchy level and specifying a regular expression (regex) to be matched:

Configuring the Trace Operations

By default, if the traceoptions configuration is present, only important events are logged. You can configure the trace operations to be logged by including the following statements at the [edit services adaptive-services-pics traceoptions] or [edit services logging traceoptions] hierarchy level:

Table 1 describes the meaning of the adaptive services tracing flags.

Table 1: Adaptive Services Tracing Flags

Flag

Description

Default Setting

all

Trace all operations.

Off

command-queued

Trace command enqueue events.

Off

config

Log reading of the configuration at the [edit services] hierarchy level.

Off

handshake

Trace handshake events.

Off

init

Trace initialization events.

Off

interfaces

Trace interface events.

Off

mib

Trace GGSN SNMP MIB events.

Off

removed-client

Trace client cleanup events.

Off

show

Trace CLI command servicing.

Off

To display the end of the log, issue the show log serviced | last operational mode command: