Transport-Layer-1.pdf

Transport Layer Transport Layer our goals: ○ understand principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control learn about Internet transport layer protocols: ○ U...

Transport Layer Transport Layer our goals: ○ understand principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control learn about Internet transport layer protocols: ○ UDP: connectionless best effort transport service ○ TCP: connection-oriented, reliable, flow controlled, and congestion controlled transport service outline 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 Transport services and protocols provide logical communication between app processes running on different hosts transport protocols run in end systems ○ sender: breaks app messages into segments, passes to network layer ○ receiver: reassembles segments into messages, passes to app layer more than one transport protocol available to apps ○ Internet: TCP and UDP Layered Architecture Logical Data Paths Application Application Layer Layer Transport Transport Layer Layer Network Network Network Layer Layer Layer Data Link Data Link Data Link Data Link Layer Layer Layer Layer Physical Physical Physical Physical Layer Layer Layer Layer End Node Switch Router End Node Physical Data Path Transport vs. network layer services and protocols network layer: logical communication between hosts transport layer: logical communication between processes ○ relies on, enhances, network layer services 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 Actions Sender: ○ is passed an application-layer message ○ determines segment header fields values ○ creates segment ○ passes segment to IP Transport Layer Actions Receiver: ○ receives segment from IP ○ checks header values ○ extracts application-layer message ○ demultiplexes message up to application via socket Internet Network-layer protocol TCP (Transmission Control Protocol): Connection-oriented UDP (User Datagram Protocol): Connectionless The Internet’s network-layer protocol has a name—IP, for Internet Protocol IP provides logical communication between hosts IP service model: ○ best-effort delivery service ○ Unreliable service ○ no delivery guarantees, no orderly delivery guarantees, no data integrity guarantees For these reasons, IP is said to be an unreliable service Can the transport layer protocols improve upon this service? Internet transport-layer protocols TCP: Transmission Control Protocol ○ reliable, in-order delivery (TCP) ○ congestion control ○ flow control ○ connection setup UDP: User Datagram Protocol ○ unreliable, unordered delivery: UDP ○ no-frills extension of “best-effort” IP services provided by both TCP and UDP ○ extending IP’s layer host-to-host delivery to process-to-process delivery multiplexing and de-multiplexing ○ error checking services not available: ○ delay guarantees, bandwidth guarantees outline 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 Multiplexing/demultiplexing Multiplexing at sender: Handles data from multiple sockets, adds port number to header (later used for demultiplexing) Multiplexing/demultiplexing Demultiplexing at receiver: Uses port number in header to deliver received segments to correct socket How demultiplexing works host receives IP datagrams ○ each datagram carries one transport-layer segment ○ each segment has source, destination port numbers as well as ○ each datagram has source IP address, destination IP address host uses IP addresses & port numbers to direct segment to appropriate socket  message Source Dest message port # port # Source IP Dest IP Source Dest message port # port # Connectionless demultiplexing recall: created socket has host-local port #: ○ socket = socket(AF_INET, SOCK_DGRAM) ○ Server: socket.bind(("", serverPort)) ○ Client: The port for client is specified by the OS recall: when creating datagram to send into UDP socket, must specify ○ destination IP address ○ destination port # When host receives UDP segment: ○ checks destination port # in segment ○ directs UDP segment to socket with that port # IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be directed to same socket at dest Connectionless demux: example  Connectionless demux: example mySocket = mySocket = socket(AF_INET,SOCK_STREAM) mySocket = socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 6428) socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 9157) mySocket.bind(myaddr, 5775)  Connectionless demux: example mySocket = mySocket = socket(AF_INET,SOCK_STREAM) mySocket = socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 6428) socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 9157) mySocket.bind(myaddr, 5775)  Connectionless demux: example mySocket = mySocket = socket(AF_INET,SOCK_STREAM) mySocket = socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 6428) socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 9157) mySocket.bind(myaddr, 5775)  Connectionless demux: example mySocket = mySocket = socket(AF_INET,SOCK_STREAM) mySocket = socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 6428) socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 9157) mySocket.bind(myaddr, 5775)  Connectionless demux: example mySocket = mySocket = socket(AF_INET,SOCK_STREAM) mySocket = socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 6428) socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr, 9157) mySocket.bind(myaddr, 5775) Connection-oriented demultiplexing TCP socket identified by 4-tuple: ○ source IP address ○ source port number ○ dest IP address ○ dest port number demux: receiver uses all four values (4-tuple) to direct segment to appropriate socket server host may support many simultaneous TCP sockets: ○ each socket identified by its own 4-tuple ○ each socket associated with a different connecting client web servers have different sockets for each connecting client ○ non-persistent HTTP will have different socket for each request  Connection-oriented demux: example mySocket = socket(AF_INET,SOCK_STREAM) mySocket = mySocket = mySocket.bind(myaddr,6428); socket(AF_INET,SOCK_STREAM) socket(AF_INET,SOCK_STREAM) mySocket.bind(myaddr,5775); mySocket.bind(myaddr,9157) Question Suppose Client A initiates a Telnet session with Server S. At about the same time, Client B also initiates a Telnet session with Server S. Which one is a possible source and destination port numbers for the segments sent from A to S. Telnet runs on port 23. A. Source port#:23 destination port#:23 B. Source port#:468 destination port#:23 C. Source port#:23 destination port#:468 D. Source port#:468 destination port#:468 Question Suppose Client A initiates a Telnet session with Server S. At about the same time, Client B also initiates a Telnet session with Server S. If A and B are different hosts, is it possible that the source port number in the segments from A to S is the same as that from B to S? A. Yes B. No Multiplexing/demultiplexing: 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 outline 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 UDP: User Datagram Protocol [RFC 768] “best effort” service, UDP segments may be: ○ Lost ○ delivered out-of-order to app Connectionless: ○ no handshaking between UDP sender and receiver No connection state such as receive and send buffers, congestion-control parameters, etc. A server can support more active clients when running over UDP ○ each UDP datagram handled independently of others Favored in applications needing ○ Finer application-level control over what data is sent, and when (TCP throttles packet transmissions in many ways by mechanisms such as congestion control, retransmission, etc. ○ No connection establishment / state ○ Small packet header overhead TCP segment has 20 bytes of header overhead; UDP had 8 bytes of overhead UDP: User Datagram Protocol Why is there a UDP? ○ no connection establishment (which can add RTT delay) ○ simple: no connection state at sender, receiver ○ small header size ○ no congestion control UDP can blast away as fast as desired! can function in the face of congestion UDP: User Datagram Protocol [RFC 768] UDP must be used in applications that are Loss tolerant Rate sensitive applications react poorly to TCP’s congestion control ○ Controversial to use UDP in rate sensitive applicaiton UDP packets drops TCP senders decrease their rates Major applications using UDP: ○ DNS ○ streaming multimedia apps ○ SNMP: must often run when the network is in a stressed state; reliable, congestion-controlled data transfer is difficult to achieve ○ HTTP/3 If reliable transfer needed over UDP (for example HTTP/3): ○ add reliability at application layer ○ add congestion control at application layer ○ Application-specific error recovery! UDP: User Datagram Protocol [RFC 768] UDP: Transport Layer Actions UDP Sender: ○ is passed an application-layer message ○ determines UDP segment header fields values ○ creates UDP segment ○ passes segment to IP UDP: Transport Layer Actions UDP Receiver: ○ receives segment from IP ○ checks UDP checksum header values ○ extracts application-layer message ○ demultiplexes message up to application via socket UDP: segment header UDP checksum Goal: detect errors (i.e., flipped bits) in transmitted segment UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment Sender: ○ treat segment contents, including header fields, as sequence of 16-bit integers ○ checksum: addition (one’s complement sum) of segment contents ○ checksum value put into UDP checksum field Receiver: ○ compute checksum of received segment ○ check if computed checksum equals checksum field value: not equal - error detected equal - no error detected. But maybe errors nonetheless? More later …. Internet checksum: example example: checksum of two 16-bit integers Note: when adding numbers, a carryout from the most significant bit needs to be added to the result Checksum is one’s complement of the sum Question Compute the Internet checksum value for these two 16-bit words: 11110101 11010011 10110011 01000100 A. 01011110 11000101 B. 01010110 11101000 C. 01101110 11010101 D. 01010110 11100111 Question When computing the Internet checksum for two numbers, a single flipped bit in each of the two numbers will always result in a changed checksum. True False Internet checksum: example example: add two 16-bit integers  Internet Checksum: Example example: calculate checksum for a packet with 3 16 bits data 0110011001100000 0110011001100000 0101010101010101 0101010101010101 1000111100001100 ------------------------------ 1011101110110101 1000111100001100 ---------------------------- t 0100101011000010 1011010100111101 1s complemen checksum Why UDP provides a Checksum? link-by-link is not guaranteed ○ No guarantee that all the links between source and destination provide error checking in-memory errors ○ bit errors could be introduced when a segment is stored in a router’s memory Summary: UDP “no frills” protocol: ○ 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) outline 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