1. CS332, Ch. 26: TCP Victor Norman Calvin College 1

2. What are the important characteristics of TCP? Connection-oriented Point-to-point Full duplex Reliable Uses ports to identify applications using TCP. 2

3. What does TCP assume it gets from the layer below? Connection-less Point-to-point Simplex Unreliable delivery 3

4. What does connection-oriented mean? End points must communicate first and set up the virtual connection. No data is sent until that’s finished. End points must gracefully tear down the connection. 4

5. What does a Virtual Connection mean? The endpoints set up and maintain all the state of the “connection” – the middle devices (routers, NATs, etc.) know nothing about it. As opposed to a circuit through a network in which all devices must participate. 5

6. What does point-to-point mean? One application talks to one application – one port to one port 6

7. What does full duplex mean? Both applications on the endpoints can transmit at the same time. 7

8. What does reliable delivery mean? Gets the data there – quickly – correctly (without errors) – in order – completely 8

9. What kinds of problems does TCP have to be able to handle? Very unreliable delivery from IP. – Duplicate packets. – Packets out of order. – Errors in packets. Differing speeds of end points. End point reboot. Delay from when network changes radically. 9

10. How does TCP handle all this? Unreliable delivery from IP?: – checksum the data (eliminate bad data) – keep track of which bytes have been sent and which have been received, and resend missing bytes – “acknowledgement and retransmission” 10

11. How does TCP handle all this? (part 2) Different speeds of end points?: – (Two problems: how much data an end point can handle at once, and how long it takes to handle it.) – End points constantly communicate how much more data they can still handle at that time (called “window advertisement”). – This is “flow control”. 11

12. How does TCP handle all this? (part 3) End point reboot? (Or application on an endpoint restarts.) – Every connection is given a unique identifier and packets with that id are only accepted. 12

13. How does TCP handle all this? (part 4) Delay from network changes radically: consider this: – end points want to get data through as fast as possible (in general). – Usually end points want data to flow consistently, not bursty. – When network “goes down” for a bit, the more data that is “in transit”, the more has to be retransmitted. – This problem is very complex. Called “congestion control”. 13

14. Collapsing ACKs Q: Couldn’t TCP be more efficient by sending one ack after receiving multiple packets? A: Yes, but how long does the end point wait before deciding to ACK what it has and not wait for any more? And, the longer it waits the lower the bandwidth utilization of the network… 14

15. How unreliable is UDP? Q: TCP is reliable, but in comparison how much of a problem is the unreliability of UDP? A: Hard to say… Anecdotally, a student a few years ago implemented a protocol in UDP and could not get it to work fast enough because he had to write so much logic into the protocol to make it pseudo-reliable. He kept losing packets when sending them over a long-haul… 15

16. Idle Connections? Q: What about idle connections? Are no packets sent? If the connection goes idle does it get shut down? A: If there is no data to send, the connection stays alive but no packets are sent. You can turn on TCP keep-alives via a socket API. This causes the client to periodically send an empty data packet that is ACKed. It is useful just for checking if the peer is still up and running. 16

17. Packets/Segments/Windows Q: What happens if a single packet in a window gets lost? Do we have to transmit the whole window that packet was in, or just the packet? A: A window is a just a number of bytes the receiver is able/prepared to receive. It is not a number of packets/segments. If some # of bytes (sent in a segment) is lost, the sender will retransmit. 17

18. Congestion Collapse Q: What is congestion collapse? A: Congestion collapse is when congestion happens in a bottleneck in the network (usually a router), and the router discards packets. When the endpoints detect it, they retransmit, which only makes more traffic at the bottleneck, which causes more dropped packets and more retransmits. … 18

19. Flow control vs. Congestion Control Flow control via a sliding window allows multiple packets (“segments”) to be sent before any ACK is received. This increases bandwidth utilization (i.e., “speed”). Congestion control reduces the amount of traffic being sent to avoid congestion collapse. Both are done by manipulating the window size on a TCP connection. 19

20. Congestion Detection Congestion is detected by… – increased round-trip time (data  ack). – timeouts. The reaction is to reduce the window size and increase the per-packet timeout value. 20

21. Host Settings Q: Is there something that hosts implementing TCP could do to minimize congestion and avoid having TCP control it or is it better to have TCP adjust window sizes and handle it that way? A: You can reduce congestion and increase the number of clients that can connect, and improve security by having a server advertise a very small window size when a connection is established. 21

22. SYN and FIN Q: How are SYN and FIN exactly sent and how do they look like? More specifically, how will the TCP header differ for a SYN and FIN from for example a regular packet being sent? Is that determined in the options field of the TCP header? A: A TCP header has flag fields, including SYN, ACK, and FIN flags. 22

23. Piggybacking Note that when data is flowing both directions, and packet containing TCP data in one direction can also carry the ACK for data flowing in the opposite direction. A SYNACK packet (in the 3-way handshake) is similar – it ACKs the first SYN packet and indicates a SYN in the opposite direction. The response is to send an ACK packet (which I think could carry data). 23

24. Lost teardown ACK Q: What would happen if the final ACK of a connection closing 3-way handshake is lost? A: The connection would remain in “half-closed” state, I think. Similar to SYN flood DDoS attack, where a bad guy floods a server with SYN packets, but never ACKs them. The server allocates resources (socket port) on SYN, and holds them for a while if not ACKed. The connections are in “Half-opened” state. 24