3.3 – Connectionless Transport: UDP

  • UDP does just about as little as a transport protocol can do.
    • Aside from the multiplexing/demultiplexing function and some light error checking, it adds nothing to IP.
  • UDP takes messages from the application process, attaches source and destination port number fields for the multiplexing/demultiplexing, adds two other small fields and passes the resulting segment to the network layer.
  • The network layer encapsulates it and makes it into an IP datagram. IP then makes a best-effort delivery. UDP then uses the destination port number to deliver it to the correct application process if it isn’t lost on the way.
  • There’s no handshaking between sending and receiving transport-layer entities before sending a segment which is why UDP is said to be connectionless.
  • DNS is an example of a protocol that uses UDP.
    • When a DNS application wants to make a query it constructs a DNS query message and passes the message to UDP. UDP then adds header fields to it and passes it to the network layer who encapsulates it into a Datagram and sends it to a DNS server.
      • It then waits for a reply and if it doesn’t get a reply then it will either resend it, send it to another host or inform the application that it cant get a reply.
  • Some applications are better suited for UDP for the following reasons:
    • Finer application-level control over what data is sent, and when:
      • TCP has a congestion-control mechanismen that throttles the TCP sender when a link is excessively congested. TCP will also continue to resend a segment until the receipt of the segment has been acknowledged by the destination, regardless of how long it takes.
      • Real-time applications often require minimum sending, do not want to overly delay segments transmission and can tolerate some data loss, which makes UDP a better choice as it doesn’t have all the mechanisms that TCP have.
    • No connection establishment:
      • UDP does not introduce any delay to establish a connection, UDP just blasts away without any formal preliminaries.
    • No connection State:
      • TCP maintains connection state in the end-systems. This connection state includes receive and send buffers, congestion-control parameters, and sequence and acknowledgement number parameters. UDP on the other hand does not maintain a connection state and does not track any of these parameters (thus a server can typically support many more active clients over UDP than TCP).
    • Small packet header overhead:
      • The TCP segment has 20 bytes header overhead in every segment, UDP only has 8 bytes of overhead.
  • Applications and their protocol:
    • Electronic mail: SMTP – TCP
    • Remote terminal access: Telnet – TCP
    • Web: HTTP – TCP
    • File transfer: FTP – TCP
    • Remote file server: NFS - Typically UDP
    • Streaming multimedia: typically proprietary – UDP or TCP
    • Internet telephony: typically proprietary – UDP or TCP
    • Network management: SNMP – Typically UDP
    • Name translation DNS - Typically UDP
  • The lack of congestion control in UDP can result in high loss rates between a UDP sender and receiver, and the crowding out of TCP session. It’s a serious issue and many researchers have proposed new mechanisms to force all sources including UDP sources to perform adaptive congestion control.

3.3.1 – UDP Segment Structure

  • The application data occupies the data field of the UDP segment.
  • The UDP header has only 4 fields each of consisting of 2 bytes.
    • Source port and destination port – allows the segment to be delivered to the correct socket/process
    • Length – needed since the size of the data field may differ from one UDP segment to the next.
    • The checksum is used by the receiving host to check whether errors have been introduced into the segment.

3.3.2 UDP Checksum

  • Provides error detection to determine whether bits within the segment has been altered as it moved from the source to the destination.
  • UDP at the sender side performs the 1s complement of the sum of all the 16-bit words in the segment, with any overflow encountered during the sum being wrapped around. This result is put in the checksum field of the segment.
  • Example:
    • 011001100110000001010101010101011000111100001100
    • The sum of the first two 16-bit words is:011001100110000001010101010101011011101110110101
    • Adding the third word to the sum above gives us:101110111011010110001111000011000100101011000010
    • Since this was a 1s compliment we have to invert the numbers and we get:1011010100111101 which becomes the checksum
    • At the receiver, all four 16-bit words are added including the checksum. If there’s no errors then the sum will be 1111111111111111. If there’s a 0 we know there has been introduced an error.
  • Given that neither link-by-link reliability nor in-memory error detection is guaranteed, UDP must provide error detection at the transport layer, on an end-end basis, if the end-end data transfer service is to provide error detection.
  • Because IP is supposed to run over just about any layer-2 protocol, it is useful for the transport layer to provide error checking as a safety measure. Although UDP provides error checking, it does not do anything to recover from an error. Some implementation of UDP discard the damaged segment, other just pass it.

results matching ""

    No results matching ""