1 UDP: more Multiplexing/demultiplexing Multiplexing: - PDF document

Transport Layer Overview: ❒ transport layer services ❒ multiplexing/demultiplexing 6: Transport Layer Overview ❒ connectionless transport: UDP ❒ principles of reliable data transfer ❒ connection-oriented transport: TCP ❍ reliable transfer Last Modified: ❍ flow control ❍ connection management 2/17/2003 2:18:41 PM ❍ congestion control ❒ Instantiation and implementation in the Internet 3: Transport Layer 3: Transport Layer 3a-1 3a-2 Process-to-Process Message Transport services and protocols Delivery ❒ provide logical communication Goal : Deliver application data to correct process (and more application between app’ processes transport particularly to the right socket) network running on different hosts data link network physical data link logical end-end transport network ❒ transport protocols run in physical S egment - unit of data exchanged between transport layer data link end systems physical entities; transport protocol data unit (TPDU) network data link ❒ transport vs network layer receiver physical network data link P3 P4 services: physical application-layer M M ❒ network layer: data transfer network data data link application between end systems physical segment P1 P2 transport header M network ❒ transport layer: data M application application application transport transfer between processes network segment transport transport Ht M data link network ❍ relies on, enhances, network physical network Hn segment layer services 3: Transport Layer 3: Transport Layer 3a-3 3a-4 Transport protocol example UDP: User Datagram Protocol [RFC 768] ❒ “no frills,” “bare bones” ❒ 2 households each with 12 children all cousins. Internet transport Why is there a UDP? ❍ cousins all write letters to each other every week protocol ❒ no connection ❍ In each house, one child volunteers to collect all the ❒ “best effort” service, UDP establishment (which can outgoing letters and distribute all the incoming letters add delay) segments may be: ❒ Analogy to the Internet ❒ TCP is based on a full ❍ lost ❍ Hosts = houses duplex connection so can’t ❍ delivered out of order use to send to multiple ❍ Processes = cousins to app receivers at once (I.e. ❍ Application messages = letters in envelopes ❒ connectionless: broadcast or multicast) ❍ Network layer protocol = postal service ❒ simple: no connection state ❍ no handshaking between ❍ Transport layer protocol = volunteers at sender, receiver UDP sender, receiver • If note any missing letters and rerequest them etc. then ❒ small segment header ❍ each UDP segment like TCP ❒ no congestion control: UDP handled independently • If just hand out whatever comes in then like UDP can blast away as fast as of others desired 3: Transport Layer 3: Transport Layer 3a-5 3a-6 1

UDP: more Multiplexing/demultiplexing Multiplexing: Demultiplexing: often used for streaming ❒ gathering data from multiple Stream of incoming data into 32 bits multimedia apps application processes on the one machine separated into Length, in ❍ loss tolerant source port # dest port # same host and sending out bytes of UDP smaller streams destined for ❍ rate sensitive the same network interface length checksum segment, individual processes ❍ Conducive to multicast including 32 bits ❒ other UDP uses (why?): header Demultiplexing based on IP source port # dest port # ❍ DNS: small, retransmit if addresses and port number necessary for both the sender and Application other header fields receiver ❍ SNMP data ❍ Can distinguish traffic reliable transfer over UDP: ❒ coming to same port but add reliability at application (message; Ex. DNS part of separate layer Request format) application conversations (like ❍ application-specific error data multiple client connections recover! (message) to a web server) UDP segment format TCP/UDP segment format 3: Transport Layer 3: Transport Layer 3a-7 3a-8 Port Implementation Multiplexing/demultiplexing example One Web browser on Two Web browsers on host A host C opens 2 sockets ❒ Message queue each open 1 socket ❍ Append incoming message to the end ❍ Much like a mailbox file ❍ Choose which message queue based on <src ip+ port, dest ip +port> Source IP: C Source IP: C Source IP: A Source IP: A Dest IP: B Dest IP: B ❒ If queue full, ,message can be discarded Dest IP: B Dest IP: B source port: x source port: y source port: x source port: t ❍ why is that ok? Best effort delivery dest. port: 80 dest. port: 80 dest. port: 80 dest. port: 80 ❍ The network doesn’t guarantee not to drop, so the OS needn’t guarantee that either ❒ When application, reads from socket, operating <C,x> to<B,80> <C,y> to<B,80> <A,x> to<B,80> <A,t> to<B,80> system removes some bytes from the head of the queue ❒ If queue empty, application blocks waiting Web server B 3: Transport Layer 3: Transport Layer 3a-10 3a-9 Demultiplexing Demultiplexing (cont) ❒ Packets arrive on Process A ❒ Receiving process may specify combinations network Process B interface, copied 2 ports 1 port of <srcaddr, srcport, destaddr, destport> up into system it will receive or ANY User level memory ❒ Demultiplexing by port numbers and IP ❒ Placed in Kernel level message queue address: other choices? by transport ❍ Ip address and process id? high overhead of protocol, dest IP coordination and couldn’t have multiple streams and port number, per process src IP and port number ❍ Additional level of addressing by port number Drop? ❒ Copied to user provides level of indirection and finer level when app granularity addressing Incoming messages reads socket 3: Transport Layer 3a-11 3: Transport Layer 3a-12 2

UDP header field: checksum UDP Headers ❒ Entire UDP header is 8 Goal: detect “errors” (e.g., flipped bits) in transmitted 32 bits bytes segment ❒ Source and destination source port # dest port # Length, in Sender: Receiver: ports for demultiplexing bytes of UDP length checksum segment, ❒ treat segment contents ❒ Port field is 16 bits; so 2 16 compute checksum of received ❒ including as sequence of 16-bit segment or 64K possible ports -not header integers (add 0 pad to get check if computed checksum enough for whole Internet, ❒ even 16 bit chunks if equals checksum field value: why ok? Just for the single necessary) ❍ NO - error detected Application host! ❒ checksum: addition (1’s ❍ YES - no error detected. But data ❒ Length is 16 bits maybe errors nonethless? complement sum) of (message) More later …. ❒ Checksum is 16 bits segment contents ❍ Errors could be anywhere – ❒ sender puts checksum in data, in headers, even in value into UDP checksum UDP segment format checksum field ❒ Checksum optional but should always be used 3: Transport Layer 3a-13 3: Transport Layer 3a-14 UDP checksum UDP checksum ❒ Checksum over UDP header and the ❒ Actually optional “pseudo header” – not just the data ❍ If sender does not compute set checksum field to 0 ❒ 12 byte Pseudo header precedes UDP ❍ If calculated checksum is 0? Store it as all one header bits (65535) which is equivalent in ones- ❍ duplicates source and destination IP addresses complement arthimetic and the 8 bit protocol ID from IP header ❒ If checksum is non-zero and receiver ❍ also duplicates 16 bit UDP length from UDP computes a different value, silently drop header packet; no error msg generated ❒ Why?Double-check message correctly ❒ Note: We will talk about more about error delivered between endpoints. detection and correction at the link layer…. ❍ Ex.Detect if IP address modified in transit 3: Transport Layer 3a-15 3: Transport Layer 3a-16 UDP Header: length Experimenting with UDP ❒ Length of data and header (min value 8 ❒ Programs like sock, ttcp or pcattcp allow you to generate streams of TCP or UDP data according to bytes = 0 bytes data) your specifications (total amount of data to send, ❒ 16 bit length field => max length of 65535 size of each segment sent, etc.) bytes ❒ Normally, procedure is as follows ❒ Can you really send that much? ❍ Start tracer like Ethereal • Consider a filter like (ip.addr eq senderIPaddress) ❍ May be limited by kernel send buffer (often <= ❍ Start server process (ex. pcattcp –r –u) 8192 bytes) ❍ Start client process sending traffic (ex. pcattcp –t –u <ip ❍ May be limited by kernel’s IP implementation address of server) (possibly <= 512 bytes) ; Hosts required to • Note: loopback or own IP address may not appear in receive 576 bytes of UDP data so senders may Ethereal limit themselves to that as well ❍ Experiment with different size sends –l bytes (default is 8192) or number of buffers to send –n sends (default is 2048) • On Ethernet 1473 causes fragmentation, 1472 does not 3: Transport Layer 3a-17 3: Transport Layer 3a-18 3