Chapter 5Transport Layer: UDP, TCP

Professor Rick HanUniversity of Colorado at Boulder

rhan@cs.colorado.edu

Prof. Rick Han, University of Colorado at Boulder

Announcements

• Netstat portion of Homework #3 on Web, due March 12 (two weeks)

• Programming Assignment #2 due Friday March 22 by midnight

• Midterm March 14• Only through Network Layer, Chapter 4

• OH changed today – 4:45-5:45 due to BACTAC talk

• Next, transport layer

Prof. Rick Han, University of Colorado at Boulder

Recap of Previous Lecture• IP Multicast

• 1->N• Link-State Multicast: MOSPF

• Piggyback off of Dijkstra’s shortest path tree• Distance-Vector Multicast: DVMRP

• Reverse-path flooding to all nodes• Reverse-path pruning

• Protocol Independent Multicast: PIM• For sparse wide-area trees• Unicast to Rendezvous Point, RP then

multicasts• Tree built by explicit joins

• Internet Group Management Protocol (IGMP)• How leaf nodes join a multicast group

Prof. Rick Han, University of Colorado at Boulder

The Layered Network Stack

Physical Layer

Application Layer

Transport Layer (TCP/UDP)

Network Layer (IP)

Data Link Layer

Internet Stack

Physical Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

OSI StackPresentation Layer

Application Layer

Prof. Rick Han, University of Colorado at Boulder

UDP: Unreliable Transport Protocols

• IP Provides Best-Effort unreliable datagram delivery

• User Datagram Protocol (UDP) provides best-effort unreliable datagram delivery• Packets may be lost

• Due to congestion• In routers• At receiver and/or sender

• Due to fading• Packets may be reordered• Packets may be duplicated

Prof. Rick Han, University of Colorado at Boulder

UDP (2)• UDP “Features”

• Transport protocol above IP• simply passes IP through to the upper

(application) layers

• UDP “Features”:• Gives app’s the option to send packets

unreliably• Useful for multicast app’s

• Low delay transmission for interactive text/audio/video

• Minimal connection setup time• Minimal connection state: “connectionless”• No congestion control – blast away• Build own application-level protocol on top of

UDP

Prof. Rick Han, University of Colorado at Boulder

UDP (3)

• UDP Header:• Only 8 bytes! (vs. IP 20 bytes header)• Source port for UDP sending process• Dest port for UDP receiving process• Length in bytes of UDP header + payload• Checksum over UDP header + payload

Source Port # Dest. Port #

UDP length Checksum

16 32

UDP payload data

UDP payload

IPhdr

UDPhdr

Prof. Rick Han, University of Colorado at Boulder

UDP (4)• UDP Checksum calculation

• UDP creates a “pseudo-header” containing IP header info

• Doublechecks that the packet has the correct IP address and UDP port #

Source Port # Dest. Port #

UDP length Checksum

16 32

UDP payload data

0 Protocol UDP length

32-bit IP destination address

32-bit IP source address

• Discarded if checksum fails

Pseudo-Header

UDP Header

Prof. Rick Han, University of Colorado at Boulder

UDP Multiplexing/Demultiplexing

IP

Host 1

IP

Host 2

Eth.MAC

Phys.

EthMAC

Phys.

• IP layer inspects Protocol field = UDP

• Sends to buffer of waiting UDP process with matching port #

UDPPort 5100

UDPPort 5200

UDPPort 6001

UDPPort 433

Prof. Rick Han, University of Colorado at Boulder

TCP: Transmission Control Protocol – Reliable Delivery

• TCP provides:• Reliable delivery of packets, AND• Stream or in-order delivery• Also, full-duplex service

• Why TCP, when we can build reliable protocols on top of UDP?• Many applications require reliable in-order

delivery of packets• Web pages, email, file transfer, …

• Why should each application reinvent the wheel?• Can concentrate expert knowledge into building

one reliable protocol provided to every application

Prof. Rick Han, University of Colorado at Boulder

TCP (2)

• TCP is a true transport protocol, above IP• TCP “Features”:

• Flow control• Congestion control• Connection setup• Connection state machine• Reliability, at the cost of some delay

• Achieves reliability by:• Retransmission of a segment after a timeout or

duplicate ACK• Sliding window with sequence #’s

TCP payload

IPhdr

TCPhdr

Prof. Rick Han, University of Colorado at Boulder

TCP (3)• TCP Header:

• 20 bytes• Source port for TCP sending process• Dest port for TCP receiving process• 32-bit Sequence # (host is sender)• 32-bit ACK # (host is receiver ACK’ing data sent

by other endpoint)

Source Port # Dest. Port #

32-bit Sequence #

32-bit Acknowledgement #

Checksum

Window Size

Urgent Pointer

Flags

16 32

Prof. Rick Han, University of Colorado at Boulder

TCP (3)• TCP Header:

• Flags:• SYN: synchronize sequence #’s to initiate

connection• FIN: sender is finished sending data• RST: reset the connection, • More…

Source Port # Dest. Port #

32-bit Sequence #

32-bit Acknowledgement #

Checksum

Window Size

Urgent Pointer

Flags

16 32

Prof. Rick Han, University of Colorado at Boulder

TCP (4)• TCP Header:

• Flow control window size: Receiver advertises how many bytes it is willing to accept into its buffer

• Checksum: computed over TCP header + payload• Similar to UDP, prepends an IP Pseudo-Header

• Urgent Pointer points to where there is emergency data in payload

Source Port # Dest. Port #

32-bit Sequence #

32-bit Acknowledgement #

Checksum

Window Size

Urgent Pointer

Flags

16 32

Prof. Rick Han, University of Colorado at Boulder

TCP (5)• TCP Header:

• Variable-sized (not just 20 bytes), can have Options after the Urgent Pointer field

• Signalled in Flags field• Most common option: Maximum Segment Size

(MSS) exchanged during setup

Source Port # Dest. Port #

32-bit Sequence #

32-bit Acknowledgement #

Checksum

Window Size

Urgent Pointer

Flags

16 32

Prof. Rick Han, University of Colorado at Boulder

High-Level TCP Characteristics

• Protocol implemented entirely at the ends– Fate sharing

• Protocol has evolved over time and will continue to do so

– Nearly impossible to change the header

– Uses options to add information to the header

– Change processing at endpoints

– Backward compatibility is what makes it TCP

Prof. Rick Han, University of Colorado at Boulder

Connection Setup• A and B must agree on initial sequence

number selection• Use 3-way handshake

A B

SYN + Seq ASYN+ACK-A + Seq B

ACK-B

Prof. Rick Han, University of Colorado at Boulder

Connection Setup (2)• Why a three-way handshake?

– Three-way handshake is necessary and sufficient for unambiguous setup/teardown even under conditions of

• Loss• Duplication• Delay

Prof. Rick Han, University of Colorado at Boulder

Two-Way Handshake

Handshake pictures courtesy of UMass Amherst

Prof. Rick Han, University of Colorado at Boulder

Two-Way Handshake: Old Accepts

Prof. Rick Han, University of Colorado at Boulder

Two-Way Handshake: Duplicate Requests

Prof. Rick Han, University of Colorado at Boulder

Two-Way Handshake: Failure

Prof. Rick Han, University of Colorado at Boulder

Two-Way Handshake W/ Timers

Prof. Rick Han, University of Colorado at Boulder

3-way Handshake: Unique ID’s

• Both sender and receiver choose unique ID’s to label their (x,y) connection• x chosen by Sender, y by receiver• Prevents Failure scenario in two-way handshakes

w/o timers

Client:(active)

Server(passive)