iLab TCP / UDP Minoo Rouhi rouhi@net.in.tum.de Slides by Florian - - PowerPoint PPT Presentation

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

wireless LAN app 1 app 2 TCP/UDP IP app 1 app 2 TCP/UDP IP Ethernet driver WLAN driver IP Ethernet driver WLAN driver

application protocol application protocol transport protocol IP protocol IP protocol Ethernet protocol WLAN protocol

app 1 app 1 Ethernet router

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

sender receiver (possible outcome) 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)

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)

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 What is the size of the segments?

19 / 43

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 ACK=2

timeout

SEQ=2

21 / 43

Fast Retransmit

◮ sender retansmits segment after receiving three duplicate ACKs

Sender Receiver S E Q = 1 SEQ=2 S E Q = 3 S E Q = 4 S E Q = 5 A C K = 2 A C K = 2 A C K = 2 A C K = 2 3 duplicate ACKs SEQ=2

22 / 43

Connection Establishment

3-way-handshake

◮ establish initial sequence numbers and window sizes

• ut-of-band TCP injection: http://arxiv.org/abs/1602.07128

◮ negotiate options

Client Server [ S Y N ] S E Q = 7 [ S Y N , A C K ] S E Q = 1 3 A C K = 8 [ 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

• ut-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 [ S Y N , A C K ] S E Q = 1 3 A C K = 8 [ 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 ] [ A C K ] [ F I N ] [ A C K ]

timeout

24 / 43

TCP header

3 4 6 7 15 16 31

source port destination port sequence number acknowledgement number hdr len resvd

U R G A C K P S H R S T S Y N F I N

window size checksum urgent pointer [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

• f 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

time[RTT] 1 2 3 4 5 cwnd[MSS] 20 40 60 80

30 / 43

Congestion Control: Slow Start Phase

◮ initialization: cwnd = 10 ∗ MSS, ssthresh ◮ when receiving an ACK: cwnd = cwnd + 1MSS

time[RTT] 1 2 3 4 5 cwnd[MSS] 20 40 60 80

30 / 43

Congestion Control: Slow Start Phase

◮ initialization: cwnd = 10 ∗ MSS, ssthresh ◮ when receiving an ACK: cwnd = cwnd + 1MSS

time[RTT] 1 2 3 4 5 cwnd[MSS] 20 40 60 80

30 / 43

Congestion Control: Slow Start Phase

◮ initialization: cwnd = 10 ∗ MSS, ssthresh ◮ when receiving an ACK: cwnd = cwnd + 1MSS

time[RTT] 1 2 3 4 5 cwnd[MSS] 20 40 60 80

30 / 43

Congestion Control: Slow Start Phase

◮ initialization: cwnd = 10 ∗ MSS, ssthresh ◮ when receiving an ACK: cwnd = cwnd + 1MSS

time[RTT] 1 2 3 4 5 cwnd[MSS] 20 40 60 80

30 / 43

Congestion Control: Slow Start Phase

◮ initialization: cwnd = 10 ∗ MSS, ssthresh ◮ when receiving an ACK: cwnd = cwnd + 1MSS

time[RTT] 1 2 3 4 5 cwnd[MSS] 20 40 60 80 ssthresh

30 / 43

Congestion Control: Congestion Avoidance Phase

◮ when receiving an ACK: increase cwnd using a cubic function

time[RTT] 1 2 3 4 5 cwnd[MSS] 80 100 120 140 160 ssthresh

31 / 43

Congestion Control: Congestion Avoidance Phase

◮ when receiving an ACK: increase cwnd using a cubic function

time[RTT] 1 2 3 4 5 cwnd[MSS] 80 100 120 140 160 ssthresh Wmax

31 / 43

Congestion Control: Congestion Avoidance Phase

◮ when receiving an ACK: increase cwnd using a cubic function

time[RTT] 1 2 3 4 5 cwnd[MSS] 80 100 120 140 160 ssthresh Wmax

31 / 43

Congestion Control: Congestion Avoidance Phase

◮ when receiving an ACK: increase cwnd using a cubic function ◮ slow growth around Wmax enhances stability

time[RTT] 1 2 3 4 5 cwnd[MSS] 80 100 120 140 160 ssthresh Wmax

31 / 43

Congestion Control: Congestion Avoidance Phase

◮ when receiving an ACK: increase cwnd using a cubic function ◮ fast growth away from Wmax increases bandwith utilization

time[RTT] 1 2 3 4 5 cwnd[MSS] 80 100 120 140 160 ssthresh Wmax

31 / 43

Congestion Control: Packet Loss

◮ timeout: assumption: the network is congested

→ go to slow start ssthresh = 0.8 ∗ last_cwnd cwnd = 10 ∗ MSS

◮ 3 duplicate ACKs: assumption: only a segment was lost

→ continue congestion avoidance ssthresh = 0.8 ∗ last_cwnd cwnd = ssthresh + 3MSS

32 / 43

TCP CUBIC

33 / 43

TCP CUBIC – Problems

◮ congestion indicated only by packet loss ◮ keeps the buffers full

Problems

◮ vulnerable to random packet loss ◮ high latency 34 / 43

TCP BBR

◮ Bottleneck-Bandwidth and RTT ◮ developed by Google, published late 2016 ◮ available since Linux 4.9 ◮ two congestion estimators

• estimated RTT
• estimated Bottleneck-Bandwidth

→ Bandwidth-Delay-Product (BDP)

35 / 43

TCP BBR vs. CUBIC

Neal Cardwell et. al. "BBR Congestion Control" IETF 97: Seoul. Nov 2016

36 / 43

TCP BBR vs. CUBIC

Neal Cardwell et. al. "BBR Congestion Control" IETF 97: Seoul. Nov 2016

37 / 43

TCP Options

Window Scaling

◮ default window size max. 65 KB (16bit field) ◮ example: 16MBit/s, 150ms RTT, bandwidth-delay product:

16MBit/s ∗ 0.15s = 2, 400Kbit = 300KB

◮ solution: window scaling allows to increase the window size up

to 4GB

◮ window scaling is negotiated during the TCP handshake ◮ problem remains: sequence numbers (32bit) still limit the

amount of unacknowledged data

Selective Acknowledgements (SACK)

◮ allow the receiver to acknowledge ranges of segments ◮ avoid unnecessary retransmissions compared to cumulative

ACKs

38 / 43

TCP Summary

Characteristics

◮ complex ◮ reliable → head-of-line blocking ◮ stream-oriented ◮ sending-rate adaption

Problems

◮ vulnerable to resource exploitation ◮ congestion control may be too restrictive, e.g. wireless networks 39 / 43

Outline

Meta Transport Layer UDP TCP Other Transport Layer Protocols

40 / 43

Stream Control Transmission Protocol (SCTP)

first standardized in 2000 by RFC 2690

◮ TCP/UDP hybrid: reliable, optional ordering, message-oriented ◮ permits reliable, unordered delivery ◮ other features: multihoming, 4-way-handshake, etc.

Problems:

◮ requires changes in application implementations ◮ lack of support in middleboxes (firewalls, NATs, etc.) 41 / 43

Multipath TCP (MPTCP)

◮ stardardized in 2013 by RFC 6824 ◮ can use multiple interfaces/links simultaneously ◮ goal: improve resource utilization, throughput and reliability ◮ mimics standard TCP, even offers a fallback mode 42 / 43

Quick UDP Internet Connections (QUIC)

◮ developed by Google, implemented in Chrome Browser,

released in 2013

◮ UDP-based protocol that implements reliability, congestion

control, multiple streams, encryption etc.

◮ goal: reduced latency (compared to TCP + TLS) ◮ mimics UDP (middlebox support) 43 / 43