Question? Leave a message!




Transport Protocol Design: UDP, TCP

Transport Protocol Design: UDP, TCP 37
Dr.ShivJindal Profile Pic
Dr.ShivJindal,India,Teacher
Published Date:19-07-2017
Website URL
Comment
Transport Protocol Design: UDP, TCP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1Overview UDP: connectionless, end-to-end service UDP Servers TCP features, Header format Connection Establishment Connection Termination TCP Server Design Ref: Chap 11, 17,18; RFC 793, 1323 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2Transport Protocols  Protocol implemented entirely at the ends  Fate-sharing  Completeness/correctness of function implementations  UDP provides just integrity and demux  TCP adds…  Connection-oriented  Reliable  Ordered  Point-to-point  Byte-stream  Full duplex  Flow and congestion controlled Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3UDP: User Datagram Protocol RFC 768  Minimal Transport Why is there a UDP? Service:  No connection  “Best effort” service, UDP establishment (which can segments may be: add delay)  Lost  Simple: no connection state at sender, receiver  Delivered out of order  Small header to app  No congestion control: UDP  Connectionless: can blast away as fast as  No handshaking desired: dubious between UDP sender, receiver  Each UDP segment handled independently Shivkumar Kalyanaraman of others Rensselaer Polytechnic Institute 4Multiplexing / demultiplexing Recall: segment - unit of data Demultiplexing: delivering exchanged between transport received segments to layer entities correct app layer processes  aka TPDU: transport protocol data unit receiver P3 P4 application-layer M M data application segment P1 P2 transport M header M network application application transport segment H M transport t network segment H network n Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5Multiplexing / demultiplexing Multiplexing: gathering data from multiple 32 bits app processes, enveloping source port dest port data with header (later used for demultiplexing) other header fields multiplexing/demultiplexing:  based on sender, receiver port numbers, IP addresses application  source, dest port s in data each segment (message)  recall: well-known port numbers for specific applications TCP/UDP segment format Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6UDP, cont.  Often used for streaming 32 bits multimedia apps Source port Dest port  Loss tolerant Length, in bytes of UDP Checksum Length  Rate sensitive segment,  Other UDP uses (why?): including header  DNS  SNMP Application  Reliable transfer over data UDP: add reliability at (message) application layer  Application-specific UDP segment format error recover Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7UDP Checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment. Note: IP only has a header checksum. Receiver: Sender:  Treat segment contents  Compute checksum of as sequence of 16-bit received segment integers  Check if computed checksum equals  Checksum: addition (1’s checksum field value: complement sum) of segment contents  NO - error detected  Sender puts checksum  YES - no error value into UDP detected. But maybe checksum field errors nonetheless? Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8Introduction to TCP  Communication abstraction: Reliable Ordered Point-to-point Byte-stream Full duplex Flow and congestion controlled  Protocol implemented entirely at the ends Fate sharing Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9Evolution of TCP 1984 1975 Nagel’s algorithm Three-way handshake 1987 to reduce overhead Raymond Tomlinson Karn’s algorithm 1990 of small packets; In SIGCOMM 75 to better estimate 4.3BSD Reno predicts congestion round-trip time collapse fast retransmit delayed ACK’s 1983 1986 1988 BSD Unix 4.2 Van Jacobson’s Congestion supports TCP/IP 1974 algorithms collapse TCP described by congestion avoidance observed Vint Cerf and Bob Kahn and congestion control 1982 In IEEE Trans Comm (most implemented in TCP & IP RFC 793 & 791 4.3BSD Tahoe) 1990 1975 1980 1985 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10TCP Through the 1990s 1994 1996 T/TCP SACK TCP (Braden) (Floyd et al) Transaction Selective TCP Acknowledgement 1996 1996 1993 1994 FACK TCP Hoe TCP Vegas ECN (Mathis et al) Improving TCP (Brakmo et al) (Floyd) startup extension to SACK real congestion Explicit avoidance Congestion Notification 1993 1994 1996 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11TCP Header Source port Destination port Sequence number Flags: SYN Acknowledgement FIN RESET HdrLen Advertised window Flags 0 PUSH Checksum Urgent pointer URG ACK Options (variable) Data Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12Principles of Reliable Data Transfer  Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 13Reliability Models  Reliability = requires redundancy to recover from uncertain loss or other failure modes.  Two types of redundancy:  Spatial redundancy: independent backup copies  Forward error correction (FEC) codes  Problem: requires huge overhead, since the FEC is also part of the packet(s) it cannot recover from erasure of all packets  Temporal redundancy: retransmit if packets lost/error Lazy: trades off response time for reliability  Design of status reports and retransmission optimization important Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 14Temporal Redundancy Model Packets • Sequence Numbers • CRC or Checksum Timeout • ACKs Status Reports • NAKs, • SACKs • Bitmaps Retransmissions • Packets • FEC information Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15Types of errors and effects  Forward channel bit-errors (garbled packets)  Forward channel packet-errors (lost packets)  Reverse channel bit-errors (garbled status reports)  Reverse channel bit-errors (lost status reports)  Protocol-induced effects:  Duplicate packets  Duplicate status reports  Out-of-order packets  Out-of-order status reports  Out-of-range packets/status reports (in window-based transmissions) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 16Mechanisms …  Mechanisms:  Checksum in pkts: detects pkt corruption  ACK: “packet correctly received”  NAK: “packet incorrectly received”  aka: stop-and-wait Automatic Repeat reQuest (ARQ) protocols  Provides reliable transmission over:  An error-free forward and reverse channel  A forward channel which has bit-errors; reverse: ok  Cannot handle reverse-channel bit-errors; or packet- losses in either direction. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 17More mechanisms …  Mechanisms:  Checksum: detects corruption in pkts & acks  ACK: “packet correctly received”  NAK: “packet incorrectly received”  Sequence number: identifies packet or ack  1-bit sequence number used only in forward channel aka: alternating-bit protocols  Provides reliable transmission over:  An error-free channel  A forward & reverse channel with bit-errors  Detects duplicates of packets/acks/naks  Still needs NAKs, and cannot recover from packet errors… Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 18More Mechanisms …  Mechanisms:  Checksum: detects corruption in pkts & acks  ACK: “packet correctly received”  Duplicate ACK: “packet incorrectly received”  Sequence number: identifies packet or ack 1-bit sequence number used both in forward & reverse channel  Provides reliable transmission over:  An error-free channel  A forward & reverse channel with bit-errors  Detects duplicates of packets/acks  NAKs eliminated  Packet errors in either direction not handled… Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 19Reliability Mechanisms…  Mechanisms:  Checksum: detects corruption in pkts & acks  ACK: “packet correctly received”  Duplicate ACK: “packet incorrectly received”  Sequence number: identifies packet or ack 1-bit sequence number used both in forward & reverse channel  Timeout only at sender  Provides reliable transmission over:  An error-free channel  A forward & reverse channel with bit-errors  Detects duplicates of packets/acks  NAKs eliminated  A forward & reverse channel with packet-errors (loss) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 20