Chapter 3: Transport Layer (Computer Networking) 2020 PDF

Computer Networking CCS-2201/CE-231: Introduction to Networks Dr. Ehab Abousaif PhD in Electrical and Computer Eng., University of Idaho, USA IEEE member, IMAPS member College of Computing and Information Technology, AASTMT Cell: 01114757888 Email: [email protected] Chapter 3 Transport Layer...

Computer Networking CCS-2201/CE-231: Introduction to Networks Dr. Ehab Abousaif PhD in Electrical and Computer Eng., University of Idaho, USA IEEE member, IMAPS member College of Computing and Information Technology, AASTMT Cell: 01114757888 Email: [email protected] Chapter 3 Transport Layer Computer Networking: A A note on the use of these PowerPoint slides: Top-Down Approach  These slides are based on the original slides made by the authors of the book. 8th edition  These slides are a modified version of the original slides and have the same copyrights for Jim Kurose, Keith Ross the authors and for Dr. Ehab Abousaif who modify the slides and put it into this final form. Pearson, 2020 Copyrights ©Dr. Ehab Abousaif – 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 Copyrights ©Dr. Ehab Abousaif – 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 Copyrights ©Dr. Ehab Abousaif – 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 TCP ( series of data, reliable data transmission) enterprise network UDP Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-4 Transport vs. network layer services and protocols household analogy: transport layer: 12 kids in Ann’s house sending communication between letters to 12 kids in Bill’s processes on different hosts. house: relies on, enhances, network  hosts = houses layer services  processes = kids  app messages = letters in envelopes network layer:  transport protocol = Ann and Bill communication between who demux to in-house siblings hosts  network-layer protocol = postal service Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-5 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-6 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-7 Two principal Internet transport protocols application  TCP: Transmission Control Protocol transport network mobile network data link reliable, in-order delivery physical national or global ISP congestion control flow control (organize speed of sending data to the receiver receive data with suitable speed) connection setup local or regional ISP  UDP: User Datagram Protocol home network unreliable, unordered delivery content provider no-frills extension of “best-effort” IP network datacenter application transport network  services not available: network data link delay guarantees physical bandwidth guarantees enterprise network Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-8 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-9 Multiplexing and demultiplexing HTTP server client application application HTTP msg transport transport network transport network link network link physical link physical physical Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-10  HTTP server client application application HTTP msg transport Ht HTTP msg transport network transport network link network link physical link physical physical Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-11  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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-12  HTTP server client application application transport transport network transport network link network link physical link physical physical Hn Ht HTTP msg Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-13  HTTP server client application application HTTP msg transport Ht HTTP msg transport network transport Hn Hnetwork t HTTP msg link network link physical link physical physical Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-14  HTTP server client application application HTTP msg transport Ht HTTP msg Htransport t HTTP msg network transport network link network link physical link physical physical Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-15  Q: how did transport layer know to deliver message to Firefox browser process rather then Netflix process or Skype process? client application application HTTP msg HTTP msg transport Ht HTTP msg transport network transport network link network link physical link physical physical Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-16 Multiplexing/demultiplexing multiplexing as sender: demultiplexing as 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-17 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( IP address+ TCP/UDP segment format port number) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-18 Connectionless demultiplexing (DNS, Video streaming) Recall: when receiving host receives  when creating socket, must UDP segment: specify host-local port #:(java) checks destination port # in segment DatagramSocket mySocket1 = new DatagramSocket(12534); directs UDP segment to socket with that port #  when creating datagram to send into UDP socket, must specify IP/UDP datagrams with same dest. port #, but different source IP destination IP address addresses and/or source port destination port # numbers will be directed to same socket at receiving host Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-19  Connectionless demultiplexing (UDP): an example (IPv4) mySocket = socket(AF_INET,SOCK_DGRAM) mySocket.bind(myaddr,6428); Socket mySocket = mySocket = socket(AF_INET,SOCK_STREAM) socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr,9157); mySocket.bind(myaddr,5775); application application application P1 P3 P4 transport transport transport network network link network link physical link physical physical B D source port: 6428 source port: ? dest port: 9157 dest port: ? More segment come from different sources A C source port: 9157 source port: ? dest port: 6428 dest port: ? Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-20 Connection-oriented demultiplexing(TCP)  TCP socket identified by  server may support many 4-tuple: simultaneous TCP sockets: source IP address each socket identified by its source port number own 4-tuple dest IP address each socket associated with dest port number a different connecting client  demux: receiver uses all four values (4-tuple) to direct segment to appropriate socket  demux: In connectionless uses port number only Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-21 Connection-oriented demultiplexing: example 3 applications application application P4 P5 P6 application P1 P2 P3 transport transport transport network network link network link physical link physical server: IP physical address B host: IP source IP,port: B,80 host: IP address A dest IP,port: A,9157 source IP,port: C,5775 address C dest IP,port: B,80 source IP,port: A,9157 dest IP, port: B,80 source IP,port: C,9157 dest IP,port: B,80 Three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets (source IP& Port ) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-22 Summary  Multiplexing, demultiplexing: based on segment, datagram header field values  UDP: demultiplexing using destination port number (only)  TCP: demultiplexing using 4-tuple: source and destination IP addresses, and port numbers  Multiplexing/demultiplexing happen at all layers Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-23 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-24 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-25 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-26 UDP: User Datagram Protocol [RFC 768] Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-27 UDP: Transport Layer Actions SNMP client SNMP server application application transport transport (UDP) (UDP) network (IP) network (IP) link link physical physical Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-28 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-29 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-30 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-31 UDP checksum Goal: detect errors (i.e., flipped bits) in transmitted segment 1st number 2nd number sum Transmitted: 5 6 11 101 Received: 4 6 11 receiver-computed sender-computed checksum = checksum (as received) 100 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-32 Internet checksum Goal: detect errors (i.e., flipped bits) in transmitted segment sender: receiver:  treat contents of UDP  compute checksum of received segment (including UDP header segment fields and IP addresses) as sequence of 16-bit integers  check if computed checksum equals  checksum: addition (one’s checksum field value: complement sum) of segment not equal - error detected content equal - no error detected. But maybe  checksum value put into errors nonetheless? More later …. UDP checksum field Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-33 Internet checksum: an example example: add two 16-bit integers 1110011001100110 1101010101010101 wraparound 11011101110111011 sum 1011101110111100 checksum 0100010001000011 Note: when adding numbers, a carryout from the most significant bit needs to be added to the result * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-34 Internet checksum: weak protection! example: add two 16-bit integers 01 1110011001100110 10 1101010101010101 wraparound 11011101110111011 Even though numbers have sum 1011101110111100 changed (bit flips), no change checksum 0100010001000011 in checksum! Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-35 Summary: UDP  “no frills” protocol: )Not complex). segments may be lost, delivered out of order best effort service: “send and hope for the best”  UDP has its plusses: no setup/handshaking needed (no RTT incurred) can function when network service is compromised helps with reliability (checksum)  build additional functionality on top of UDP in application layer (e.g., HTTP/3) Copyrights ©Dr. Ehab Abousaif – 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  Principles of congestion control  TCP congestion control  Evolution of transport-layer functionality Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-37  Principles of reliable data transfer sending receiving process process application data data transport reliable channel reliable service abstraction Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-38  Principles of reliable data transfer sending receiving sending receiving process process process process application data data application data data transport transport reliable channel sender-side of receiver-side reliable service abstraction reliable data of reliable data transfer protocol transfer protocol transport network unreliable channel reliable service implementation Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-39 Principles of reliable data transfer sending receiving process process application data data transport sender-side of receiver-side Complexity of reliable data reliable data transfer protocol of reliable data transfer protocol transfer protocol will depend (strongly) on characteristics of transport network unreliable channel (lose, unreliable channel corrupt, reorder data?) reliable service implementation Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-40 Principles of reliable data transfer sending receiving process process application data data transport sender-side of receiver-side reliable data of reliable data Sender, receiver do not know transfer protocol transfer protocol the “state” of each other, e.g., was a message received? transport network  unless communicated via a unreliable channel message reliable service implementation Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-41  Reliable data transfer protocol (rdt): interfaces rdt_send(): called from above, deliver_data(): called by rdt (e.g., by app.). Passed data to to deliver data to upper layer deliver to receiver upper layer sending receiving process process rdt_send() data data deliver_data() sender-side data receiver-side implementation of implementation of rdt reliable data packet rdt reliable data transfer protocol transfer protocol udt_send() Header data Header data rdt_rcv() unreliable channel udt_send(): called by rdt rdt_rcv(): called when packet to transfer packet over arrives on receiver side of Bi-directional communication over unreliable channel to receiver unreliable channel channel Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-42 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 state state determined by next 1 event event 2 actions Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-43 rdt1.0: reliable transfer over a reliable channel  underlying channel perfectly reliable no bit errors no loss of packets  separate FSMs for sender, receiver: sender sends data into underlying channel receiver reads data from underlying channel Wait for rdt_send(data) Wait for rdt_rcv(packet) sender call from packet = make_pkt(data) receiver call from extract (packet,data) above udt_send(packet) below deliver_data(data) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-44 rdt2.0: channel with bit errors  underlying channel may flip bits in packet checksum (e.g., Internet checksum) to detect bit errors  the question: how to recover from errors? How do humans recover from “errors” during conversation? Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-45 rdt2.0: channel with bit errors  underlying channel may flip bits in packet checksum to detect bit errors  the question: how to recover from errors? acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK stop and wait sender sends one packet, then waits for receiver response Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-46 rdt2.0: FSM specifications rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && Wait for Wait for isNAK(rcvpkt) sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) above NAK udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for L call from receiver below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-47 rdt2.0: FSM specification rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && Wait for Wait for isNAK(rcvpkt) sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) above NAK udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for L call from receiver below Note: “state” of receiver (did the receiver get my message correctly?) isn’t known to sender unless rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) somehow communicated from receiver to sender deliver_data(data)  that’s why we need a protocol! udt_send(ACK) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-48 rdt2.0: operation with no errors rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && Wait for Wait for isNAK(rcvpkt) sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) above NAK udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for L call from receiver below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-49 rdt2.0: corrupted packet scenario rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && Wait for Wait for isNAK(rcvpkt) sender call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) above NAK udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for L call from receiver below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-50 rdt2.0 has a fatal flaw! what happens if ACK/NAK handling duplicates: corrupted?  sender retransmits current pkt  sender doesn’t know what if ACK/NAK corrupted happened at receiver!  sender adds sequence number  can’t just retransmit: possible to each pkt duplicate  receiver discards (doesn’t deliver up) duplicate pkt stop and wait sender sends one packet, then waits for receiver response Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-51 rdt2.1: sender, handling garbled ACK/NAKs rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || Wait for Wait for isNAK(rcvpkt) ) call 0 from ACK or NAK 0 udt_send(sndpkt) above rdt_rcv(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && && notcorrupt(rcvpkt) isACK(rcvpkt) && isACK(rcvpkt) L L Wait for Wait for ACK or call 1 from rdt_rcv(rcvpkt) NAK 1 above && (corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-52 rdt2.1: receiver, handling garbled ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) udt_send(sndpkt) Wait for Wait for rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && below below not corrupt(rcvpkt) && has_seq1(rcvpkt) has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-53 rdt2.1: discussion sender: receiver:  seq # added to pkt  must check if received packet  two seq. #s (0,1) will suffice. is duplicate Why? state indicates whether 0 or 1 is expected pkt seq #  must check if received ACK/NAK corrupted  note: receiver can not know if its last ACK/NAK received OK  twice as many states at sender state must “remember” whether “expected” pkt should have seq # of 0 or 1 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-54 rdt2.2: a NAK-free protocol  same functionality as rdt2.1, using ACKs only  instead of NAK, receiver sends ACK for last pkt received OK receiver must explicitly include seq # of pkt being ACKed  duplicate ACK at sender results in same action as NAK: retransmit current pkt As we will see, TCP uses this approach to be NAK-free Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-55 rdt2.2: sender, receiver fragments rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Wait for Wait for ACK isACK(rcvpkt,1) ) call 0 from above 0 udt_send(sndpkt) sender FSM fragment rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && && isACK(rcvpkt,0) (corrupt(rcvpkt) || L has_seq1(rcvpkt)) Wait for receiver FSM 0 from udt_send(sndpkt) below fragment rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-56 rdt3.0: channels with errors and loss New channel assumption: underlying channel can also lose packets (data, ACKs) checksum, sequence #s, ACKs, retransmissions will be of help … but not quite enough Q: How do humans handle lost sender-to- receiver words in conversation? Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-57 rdt3.0: channels with errors and loss 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 seq #s already handles this! receiver must specify seq # of packet being ACKed  use countdown timer to interrupt after “reasonable” amount of time timeout Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-58 rdt3.0 sender rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer Wait for Wait call 0 from for above ACK0 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt,1) && notcorrupt(rcvpkt) stop_timer && isACK(rcvpkt,0) stop_timer Wait Wait for for call 1 from ACK1 above rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-59 rdt3.0 sender rdt_send(data) rdt_rcv(rcvpkt) && sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) || udt_send(sndpkt) isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) start_timer L L Wait for Wait for timeout call 0 from ACK0 udt_send(sndpkt) above start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt,1) && notcorrupt(rcvpkt) stop_timer && isACK(rcvpkt,0) stop_timer Wait Wait for timeout for call 1 from udt_send(sndpkt) ACK1 above start_timer rdt_rcv(rcvpkt) rdt_send(data) L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum) isACK(rcvpkt,0) ) udt_send(sndpkt) start_timer L Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-60 rdt3.0 in action sender receiver sender receiver send pkt0 pkt0 send pkt0 pkt0 rcv pkt0 rcv pkt0 ack0 send ack0 ack0 send ack0 rcv ack0 rcv ack0 send pkt1 pkt1 send pkt1 pkt1 rcv pkt1 X loss ack1 send ack1 rcv ack1 send pkt0 pkt0 rcv pkt0 timeout ack0 send ack0 resend pkt1 pkt1 rcv pkt1 ack1 send ack1 rcv ack1 send pkt0 pkt0 (a) no loss rcv pkt0 ack0 send ack0 (b) packet loss Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-61 rdt3.0 in action sender receiver sender receiver send pkt0 pkt0 rcv pkt0 send pkt0 pkt0 send ack0 ack0 rcv pkt0 rcv ack0 ack0 send ack0 send pkt1 pkt1 rcv ack0 rcv pkt1 send pkt1 pkt1 send ack1 rcv pkt1 ack1 ack1 send ack1 X timeout loss resend pkt1 timeout pkt1 rcv pkt1 resend pkt1 pkt1 rcv pkt1 rcv ack1 (detect duplicate) send pkt0 pkt0 send ack1 (detect duplicate) ack1 send ack1 ack1 rcv pkt0 rcv ack1 rcv ack1 send ack0 send pkt0 pkt0 (ignore) ack0 rcv pkt0 ack0 send ack0 pkt1 (c) ACK loss (d) premature timeout/ delayed ACK Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-62 Performance of rdt3.0 (stop-and-wait)  U sender: utilization – fraction of time sender busy sending  example: 1 Gbps link, 15 ms prop. delay, 8000 bit packet time to transmit packet into channel: L 8000 bits Dtrans = R = 9 = 8 microsecs 10 bits/sec Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-63 rdt3.0: stop-and-wait operation sender receiver first packet bit transmitted, t = 0 first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-64 rdt3.0: stop-and-wait operation sender receiver L/R L/R Usender= RTT + L / R.008 RTT = 30.008 = 0.00027  rdt 3.0 protocol performance stinks!  Protocol limits performance of underlying infrastructure (channel) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-65 rdt3.0: pipelined protocols operation pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged packets range of sequence numbers must be increased buffering at sender and/or receiver Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-66 Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R 3-packet pipelining increases utilization by a factor of 3! U 3L / R.0024 sender = = = 0.00081 RTT + L / R 30.008 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-67 Go-Back-N: sender  sender: “window” of up to N, consecutive transmitted but unACKed pkts k-bit seq # in pkt header  cumulative ACK: ACK(n): ACKs all packets up to, including seq # n on receiving ACK(n): move window forward to begin at n+1  timer for oldest in-flight packet  timeout(n): retransmit packet n and all higher seq # packets in window Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-68 Go-Back-N: receiver  ACK-only: always send ACK for correctly-received packet so far, with highest in-order seq # may generate duplicate ACKs need only remember rcv_base  on receipt of out-of-order packet: can discard (don’t buffer) or buffer: an implementation decision re-ACK pkt with highest in-order seq # Receiver view of sequence number space: received and ACKed … … Out-of-order: received but not ACKed rcv_base Not received Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-69 Go-Back-N in action sender window (N=4) sender receiver 012345678 send pkt0 012345678 send pkt1 012345678 send pkt2 receive pkt0, send ack0 012345678 send pkt3 Xloss receive pkt1, send ack1 (wait) receive pkt3, discard, 012345678 rcv ack0, send pkt4 (re)send ack1 012345678 rcv ack1, send pkt5 receive pkt4, discard, (re)send ack1 ignore duplicate ACK receive pkt5, discard, (re)send ack1 pkt 2 timeout 012345678 send pkt2 012345678 send pkt3 012345678 send pkt4 rcv pkt2, deliver, send ack2 012345678 send pkt5 rcv pkt3, deliver, send ack3 rcv pkt4, deliver, send ack4 rcv pkt5, deliver, send ack5 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-70 Selective repeat receiver individually acknowledges all correctly received packets buffers packets, as needed, for eventual in-order delivery to upper layer sender times-out/retransmits individually for unACKed packets sender maintains timer for each unACKed pkt sender window N consecutive seq #s limits seq #s of sent, unACKed packets Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-71 Selective repeat: sender, receiver windows Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-72 Selective repeat: sender and receiver sender receiver data from above: packet n in [rcvbase, rcvbase+N-1]  if next available seq # in  send ACK(n) window, send packet  out-of-order: buffer timeout(n):  in-order: deliver (also deliver buffered, in-order packets),  resend packet n, restart timer advance window to next not-yet- ACK(n) in [sendbase,sendbase+N-1]: received packet  mark packet n as received packet n in [rcvbase-N,rcvbase-1]  if n smallest unACKed packet,  ACK(n) advance window base to next otherwise: unACKed seq #  ignore Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-73 Selective Repeat in action sender window (N=4) sender receiver 012345678 send pkt0 012345678 send pkt1 012345678 send pkt2 receive pkt0, send ack0 012345678 send pkt3 Xloss receive pkt1, send ack1 (wait) receive pkt3, buffer, 012345678 rcv ack0, send pkt4 send ack3 012345678 rcv ack1, send pkt5 receive pkt4, buffer, record ack3 arrived send ack4 receive pkt5, buffer, pkt 2 timeout send ack5 012345678 send pkt2 012345678 (but not 3,4,5) 012345678 rcv pkt2; deliver pkt2, 012345678 pkt3, pkt4, pkt5; send ack2 Q: what happens when ack2 arrives? Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-74  sender window receiver window Selective repeat: (after receipt) pkt0 (after receipt) a dilemma! 0123012 0123012 pkt1 0123012 0123012 pkt2 0123012 0123012 example: 0123012 pkt3 X  seq #s: 0, 1, 2, 3 (base 4 counting) 0123012 pkt0 will accept packet with seq number 0  window size=3 (a) no problem 0123012 pkt0 0123012 pkt1 0123012 0123012 pkt2 X 0123012 X 0123012 X timeout retransmit pkt0 0123012 pkt0 will accept packet with seq number 0 (b) oops! Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-75  sender window receiver window Selective repeat: (after receipt) pkt0 (after receipt) a dilemma! 0123012 0123012 pkt1 0123012 0123012 pkt2 0123012 0123012 example: 0123012 pkt3 X  seq #s: 0, 1, 2, 3 (base 4 counting)  receiver can’t 0123012 pkt0 will accept packet see sender side with seq number 0  window size=3 (a) no problem  receiver behavior identical in both cases! 0something’s 123012 pkt0 Q: what relationship is needed 0(very) 1 2 3 0 1wrong! 2 pkt1 0123012 pkt2 X between sequence # size and 0123012 X 0123012 0123012 window size to avoid problem X timeout in scenario (b)? retransmit pkt0 0123012 pkt0 will accept packet with seq number 0 (b) oops! Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-76 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-77 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-78  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 E UAP R S F 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-79 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-80 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-81 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-82 TCP round trip time, timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT  exponential weighted moving average (EWMA)  influence of past sample decreases exponentially fast RTT: gaia.cs.umass.edu to fantasia.eurecom.fr  typical value:  = 0.125 350 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr RTT (milliseconds) 300 250 RTT (milliseconds) 200 sampleRTT 150 EstimatedRTT 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) time (seconds) SampleRTT Estimated RTT Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-83 TCP round trip time, timeout  timeout interval: EstimatedRTT plus “safety margin” large variation in EstimatedRTT: want a larger safety margin TimeoutInterval = EstimatedRTT + 4*DevRTT estimated RTT “safety margin”  DevRTT: EWMA of SampleRTT deviation from EstimatedRTT: DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-84 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-85 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-86 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-87 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-88 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-89 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-90 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-91 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 receive window flow control: # bytes receiver willing to accept IP code from sender receiver protocol stack Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-92 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-93 TCP flow control  TCP receiver “advertises” free buffer space in rwnd field in TCP header to application process RcvBuffer size set via socket options (typical default is 4096 bytes) RcvBuffer buffered data many operating systems autoadjust RcvBuffer rwnd free buffer space  sender limits amount of unACKed (“in-flight”) data to received rwnd TCP segment payloads  guarantees receive buffer will not TCP receiver-side buffering overflow Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-94 TCP flow control flow control: # bytes receiver willing to accept  TCP receiver “advertises” free buffer space in rwnd field in TCP header RcvBuffer size set via socket receive window options (typical default is 4096 bytes) many operating systems autoadjust RcvBuffer  sender limits amount of unACKed (“in-flight”) data to received rwnd  guarantees receive buffer will not overflow TCP segment format Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-95 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(); Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-96 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-97  2-way handshake scenarios choose x req_conn(x) ESTAB acc_conn(x) ESTAB data(x+1) accept ACK(x+1) data(x+1) connection x completes No problem! Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-98 2-way handshake scenarios choose x req_conn(x) ESTAB retransmit acc_conn(x) req_conn(x) ESTAB req_conn(x) connection client x completes server terminates forgets x ESTAB acc_conn(x) Problem: half open connection! (no client) Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-99 2-way handshake scenarios choose x req_conn(x) ESTAB retransmit acc_conn(x) req_conn(x) ESTAB data(x+1) accept data(x+1) retransmit data(x+1) connection x completes server client terminates forgets x req_conn(x) ESTAB data(x+1) accept data(x+1) Problem: dup data accepted!  TCP 3-way handshake Server state serverSocket = socket(AF_INET,SOCK_STREAM) Client state serverSocket.bind((‘’,serverPort)) serverSocket.listen(1) clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept() LISTEN clientSocket.connect((serverName,serverPort)) LISTEN choose init seq num, x send TCP SYN msg SYNSENT SYNbit=1, Seq=x choose init seq num, y send TCP SYNACK msg, acking SYN SYN RCVD SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 received SYNACK(x) ESTAB indicates server is live; send ACK for SYNACK; this segment may contain ACKbit=1, ACKnum=y+1 client-to-server data received ACK(y) indicates client is live ESTAB Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-101 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-102 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 Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-103 Evolving transport-layer functionality  TCP, UDP: principal transport protocols for 40 years  different “flavors” of TCP developed, for specific scenarios: Scenario Challenges Long, fat pipes (large data Many packets “in flight”; loss shuts down transfers) pipeline Wireless networks Loss due to noisy wireless links, mobility; TCP treat this as congestion loss Long-delay links Extremely long RTTs Data center networks Latency sensitive Background traffic flows Low priority, “background” TCP flows  moving transport–layer functions to application layer, on top of UDP HTTP/3: QUIC Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-104 QUIC: Quick UDP Internet Connections  application-layer protocol, on top of UDP increase performance of HTTP deployed on many Google servers, apps (Chrome, mobile YouTube app) HTTP/2 HTTP/2 (slimmed) Application HTTP/3 TLS QUIC Transport TCP UDP Network IP IP HTTP/2 over TCP HTTP/2 over QUIC over UDP Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-105 QUIC: Quick UDP Internet Connections adopts approaches we’ve studied in this chapter for connection establishment, error control, congestion control error and congestion control: “Readers familiar with TCP’s loss detection and congestion control will find algorithms here that parallel well-known TCP ones.” [from QUIC specification] connection establishment: reliability, congestion control, authentication, encryption, state established in one RTT  multiple application-level “streams” multiplexed over single QUIC connection separate reliable data transfer, security common congestion control Copyrights ©Dr. Ehab Abousaif – Transport Layer: 3-106 QUIC: Connection establishment TCP handshake (transport layer) QUIC handshake data TLS handshake (security) data TCP (reliability, congestion control QUIC: reliability, congestion control, state) + TLS (authentication, crypto authentication, crypto state state)  1 handshake