Transport Layer Protocols and Services in Computer Networks

transport layer udp moving toward tcp n.w
1 / 64
Embed
Share

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.

  • Computer Networks
  • Transport Layer
  • UDP
  • TCP
  • Port Numbers

Uploaded on | 0 Views


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


  1. 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

  2. traceroute Transport-layer services Connectionless transport: UDP Spring 2018 2

  3. Transport services and protocols Mission: provide logical communication between applications running on different hosts Logical communication = as if the applications were directly connected

  4. 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

  5. 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

  6. 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

  7. 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

  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

  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

  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

  11. Headers Transport layer adds header with additional information (port numbers, ...)

  12. traceroute Transport-layer services Connectionless transport: UDP Spring 2018 13

  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

  14. UDP Humor I'd love to tell you a UDP joke, but I'm not sure you would get it. Spring 2018 15

  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

  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

  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)

  18. 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

  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

  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

  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

  22. Checksum check 0110011001100000 0110011000100000 0101010101010101 0101010101010101 1000111100001100 1000111100001100 + 1011010100111101 + 1011010100111101 11111111111111110 11111111110111110 1111111111111111 1111111110111111 No Error Ooops!

  23. 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

  24. Reliable Transfer Spring 2018

  25. traceroute RDT Theory and Tools Stop-and-wait Protocol Motivates Pipelining Sliding-window Protocols Go-back-N (GBN) Selective Repeat (SR) Spring 2018 26

  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

  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

  28. Tools Receiver feedback Positive acknowledgement (ACK) Good segment received Negative acknowledgement (NACK) Bad segment received Spring 2018 29

  29. Tools (2) Error detection Checksum -- Segment received, but bit errors exist Timer expiration -- Segment or receiver feedback is lost Spring 2018 30

  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

  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

  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

  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

  34. Stop-and-wait in Action Version 1 Checksum: Detects flipped bits ACK / NAK: Feedback segment is good segment is damaged Spring 2018 36

  35. 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

  36. 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

  37. 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

  38. Stop-and-wait in Action Operation with no loss Lost Segment

  39. 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

  40. 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

  41. 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!

  42. 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

  43. Pipelined Protocols Pipelining: send multiple, in-flight , yet- to-be-acknowledged segments A stop-and-wait protocol A pipelined protocol Spring 2018 46

  44. 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

  45. traceroute RDT Theory and Tools Stop-and-wait Protocol Motivates Pipelining Sliding-window Protocols Go-back-N (GBN) Selective Repeat (SR) Spring 2018 48

  46. 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

  47. 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

  48. 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

  49. GBN: Window Sender variables: send_base, nextseqnum As segs are ACK ed, window slides to right GBN is a sliding-window protocol

  50. GBN in Action N = ? sendbase? next_seqnum? Spring 2018 53

Related


More Related Content