1 / 26

7: Transport Layer Overview and UDP

7: Transport Layer Overview and UDP. Last Modified: 12/19/2019 8:41:59 PM. Overview: transport layer services multiplexing/demultiplexing (socket to socket delivery) checksum Roadmap UDP: connectionless transport principles of reliable data transfer

hughw
Download Presentation

7: Transport Layer Overview and UDP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 7: Transport Layer Overview and UDP Last Modified: 12/19/2019 8:41:59 PM 3: Transport Layer

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

  3. provide logical communication 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 relies on, enhances, network layer services application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport Transport services and protocols 3: Transport Layer

  4. Transport protocol example • A bit like volunteer at shared house that collects all outgoing mail and delivers to post office and takes incoming mail from post • Analogy to the Internet • 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

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

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

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

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

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

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

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

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

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

  14. Demultiplexing (cont) • Receiving process may specify combinations of <srcaddr, srcport, destaddr, destport> it will receive or ANY • Demultiplexing by port numbers and IP address: other choices? • Ip address and process id? high overhead of coordination and couldn’t have multiple streams per process • Additional level of addressing by port number provides level of indirection and finer granularity addressing 3: Transport Layer

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

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

  17. Ones complement sum of : 0110011001100110 0101010101010101 0000111100001111 1’s complement of first two (notice the carry) 0110011001100110 + 0101010101010101 ----------------- 1011101110111011 Add in third 1011101110111011 + 0000111100001111 ----------------- 1100101011001010 Take 1’s complement (ie flip all bits) to get final checksum 0011010100110101 Example 3: Transport Layer

  18. Pseudo-header • Checksum over UDP header and the “pseudo header” – not just the data • 12 byte Pseudo header precedes UDP header • 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 • Pseudo header to double-check message correctly delivered between endpoints. • Ex.Detect if IP address modified in transit • Borrowing from the IP header is terribly un-modular, but decided too expensive to do a checksum at both layers! 3: Transport Layer

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

  20. UDP Header: length • Length of data and header (min value 8 bytes = 0 bytes data) • 16 bit length field => max length of 65535 bytes • Can you really send that much? • May be limited by kernel send buffer (often <= 8192 bytes) • 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

  21. Why wouldn’t everyone want reliable TCP? UDP has less overhead UDP has no connection establishment (which can add delay) UDP has small segment header no congestion control: UDP can blast away as fast as desired No connection state at sender, receiver If don’t need all TCP services DNS: small, retransmit if necessary reliable transfer over UDP: add reliability at application layer application-specific error recover! 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) UDP often used for streaming multimedia apps for multicast/broadcast and to avoid overhead Why is there a UDP? 3: Transport Layer

  22. Experimenting with UDP • 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.) • Normally, procedure is as follows • Start tracer like Wireshark • Consider a filter like (ip.addr eq senderIPaddress) • Start server process (ex. pcattcp –r –u) • Start client process sending traffic (ex. pcattcp –t –u <ip address of server) • Note: loopback or own IP address may not appear in Ethereal • 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

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

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

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

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

More Related