
Transport Layer Protocols and Services in Computer Networks
Explore the fundamental concepts of transport layer protocols like UDP and TCP, their responsibilities in providing logical communication between applications on different hosts, and the importance of multiplexing in message delivery. Learn about port numbers, their role in addressing applications, and common examples of well-known ports in TCP and UDP protocols.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Transport Layer: UDP, Moving Toward TCP 14-740: Fundamentals of Computer Networks Credit: Bill Nace, 14-740, Fall 2107 Material from Computer Networking: A Top Down Approach, 6thedition. J.F. Kurose and K.W. Ross
traceroute Transport-layer services Connectionless transport: UDP Spring 2018 2
Transport services and protocols Mission: provide logical communication between applications running on different hosts Logical communication = as if the applications were directly connected
Using Network Services Network layer provides Internet Protocol (IP) Provides best-effort logical communication between hosts ...of data provided in packets Does not provide reliability guarantees or many others (timeliness, security, bandwidth, etc) Application Transport Network Data Link Physical
Transport Responsibilities Multiplex messages ... ... and De-multiplex Breaking data into appropriate size pieces, called segments ... ... and re-assembly Connection setup, state management, teardown (if necessary) TCP: reliability guarantees
Multiplexing End hosts have multiple applications running Messages are multiplexed at the sender ... de-multiplexed at the receiver App App App App App segments Transport Transport packets packets packets Network Network Network Network frames frames frames Data Link Data Link Data Link Data Link bits bits bits Physical Physical Physical Physical Spring 2018 6
Port Numbers Multiplexing implies addressing How do you know which application to deliver data to? or which application sent the data? 16-bit unsigned number Some applications use well known port numbers Numbers assigned by IANA Spring 2018 8
"Well Known" Ports TCP Examples UDP Examples Port # Application Port # Application 22 SSH: Secure shell 53 DNS 25 SMTP: Email 161 SNMP: Net Mgmt 80 HTTP 520 RIP: Routing 443 HTTPS 944 NFS: File System Spring 2018 9
Binding Port numbers are bound to an application Application tells Transport layer I will listen on this port Ephemeral ports often used where response is sent from a different port Spring 2018 10
Segmentation Second responsibility of Transport layer Sender: Application provides messages Broken into segments, passed to Network layer one-by-one Receiver: collects segments, reassembles into messages, passes to application layer
Headers Transport layer adds header with additional information (port numbers, ...)
traceroute Transport-layer services Connectionless transport: UDP Spring 2018 13
User Datagram Protocol bare bones, no-frills transport Defined in RFC 768 best-effort service segments may be lost may be delivered out-of-order Connectionless No handshaking Each segment handled independently Spring 2018 14
UDP Humor I'd love to tell you a UDP joke, but I'm not sure you would get it. Spring 2018 15
Why? UDP requires no connection establishment, thus no additional delay Very simple: no state to maintain Segment header is small No congestion control UDP can blast away as fast as desired Spring 2018 16
Uses Often used for streaming multimedia apps Loss tolerant Rate sensitive (timeliness) Used in DNS, SNMP Reliability can be added at app layer application-specific error recovery Perhaps proprietary algorithms Spring 2018 17
Segment Format 32 bits Small header -- only 8 bytes Port numbers are 16 bits Values of 0-65535 Length is of entire segment, including header, measured in bytes Segment could be 64KBytes source port # dest port # length checksum Application data (message)
Checksum Goal: detect errors (flipped bits) in transmitted segment Algorithm selected for ease of implementation in software See RFC 1071 for efficient implementation details End-to-end detection of bit errors Spring 2018 19
Checksum: Sender Sender: Calculate the sum of all the 16-bit words in the segment Wrap carry from output to input Take the 1s complement (flip the bits) Put the result in the UDP header Spring 2018 20
Checksum: Receiver Receiver: Add segment contents, including checksum, as 16-bit words Wrapping carry Error if result is not all 1s Spring 2018 21
Checksum Example 0110011001100000 0110011001100000 Message +0101010101010101 +0101010101010101 0110011001100000 1011101110110101 1011101110110101 0101010101010101 1011101110110101 1000111100001100 +1000111100001100 10100101011000001 Carry-out is added in again 1 This is the checksum +0100101011000001 1011010100111101 0100101011000010 Flip all the bits
Checksum check 0110011001100000 0110011000100000 0101010101010101 0101010101010101 1000111100001100 1000111100001100 + 1011010100111101 + 1011010100111101 11111111111111110 11111111110111110 1111111111111111 1111111110111111 No Error Ooops!
Checksum good enough? Detects any single-bit flip Does not detect all 2-bit errors Designers decided this is good enough Tradeoff of Ease of implementation Performance overhead Strong enough for common case Spring 2018 24
Reliable Transfer Spring 2018
traceroute RDT Theory and Tools Stop-and-wait Protocol Motivates Pipelining Sliding-window Protocols Go-back-N (GBN) Selective Repeat (SR) Spring 2018 26
RDT: Requirements Reliable Data Transfer (RDT) Reliable channel service abstraction No transferred bits are corrupted All bits are delivered (and no extras) ... ... in the order sent Generally bidirectional Today, we talk about unidirectional Spring 2018 27
Fault Models Network-layer may have faults Bit-errors Lossy: i.e. segment can go missing Duplicate delivery Out-of-order delivery Spring 2018 28
Tools Receiver feedback Positive acknowledgement (ACK) Good segment received Negative acknowledgement (NACK) Bad segment received Spring 2018 29
Tools (2) Error detection Checksum -- Segment received, but bit errors exist Timer expiration -- Segment or receiver feedback is lost Spring 2018 30
Tools (3) Retransmission Sender sends another copy of segment Sequence number Distinguish between old and new Gaps let receiver detect lost segment Window, pipelining Control sending of multiple segments Spring 2018 31
traceroute RDT Theory and Tools Stop-and-wait Protocol Motivates Pipelining Sliding-window Protocols Go-back-N (GBN) Selective Repeat (SR) Spring 2018 32
Stop-and-wait Simplest Protocol that will handle bit errors and segment loss Example of how to use: checksum acknowledgement sequence numbers (1 bit) timers Spring 2018 33
The protocol (v1) Tools used: Checksum, ACK and NAK When sending a segment Wait to get an ACK/NAK If NAK, resend the segment Then go back to waiting If ACK, great! When segment is received Examine checksum Reply with ACK for good segment Deliver to App layer NAK for corrupted ones Protocol does not create duplicate segments ... but it doesn't handle corrupted ACK/NAK Spring 2018
Stop-and-wait in Action Version 1 Checksum: Detects flipped bits ACK / NAK: Feedback segment is good segment is damaged Spring 2018 36
The protocol (v2) Tools used: Cksm, ACK/NAK, 1-bit seq number When sending a segment seq # = 1 - last seq # Wait to get ACK/NAK If corrupted or NAK, resend Otherwise, great! When segment is received Reply with ACK for good segments NAK for corrupted ones If seq # is last seq # Deliver to App Layer Protocol retransmits a damaged ACK/NAK ... but it doesn't handle segment loss Spring 2018
Stop-and-wait in Action Version 2 Checksum: Detects flipped bits in segment or ACK / NAK Sequence Number: Detects duplicate segments Duplicate! Not delivered to App layer Spring 2018 39
The protocol (v3) Tools used: Cksm, ACK/NAK, seq numbers, timers When sending a segment, set timer, include seq number When ACK received (&right seq #), remove timer and proceed with next segment NACK: reset timer, resend If timer goes off, resend (and set the timer) When segment is received ACK for good segments NAK for corrupted ones Include seq number If seq # is last seq # Deliver to App Layer Protocol retransmits lost segments ... but it creates (and detects) duplicate segments Spring 2018
Stop-and-wait in Action Operation with no loss Lost Segment
Sequence Numbers Without sequence numbers, receiver doesn t know if retransmitted segment is new data or old Lost ACK and Lost Segment are identical to sender Lost ACK
Sequence Numbers (2) Sender can t distinguish first and second ACK1 Sequence number indicates duplicate Sender waiting for ACK0 Does nothing on ACK1 Premature Timeout
Stop-and-wait has a problem L = 1000B segment R = 1.5Mbps RTT = 45 ms L / R .0053 Usender = = = 0.1059 L / R + RTT .0503 Blech!
How can U be One? Bandwidth-Delay Product Amount of data that could be in transit Sender could pump this much data without awaiting an ACK Example RTT = 45ms, R = 1.5Mbps BWxDelay = R x RTT = 67.5Kb If L = 1KB, (i.e. 8Kb) 8 segments could be in flight Spring 2018 45
Pipelined Protocols Pipelining: send multiple, in-flight , yet- to-be-acknowledged segments A stop-and-wait protocol A pipelined protocol Spring 2018 46
Pipelining: Increased Utilization Increased utilization by a factor of 3! 3 x L / R 0.016 Usender = = = 0.317 L / R + RTT .0503 Spring 2018 47
traceroute RDT Theory and Tools Stop-and-wait Protocol Motivates Pipelining Sliding-window Protocols Go-back-N (GBN) Selective Repeat (SR) Spring 2018 48
Sliding-window Protocols A mechanism to control multiple, in-flight segments without overwhelming receiver Sender is allowed to transmit N segments without waiting for an ACK N is the window size, a range of permissible sequence numbers Two generic forms Go-Back-N (GBN) Selective Repeat (SR) Spring 2018 49
GBN: Sender Sender places a k-bit seq# in header window of up to N, consecutive unACKed segments allowed Sets a timer for each in-flight segment timeout(n): retransmit segment n and all higher seq# segments in window ACK(n): ACKs all segments up to, including seq# n Cumulative ACK Spring 2018 50
GBN: Receiver ACK-only: always send ACK for correctly- received segment with highest in-order seq# May generate duplicate ACKs But, only remembers expected seq# Receipt of out-of-order segment: Discard! No receiver side buffering Re-ACK seg with highest in-order seq# Spring 2018 51
GBN: Window Sender variables: send_base, nextseqnum As segs are ACK ed, window slides to right GBN is a sliding-window protocol
GBN in Action N = ? sendbase? next_seqnum? Spring 2018 53