1. TCP - Part I
Relates to Lab 5. First module on TCP which covers packet format, data transfer, and connection management.

2. Overview TCP = Transmission Control Protocol
Connection-oriented protocol
Provides a reliable unicast end-to-end byte stream over an unreliable internetwork.

3. Connection-Oriented
Before any data transfer, TCP establishes a connection:
One TCP entity is waiting for a connection (“server”)
The other TCP entity (“client”) contacts the server
The actual procedure for setting up connections is more complex.
Each connection is full duplex

4. Reliable Byte Stream Service: Detecting errors:
The received byte stream from the application is broken up into chunks which are called segments
Receiver sends acknowledgements (ACKs) for segments received correctly
TCP maintains a timer. If an ACK is not received in time, the segment is retransmitted
Detecting errors:
TCP uses a checksum to detect errors. Segments with invalid checksums are discarded
Each byte that is transmitted has a sequence number

5. Byte Stream Service
To the lower layers, TCP handles data in blocks - segments
To the higher layers TCP handles data as a sequence of bytes and does not identify boundaries between bytes
So: Higher layers do not know about the beginning and end of segments!

6. TCP Packet Format
TCP segments have a byte header with >= 0 bytes of application data

7. TCP header fields Port Number:
A port number identifies the endpoint of a connection.
A pair <IP address, port number> identifies one endpoint of a connection.
Two pairs <client IP address, client port number> and <server IP address, server port number> identify a TCP connection.

8. TCP header fields Sequence Number (SeqNo):
Sequence number is 32 bits long.
So the range of SeqNo is
0 <= SeqNo <=  4.3 Gbyte
A sequence number identifies a specific byte in the byte stream. Each byte has a sequence number
An Initial Sequence Number (ISN) for a connection is picked at random at each end and is set during connection establishment

9. TCP header fields Acknowledgement Number (AckNo):
Acknowledgements can be piggybacked
a segment from A -> B can contain an acknowledgement for data sent in the B -> A direction
A hosts uses the AckNo field to send acknowledgements
if a host sends an AckNo in a segment it sets the “ACK flag”
The AckNo contains the next SeqNo that a receiving host is expecting to receive from the sender. Eg:
The acknowledgement for a segment with sequence number “0” and data length of 1500 bytes is AckNo = 1500 ( = 1500 bytes)
The next segment sent from sender should have a SeqNo = 1500.

10. TCP header fields Data Offset, i.e., Header Length (4bits):
Length of header in 32-bit words
Note that TCP header is variable length
minimum 20bytes = 5words
maximum of 60bytes (due to the 40byte options field)
Reserved (3bits):
Bits left open for future use. Set to ZERO

11. TCP header fields Flag bits cont:
URG (1 bit) – indicates that the Urgent pointer field is significant and the following bytes contain an urgent message in the range:
SeqNo = 1st byte of urgent message
1st byte of Normal data starts at = SeqNo+urgent pointer
ACK (1 bit) – indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.
PSH (1 bit) – Push function. Sender asks receiver to push the buffered data to the receiving application. Normally set by sender when the sender’s buffer is empty.
RST (1 bit) – Sender tells receiver to reset the connection. Receiver of a RST terminates the connection and indicates higher layer application about the reset.

12. TCP header fields Flag bits cont:
SYN (1 bit) – Synchronize sequence numbers. Only the first packet sent from each end should have this flag set (during connection set up).
Some other flags and fields change meaning based on this flag -> some are only valid for when it is set, and others when it is clear.
FIN (1 bit) – Last package from sender. Sender is done with transmitting
Used for closing a connection
Both sides of a connection must send a FIN
One side can be done before the other

13. TCP header fields Window Size:
flow control from a receiver limiting transmissions from a sender – “controlling flow of data being sent from S -> R by R”
Each side of the connection advertises a receive window size in bytes
Maximum window size can be 216-1= bytes
The size of the receive window, specifies the number of bytes (beyond the segment identified by the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive
Urgent Pointer:
Only valid if URG flag is set

14. TCP header fields TCP Checksum:
TCP checksum covers both TCP Pseudo header and TCP header and data. Pseudo header consists of:
IP Source address
IP Destination address
Protocol Type: TCP in this case
TCP length – header and data

15. TCP header fields Options: The “len” field indicates length in
bytes of the option (>1byte):
kind+length+data
e.g = 4

16. MTU and MSS:
The Maximum Transmission Unit (MTU) is the maximum length of data that can be transmitted by a protocol in one instance. If we take the Ethernet interface as an example, the MTU size of an Ethernet interface is 1500 bytes by default, which excludes the Ethernet frame header and trailer. It means that the interface cannot carry any frame larger then 1500 bytes. If we look inside the frame, we have a 20 byte IP header + 20 byte TCP header, leaving a 1460 byte of the payload that can be transmitted in one frame. This is what we refer to as TCP MSS. The diagram below visualizes this concept:
IP Header
TCP Header
Payload
FCFS
Ethernet Header
MTU (on Cisco router referred to as IP MTU)
TCP MSS
14 bytes
20-40 bytes
4 bytes

17. Path Discovery Protocol
Used for determining the maximum transmission unit (MTU) size on the network path between two Internet Protocol (IP) hosts, usually with the goal of avoiding IP fragmentation
Path MTU Discovery works by setting the Don't Fragment (DF) flag bit in the IP headers of outgoing packets
Any device along the path whose MTU is smaller than the size of IP datagram will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4) message containing its MTU
This will result in the source host reducing its Path MTU appropriately.
The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.
Recall traceroute and ICMP error for TTL, similar operation.

18. Connection Management in TCP
Opening a TCP Connection
Closing a TCP Connection
Special Scenarios
State Diagram

19. TCP Connection Establishment
TCP uses a three-way handshake to open a connection:
(1) ACTIVE OPEN: Client sends a segment with
SYN bit set
port number of client
initial sequence number (ISN) of client – e.g. x
(2) PASSIVE OPEN: Server responds with a segment with
initial sequence number of server, e.g. y
ACK for ISN of client: x+1
(3) Client acknowledges by sending a segment with:
SeqNo = x+1
ACK ISN of server: y+1

20. Three-Way Handshake

21. Three-Way Handshake – actual example
: (0)

22. A TCP SYN Packet

23. A TCP SYN, ACK Packet

24. A TCP ACK Packet (last in 3 way handshake

25. A TCP Data Packet

26. Using Wireshark to Illustrate flow
To better understand how sequence and acknowledgement numbers are used throughout the duration of a TCP session, we can utilize Wireshark's built-in flow graphing ability. Navigate to Statistics > Flow Graph..., select TCP flow and click OK. Wireshark automatically builds a graphical summary of the TCP flow.
Each row represents a single TCP packet. The left column indicates the direction of the packet, TCP ports, segment length, and the flag(s) set. The column at right lists the relative sequence and acknowledgement numbers in decimal. Selecting a row in this column also highlights the corresponding packet in the main window. We can use this flow graph to better understand how sequence and acknowledgement numbers work.

27. Figure Illustrating Wireshark output

28. Packet Flow explanation
Packet #1: Each side of a TCP session starts out with a (relative) sequence number of zero. Likewise, the acknowledgement number is also zero, as there is not yet a complementary side of the conversation to acknowledge. (Note: The version of Wireshark used for this demonstration, 1.2.7, shows the acknowledgement number as an apparently random number. This believed to be a software bug; the initial acknowledgement number of a session should always be zero, as you can see from inspecting the hex dump of the packet.)
Packet #2: The server responds to the client with a sequence number of zero, as this is its first packet in this TCP session, and a relative acknowledgement number of 1. The acknowledgement number is set to 1 to indicate the receipt of the client's SYN flag in packet #1. Notice that the acknowledgement number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence. (This does not interfere with the accounting of payload data, because packets with the SYN or FIN flag set do not carry a payload.)

29. Packet #3: Like in packet #2, the client responds to the server's sequence number of zero with an acknowledgement number of 1. The client includes its own sequence number of 1 (incremented from zero because of the SYN). At this point, the sequence number for both hosts is 1. This initial increment of 1 on both hosts' sequence numbers occurs during the establishment of all TCP sessions.
Packet #4: This is the first packet in the stream which carries an actual payload (specifically, the client's HTTP request). The sequence number is left at 1, since no data has been transmitted since the last packet in this stream (NOTE: the last ACK packet in 3Way handshake (packet #3) has no SYN flag set). The acknowledgement number is also left at 1, since no data has been received from the server, either. Note that this packet's payload is 725 bytes in length.

30. Packet #5: This packet is sent by the server solely to acknowledge the data sent by the client in packet #4 while upper layers process the HTTP request. Notice that the acknowledgement number has increased by 725 (the length of the payload in packet #4) to 726; e.g., "I have received 725 bytes so far and am waiting for byte 726." The server's sequence number remains at 1.
Packet #6: This packet marks the beginning of the server's HTTP response. Its sequence number is still 1, since none of its packets prior to this one have carried a payload. This packet carries a payload of 1448 bytes.

31. Packet #7: The sequence number of the client has been increased to 726 because of the last packet it sent. Having received 1448 bytes of data from the server, the client increases its acknowledgement number from 1 to 1449.For the majority of the capture, we will see this cycle repeat. The client's sequence number will remain steady at 726, because it has no data to transmit beyond the initial 725 byte request. The server's sequence number, in contrast, continues to grow as it sends more segments of the HTTP response.

32. Why is a Two-Way Handshake not enough?
Timeout,
aida
resends
SYN request
The red line is a delayedSYN packet
Ack
New SYN will be discarded as a duplicate SYN as connection at mng is expecting an ACK from aida in response to its SYN not another SYN
SYN, ACK
response to first
delayed SYN received
: (0)
Ack

33. TCP Connection Termination
Each end of the data flow must be shut down independently (“half-close”)
If one end is done it sends a FIN segment. This means that no more data will be sent
Four steps involved:
(1) X sends a FIN to Y (active close)
(2) Y ACKs the FIN,
(at this time: Y can still send data to X)
(3) and Y sends a FIN to X (passive close)
(4) X ACKs the FIN.

34. TCP Connection Termination

35. TCP States in “Normal” Connection Lifetime

36. TCP States

37. TIME_WAIT state TIME_WAIT = 2MSL
When TCP does an active close, and sends the final ACK, the connection must stay in the TIME_WAIT state for twice the maximum segment lifetime.
2MSL= 2 * Maximum Segment Lifetime (roundtrip delay)
Why? TCP is given a chance to resend the final ACK. (Server will timeout after sending the first FIN segment and resend the FIN)

38. Resetting Connections
Resetting connections is done by setting the RST flag
When is the RST flag set?
Connection request arrives and no server process is waiting on the destination port
Abort (Terminate) a connection Causes the receiver to throw away buffered data. Receiver does not acknowledge the RST segment