Introduc)on to Transport Protocols

Transcription

1 Introduc)on to Transport Protocols 1

2 Mul)plexing Network layer: IP address Ø ID of a computer in the network Transport layer: Port number Ø Iden)fy the applica)on that will receive the incoming data Ø Mul)plexing service Port classifica)on Ø Very-well known ports: Ø Registered ports: Ø Ephemeral ports Ø See /etc/services in Linux

3 Flow ID A flow is iden)fied by Ø The source IP address Ø The des)na)on IP address Ø Source port number Ø Des)na)on port number Ø Transport protocol ID UDP = User Datagram Protocol TCP = Transport Control Protocol

4 UDP vs TCP UDP Connec)onless protocol Unreliable Ø Data integrity (op)onal) Message oriented protocol Protocol number = TCP Connec)on-oriented protocol Ø Connec)on management Reliable Ø Flow control Ø Error correc)on Ø In-order delivery Ø Data Integrity Stream-based Conges)on control Protocol number = 6

5 UDP vs TCP Source Port Des)na)on Port Source Port Des)na)on Port Sequence Number Acknowledgement Number Flags Window Source: TCP/IP Reference. h]ps://nmap.org/book/tcpip-ref.html 5

6 Some TCP fields Sequence number Ø The ID of the first byte available in the payload Ø Generated at random by both the sender and the receiver Acknowledgement number Ø The ID of the next requested byte Window Ø Available free buffer how many bytes more can be sent before overloading the receiver TCP flags C,E,U,A,P,R,S,F Ø SYN (S): indicates a connec)on establishment Ø ACK (A): indicates an acknowledgement packet Ø FIN (F): connec)on closing 6

7 Data Integrity with Checksums IPv4 32 Source Address 64 Des)na)on Address 96 Zeros Protocol UDP/TCP Length UDP/TCP packet Header + Payload Pseudo Header 7

8 The checksum Algorithm Divide the packet in groups of 2 bytes Ø Pseudo header + TCP or UDP packet Ø [A,B] = A*256+B Ø If the number of octets is odd, then add a zero [Z,0] Ø Make the checksum field of the packet to be 0 Compute the one s complement Insert the result in the checksum field of the packet 8

9 Checking a packet Adjacent octets are paired Ø Remember: pseudo-header + TCP or UDP packet Sum the octets. Ø Leave the checksum field as is If the result == FFFF (-0 in one s complement) Ø Then, accept the packet Ø Otherwise, the packet must be dropped

10 Proper)es of one s complement Commuta)ve and Associa)ve Ø ( [A,B] +' [C,D] +'... +' [J,0] ) +' ( [0,K] +'... +' [Y,Z] ) Byte order independence Ø [A,B] +' [C,D] = [X,Y] Ø [B,A] +' [D,C] = [Y,X] Parallel summa)on

11 Numerical examples Normal order Swapped order 0001 f203 f4f5 f6f7 (0000) 2ddf0 ddf0 2 ddf2 ~ddf2 = 220d ~f2dd = 0d f2 f5f4 f7f6 (0000) 1f2dc f2dc 1 f2dd

12 Numerical examples Byte by byte Word by word (31bits words) f2 03 f4 f5 f6 f7 (00 00) 2dc 1f0 dc f0 1 2 dd f2 ~ddf2 = 220d 0001f203 f4f5f6f7 f4f7e8fa f4f7 e8fa 1ddf1 ddf1 1 ddf2

13 Checking a packet 0001 f203 f4f5 f6f7 (220d) 2fffd fffd 2 ffff

14 Introduc)on to TCP 14

15 Reliability in TCP Each TCP packet must carry at much MSS bytes as payload Ø l tcp = l tcph + l payload Ø 0 <= l payload <= MSS Each TCP packet provides the ID of the first sent byte in the Sequence Number field Ø The sequence number of the ith TCP packet sn(i) = sn(i-1) + l payload,i-1 Each TCP packet must be acknowledged (the ACK packet) Ø The acknowledgement sequence number correspond to the ID of the next expected byte 15

16 Connec)on setup and release Host1 Host2 Host1 Host2 SYN (SEQ = X) SYN ACK (SEQ = Y, ACK = X+1) Applica)on Layer ends FIN (SEQ = 1, ACK = 2) ACK (SEQ = X+1, ACK=Y+1) Data exchange can now happen at the Applica)on Layer ACK (SEQ = 2, ACK = 1+1) FIN (SEQ = 2, ACK = 1+1) ACK (SEQ = 1+1, ACK= 2+1) 16

17 Data and ACK TCP packets Host1 Host2 Host1 Host2 DATA (SEQ = X, Lp=512,ACK=Y) DATA (SEQ = X, Lp = 512,ACK=Y) ACK (SEQ = Y, ACK = X+512) ACK (SEQ=Y,ACK = X+512) DATA (SEQ=Y,Lp=256,ACK=X+512) ACK (SEQ=X+512,ACK=Y+256) 17

18 The TCP flow control TCP might not read the data as soon as it arrives Ø I don t drink my glass right now, I m watching the TV Avoid overloading the buffer receiver with data that cannot be stored any more Ø Ø How: Ø Data losses are bad for applica)ons No more water, the glass is full Say how much data can be s)ll received before gezng full Where to say that: Ø The window field of the TCP header 18

19 The TCP flow control The TCP receiver maintains a buffer, where write the received data while the computer is doing something else For each received Data packet Ø window = RBuff (lastbyterec lastbyteread) Ø window will be sent in the next ACK At the sender, for each received ACK Ø If window == 0; then stop and wait for the next ACK with a higher window Ø Otherwise, es)mate the number of in-flight bytes in-alight = lastbytesent - lastbyteacked Ø send more data L payload = min(mss, (window in-alight)) 19

20 Flow Control Example Host1 Buffer emission inf DATA (SEQ=1, Lp = 1024) ACK (ACK = 1025, WIN=1024) DATA (SEQ=1025, Lp = 1024) Host2 Buffer recep)on 2KB The sender freezes send KeepAlive The sender restart the transmission ACK (ACK = 2049, WIN=0) ACK (SEQ=SEQ+Lp-1) ACK (ACK = 2049, WIN=1024) The App Layer read 1KB 20

21 Basics On The Transport Layer Performance 21

22 Efficiency Host1 Host2 Tt = L/R RTT Round Trip Time Idle link Tt = Transmission )me L = Packet length R = Link rate 22

23 Efficiency Host1 Host2 Idle = RTT Tt * Psent Idle = RTT - (L / R * Psent) RTT (L / R * Psent) = 0 Psent = RTT * R / L R = L * Psent / RTT cwnd = Psent R = L * cwnd / RTT RTT Idle link 23

24 Impact of payload The sender s instantaneous throughput is equal to the number of data sent divided by the RT T Ø R = L * cwnd / RTT Ø L = (TCPh + Lpayload); 0 <= Lpayload <= MSS A few bytes in payload per packet = was)ng resources sending TCP headers Problem: how to avoid bandwidth was)ng? Ø Delay ACK Send ACK every two received DATA packets or a~er maxdelayack (= 500ms RFC1122, 40ms Linux) Ø Buffer data to create bigger packets look for Nagle s algorithm for more informa)on 24

25 The TCP Conges)on Control 25

26 Network conges)on Or what is the best rate to send water without losing it? 26

27 Conges)on Control: the key success of Internet The conges)on control is the key factor behind the success of internet Ø Stability Ø Scalability TCP provides conges)on control, not UDP Ø UDP applica)ons needing to provide conges)on control at the applica)on level Ø With TCP you just care to send data, the rest is done by the TCP/IP stack 27

28 Network Conges)on A B Propagation Figure 1.16 Nodal processing Queueing Transmission (waiting for transmission) The nodal delay at router A 28

29 Slow Start cwnd Host1 DATA ACK Host2 Psent = cwnd = conges)on window Ø Ø Number of sent packets without wai)ng for ACKs Number of sent packets per RTT slow-start: cwnd doubles per RTT Ø Ø Exponen)al growing Hypothesis: we did not experience packet losses so far, quickly increase the rate Exit slow-start when reaching a threshold (ssthresh) cwnd = 1 for each received ACK If cwnd < ssthresh cwnd = cwnd + 1 Else exit slow-start 29

30 Conges)on Avoidance Conges)on Avoidance Ø Linear growing of cwnd Ø Hypothesis is: we are close to the network capacity, so increase the sending rate slowly if cwnd >= ssthresh Ø cwnd = cwnd + 1 / cwnd cwnd Host1 ACK DATA Host2 30

31 Conges)on window evolu)on Link capacity ssthresh cwnd Packet Losses might occur! RTT

32 Retransmission of lost packets: Fast Retransmit Host1 Host2 #Seqs X Ack = 2 Ack = 3 Ack = 3 (dupack) Ack = 3 (dupack) Ack = 3 (dupack) Buff 1 (read) 2 (read) 4 4,5 4,5,6 3 Ack =??? 3,4,5,6 (read) 32

33 Retransmission of lost packets: Timeout Host1 Host2 RTT #Seqs X Ack = 2 Ack = 2 (dupack) Ack = 2 (dupack) Retransmission Timeout RTO 3 33

34 Sliding (conges)on) Window Sent Ack ed Sent Not Ack ed yet cwnd Not Sent yet Ready to be sent cwnd Not ready for transmission cwnd 34

35 TCP versions Several strategies to test the bandwidth capacity and react to loss retransmissions have been proposes Ø TCP Tahoe, TCP Reno, TCP New Reno, Compound TCP,CUBIC TCP, DCTCP, LEDBAT, TCP New Reno has been one of the most deployed TCP version Linux Ø CUBIC TCP Windows - source h]ps:// technet.microso~.com/en-us/library/ hh aspx Ø Ø Ø Compound TCP can be enabled Data Center TCP (DCTCP) default in server versions TCP New Reno default in clients TCP New Reno in few steps if cwnd <= ssthresh; then execute slow-start else execute congestion avoidance In case of losses: if Fast Retransmit; then // execute fast recovery cwnd = cwnd / 2 ssthresh = cwnd else ssthresh = cwnd / 2 cwnd = 1 35

36 Expected New Reno behavior Fast Recovery Addi)ve Increase ssthresh inf cwnd Timeout Fast Retransmit RTT Mul)plica)ve Decrease 36

37 Expected New Reno behavior: 2 flows, same RTT 12 cwnd RTT 37

38 Fairness Same RTT Connec)on 2 - Throughput Connec)on 1 - Throughput 38

39 39

40 cwnd 40