Computer Networks & Security 2016/2017

Size: px

Start display at page:

Download "Computer Networks & Security 2016/2017"

Brent Harmon
6 years ago
Views:

1 Computer Networks & Security 2016/2017 Transport Layer (04) Dr. Tanir Ozcelebi Courtesy: Kurose & Ross Courtesy: Forouzan TU/e Computer Science Security and Embedded Networked Systems

2 Transport Layer Our goals: Conceptual: understand principles behind transport layer services such as: process-to-process delivery reliable data transfer flow control congestion control Practical: learn about transport layer protocols in the Internet: UDP: connectionless transport TCP: connection-oriented transport Slide 2

3 Position of Transport Layer Slide 3

4 Transport Protocols Transport protocols run in end systems send side: breaks app messages into segments, passes to network layer multiplexing rcv side: reassembles segments into messages, passes to app layer demultiplexing application transport network data link physical Possible to have more than one transport protocol available to apps Internet: TCP and UDP application transport network data link physical Slide 4

5 Process-to-process addressing (Multiplexing / Demultiplexing) Multiplexing at send host: getting data from multiple sockets, enveloping data with headers (later used for demux) Demultiplexing at rcv host: delivering received segments to the correct socket = socket = process application P3 P1 P1 application P2 P4 application transport transport transport network network network link link link physical physical physical host 1 host 2 host 3 Slide 5

Socket/port addressing Port number needed to choose among multiple processes running on the host The Internet model: 16 bit integer 0 65 535 Client

6 Socket/port addressing Port number needed to choose among multiple processes running on the host The Internet model: 16 bit integer Client mostly chooses ephemeral (temporary) port numbers Server mostly uses well-known (permanent) port numbers ephemeral port number well-known port number Slide 6

7 e.g. TCP/UDP segment format 32 bits source port # dest port # other header fields application data (message) Slide 7

8 Socket/port addressing (cont d) IP addresses & port numbers are used to direct a segment to the appropriate socket at the receiving side. each datagram has source IP address, destination IP address each datagram carries 1 transport-layer segment each segment has source and destination port numbers Slide 8

9 Connectionless (UDP) mux/demux Client app. creates UDP socket, sends data to UDP stack through socket socket does not define a connection can be used to communicate with multiple hosts. local socket identified by: (local IP address, local port number) make a packet with destination port# and IP and send it through the local socket. Receiver uses just the destination port number and destination IP to direct a segment to appropriate socket. IP datagrams with different source IP addresses and/or source port numbers are directed to the same socket. Slide 9

10 Connection-oriented (TCP) mux/demux TCP socket identified by 4-tuple, defines a connection: source & destination IP addresses source & destination port numbers Receiver uses all 4 values to direct segment to appropriate socket Server supports many simultaneous TCP sockets at the same port # each socket identified by its own 4-tuple e.g. web servers have different sockets for each connecting client fixed server port number: 80 Note: non-persistent HTTP will have a different socket for each request Slide 10

11 Connection-oriented demux (cont) P1 P4 P5 P6 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP: C Client IP: A Web server IP: C SP: 9157 DP: 80 S-IP: B D-IP: C Client IP:B Slide 11

12 Connection-oriented demux (cont) P1 P4 P5 P6 P2 P1 P3 SP: 9157 SP: 9157 Client IP: A DP: 80 S-IP: A D-IP: C Web server IP: C DP: 80 S-IP: B D-IP: C Client IP:B Slide 12

13 User Datagram Protocol UDP unreliable connectionless transport protocol Why would anybody need this? required for mux / demux small overhead (small headers suitable for short messages) simple: no connection establishment or state, no flow or complex error control no congestion control: UDP can blast away as fast as desired Applications: simple request-response communication applications with internal flow & error control non-critical & periodical tasks (e.g. updating routing information) in conjunction with higher layer protocols for real-time data Slide 13

UDP header source port number from 0 to 65535 destination port number from 0 to 65535 length the total length of the user datagram

14 UDP header source port number from 0 to destination port number from 0 to length the total length of the user datagram (header + data 8 bytes) number of bytes checksum detect errors over the entire datagram optional (if not calculated filled with 0 s) Slide 14

15 UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment Sender: treat segment contents (and pseudo IP header) as sequence of 16-bit integers checksum: 1 s complement of addition (1 s complement sum) put checksum value into UDP checksum field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO: error detected YES: no error detected. But maybe errors nonetheless? More later. Slide 15

16 Checksum example Note When adding numbers, a carryout from the most significant bit needs to be added to the result Example: add two 16-bit integers wraparound sum checksum Slide 16

17 Principles of reliable data transfer Characteristics of unreliable channel determines the complexity of reliable data transfer protocol (rdt) Slide 17

18 Reliable data transfer: getting started rdt_send(): called from above, (e.g., by app.) to send data (to be delivered to receiver upper layer) deliver_data(): called by rdt to deliver data to upper layer send side receive side udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel Slide 18

19 Reliable data transfer: getting started We will: incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) consider only unidirectional data transfer but control info will flow in both directions! use finite state machines (FSM) to specify sender, receiver event causing state transition actions taken on state transition state: when in this state next state uniquely determined by the next event state 1 event actions state 2 Slide 19

20 rdt1.0: reliable transfer over a reliable channel underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for sender & receiver Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) sender receiver Slide 20

21 rdt2.0: channel with bit errors Underlying channel may flip bits in packet checksum to detect bit errors Question: how to recover from errors: acknowledgements (ACK): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAK): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK New mechanisms needed in rdt2.0: error detection receiver feedback: control msgs (ACK,NAK) from rcvr to sender Slide 21

22 rdt2.0: operation with no errors rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) Wait for call from above rdt_rcv(rcvpkt) && isack(rcvpkt) Λ sender Wait for ACK or NAK rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Slide 22

23 rdt2.0: operation with no errors rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) Wait for call from above rdt_rcv(rcvpkt) && isack(rcvpkt) Λ sender Wait for ACK or NAK rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Slide 23

24 rdt2.0: error scenario rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) Wait for call from above rdt_rcv(rcvpkt) && isack(rcvpkt) Λ sender Wait for ACK or NAK rdt2.0 has a fatal flaw! rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) Slide 24

25 rdt2.0 has a fatal flaw! What happens if ACK/NAK messages are corrupted? sender doesn t know what happened at receiver! can t just retransmit: possible duplicate Handling duplicates: sender adds sequence number to each pkt sender retransmits current pkt if ACK/NAK garbled receiver discards (doesn t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for receiver response Slide 25

26 rdt2.1: sender, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) Λ rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) udt_send(sndpkt) rdt_send(data) Wait for call 0 from above Wait for ACK or NAK 1 sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) Wait for ACK or NAK 0 Wait for call 1 from above rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) Λ Slide 26

27 rdt2.1: receiver, handles garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) Wait for 0 from below extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) Slide 27

28 rdt2.1: discussion Sender: seq # added to pkt two seq. # s (0,1) will suffice (why?) must check if received ACK/NAK corrupted twice as many states state must remember whether current pkt has 0 or 1 seq. # Receiver: must check if received packet is duplicate state indicates whether 0 or 1 is expected pkt seq # note: receiver can not know if its last ACK/NAK is received OK by the sender Slide 28

29 rdt2.2: a NAK-free protocol same functionality as rdt2.1, using ACKs only instead of NAK, receiver sends ACK for last pkt correctly received receiver must explicitly include seq # of pkt being ACKed duplicate ACK at sender results in same action as NAK: retransmit current pkt Slide 29

30 rdt2.2: sender, receiver rdt_rcv(rcvpkt) && (corrupt(rcvpkt) has_seq1(rcvpkt)) udt_send(sndpkt) rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) Wait for call 0 from above Wait for 0 from below Wait for ACK 0 sender FSM fragment receiver FSM fragment rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) Λ rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack1, chksum) udt_send(sndpkt) Slide 30

31 rdt3.0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough network connection between the sender and the receiver cannot reorder messages. Approach: sender waits reasonable amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but use of seq. # s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer Slide 31

32 rdt3.0 sender rdt_rcv(rcvpkt) Λ Wait for call 0from above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) ) Wait for ACK1 rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) Wait for ACK0 Wait for call 1 from above rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) Λ timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer rdt_rcv(rcvpkt) Λ sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer Λ Slide 32

33 Pipelined Protocols Go-back-N Sender can have up to N unacked packets in pipeline Selective Repeat Sender can have up to N unacked packets in pipeline Rcvr only sends cumulative ACKs Doesn t ACK packet if there s a gap Rcvr ACKs individual packets Sender has timer for oldest unacked packet (typical) If timer expires, retransmit all unacked packets Sender maintains timer for each unacked packet When timer expires, retransmit only unacked packet Slide 33

34 Go-Back-N Sender: sequence number in pkt header window of up to N, consecutive unacked pkts allowed ACK(n): ACKs all pkts up to and including seq # n - cumulative ACK Sender may receive duplicate ACKs (see receiver) timer for each in-flight pkt or a single timer for all in-flight packets See an implementation with a single timer in the following slides timeout(n): retransmit pkt n and all higher seq # pkts in window Slide 34

35 Selective repeat Main differences from GBN: receiver individually acknowledges all correctly received pkts buffers received pkts that are out-of-order eventually delivers those to upper layer in-order sender only resends pkts for which ACK is not received keeps timer for each unacked pkt Slide 35

36 Selective repeat: sender, receiver windows Slide 36

37 Selective repeat in action Slide 37

38 Connection-oriented transport: Transport Control Protocol point-to-point reliable, in-order delivery pipelined TCP congestion & flow control set the window size send & receive buffers full duplex bi-directional data flow in same connection connection-oriented initialize sender, receiver state before data exchange seq. #s, buffers, flow control info (e.g. RcvWindow) application application socket door writes data TCP reads data TCP socket door send buffer receive buffer segment Slide 38

39 TCP segment format URG: urgent data (generally not used) ACK: ACK # valid Header length in 32-bit words PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # head len sequence number acknowledgement number not used U A P R S F checksum Receive window Urg data pnter Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept Slide 39

40 TCP timers to set TCP timeout value to deal with zero-size receive windows to prevent a long idle connection between a client and a server to guarantee successful connection termination Slide 40

41 Retransmission Timer: TCP RTT Q: How to set TCP timeout value? longer than RTT but RTT varies too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss à Must have a good estimation for RTT! Slide 41

42 TCP reliable data transfer detect segments that are corrupted lost out-of-order duplicated retransmissions triggered by timeout events duplicate ACKs Slide 42

43 Error control in TCP Three tools: 1. checksum 2. acknowledgment no NACKs 3. timeout (2 options): separate timeout counters for each segment transmitted single timeout counter for all in-flight segments [RFC2988] less costly used in modern TCP implementations (We will assume the latter as well.) Initially let s consider a simplified TCP sender: ignore duplicate ACKs ignore flow control, congestion control Slide 43

44 TCP sender (simplified) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer SendBase-1: The last cumulatively ACKed byte. event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer else stop timer } } /* end of loop forever */ Slide 44

45 TCP: retransmission scenarios Host A Host B Host A Host B Seq=92, 8 bytes data Seq=92, 8 bytes data timeout SendBase = 100 time X loss ACK=100 Seq=92, 8 bytes data ACK=100 lost ACK scenario Sendbase= 100 SendBase= 120 SendBase= 120 Seq=92 timeout Seq=92 timeout time Seq=100, 20 bytes data Seq=92, 8 bytes data premature timeout Slide 45

46 TCP retransmission scenarios (more) Host A Host B Seq=92, 8 bytes data timeout Seq=100, 20 bytes data X loss ACK=100 Sendbase= 120 ACK=120 time Cumulative ACK scenario Slide 46

47 Fast Retransmit Time-out period often relatively long: long delay before resending lost packet Detect lost segments via duplicate ACKs. Sender often sends many segments back-to-back If a single segment is lost, it is likely that there will be many duplicate ACKs. If sender receives 3 ACKs for the same data, it assumes that the segment after ACKed data was lost: fast retransmit: resend segment before timer expires Slide 47

48 Retransmission after triple duplicate ACK s Host A Host B X timeout resend 2 nd segment time Slide 48

49 TCP Flow Control Speed-matching service: match the send rate to the receiving app s drain rate Receiving side has a receive buffer and app process may be slow at reading from this buffer. flow control sender won t overflow receiver s buffer by transmitting too much, too fast Slide 49

50 Congestion Congestion: Appears if the load on the network is greater than the capacity of the network load: the number of packets sent to the network in unit time capacity: the number of packets a network can handle in unit time Indicators lost packets (buffer overflow at routers) long delays (queuing in router buffers) Congestion control goal: keep the load below capacity (different from flow control!) Slide 50

51 Congestion control in TCP TCP assumes that the cause of a timeout is congestion Retransmission of lost packets does not solve congestion problem it worsens the situation! NOTE: In flow control, sender window size is determined by the receiver window no information about the network congestion. In case of congestion, the sender has to slow down. If a lot of other senders are doing the same, they can collectively solve congestion. Send window: min (receiver window size, congestion window size) Slide 51

52 TCP sender congestion control (AIMD) 1. Slow Start (SS) & Additive Increase (AI) start with the congestion window (cwnd) = 1 segment (with size MSS) for each successfully received ACK increase the cwnd size by 1 segment until cwnd = threshold value; (exponential increase) Afterwardsà Congestion Avoidance (CA): for each successfully received ACK, increase cwnd by 1/n segments up to the size of the receiver window. n=current cwnd 2. Multiplicative Decrease (MD) & Fast Recovery after a timeout, cwnd is set to 1 segment and the threshold is set to cwnd/2. Congestion Avoidance Multiplicative Decrease Fast Recovery followed by CA if 3 duplicated ACKs are received, the threshold is set cwnd/2 and fast recovery is started (TCP Reno) Slow Start Slide 52

53 TCP congestion control: Finite State Machine Slide 53

54 TCP sender congestion control (AIMD) State Event TCP Sender Action Comment Slow Start (SS) ACK received for previously unacked data CongWin = CongWin + MSS, If (CongWin > Threshold) set state to Congestion Avoidance Resulting in a doubling of CongWin every RTT Congestion Avoidance (CA) ACK received for previously unacked data CongWin = CongWin + MSS * (MSS/CongWin) Additive increase, resulting in increase of CongWin by 1 MSS every RTT SS or CA Loss event detected by triple duplicate ACK Threshold = CongWin/2, CongWin = Threshold, Set state to Congestion Avoidance Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. SS or CA Timeout Threshold = CongWin/2, CongWin = 1 MSS, Set state to Slow Start SS or CA Duplicate ACK Increment duplicate ACK count for segment being acked Enter slow start CongWin and Threshold not changed Slide 54

55 Summary Transport layer provides services on top of the network layer, where the basic functionality is mux/demux. process-to-process segment addressing Complexity of a reliable data transfer protocol depends on the assumptions of the underlying unreliable channel. Congestion must be avoided! TCP performance can be hampered by congestion control. UDP-based applications should be TCP friendly. TCP interprets transmission timeout as an indication of congestion. fast-retransmit in case of 3-duplicate ACKs Slide 55

Internet transport-layer protocols. Transport services and protocols. Sending and receiving. Connection-oriented (TCP) Connection-oriented

Internet transport-layer protocols. Transport services and protocols. Sending and receiving. Connection-oriented (TCP) Connection-oriented Transport services and protocols Internet -layer protocols logical communication between processes protocols run in end systems send side: breaks app messages into segments, passes to layer rcv side: reassembles