The TCP Segment Header

Source port and Destination port

• The Source port and Destination port fields identify the local end
points of the connection.
• A TCP port plus its host’s IP address forms a 48-bit unique end point.
• The source and destination end points together identify the
connection.
• This connection identifier is called a 5 tuple because it consists of five
pieces of information: the protocol (TCP), source IP and source port,
and destination IP and destination port.
Sequence number and Acknowledgement
number
• The Sequence number and Acknowledgement number fields perform
their usual functions. Note that the latter specifies the next in-order
byte expected, not the last byte correctly received.
• It is a cumulative acknowledgement because it summarizes the
received data with a single number.
• It does not go beyond lost data. Both are 32 bits because every byte
of data is numbered in a TCP stream.
TCP header length
• The TCP header length tells how many 32-bit words are contained in
the TCP header.
• This information is needed because the Options field is of variable
length, so the header is, too.
• Technically, this field really indicates the start of the data within the
segment, measured in 32-bit words, but that number is just the
header length in words, so the effect is the same.
Blank Space
• A 4-bit field that is not used.
• The fact that these bits have remained unused for 30 years (as only 2
of the original reserved 6 bits have been reclaimed) is testimony to
how well thought out TCP is.
• Lesser protocols would have needed these bits to fix bugs in the
original design.
CWR and ECE
• CWR and ECE are used to signal congestion when ECN (Explicit
Congestion Notification) is used, as specified in RFC 3168.
• ECE is set to signal an ECN-Echo to a TCP sender to tell it to slow down
when the TCP receiver gets a congestion indication from the network.
• CWR is set to signal Congestion Window Reduced from the TCP
sender to the TCP receiver so that it knows the sender has slowed
down and can stop sending the ECN-Echo. We discuss the role of ECN
in TCP congestion control in Sec. 6.5.10.
URG
• URG is set to 1 if the Urgent pointer is in use.
• The Urgent pointer is used to indicate a byte offset from the current
sequence number at which urgent data are to be found.
• This facility is in lieu of interrupt messages. As we mentioned above,
this facility is a bare-bones way of allowing the sender to signal the
receiver without getting TCP itself involved in the reason for the
interrupt, but it is seldom used.
ACK
• The ACK bit is set to 1 to indicate that the Acknowledgement number
is valid.
• This is the case for nearly all packets.
• If ACK is 0, the segment does not contain an acknowledgement, so
the Acknowledgement number field is ignored.
PSH
• The PSH bit indicates PUSHed data.
• The receiver is hereby kindly requested to deliver the data to the
application upon arrival and not buffer it until a full buffer has been
received (which it might otherwise do for efficiency)
RST
• The RST bit is used to abruptly reset a connection that has become
confused due to a host crash or some other reason.
• It is also used to reject an invalid segment or refuse an attempt to
open a connection.
• In general, if you get a segment with the RST bit on, you have a
problem on your hands.
SYN
• The SYN bit is used to establish connections.
• The connection request has SYN = 1 and ACK = 0 to indicate that the
piggyback acknowledgement field is not in use.
• The connection reply does bear an acknowledgement, however, so it
has SYN = 1 and ACK = 1.
• In essence, the SYN bit is used to denote both CONNECTION REQUEST
and CONNECTION ACCEPTED, with the ACK bit used to distinguish
between those two possibilities
FIN
• The FIN bit is used to release a connection.
• It specifies that the sender has no more data to transmit.
• However, after closing a connection, the closing process may continue
to receive data indefinitely.
• Both SYN and FIN segments have sequence numbers and are thus
guaranteed to be processed in the correct order.
Window size
• The Window size field tells how many bytes may be sent starting at
the byte acknowledged.
• A Window size field of 0 is legal and says that the bytes up to and
including Acknowledgement number − 1 have been received, but that
the receiver has not had a chance to consume the data and would like
no more data for the moment, thank you. The receiver can later grant
permission to send by transmitting a segment with the same
Acknowledgement number and a nonzero Window size field.
Checksum
• A Checksum is also provided for extra reliability.
• It checksums the header, the data, and a conceptual pseudoheader in
exactly the same way as UDP, except that the pseudoheader has the
protocol number for TCP (6) and the checksum is mandatory
Options
• The Options field provides a way to add extra facilities not covered by
the regular header.
• Many options have been defined and several are commonly used.
• The options are of variable length, fill a multiple of 32 bits by using
padding with zeros, and may extend to 40 bytes to accommodate the
longest TCP header that can be specified.
• Some options are carried when a connection is established to
negotiate or inform the other side of capabilities. Other options are
carried on packets during the lifetime of the connection. Each option
has a Type-Length-Value encoding.
Options….
• A widely used option is the one that allows each host to specify the
MSS (Maximum Segment Size) it is willing to accept.
• Using large segments is more efficient than using small ones because
the 20-byte header can be amortized over more data, but small hosts
may not be able to handle big segments.
• During connection setup, each side can announce its maximum and
see its partner’s. If a host does not use this option, it defaults to a
536-byte payload. All Internet hosts are required to accept TCP
segments of 536 + 20 = 556 bytes. The maximum segment size in the
two directions need not be the same.
Options….
• For lines with high bandwidth, high delay, or both, the 64-KB window
corresponding to a 16-bit field is a problem. For example, on an OC-
12 line (of roughly 600 Mbps), it takes less than 1 msec to output a
full 64-KB window. If the round-trip propagation delay is 50 msec
(which is typical for a transcontinental fiber), the sender will be idle
more than 98% of the time waiting for acknowledgements. A larger
window size would allow the sender to keep pumping data out. The
window scale option allows the sender and receiver to negotiate a
window scale factor at the start of a connection. Both sides use the
scale factor to shift the Window size field up to 14 bits to the left,
thus allowing windows of up to 230 bytes. Most TCP implementations
support this option.
Options….
• The timestamp option carries a timestamp sent by the sender and
echoed by the receiver. It is included in every packet, once its use is
established during connection setup, and used to compute round-trip
time samples that are used to estimate when a packet has been lost.
It is also used as a logical extension of the 32- bit sequence number.
On a fast connection, the sequence number may wrap around quickly,
leading to possible confusion between old and new data. The PAWS
(Protection Against Wrapped Sequence numbers) scheme discards
arriving segments with old timestamps to prevent this problem.
Options….
• Finally, the SACK (Selective ACKnowledgement) option lets a receiver
tell a sender the ranges of sequence numbers that it has received. It
supplements the Acknowledgement number and is used after a
packet has been lost but subsequent (or duplicate) data has arrived.
The new data is not reflected by the Acknowledgement number field
in the header because that field gives only the next in-order byte that
is expected. With SACK, the sender is explicitly aware of what data
the receiver has and hence can determine what data should be
retransmitted. SACK is defined in RFC 2108 and RFC 2883 and is
increasingly used.