iLab TCP / UDP Minoo Rouhi rouhi@net.in.tum.de Slides by Florian Wohlfart wohlfart@in.tum.de Chair of Network Architectures and Services Department of Informatics Technical University of Munich Lab 4 – 17ws 1 / 43
Outline Meta Transport Layer UDP TCP Other Transport Layer Protocols 2 / 43
Oral attestations Scope of the oral attestations: ◮ expert knowledge of the lecture content ◮ show us your individual understanding of the labs ◮ labs and lectures 1–5 (including crypto) ◮ you may choose the lab to start with ◮ prepare for oral attestation : you have to explain things ◮ duration 10 minutes ◮ 20% of grade ◮ room 03.05.051 3 / 43
Attestation slots How to get an attestation slot: ◮ choose in Moodle else we’ll choose for you ◮ open today from 20:00 until Monday, 20. Nov., 12:00 ◮ 2017-12-18 Mon ◮ 2017-12-19 Tue ◮ 2017-12-20 Wed ◮ 2017-12-21 Thu 4 / 43
Sample questions ◮ Explain the tasks of the ISO/OSI layers ◮ What are the most important properties/header fields of IP ◮ What are ICMP messages used for and give an example ◮ What is the Count to Infinity Problem ◮ What is an Autonomous System ◮ Why do we have policies in BGP ◮ Explain the 3 way handshake of TCP ◮ What kinds of windows do we have in TCP and what for ◮ How does Fast Recovery work ◮ Name and explain some DNS records ◮ How does DNSSEC work 5 / 43
Irregular lecture slot ◮ 2017-11-21 Tue at 14:00 (00.13.009A, Seminarraum) 6 / 43
Outline Meta Transport Layer UDP TCP Other Transport Layer Protocols 7 / 43
Outline Meta Transport Layer UDP TCP Other Transport Layer Protocols 8 / 43
Transport Layer application protocol app 2 app 2 application protocol app 1 app 1 app 1 app 1 transport protocol TCP/UDP TCP/UDP router IP protocol IP protocol IP IP IP Ethernet WLAN Ethernet Ethernet WLAN WLAN driver protocol driver driver protocol driver wireless LAN Ethernet 9 / 43
Ports ◮ purpose: transport layer multiplexing / demultiplexing ◮ 16bit number (0..65535) ◮ adress applications on a host Client/Server communication ◮ client-side: usually random choice from [1024..65535] ◮ server-side: well known port numbers Well-known port numbers ◮ HTTP/HTTPS: TCP port 80/443 ◮ SSH: TCP port 22 ◮ DNS: UDP and TCP port 53 see: http://www.iana.org/assignments/port-numbers 10 / 43
Sockets application layer API to networking functionality usually offered by the OS network stack Message Orientation sender receiver send(“Hi Bob!”) recv() -> “Hi Bob!” send(“How are you?”) recv() -> “How are you?” Stream Orientation receiver (possible outcome) sender send(“Hi Bob!”) recv() -> “” send(“How are you?”) recv() -> “Hi Bob!How are you?” 11 / 43
Transport Protocol Implementations User Datagram Protocol (UDP) ◮ unreliable ◮ lightweight Transmission Control Protocol (TCP) ◮ reliable ◮ connection oriented ◮ sending-rate limitation Other ◮ Stream Control Transmission Protocol (SCTP) ◮ Multipath TCP (MTCP) ◮ Quick UDP Internet Connections (QUIC) 12 / 43
Outline Meta Transport Layer UDP TCP Other Transport Layer Protocols 13 / 43
User Datagram Protocol (UDP) 0 15 16 31 source port destination port length checksum Functions ◮ port multiplexing / demultiplexing ◮ error checking Example Applications ◮ DNS (port 53) ◮ RIP (port 520) ◮ media streaming / realtime communication 14 / 43
User Datagram Protocol (UDP) 0 15 16 31 source port destination port length checksum Functions ◮ port multiplexing / demultiplexing ◮ error checking Example Applications ◮ DNS (port 53) ◮ RIP (port 520) ◮ media streaming / realtime communication Why is UDP used for these applications? 14 / 43
UDP Summary Characteristics ◮ simple and lightweight ◮ unreliable ◮ message-oriented ◮ stateless ◮ good choice for time-critical applications ◮ supports unidirectional communication Problems ◮ unlimited sending rate may overload the network/receiver 15 / 43
Outline Meta Transport Layer UDP TCP Other Transport Layer Protocols 16 / 43
Transmission Control Protocol (TCP) Functions ◮ port multiplexing / demultiplexing ◮ error checking ◮ reliable and ordered delivery ◮ stream-orientation ◮ control of sending-rate (avoid overloading the network or the receiver) Applications ◮ most reliable protocols: HTTP(S), SMTP, etc. 17 / 43
Background: Reliable Data Transfer How does the sender know whether a packet was successfully transferred? ◮ requires feedback from the receiver ◮ requires identification of packets Sender Receiver segment X segment Y ACK segment X ACK segment Y 18 / 43
Reliable Data Transfer in TCP sequence number ◮ indicates the first data byte of a segment ◮ increased with every byte of payload sent ◮ initial SN is exchanged during connection establishment Sender Receiver SEQ=5035 SEQ=6059 SEQ=12 ACK=6059 SEQ=12 ACK=7083 19 / 43
Reliable Data Transfer in TCP sequence number ◮ indicates the first data byte of a segment ◮ increased with every byte of payload sent ◮ initial SN is exchanged during connection establishment Sender Receiver SEQ=5035 SEQ=6059 SEQ=12 ACK=6059 SEQ=12 ACK=7083 19 / 43 What is the size of the segments?
Reliable Data Transfer in TCP (contd.) acknowledgement number ◮ gives the next sequence number that the receiver is expecting ◮ also acknowledges all smaller sequence numbers Sender Receiver SEQ=5035 SEQ=6059 SEQ=12 ACK=6059 SEQ=12 ACK=7083 20 / 43
Retransmission after Timeout ◮ timeout at the sender triggers retransmission Sender Receiver SEQ=1 SEQ=2 timeout ACK=2 SEQ=2 21 / 43
Fast Retransmit ◮ sender retansmits segment after receiving three duplicate ACKs Sender Receiver S E Q = 1 SEQ=2 2 = K C S A E Q = 3 S E Q = 4 2 = K C S A E Q = 5 = 2 K C A 2 = K C A 3 duplicate SEQ=2 ACKs 22 / 43
Connection Establishment 3-way-handshake ◮ establish initial sequence numbers and window sizes out-of-band TCP injection: http://arxiv.org/abs/1602.07128 ◮ negotiate options Client Server [ S Y N ] S E Q = 7 8 = K C A 3 1 = Q E S K ] C A , N Y S [ [ A C K ] S E Q = 8 A C K = 1 4 23 / 43
Connection Establishment 3-way-handshake ◮ establish initial sequence numbers and window sizes out-of-band TCP injection: http://arxiv.org/abs/1602.07128 ◮ negotiate options ◮ vulnerable to SYN-flood attacks → SYN cookies, TCPCT Client Server [ S Y N ] S E Q = 7 8 = K C A 3 1 = Q E S K ] C A , N Y S [ [ A C K ] S E Q = 8 A C K = 1 4 23 / 43
Connection Teardown 4-way-handshake ◮ each side needs to terminate the connection → half-open connections possible ◮ initiator waits for a timeout before closing the connection Initiator Receiver [ F I N ] ] K C A [ N ] F I [ [ A timeout C K ] 24 / 43
TCP header 0 3 4 6 7 15 16 31 source port destination port sequence number acknowledgement number U A P R S F hdr len resvd window size R C S S Y I G K H T N N urgent pointer checksum [options] ◮ up to 40 Bytes of header options e.g. Window Scale, Selective Acknowledgment (SACK) ◮ header length: 20 – 60 Bytes 25 / 43
Limiting the Sending-rate Why? ◮ avoid overloading the receiver → flow control ◮ avoid overloading the network → congestion control Sending Window ◮ specifies the amount of unacknowledged data that the sender is allowed to send ◮ is equal to the max. number of bytes in transit ◮ sending _ window = min ( receive _ window , cwnd ) 26 / 43
Flow Control Flow Control ◮ prohibits overloading the receiver ◮ receiver announces the current size of the receive _ window to the sender in the TCP header window size field ◮ limited by the buffer size at the receiver 27 / 43
Background: Network Congestion Jacobson, Van. "Congestion avoidance and control." ACM SIGCOMM Computer Communication Review, 1988. 28 / 43
Background: Network Congestion ◮ segments get lost due to full buffers in routers ◮ retransmissions may even amplify a congestion Jacobson, Van. "Congestion avoidance and control." ACM SIGCOMM Computer Communication Review, 1988. 28 / 43
Background: Network Congestion ◮ segments get lost due to full buffers in routers ◮ retransmissions may even amplify a congestion ◮ self-clocking creates an equilibrium at the max. sending-rate: Jacobson, Van. "Congestion avoidance and control." ACM SIGCOMM Computer Communication Review, 1988. 28 / 43
Congestion Control Principles ◮ basic assumption: packet loss is only caused by congestion ◮ end-host driven: no support from the network necessary Two phases ◮ Slow Start starts a connection: gradually increase the amount of data in-transit until reaching the equilibrium ◮ Congestion Avoidance tries to keep the equilibrium state and react to changes on the link State ◮ current size of the congestion window ( cwnd ) ◮ slow start threshold ( ssthresh ) defines transition between phases 29 / 43
Congestion Control: Slow Start Phase ◮ initialization: cwnd = 10 ∗ MSS , ssthresh cwnd [ MSS ] 80 60 40 20 0 0 1 2 3 4 5 time [ RTT ] 30 / 43
Recommend
More recommend
