Transport Layer 2 Transport Layer 1 Transport Layer

Transport Layer 2: Transport Layer 1

Transport Layer Chapter goals: Chapter Overview: r understand principles r transport layer services behind transport layer services: r multiplexing/demultiplexing r connectionless transport: UDP multiplexing/demultiplex r principles of reliable data ing transfer m reliable data transfer r connection-oriented transport: m flow control TCP m congestion control m reliable transfer r instantiation and m flow control implementation in the m connection management Internet m r principles of congestion control r TCP congestion control 2: Transport Layer 1 2

Transport services and protocols r provide logical communication network data link physical po s an tr rt relies on, enhances, network layer services d en d- m en r al r network data link physical ic r network data link physical g lo r between app’ processes running on different hosts transport protocols run in end systems transport vs network layer services: network layer: data transfer between end systems transport layer: data transfer between processes application transport network data link physical 2: Transport Layer 1 3

Transport-layer protocols network data link physical rt m network data link physical po m real-time bandwidth guarantees reliable multicast s an m network data link physical tr unordered unicast or multicast delivery: UDP r services not available: d en d- r unreliable (“best-effort”), en m al m congestion flow control connection setup network data link physical ic m application transport network data link physical g lo Internet transport services: r reliable, in-order unicast delivery (TCP) application transport network data link physical 2: Transport Layer 1 4

Multiplexing/demultiplexing Recall: segment - unit of data exchanged between transport layer entities m aka TPDU: transport protocol data unit application-layer data segment header segment Ht M Hn segment P 1 M application transport network P 3 Demultiplexing: delivering received segments to correct app layer processes receiver M M application transport network P 4 M P 2 application transport network 2: Transport Layer 1 5

Multiplexing/demultiplexing Multiplexing: gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) multiplexing/demultiplexing: r based on sender, receiver port numbers, IP addresses m source, dest port #s in each segment m recall: well-known port numbers for specific applications r Internal action between layers: in the network, messages from different applications will be in different packets. 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format 2: Transport Layer 1 6

Multiplexing/demultiplexing: examples host A source port: x dest. port: 23 server B source port: 23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 port use: simple telnet app Web client host A Web client host C Source IP: A Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 Web server B port use: Web server 2: Transport Layer 1 7

UDP: User Datagram Protocol r “no frills, ” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others [RFC 768] Why is there a UDP? r no connection establishment (which can add delay) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired 2: Transport Layer 1 8

UDP: more r often used for streaming multimedia apps m loss tolerant m rate sensitive Length, in bytes of UDP segment, (why? ): including header r other UDP uses m DNS m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recover! 32 bits source port # dest port # length checksum Application data (message) UDP segment format 2: Transport Layer 1 9

UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender: r treat segment contents as sequence of 16 -bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field Receiver: r compute checksum of received segment r check if computed checksum equals checksum field value: m NO - error detected m YES - no error detected. But maybe errors nonethless? More later …. 2: Transport Layer 1 10

TCP: Overview r point-to-point: m one sender, one receiver r reliable, in-order byte steam: m no “message boundaries” r pipelined: m TCP congestion and flow control set window size r send & receive buffers RFCs: 793, 1122, 1323, 2018, 2581 r full duplex data: m bi-directional data flow in same connection m MSS: maximum segment size r connection-oriented: m handshaking (exchange of control msgs) init’s sender, receiver state before data exchange r flow controlled: m sender will not overwhelm receiver 2: Transport Layer 2 11

TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) source port # dest port # sequence number acknowledgement number head not UA P R S F len used checksum rcvr window size ptr urgent data Options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept application data (variable length) 2: Transport Layer 2 12

TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side m cumulative ACK Q: how receiver handles out-of-order segments m A: TCP spec doesn’t say, - up to implementor Host B Host A User types ‘C’ Seq=4 2, ACK = 79, da ta ata = d , 3 4 K= , AC q=79 Se host ACKs receipt of echoed ‘C’ = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=4 3, ACK =80 simple telnet scenario 2: Transport Layer 2 time 13

TCP seq. #’s and ACKs Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side m cumulative ACK Q: how receiver handles out-of-order segments m A: TCP spec doesn’t say, - up to implementor Host B Host A User types ‘C’ Seq=4 2 , ACK= 79, Seq= host ACKs receipt of echoed ‘C’ 79, da ta = ‘C ED’ host ACKs receipt of ’ K E E ‘C’, echoes a = ‘W t a d , 5 =4 back ‘C’ ACK Seq=4 5, ACK =83, d ata = “ MONT H” time 2: Transport Layer 2 14

TCP: reliable data transfer event: data received from application above create, send segment wait for event simplified sender, assuming • one way data transfer • no flow, congestion control event: timer timeout for segment with seq # y retransmit segment event: ACK received, with ACK # y ACK processing 2: Transport Layer 2 15

TCP: reliable data transfer Simplified TCP sender 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 20 21 22 23 24 25 26 else {/*sendbase == y , a duplicate ACK for already ACKed segmen increment number of duplicate ACKs received for y if (number of duplicate ACKS received for y == 3) { /* TCP fast retransmit */ resend segment with sequence number y restart timer for segment y } } /* end of loop forever */ 2: Transport Layer 2 16

TCP ACK generation [RFC 1122, RFC 2581] Event TCP Receiver action in-order segment arrival, no gaps, everything else already ACKed delayed ACK. Wait up to 500 ms for next segment. If no next segment, send ACK in-order segment arrival, no gaps, one delayed ACK pending immediately send single cumulative ACK out-of-order segment arrival higher-than-expect seq. # gap detected send duplicate ACK, indicating seq. # of next expected byte arrival of segment that partially or completely fills gap immediate ACK if segment starts at lower end of gap 2: Transport Layer 2 17

TCP: retransmission scenarios Host A , 8 byt es dat a 100 X = ACK loss Seq=9 2 , 8 byt es dat a 0 10 = K 120 = C K A AC Seq=9 2, 8 by tes da t a 20 100 lost ACK scenario 2, 8 by tes da ta Seq= 100, 2 0 byte s data K=1 AC = ACK time Host B Seq=9 Seq=100 timeout Seq=92 timeout Seq=9 2 timeout Host A Host B time premature timeout, cumulative ACKs 2: Transport Layer 2 18

TCP Flow Control flow control sender won’t overrun receiver’s buffers by transmitting too much, too fast Rcv. Buffer = size or TCP Receive Buffer Rcv. Window = amount of spare room in Buffer receiver: explicitly informs sender of (dynamically changing) amount of free buffer space m Rcv. Window field in TCP segment sender: keeps the amount of transmitted, un. ACKed data less than most recently received Rcv. Window receiver buffering 2: Transport Layer 3 19

TCP Round Trip Time and Timeout Q: how to set TCP timeout value? r longer than RTT note: RTT will vary r too short: premature timeout m unnecessary retransmissions r too long: slow reaction to segment loss m Q: how to estimate RTT? r Sample. RTT: measured time from segment transmission until ACK receipt m ignore retransmissions, cumulatively ACKed segments r Sample. RTT will vary, want estimated RTT “smoother” m use several recent measurements, not just current Sample. RTT 2: Transport Layer 3 20

TCP Round Trip Time and Timeout Estimated. RTT = (1 -x)*Estimated. RTT + x*Sample. RTT r Exponential weighted moving average r influence of given sample decreases exponentially fast r typical value of x: 0. 1 Setting the timeout r Estimted. RTT plus “safety margin” r large variation in Estimated. RTT -> larger safety margin Timeout = Estimated. RTT + 4*Deviation = (1 -x)*Deviation + x*|Sample. RTT-Estimated. RTT| 2: Transport Layer 3 21

TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s m buffers, flow control info (e. g. Rcv. Window) r client: connection initiator Socket client. Socket = new Socket("hostname", "port number"); r server: contacted by client Socket connection. Socket = welcome. Socket. accept(); Three way handshake: Step 1: client end system sends TCP SYN control segment to server m specifies initial seq # (client_isn) Step 2: server end system receives SYN, replies with SYNACK control segment ACKs received SYN m allocates buffers m specifies server-> receiver initial seq. # (server_isn) Step 3: client allocates buffers and variables upon receiving SYNACK m m SYN=0 Seq = client_isn + 1 Ack = server_isn +1 2: Transport Layer 3 22

TCP Connection Management (cont. ) Closing a connection: client closes socket: client. Socket. close(); client close Step 1: client end system close FIN timed wait FIN, replies with ACK. Closes connection, sends FIN ACK sends TCP FIN control segment to server Step 2: server receives server ACK closed 2: Transport Layer 3 23

TCP Connection Management (cont. ) Step 3: client receives FIN, replies with ACK. m client closing Enters “timed wait” will respond with ACK to received FINs server FIN ACK Step 4: server, receives closing FIN Note: with small modification, can handly simultaneous FINs. timed wait ACK. Connection closed. ACK closed 2: Transport Layer 3 24

TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 2: Transport Layer 3 25

Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle” r different from flow control! r manifestations: m lost packets (buffer overflow at routers) m long delays (queueing in router buffers) r a top-10 problem! 2: Transport Layer 3 26

Causes/costs of congestion: scenario 1 r two senders, two receivers r one router, infinite buffers r no retransmission r large delays when congested r maximum achievable throughput 2: Transport Layer 3 27

Causes/costs of congestion: scenario 2 r one router, finite buffers r sender retransmission of lost packet 2: Transport Layer 3 28

Approaches towards congestion control Two broad approaches towards congestion control: End-end congestion control: r no explicit feedback from network r congestion inferred from end-system observed loss, delay r approach taken by TCP Network-assisted congestion control: r routers provide feedback to end systems m single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) m explicit rate sender should send at 2: Transport Layer 4 29

TCP Congestion Control r end-end control (no network assistance) r transmission rate limited by congestion window size, Congwin, over segments: Congwin r w segments, each with MSS bytes sent in one RTT: throughput = w * MSS Bytes/sec RTT 2: Transport Layer 4 30

TCP congestion control r “probing” for usable bandwidth: m m m ideally: transmit as fast as possible (Congwin as large as possible) without loss increase Congwin until loss (congestion) loss: decrease Congwin, then begin probing (increasing) again r two “phases” m slow start m congestion avoidance r important variables: m Congwin m threshold: defines threshold between two slow start phase, congestion control phase 2: Transport Layer 4 31

TCP Slowstart Host A initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR Cong. Win > threshold) RTT Slowstart algorithm Host B one segme nt two segme nts four segme nts r exponential increase (per RTT) in window size (not so slow!) r loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) time 2: Transport Layer 4 32

TCP Congestion Avoidance Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 1 perform slowstart 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs 2: Transport Layer 4 33

AIMD TCP congestion avoidance: r AIMD: additive increase, multiplicative decrease m m increase window by 1 per RTT decrease window by factor of 2 on loss event TCP Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 TCP connection 2 bottleneck router capacity R 2: Transport Layer 4 34

Why is TCP fair? Two competing sessions: r Additive increase gives slope of 1, as throughout increases r multiplicative decreases throughput proportionally equal bandwidth share Connection 2 throughput R loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R 2: Transport Layer 4 35

Summary r principles behind transport layer services: multiplexing/demultiplexing m reliable data transfer m flow control m congestion control r instantiation and implementation in the Internet m UDP m TCP m Next: r leaving the network “edge” (application transport layer) r into the network “core” 2: Transport Layer 4 36

References r TCP vs UDP Comparison https: //www. youtube. com/watch? v=uwo. D 5 Ys. GACg r How it works? Internet TCP/IP in work, networking and data transfer https: //www. youtube. com/watch? v=E-w 4 yb. Yrt. TQ r TCP IP STACK explained with real world example https: //www. youtube. com/watch? v=Pswm. Djt. Wm. Mk r TCP Error Recovery Ordered Data https: //www. youtube. com/watch? v=j. Ae 1 r 1 WNZS 4 r Understanding TCP Sliding Windows. https: //www. youtube. com/watch? v=5 Ayq 9 vze. Af 0 r TCP Slow Start (and testing TCP data) https: //www. youtube. com/watch? v=_sxe. FJRVSXw 37