Ip Tcp Timestamp

ip tcp timestamp

I have seen this com­mand a few times, today I am going to look into it and see what it does. Also, this is prob­ably a clas­sic CCIE lab gotcha.

From the Cisco documentation:

The TCP time-​​stamp option provides bet­ter TCP round-​​trip time meas­ure­ments. Because the time stamps are always sent and echoed in both dir­ec­tions and the time-​​stamp value in the header is always chan­ging, TCP header com­pres­sion will not com­press the out­go­ing packet. To allow TCP header com­pres­sion over a serial link, the TCP time-​​stamp option is disabled.

Thats look like a clas­sic CCIE lab exam ques­tion to me

Refer to RFC 1323 for more detailed inform­a­tion on TCP time stamp. (OK, I will cover that in a minute).

To enable TCP time stamp, use the fol­low­ing com­mand in global con­fig­ur­a­tion mode:

Router(config)# ip tcp timestamp

If you want to use TCP header com­pres­sion over a serial line, TCP time stamp and TCP select­ive acknow­ledg­ment must be dis­abled. Both fea­tures are dis­abled by default. To dis­able TCP select­ive acknow­ledg­ment once it is enabled, see the pre­vi­ous “Enabling TCP Selective Acknowledgment” section.

Even trick­ier.

Extract from the RFC

Abstract

This memo presents a set of TCP exten­sions to improve per­form­ance
over large bandwidth*delay product paths and to provide reli­able
oper­a­tion over very high-​​speed paths. It defines new TCP options for
scaled win­dows and timestamps, which are designed to provide
com­pat­ible inter­work­ing with TCP’s that do not imple­ment the
exten­sions. The timestamps are used for two dis­tinct mech­an­isms:
RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
Sequences). Selective acknow­ledg­ments are not included in this memo.

What does it mean ?

Stephens TCP/​IP Illustrated Vol2 says:

The timestamp option lets the sender place a timestamp value in every seg­ment. The receiver reflects this value in the acknow­ledg­ment, allow­ing the sender to cal­cu­late an RTT for each received ACK. (We must say “each received ACK” and not “each seg­ment” since TCP nor­mally acknow­ledges mul­tiple seg­ments per ACK.) We said that many cur­rent imple­ment­a­tions only meas­ure one RTT per win­dow, which is OK for win­dows con­tain­ing eight seg­ments. Larger win­dow sizes, how­ever, require bet­ter RTT calculations

Paraphrasing RFC 1323

3. RTTM: ROUND-​​TRIP TIME MEASUREMENT

3.1 Introduction

Accurate and cur­rent RTT estim­ates are neces­sary to adapt to
chan­ging traffic con­di­tions and to avoid an instabil­ity known as
“con­ges­tion col­lapse” [Nagle84] in a busy net­work. However,
accur­ate meas­ure­ment of RTT may be dif­fi­cult both in the­ory and in
implementation.

Many TCP imple­ment­a­tions base their RTT meas­ure­ments upon a sample
of only one packet per win­dow. While this yields an adequate
approx­im­a­tion to the RTT for small win­dows, it res­ults in an
unac­cept­ably poor RTT estim­ate for an LFN. If we look at RTT
estim­a­tion as a sig­nal pro­cessing prob­lem (which it is), a data
sig­nal at some fre­quency, the packet rate, is being sampled at a
lower fre­quency, the win­dow rate. This lower sampling fre­quency
viol­ates Nyquist’s cri­teria and may there­fore intro­duce “ali­asing“
arti­facts into the estim­ated RTT [Hamming77].

A good RTT estim­ator with a con­ser­vat­ive retrans­mis­sion timeout
cal­cu­la­tion can tol­er­ate ali­asing when the sampling fre­quency is
“close” to the data fre­quency. For example, with a win­dow of 8
pack­ets, the sample rate is ¹⁄₈ the data fre­quency — less than an
order of mag­nitude dif­fer­ent. However, when the win­dow is tens or
hun­dreds of pack­ets, the RTT estim­ator may be ser­i­ously in error,
res­ult­ing in spuri­ous retransmissions.

If there are dropped pack­ets, the prob­lem becomes worse. Zhang
[Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is
not pos­sible to accu­mu­late reli­able RTT estim­ates if retrans­mit­ted
seg­ments are included in the estim­ate. Since a full win­dow of
data will have been trans­mit­ted prior to a retrans­mis­sion, all of
the seg­ments in that win­dow will have to be ACKed before the next
RTT sample can be taken. This means at least an addi­tional
window’s worth of time between RTT meas­ure­ments and, as the error
rate approaches one per win­dow of data (e.g., 10**-6 errors per
bit for the Wideband satel­lite net­work), it becomes effect­ively
impossible to obtain a valid RTT measurement.

A solu­tion to these prob­lems, which actu­ally sim­pli­fies the sender
sub­stan­tially, is as fol­lows: using TCP options, the sender places
a timestamp in each data seg­ment, and the receiver reflects these
timestamps back in ACK seg­ments. Then a single sub­tract gives the
sender an accur­ate RTT meas­ure­ment for every ACK seg­ment (which
will cor­res­pond to every other data seg­ment, with a sens­ible
receiver). We call this the RTTM (Round-​​Trip Time Measurement)
mechanism.

It is vitally import­ant to use the RTTM mech­an­ism with big
win­dows; oth­er­wise, the door is opened to some dan­ger­ous
instabil­it­ies due to ali­asing. Furthermore, the option is
prob­ably use­ful for all TCP’s, since it sim­pli­fies the sender.

Conclusion

So from my read­ing, by for­cing a RTT into every packet instead one packet per TCP Window we will improve the per­form­ance of the TCP con­ges­tion algorithm. This works best on high per­form­ance links (that is, high speed and low latency) because the TCP Window get (rel­at­ively) very large, thus the RTT meas­ure­ment could eas­ily not be accur­ately peaky con­di­tions on the circuit.

This would only apply to pack­ets ori­gin­ated from the router con­trol plane and not apply to pack­ets from external devices (aka serv­ers and work­sta­tions) so would only be use­ful for spe­cific applic­a­tions in the real world.

So I can think of the fol­low­ing cases when this would be useful:

• tun­nel inter­faces on gig­abit services
• using a router as packet gen­er­ator
• BGP peer­ing — large num­ber of routes to exchange, this option might improve the con­nec­tion estab­lish­ment time
• SSL VPN’s — might be able to improve applic­a­tion response in a high speed enter­prise network

If you can think of any oth­ers, please let me know in the comments.

Please rate this post:

(No Ratings Yet)

 Loading ...