Week4[1].pdf

Chapter 3 Transport Layer Computer Networking: A Top-Down Approach 8th edition Jim Kurose, Keith Ross Pearson, 2020 Transport Layer: 3-1 Transport layer: overview Ou...

Chapter 3 Transport Layer Computer Networking: A Top-Down Approach 8th edition Jim Kurose, Keith Ross Pearson, 2020 Transport Layer: 3-1 Transport layer: overview Our goal: ▪ understand principles ▪ learn about Internet transport behind transport layer layer protocols: services: UDP: connectionless transport multiplexing, TCP: connection-oriented reliable demultiplexing transport reliable data transfer TCP congestion control flow control congestion control Transport Layer: 3-2 Transport layer: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control ▪ Evolution of transport-layer functionality Transport Layer: 3-3 Transport services and protocols application transport ▪ provide logical communication mobile network network data link physical between application processes national or global ISP running on different hosts ▪ transport protocols actions in end systems: local or sender: breaks application messages regional ISP into segments, passes to network layer home network content receiver: reassembles segments into provider network datacenter messages, passes to application layer application transport network network ▪ two transport protocols available to data link physical Internet applications enterprise network TCP, UDP Transport Layer: 3-4 Transport vs. network layer services and protocols household analogy: 12 kids in Ann’s house sending letters to 12 kids in Bill’s house: ▪ hosts = houses ▪ processes = kids ▪ app messages = letters in envelopes ▪ transport protocol = Ann and Bill who demux to in-house siblings ▪ network-layer protocol = postal service Transport Layer: 3-5 Transport vs. network layer services and protocols ▪network layer: logical household analogy: communication between 12 kids in Ann’s house sending letters to 12 kids in Bill’s hosts house: ▪transport layer: logical ▪ hosts = houses communication between ▪ processes = kids ▪ app messages = letters in processes envelopes relies on, enhances, network ▪ transport protocol = Ann and Bill layer services who demux to in-house siblings ▪ network-layer protocol = postal service Transport Layer: 3-6 Transport Layer Actions Sender: application ▪ is passed an application- application app. msg layer message transport ▪ determines segment TThhtransport app. msg header fields values network (IP) ▪ creates segment network (IP) link ▪ passes segment to IP link physical physical Transport Layer: 3-7 Transport Layer Actions Receiver: application ▪ receives segment from IP application ▪ checks header values transport app. msg ▪ extracts application-layer transport message network (IP) network (IP) ▪ demultiplexes message up link to application via socket link physical physical Th app. msg Transport Layer: 3-8 Two principal Internet transport protocols application transport ▪ TCP: Transmission Control Protocol mobile network network data link physical reliable, in-order delivery national or global ISP congestion control flow control connection setup local or ▪ UDP: User Datagram Protocol regional ISP unreliable, unordered delivery home network content no-frills extension of “best-effort” IP provider network datacenter application network ▪ services not available: transport network data link delay guarantees physical bandwidth guarantees enterprise network Transport Layer: 3-9 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control ▪ Evolution of transport-layer functionality Transport Layer: 3-10  HTTP server client application application HTTP msg transport transport network transport network link network link physical link physical physical Transport Layer: 3-11  HTTP server client application application HTTP msg transport Ht HTTP msg transport network transport network link network link physical link physical physical Transport Layer: 3-12  HTTP server client application application HTTP msg transport Ht HTTP msg Hnnetwork Ht HTTP msg transport transport network link network link physical link physical physical Transport Layer: 3-13  HTTP server client application application transport transport network transport network link network link physical link physical physical Hn Ht HTTP msg Transport Layer: 3-14  HTTP server client1 client2 application P-client1 P-client2 application transport transport network transport network link network link physical link physical physical Transport Layer: 3-15 Multiplexing/demultiplexing multiplexing at sender: demultiplexing at receiver: handle data from multiple use header info to deliver sockets, add transport header received segments to correct (later used for demultiplexing) socket application application P1 P2 application socket P3 transport P4 process transport network transport network link network link physical link physical physical Transport Layer: 3-16 How demultiplexing works ▪ host receives IP datagrams 32 bits each datagram has source IP source port # dest port # address, destination IP address each datagram carries one other header fields transport-layer segment each segment has source, application destination port number data ▪ host uses IP addresses & port (payload) numbers to direct segment to appropriate socket TCP/UDP segment format Transport Layer: 3-17 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control ▪ Evolution of transport-layer functionality Transport Layer: 3-18 UDP: User Datagram Protocol Why is there a UDP? ▪ “no frills,” “bare bones” Internet transport protocol ▪ no connection establishment (which can ▪ “best effort” service, UDP add RTT delay) segments may be: ▪ simple: no connection state lost at sender, receiver delivered out-of-order to app ▪ small header size ▪ connectionless: ▪ no congestion control no handshaking between UDP ▪ UDP can blast away as fast as desired! sender, receiver ▪ can function in the face of each UDP segment handled congestion independently of others Transport Layer: 3-19 UDP: User Datagram Protocol ▪ UDP use: ▪ streaming multimedia apps (loss tolerant, rate sensitive) ▪ DNS ▪ SNMP ▪ HTTP/3 ▪ if reliable transfer needed over UDP (e.g., HTTP/3): ▪ add needed reliability at application layer ▪ add congestion control at application layer Transport Layer: 3-20 UDP: User Datagram Protocol [RFC 768] Transport Layer: 3-21 UDP: Transport Layer Actions SNMP client SNMP server application application transport transport (UDP) (UDP) network (IP) network (IP) link link physical physical Transport Layer: 3-22 UDP: Transport Layer Actions SNMP client SNMP server UDP sender actions: application ▪ is passed an application- application SNMP msg layer message transport transport ▪ determines UDP segment UDP UDPhh SNMP msg (UDP) header fields values (UDP) network (IP) ▪ creates UDP segment network (IP) link ▪ passes segment to IP link physical physical Transport Layer: 3-23 UDP: Transport Layer Actions SNMP client SNMP server UDP receiver actions: application ▪ receives segment from IP application ▪ checks UDP checksum transport transport SNMP msg header value (UDP) (UDP) ▪ extracts application-layer network UDP h SNMP(IP) msg message network (IP) ▪ demultiplexes message up link link to application via socket physical physical Transport Layer: 3-24 UDP segment header 32 bits source port # dest port # length checksum application length, in bytes of data UDP segment, (payload) including header data to/from UDP segment format application layer Transport Layer: 3-25 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-26 TCP: overview RFCs: 793,1122, 2018, 5681, 7323 ▪ point-to-point: ▪ cumulative ACKs one sender, one receiver ▪ pipelining: ▪ reliable, in-order byte TCP congestion and flow control steam: set window size no “message boundaries" ▪ connection-oriented: ▪ full duplex data: handshaking (exchange of control bi-directional data flow in messages) initializes sender, same connection receiver state before data exchange MSS: maximum segment size ▪ flow controlled: sender will not overwhelm receiver Transport Layer: 3-27  TCP segment structure 32 bits source port # dest port # segment seq #: counting ACK: seq # of next expected sequence number bytes of data into bytestream byte; A bit: this is an ACK (not segments!) acknowledgement number head not length (of TCP header) len used C EUAP R SF receive window flow control: # bytes Internet checksum checksum Urg data pointer receiver willing to accept options (variable length) C, E: congestion notification TCP options application data sent by RST, SYN, FIN: connection data application into management (variable length) TCP socket Transport Layer: 3-28 TCP sequence numbers, ACKs outgoing segment from sender Sequence numbers: source port # dest port # sequence number byte stream “number” of acknowledgement number rwnd first byte in segment’s data checksum urg pointer window size Acknowledgements: N seq # of next byte expected from other side sender sequence number space cumulative ACK sent sent, not- usable not ACKed yet ACKed but not usable (“in-flight”) yet sent Q: how receiver handles out-of- order segments outgoing segment from receiver A: TCP spec doesn’t say, - up source port # dest port # sequence number to implementor acknowledgement number A rwnd checksum urg pointer Transport Layer: 3-29 TCP sequence numbers, ACKs Host A Host B User types‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario Transport Layer: 3-30 TCP round trip time, timeout Q: how to set TCP timeout Q: how to estimate RTT? value? ▪ SampleRTT:measured time ▪ longer than RTT, but RTT varies! from segment transmission until ACK receipt ▪ too short: premature timeout, ignore retransmissions unnecessary retransmissions ▪ SampleRTT will vary, want ▪ too long: slow reaction to estimated RTT “smoother” segment loss average several recent measurements, not just current SampleRTT Transport Layer: 3-31 TCP Sender (simplified) event: data received from event: timeout application ▪ retransmit segment that caused timeout ▪ create segment with seq # ▪ restart timer ▪ seq # is byte-stream number of first data byte in segment event: ACK received ▪ start timer if not already running ▪ if ACK acknowledges previously unACKed segments think of timer as for oldest unACKed segment update what is known to be ACKed expiration interval: TimeOutInterval start timer if there are still unACKed segments Transport Layer: 3-32 TCP Receiver: ACK generation [RFC 5681] Event at receiver TCP receiver action arrival of in-order segment with delayed ACK. Wait up to 500ms expected seq #. All data up to for next segment. If no next segment, expected seq # already ACKed send ACK arrival of in-order segment with immediately send single cumulative expected seq #. One other ACK, ACKing both in-order segments segment has ACK pending arrival of out-of-order segment immediately send duplicate ACK, higher-than-expect seq. #. indicating seq. # of next expected byte Gap detected arrival of segment that immediate send ACK, provided that partially or completely fills gap segment starts at lower end of gap Transport Layer: 3-33 TCP: retransmission scenarios Host A Host B Host A Host B SendBase=92 Seq=92, 8 bytes of data Seq=92, 8 bytes of data Seq=100, 20 bytes of data timeout timeout ACK=100 X ACK=100 ACK=120 Seq=92, 8 bytes of data Seq=92, 8 SendBase=100 bytes of data send cumulative SendBase=120 ACK for 120 ACK=100 ACK=120 SendBase=120 lost ACK scenario premature timeout Transport Layer: 3-34 TCP: retransmission scenarios Host A Host B Seq=92, 8 bytes of data Seq=100, 20 bytes of data ACK=100 X ACK=120 Seq=120, 15 bytes of data cumulative ACK covers for earlier lost ACK Transport Layer: 3-35 TCP fast retransmit Host A Host B TCP fast retransmit if sender receives 3 additional ACKs for same data (“triple duplicate ACKs”), resend unACKed segment with smallest seq # X ▪ likely that unACKed segment lost, so don’t wait for timeout timeout Receipt of three duplicate ACKs indicates 3 segments received Seq=100, 20 bytes of data after a missing segment – lost segment is likely. So retransmit! Transport Layer: 3-36 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP segment structure reliable data transfer flow control connection management ▪ Principles of congestion control ▪ TCP congestion control Transport Layer: 3-37 TCP flow control application Q: What happens if network Application removing process layer delivers data faster than data from TCP socket buffers application layer removes TCP socket data from socket buffers? receiver buffers TCP code Network layer delivering IP datagram payload into TCP IP socket buffers code from sender receiver protocol stack Transport Layer: 3-38 TCP flow control application Q: What happens if network Application removing process layer delivers data faster than data from TCP socket buffers application layer removes TCP socket data from socket buffers? receiver buffers TCP code Network layer delivering IP datagram payload into TCP IP socket buffers code from sender receiver protocol stack Transport Layer: 3-39 TCP flow control application Q: What happens if network Application removing process layer delivers data faster than data from TCP socket buffers application layer removes TCP socket data from socket buffers? receiver buffers TCP code flow control receiver controls sender, so sender won’t overflow IP code receiver’s buffer by transmitting too much, too fast from sender receiver protocol stack Transport Layer: 3-40 TCP connection management before exchanging data, sender/receiver “handshake”: ▪ agree to establish connection (each knowing the other willing to establish connection) ▪ agree on connection parameters (e.g., starting seq #s) application application connection state: ESTAB connection state: ESTAB connection variables: connection Variables: seq # client-to-server seq # client-to-server server-to-client server-to-client rcvBuffer size rcvBuffer size at server,client at server,client network network Socket clientSocket = Socket connectionSocket = newSocket("hostname","port number"); welcomeSocket.accept(); Transport Layer: 3-41 Agreeing to establish a connection 2-way handshake: Q: will 2-way handshake always Let’s talk work in network? ESTAB ESTAB OK ▪ variable delays ▪ retransmitted messages (e.g. req_conn(x)) due to message loss ▪ message reordering choose x req_conn(x) ▪ can’t “see” other side ESTAB acc_conn(x) ESTAB Transport Layer: 3-42  2-way handshake scenarios choose x req_conn(x) ESTAB acc_conn(x) ESTAB data(x+1) accept data(x+1) ACK(x+1) connection x completes No problem! Transport Layer: 3-43 Closing a TCP connection ▪ client, server each close their side of connection send TCP segment with FIN bit = 1 ▪ respond to received FIN with ACK on receiving FIN, ACK can be combined with own FIN ▪ simultaneous FIN exchanges can be handled Transport Layer: 3-44 Chapter 3: roadmap ▪ Transport-layer services ▪ Multiplexing and demultiplexing ▪ Connectionless transport: UDP ▪ Principles of reliable data transfer ▪ Connection-oriented transport: TCP ▪ Principles of congestion control ▪ TCP congestion control ▪ Evolution of transport-layer functionality Transport Layer: 3-45 Principles of congestion control Congestion: ▪ informally: “too many sources sending too much data too fast for network to handle” ▪ manifestations: long delays (queueing in router buffers) packet loss (buffer overflow at routers) ▪ different from flow control! congestion control: ▪ a top-10 problem! too many senders, sending too fast flow control: one sender too fast for one receiver Transport Layer: 3-46 Causes/costs of congestion: insights R/2 ▪ throughput can never exceed capacity throughput: lout lin R/2 ▪ delay increases as capacity approached delay R/2 lin R/2 lout ▪ loss/retransmission decreases effective throughput: throughput lin R/2 R/2 ▪ un-needed duplicates further decreases throughput: lout effective throughput R/2 lin ▪ upstream transmission capacity / buffering R/2 lout wasted for packets lost downstream lin’ R/2 Transport Layer: 3-47 Approaches towards congestion control End-end congestion control: ▪ no explicit feedback from network ▪ congestion inferred from data data ACKs observed loss, delay ACKs ▪ approach taken by TCP Transport Layer: 3-48 Approaches towards congestion control Network-assisted congestion control: explicit congestion info ▪ routers provide direct feedback to sending/receiving hosts with data data ACKs flows passing through congested ACKs router ▪ may indicate congestion level or explicitly set sending rate ▪ TCP ECN, ATM, DECbit protocols Transport Layer: 3-49 Explicit congestion notification (ECN) TCP deployments often implement network-assisted congestion control: ▪ two bits in IP header (ToS field) marked by network router to indicate congestion policy to determine marking chosen by network operator ▪ congestion indication carried to destination ▪ destination sets ECE bit on ACK segment to notify sender of congestion ▪ involves both IP (IP header ECN bit marking) and TCP (TCP header C,E bit marking) source TCP ACK segment destination application application TCP ECE=1 TCP network network link link physical physical ECN=10 ECN=11 IP datagram Transport Layer: 3-50 TCP fairness Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 bottleneck TCP connection 2 router capacity R Transport Layer: 3-51 Q: is TCP Fair? Example: two competing TCP sessions: ▪ additive increase gives slope of 1, as throughout increases ▪ multiplicative decrease decreases throughput proportionally R equal bandwidth share Is TCP fair? A: Yes, under idealized loss: decrease window by factor of 2 assumptions: congestion avoidance: additive increase ▪ same RTT loss: decrease window by factor of 2 congestion avoidance: additive increase ▪ fixed number of sessions only in congestion avoidance Connection 1 throughput R Transport Layer: 3-52 Fairness: must all network apps be “fair”? Fairness and UDP Fairness, parallel TCP ▪ multimedia apps often do not connections use TCP ▪ application can open multiple do not want rate throttled by congestion control parallel connections between two hosts ▪ instead use UDP: send audio/video at constant rate, ▪ web browsers do this , e.g., link of tolerate packet loss rate R with 9 existing connections: ▪ there is no “Internet police” new app asks for 1 TCP, gets rate R/10 policing use of congestion new app asks for 11 TCPs, gets R/2 control Transport Layer: 3-53