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:
Host A sends a TCP SYN packet to Host B. Host B receives it.
Host B sends a SYN-ACK packet to Host A. Host A receives it.
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:
The client sends a SYN with a TFO option that has the cookie field empty.
The server generates a cookie and sends it through the TFO option of a SYN-ACK packet.
The client caches the cookie for future TFO connections.
Thereafter, the two devices perform a TFO exchange:
The client sends a SYN with data and the cookie in the TFO option.
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.
See Also
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:
[edit]
services {
service-set ss2 {
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
}
stateful-firewall {
rule sfw_rule {
match-direction input-output;
term 0 {
from {
source-address {
any-ipv4;
}
destination-address {
any-ipv4;
}
then {
accept;
}
}
}
}
}
}
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
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 1
TFO packets stripped: 0
If you drop TFO enabled packets, you have the following configuration and output:
[edit]
services {
service-set ss2 {
service-set-options {
tcp-fast-open drop;
}
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
}
}
user@host> show services service-sets statistics tcp
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 1
TFO packets stripped: 0
If you strip the TFO option, the configuration and output change accordingly:
[edit]
services {
service-set ss2 {
service-set-options {
tcp-fast-open disabled;
}
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
}
}
user@host> show services service-sets statistics tcp
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 0
TFO packets stripped: 1
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:
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:
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
servicedlocated 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:
file filename <files number> <match regular-expression> <size size> <world-readable | no-world-readable>;
flag {
all;
command-queued;
config;
handshake;
init;
interfaces;
mib;
removed-client;
show;
}
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
- Configuring the Number and Size of Adaptive Services Log Files
- Configuring Access to the Log File
- Configuring a Regular Expression for Lines to Be Logged
- Configuring the Trace Operations
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:
file filename;
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:
file <filename> files number size size;
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:
file <filename> world-readable;
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:
file <filename> no-world-readable;
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:
file <filename> match regular-expression;
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:
flag {
all;
configuration;
routing-protocol;
routing-socket;
snmp;
}
Table 1 describes the meaning of the adaptive services tracing flags.
Flag |
Description |
Default Setting |
|---|---|---|
|
Trace all operations. |
Off |
|
Trace command enqueue events. |
Off |
|
Log reading of the configuration at the |
Off |
|
Trace handshake events. |
Off |
|
Trace initialization events. |
Off |
|
Trace interface events. |
Off |
|
Trace GGSN SNMP MIB events. |
Off |
|
Trace client cleanup events. |
Off |
|
Trace CLI command servicing. |
Off |
To display the end of the log, issue the show log serviced
| last operational mode command:
[edit] user@host# run show log serviced | last