1. Chapter 5 TCP Control Flow
Networking
CS 3470, Section 1

2. TCP Control Flow TCP connections include
3-way handshake to start connection
Transfer of data with ACKs
Connection tear-down
SequenceNum field contains the sequence number for the first byte of data carried in segment

3. TCP Connection Establishment
Both the client and server have to open a connection
Server must start first to be able to accept incoming connections
Performs a passive open
Client can then connect to the server
Performs an active open

4. TCP Connection Establishment
Both parties (client and server) must agree on the starting sequence numbers
Each side has its own set of sequence numbers that start at some random number
Sequence numbers are exchanged during the TCP three-way handshake algorithm, which establishes a TCP connection between two hosts

5. TCP Three-Way Handshake Algorithm
Acknowledgment field identifies the “next sequence number expected”, implicitly acknowledging all earlier sequence numbers

6. TCP State-Transition Diagram
Some arcs are not shown
Most of states that involve sending segments also schedule a timeout for the ACK response
If ACK not received, retransmit
If after several tries the ACK does not arrive, TCP gives up and returns to CLOSED state

8. TCP State-Transition Diagram
When closing connection
Connection in TIME_WAIT state cannot move to CLOSED until it has waited 120 seconds
Prevents delayed FINs from accidentally tearing down new connections

9. Introduction to Project 4
Model TCP state-transition diagram in your own program
Will help you make sense of network traffic for last project

10. Closing a Connection Reaching agreement: two approaches
Abort: send close msg to peer, delete state info
What if close() message lost?
Graceful: send close msg, but before deleting state
Wait for peer to acknowledge close()
Problem solved?
Can I decide to close, knowing that
Other entity also agreed to close and knows that I will close
Can two armies coordinate their attacks
If communication is unreliable?
For closing connection, we can just send a close message to the peer and delete the state on our side. But what if the close message is lost. The peer would not know the connection is closed.
So a graceful way is to send a close message and wait for ack. The peer would send an ack and delete its state. On receiving ack, we can also delete the state. What if ack is lost? The peer would have deleted the state and we wouldn’t have.
This problem is similar to the two-army problem discussed in textbook.

11. The Byzantine Generals’ Problem
Two generals are on the tops of two mountain.

12. The Byzantine Generals’ Problem
They communicate only through messengers (pigeon network?)…

13. The Byzantine Generals’ Problem
They need to coordinate the attack…

14. The Byzantine Generals’ Problem
If they attack at the same time, they win…

15. The Byzantine Generals’ Problem
If they attack at different times, they will die

16. The Byzantine Generals’ Problem
Question: can they guarantee a synchronized attack?

17. The Byzantine Generals’ Problem
11 am OK?

18. The Byzantine Generals’ Problem
Sounds good.

19. The Byzantine Generals’ Problem
I got your “Sounds good.”

20. The Byzantine Generals’ Problem
What if the last message is lost?
great!

21. The Byzantine Generals’ Problem
What if the last message is lost?
Does the other general know I got his “Sounds good” message?
great!

22. The Byzantine Generals’ Problem
Over an unreliable network, we cannot guarantee network synchronization
Rats.

23. The Byzantine Generals’ Problem
It can be proven that no protocol exists that works to solve this problem.
Three-way handshake will not work, so does not four-way handshake.
What do we do?

24. The Byzantine Generals’ Problem
It can be proven that no protocol exists that works to solve this problem.
Three-way handshake will not work, so does not four-way handshake.
What do we do?
Three- or four-way handshake is normally used to release connections
Then give up

25. Connection Release 6-14, a, b
DR: Disconnect request
Four protocol scenarios for releasing a connection. (a) Normal case of a three-way handshake. (b) final ACK lost.

26. Connection Release
6-14, c,d
(c) Response lost. (d) Response lost and subsequent DRs lost.