CENG305 Computer Networks Lecture Notes PDF

CENG305 Computer Networks Izmir Katip Celebi University Fall 2024-2025 Chapter 03 H. Burak Akyol,...

CENG305 Computer Networks Izmir Katip Celebi University Fall 2024-2025 Chapter 03 H. Burak Akyol, Ph.D. These slides are adapted from the textbook ‘Computer Networking: A Top-Down Approach' by Jim Kurose and Keith Ross. These slides are copyright 1996-2023 J.F Kurose and K.W. Ross, All Rights Reserved 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 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 household analogy: ▪transport layer: 12 kids in Ann’s house sending communication between letters to 12 kids in Bill’s processes 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 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 Transport Layer: 3-10 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 Transport Layer: 3-11  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 Transport Layer: 3-12  ? de-multiplexing  application ? transport de-multiplexing Demultiplexing multiplexing  application transport multiplexing Multiplexing 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-19 Connectionless demultiplexing Recall: when receiving host receives ▪ when creating socket, can specify host- UDP segment: local port #: checks destination port # in mySocket = socket(AF_INET,SOCK_DGRAM); mySocket.bind(myaddr,12534); segment 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 Transport Layer: 3-20 Connectionless demultiplexing: an example mySocket = socket(AF_INET,SOCK_DGRAM); mySocket.bind(myaddr,6428); mySocket = socket(AF_INET,SOCK_DGRAM); mySocket = socket(AF_INET,SOCK_DGRAM); 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: ? A C source port: 9157 source port: ? dest port: 6428 dest port: ? Connection-oriented demultiplexing ▪ 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 Transport Layer: 3-22  Connection-oriented demultiplexing: example application application P4 P5 P6 application P1 P2 P3 transport transport transport network network link network link physical link physical physical server: IP address B host: IP address C host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: C,5775 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. Transport Layer: 3-23 Summary ▪ Multiplexing, demultiplexing: based on segment, datagram header field values ▪ UDP: demultiplexing using destination IP address and port number ▪ TCP: demultiplexing using 4-tuple: source and destination IP addresses, and port numbers Transport Layer: 3-24 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 Transport Layer: 3-25 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-26 UDP: User Datagram Protocol ▪ UDP use: ▪ streaming multimedia apps (loss tolerant, rate sensitive) ▪ DNS ▪ SNMP (Simple Network Management Protocol) ▪ 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-27 UDP: User Datagram Protocol [RFC 768] Transport Layer: 3-28 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-29 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-30 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-31 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-32 UDP checksum Goal: detect errors (i.e., flipped bits) in transmitted segment 1st number 2nd number sum Transmitted: 5 6 11 Received: 4 6 11 receiver-computed sender-computed checksum = checksum (as received) Transport Layer: 3-33 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 Transport Layer: 3-34 Internet checksum: an example example: add two 16-bit integers 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 Note: when adding numbers, a carryout from the most significant bit needs to be added to the result Transport Layer: 3-35 Internet checksum: weak protection! example: add two 16-bit integers 0 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Even though numbers have sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 changed (bit flips), no change checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 in checksum! 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 Transport Layer: 3-37  Principles of reliable data transfer sending receiving process process application data data transport reliable channel reliable service abstraction 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 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 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 Transport Layer: 3-41  Reliable data transfer (rdt) protocol: 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 Bi-directional communication over arrives on receiver side of unreliable channel to receiver unreliable channel channel 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 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) 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? 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 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) 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) 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) 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) 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 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) 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) 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 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 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) 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? 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 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 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 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 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 Transport Layer: 3-62 Performance of rdt3.0 (stop-and-wait) ▪ Usender: 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 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 Transport Layer: 3-64 rdt3.0: stop-and-wait operation sender receiver L/R L/R Usender= RTT + L / R 0.008 RTT = 30.008 = 0.00027 ▪ rdt 3.0 protocol performance stinks! ▪ Protocol limits performance of underlying infrastructure (channel) 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 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 Transport Layer: 3-67