7 Transport Layer Overview and UDP Last Modified

7: Transport Layer Overview and UDP Last Modified: 3/15/2018 7: 16: 58 AM 3: Transport Layer 3 a-1

Transport Layer Overview: r transport layer services m multiplexing/demultiplexing (socket to socket delivery) m checksum r Roadmap m UDP: connectionless transport m principles of reliable data transfer m TCP: connection-oriented transport, flow control, congestion control 3: Transport Layer 3 a-2

Transport services and protocols r provide logical communication network data link physical po s an tr rt relies on, enhances, network layer services d en d- m en r al r network data link physical ic r network data link physical g lo r between processes running on different hosts transport protocols run in end systems transport vs network layer services: network layer: data transfer between end systems transport layer: data transfer between processes application transport network data link physical 3: Transport Layer 3 a-3

Transport protocol example r A bit like volunteer at sorority or fraternity house that collects all outgoing mail and delivers to post office and takes incoming mail from post r Analogy to the Internet m m m Hosts = House Processes = people’s mailboxes Application messages = letters in envelopes Network layer protocol = postal service Transport layer protocol = person who volunteers to multiplex/demultiplex • TCP? Make a copy of each outgoing letter, expect a return receipt for each one and if not send a new copy, send return receipts for each letter received • If just hand out whatever comes in then like UDP 3: Transport Layer 3 a-4

UDP: User Datagram Protocol [RFC 768] r “no frills, ” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others m 3: Transport Layer 3 a-5

UDP Datagram Format 32 bits Length, in bytes of UDP datagram, including header source port # dest port # length checksum Application data r Entire UDP header is 8 bytes r Ports ( 16 bits each) used for multiplexing and demultiplexing r Length (16 bits) used to find end of data r Checksum (16 bits) used to detect errors 3: Transport Layer 3 a-6

TCP segment structure 32 bits Also 16 bits for each source and destination ports Also checksum No length – relies on length in IP header (UDP could the same) source port # dest port # sequence number acknowledgement number head not UA P R S F len used checksum rcvr window size ptr urgent data Options (variable length) application data (variable length) 3: Transport Layer 3 b-7

Multiplexing/demultiplexing Multiplexing: gathering data from multiple application processes on the same host and sending out the same network interface 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format Demultiplexing: Stream of incoming data into one machine separated into smaller streams destined for individual processes Demultiplexing based on IP addresses and port number for both the sender and receiver m Can distinguish traffic coming to same port but part of separate conversations (like multiple client connections to a web server) 3: Transport Layer 3 a-8

Port Implementation r Message queue m Append incoming message to the end m Much like a mailbox file m Choose which message queue based on r If queue full, , message can be discarded m why is that ok? Best effort delivery m The network doesn’t guarantee not to drop, so the OS needn’t guarantee that either r When application, reads from socket, operating system removes some bytes from the head of the queue r If queue empty, application blocks waiting 3: Transport Layer 3 a-9

Connectionless demultiplexing r recall: create sockets with host-local port numbers: Datagram. Socket my. Socket 1 = new Datagram. Socket(12534); Datagram. Socket my. Socket 2 = new Datagram. Socket(12535); r recall: when creating datagram to send into UDP socket, must specify (dest IP address, dest port number) r when host receives UDP segment: m m checks destination port number in segment directs UDP segment to socket with that port number r IP datagrams with different source IP addresses and/or source port numbers directed to same socket Transport Layer 3 -10

Connection-oriented demux r TCP socket identified by 4 -tuple: m m source IP address source port number dest IP address dest port number r recv host uses all four values to direct segment to appropriate socket r server host may support many simultaneous TCP sockets: m each socket identified by its own 4 -tuple r web servers have different sockets for each connecting client m non-persistent HTTP will have different socket for each request Transport Layer 3 -11

Multiplexing/demultiplexing example Two Web browsers on host A each open 1 socket Source IP: A Dest IP: B source port: x dest. port: 80 to Source IP: A Dest IP: B source port: t dest. port: 80 to Web server B One Web browser on host C opens 2 sockets Source IP: C Dest IP: B source port: x dest. port: 80 to Source IP: C Dest IP: B source port: y dest. port: 80 to 3: Transport Layer 3 a-12

Demultiplexing r Packets arrive on Process A network interface, copied 2 ports up into system User level memory r Placed in message Kernel level queue by transport protocol, dest IP and port number, src IP and port number r Copied to user level when app Incoming messages reads socket Process B 1 port Drop? 3: Transport Layer 3 a-13

Demultiplexing (cont) r Receiving process may specify combinations of it will receive or ANY r Demultiplexing by port numbers and IP address: other choices? m Ip address and process id? high overhead of coordination and couldn’t have multiple streams per process m Additional level of addressing by port number provides level of indirection and finer granularity addressing 3: Transport Layer 3 a-14

How many ports? r Port field is 16 216 bits; so or 64 K possible ports -not enough for whole Internet, why ok? Just for the single host! r Plenty for even NAT 32 bits Length, in bytes of UDP datagram, including header source port # dest port # length checksum Application data (message) UDP datagram format 3: Transport Layer 3 a-15

UDP header field: checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment Sender: r treat segment contents as sequence of 16 -bit integers (add 0 pad to get even 16 bit chunks if necessary) r One's complement of the sum of all the 16 -bit words in the segment. r sender puts checksum value into UDP checksum field Receiver: r compute checksum of received segment r check if computed checksum equals checksum field value: m NO - error detected m YES - no error detected. But maybe errors nonetheless? More later …. m Errors could be anywhere – in data, in headers, even in checksum 3: Transport Layer 3 a-16

Example r Ones complement sum of : m m m 01100110 01010101 00001111 r 1’s complement of first two (notice the carry) m m 01100110 + 01010101 --------10111011 r Add in third m 10111011 m + 00001111 m --------m 11001010 r Take 1’s complement (ie flip all bits) to get final checksum m 00110101 3: Transport Layer 3 a-17

Pseudo-header r Checksum over UDP header and the “pseudo header” – not just the data r 12 byte Pseudo header precedes UDP header m m Source and destination IP addresses from IP headers ( 4 bytes each) Protocol ID from IP header ( 1 bytes) Duplicated UDP length from UDP header ( 2 bytes) – why? 1 byte of padding r Pseudo header to double-check message correctly delivered between endpoints. m Ex. Detect if IP address modified in transit r Borrowing from the IP header is terribly un- modular, but decided too expensive to do a 3: Transport Layer 3 a-18 checksum at both layers!

UDP checksum optional? r Actually optional m If sender does not compute set checksum field to 0 m If calculated checksum is 0? Store it as all one bits (65535) which is equivalent in ones-complement arthimetic r If checksum is non-zero and receiver computes a different value, silently drop packet; no error msg generated r Shouldn’t do this unless end-to-end transfer on a very reliable LAN like wired Ethernet r Note: We will talk about more about error detection and correction at the link layer…. 3: Transport Layer 3 a-19

UDP Header: length r Length of data and header (min value 8 bytes = 0 bytes data) r 16 bit length field => max length of 65535 bytes r Can you really send that much? m May be limited by kernel send buffer (often <= 8192 bytes) m May be limited by kernel’s IP implementation (possibly <= 512 bytes) ; Hosts required to receive 576 bytes of UDP data so senders may limit themselves to that as well 3: Transport Layer 3 a-20

Why is there a UDP? r Why wouldn’t everyone want reliable TCP? r UDP has less overhead m UDP has no connection establishment (which can add delay) m UDP has small segment header m no congestion control: UDP can blast away as fast as desired m No connection state at sender, receiver r If don’t need all TCP services m DNS: small, retransmit if necessary m m reliable transfer over UDP: add reliability at application layer application-specific error recover! r Also TCP is based on a full duplex connection so can’t use to send to multiple receivers at once (I. e. broadcast or multicast) r UDP often used for streaming multimedia apps for multicast/broadcast and to avoid overhead 3: Transport Layer 3 a-21

Experimenting with UDP r Programs like sock, ttcp or pcattcp allow you to generate streams of TCP or UDP data according to your specifications (total amount of data to send, size of each segment sent, etc. ) r Normally, procedure is as follows m Start tracer like Ethereal • Consider a filter like (ip. addr eq sender. IPaddress) m m Start server process (ex. pcattcp –r –u) Start client process sending traffic (ex. pcattcp –t –u

UDP Performance Experiments r Vary buffer size , keep total data size the same r Should see higher overall throughput when sending in larger units Why? Many overheads are fixed m m m Packet headers Kernel processing Grabbing channel at physical layer r Also interesting to repeat experiment across different network conditions (on same hub, in same AS, across ASes) m m Throughout? Data loss 3: Transport Layer 3 a-23

TCP vs UDP on a LAN r Compare overall throughput for TCP vs UDP r Expect much lower throughput for TCP – Why? m Connection establishment m Slowstart m Header overhead r On a LAN, TCP shouldn’t see many retransmissions 3: Transport Layer 3 a-24

TCP vs UDP on a WAN r Should see retransmissions and thus more slow start/congestion avoidance overhead r Quantify the effect 3: Transport Layer 3 a-25

Roadmap r UDP is a very thin layer over IP m multiplexing /demultiplexing m error detection r TCP does these things also and then adds some other significant features r TCP is quite a bit more complicated and subtle r We are not going to jump right into TCP r Start gently thinking about principles of reliable message transfer in general 3: Transport Layer 3 a-26