Timestamp options in the TCP/IP protocol stack

Translated from: http://www.cnblogs.com/lovemyspring/articles/4271716.html

TCP should be one of the most widely used protocols in the Ethernet protocol family, and here's a chat about the timestamp option in the TCP protocol. This option was introduced by RFC 1323, which was submitted in 1992 and is now fully 20 years old. But I believe most of the program apes are quite unfamiliar with the proposal.
To understand why you need to use the timestamp option, you need to start with several basic designs of the TCP protocol.

Several design intentions of the TCP protocol, as well as the problems raised:
1. The agreement stipulates that the receiving end does not need to respond to each received data message, only need to receive n messages, reply to the originator of an ACK message.
This is to improve the efficiency of communications, but also introduces several issues:
A. It is uncertain how long it will be possible to receive an ACK after the originator has sent out the message.
B. If the ACK message is lost, it is difficult to determine the timeout time required to re-send.
2. In the TCP message, the address length of the sequence number is 32 bits.
This limits the amount of data that the originator sends at most once 2^30 length, and it must wait for an ACK signal. Why is it? There are some detailed discussions in this link.
However, for ultra-Fast Ethernet (1000M to 10G), this can affect the forwarding efficiency of TCP connections.

To address the above mentioned issues, the timestamp option has two main uses:
1. Measure the delay of communication on both ends of the TCP connection (Round trip time measurement)
With the RTTM mechanism, the two ends of TCP can easily determine the delay of the submission of the line, so as to work out an optimized packet interval and message timeout time, thus solving the first problem.
2. Deal with the problem of Sequence reversal (Protect against wrapped Sequence Numbers).
When a TCP receiver receives a data message, it compares the timestamp of the received message and the timestamp of the last message received. If this time is relatively new, then you can directly judge the message received is a new message, do not need to carry out a complex sequence number Window scale calculation, thus solving the second problem.

However, RFC1323 suggests there are some pitfalls.
It is recommended that the timestamp increment interval be defined to make the 1ms-1s. If the device increases timestamp at 1ms speed, then as long as a TCP connection for 24.8 consecutive days (1ms*2^31) no communication, and then send a paper, the receiver compares this message and the last message timestamp action will be wrong. (question 1)
(Note: KeepAlive is not defined in the TCP protocol.) If the application layer code does not define a time-out mechanism, the TCP connection will never be interrupted, so there is a possibility that the 24.8 consecutive days of non-communication will occur. ）
Reference Linux related code: ((S32) (tp->rx_opt.rcv_tsval-tp->rx_opt.ts_recent) < 0)
For example tp->rx_opt.rcv_tsval = 0x80000020, tp->rx_opt.ts_recent = 0x10
((S32) (tp->rx_opt.rcv_tsval-tp->rx_opt.ts_recent) = (S32) 0x80000010, is a negative number, necessarily less than 0.

What if problem 1 is resolved?
It is known that according to RFC1323, according to the speed of the fastest timestamp increase, it also takes 24.8 days for timestamp to be reversed.
if ((S32) (tp->rx_opt.rcv_tsval-tp->rx_opt.ts_recent) < 0) is judged to be established, You can also use local timestamp that receive the message locally, minus the local timestamp of the last message received. If the time is greater than 24.8 days, then the timestamp is reversed, otherwise it is not the case of reversal. Is this a foolproof thing to do? Not necessarily!

Don't forget that the local timestamp counter is also a 32-bit, and may be flipped. (question 2)
As an extreme example, assume that the timestamp increment interval between TCP devices is inconsistent, A is 1ms,b 10ms. The TCP connection has no communication for 248 consecutive days; At this time B sends a data message to a.
The timestamp in the TCP message sent to a at this point is flipped exactly. However, because the counter of a is 1ms plus one, 248 days, a counter has been zeroed 5 times. It is still wrong to use local timestamp to make judgments at this time.

The more insurance practices are:
If the speed of the TCP connection is not so fast (2^32/S), the local timestamp with a maximum interval of 1S. thereby circumventing (question 2).
If the TCP connection is very fast, the 1S timestamp interval is somewhat outdated and can be selected at a small level, such as 100ms. If this is going to happen for 24,800 consecutive days (why 24,800 days) do not communicate, in addition to dozens, I have no way.

Translated from: http://blog.csdn.net/zhangskd/article/details/7195795

Description

Protocol SUITE:TCP/IP.

Protocol type:transport layer Protocol.

Option length:10 bytes.

The TCP Timestamp option obsoletes the TCP echo Request and Echo reply options.

RFC 1323:

The timestamps is used for both distinct MECHANISMS:RTTM (Round trip Time measurement)

and PAWS (Protected against wrapped squences).

Structure diagram

Kind. 8 bits. Set to 8.

Length. 8 bits. Set to 10.

Timestamp Value (TSval). -Bits.

This field contains the current value of the timestamp clock of the sending the option.

TImestamp Echo Reply (TSECR). -Bits.

This field has only valid if the ACK bit is a set in the TCP header. If It is valid, it echos a timestamp value

That is sent by the remote TCP in the TSval field of a timestamps option. When tsecr are not valid,

Its value must is zero. The TSECR value would generally is from the most recent Timestamp option

That was received; However, there is exceptions that is explained below. A TCP may send the

Timestamp option in an initial SYN segment (i.e., segment containing a SYN bit and no ACK bit), and

May send a tsopt on other segments only if it received a TSopt in the initial SYN segment for the

Connection.

Use in the Linux kernel

If the timestamp option is supported, you can use this option to calculate the RTT.

[Java]View PlainCopy

2. static void Tcp_ack_saw_tstamp (struct sock *sk, int flag)
4. {
6. / * Rttm rule:a TSECR value received in A segment are used to
8. * Update the averaged RTT measurement only if the segment
10. * Acknowledges some new data, i.e., only if it advances the
12. * Left edge of the Send window.
14. *
16. * Changed:reset Backoff As soon as we see the first valid
18. * Sample. If We do not, we get strongly overestimated RTO.
20. * With timestamps samples is accepted even from very
22. * Old SEGMENTS:F.E., when rtt=1 increases to 8, we retransmit
24. * 5 times and after 8 seconds delayed answer arrives RTO
26. * Becomes seconds!
28. */
30. struct Tcp_sock *TP = Tcp_sk (SK);
32. Tcp_valid_rtt_meas (SK, TCP_TIME_STAMP-TP->RX_OPT.RCV_TSECR);
34. }

RTT is equal to the current time Tcp_time_stamp minus timestamp Echo Reply, or TP->RX_OPT.RCV_TSECR.

The role of TCP timestamp option:

1) allow more accurate round-trip time measurements for deriving the retransmission

Timeout estimator.

2) protect against old segments from the previous incarnations of the TCP connection.

3) allow detection of unnecessary retransmissions.

Timestamp options in the TCP/IP protocol stack