COMP 3400 Networks Lecture 6: Transport Layer - Reliable Delivery, TCP
major resource: Computer Networking (4th Edition), Kurose and Ross, Addison Wesley, 2008

[ previous | schedule | next ]

Simplest protocol for reliable delivery

• assumes reliable channel and fast receiver
• Sender: when application supplies data, put into packets and send
• Receiver: when packet arrives, pass data up to application layer.

Stop-and-wait protocols for reliable delivery

• This family of protocols drops assumption that receiver infinitely fast.
• Sender must avoid flooding slow receiver. Must implement flow control.
• Several variations follow

Stop-and-wait with reliable channel

• Sender: when application layer supplies data, send data packet and wait for ACK (acknowledgement) packet to arrive. After ACK arrives, send next packet.
• Receiver: when data packet arrives, send ACK packet to sender. Pass data up to application layer.

Stop-and-wait with corrupt channel

• unreliable channel which can corrupt bits (but not lose them) and slow receiver
• The following protocol (rdt2.0) will work in almost all cases
  • Sender: when application layer supplies data, send data packet and wait for ACK or NAK (negative acknowledgement) packet to arrive. If ACK, send next packet. If NAK, resend same packet.
  • Receiver: when data packet arrives, check for error. If none, send ACK packet to sender else send NAK packet. Pass data up to application layer.
  • When will this not work? (hint: errors are not exclusive to data packets)
• Problem: what if ACK/NAK is corrupted? See rdt2.1
  • Solution: Add sequence number to data packet. 0 or 1 will do.
  • Sender: toggle sequence number before sending new data packet.
  • Receiver: If arriving packet has same sequence number as last one, it is duplicate so ACK it (since sender didn’t know it was received) then discard it.
  • Total solution requires all the functionality listed above for sender and receiver.
    • Sender: when application layer supplies data, toggle sequence number, send data packet and wait for ACK or NAK packet to arrive. If ACK, send next packet. If NAK or garbled, resend same packet.
    • Receiver: when data packet arrives, check for garbled. If garbled, send NAK packet to sender. If duplicate, send ACK then discard data. If correct packet, send ACK. Pass data up to application layer.

Stop-and-wait with lossy channel

• Suppose packets may not only be corrupted in transit but may disappear completely
• Given version the protocols above, you need only add timer to sender.

Consider performance of all stop-and-wait protocols

• Propagation delay is major factor - how long it takes bit to physically move from A to B
• Round trip propagation determines how long until sender receives ACK! Sender must remain idle all this time.
• For example, round trip between earth and geosynchronous satellite is half a second!
• Very inefficient

Sliding window protocols for reliable delivery

• Improve performance by providing pipelining
• Two flavors are:
  • Go-Back-N (retransmit all packets since last confirmed ACK)
    • Sender has window (range of array elements) of N packet “slots”: each slot is either available or holds a packet x transmitted but not yet ACKed
    • Sender will transmit until window is full, ACK/NAK received, or timeout
    • If ACK x, slot x+1 becomes "left edge" and slot x+N becomes "right edge" (this is the slide)
    • The window is "circular array" of size >= N, so the increments are actually mod size.
    • If NAK or timeout, retransmit everything in the window (this is the Go-Back-N)
  • Selective Repeat (retransmit only packets w/o confirmed ACK)
    • Refinement of go-back-N.
    • Keep timer and ACK marker for each slot
    • When ACK x received, set slot x ACK marker
    • When NAK or timeout on slot x, retransmit only packet x (this is the selective repeat)
    • When leftmost sub-range of slots all have ACK marked, then slide the window past that sub-range.
• TCP sliding window protocol is combo of these two.

TCP – Transport Control Protocol

Overview

• host-to-host (end-to-end) service
• reliable, error free, sequenced, stream service
• pipelined (sliding window) transmission with buffers
• full duplex (bi-directional at same time)
• provides flow and congestion control
• Unit of transmission is segment

TCP Segment Structure

• Field	Bits	Description
  Source Port	16	service access point at source host
  Destination Port	16	service access point at destination host
  Sequence Number	32	byte offset, for sliding window transmission
  Acknowledgement Number	32	also used in sliding window
  TCP Header Length	4	in 32-bit words
  unused	6
  Code Bits	6	six 1-bit control fields, explained below
  Window Size	16	used in variable-length sliding window
  Checksum	16	1's comp. sum of segment in 16-bit words
  Urgent Pointer	16	byte offset of special signals (e.g. Ctrl-C)
  Options	n * 32	n = # options specified
  Data	0-max	max = what will fit in datagram

• Header (all except last row) has 20 byte fixed length fields plus variable options field
• Selected field notes:
  • Header length is 4 byte field, count of header length in 4-byte words
  • Sequence and ack numbers are 32 bits, and represent byte counts
    • Sequence number is byte stream position of first data byte in segment
    • Ack number is sequence number of next byte expected
  • Receiver window size field is 16 bits, and represents the number of bytes that receiver is willing to receive (e.g. has available in receive buffer)
  • The "6 flags" are:
    • RST, SYN, FIN : used for connection maintenance
    • ACK : this segment contains acknowledgement
    • URG, PSH : URG high priority info; PSH deliver directly - both rarely used

TCP Reliable Transmission

• Variable length sliding window with per-segment timers and retransmission
• cumulative ACKs
• ACK may be piggybacked on data segment heading in other direction on full duplex connection
• Receiver can either accept or reject out-of-order segment

• seq# and ack# are byte counts in transmission stream
• initial seq# selected at random (what is probability of 0?)
• sender and receiver exchange initial seq# during connection set-up
• for a given segment, seq# = byte offset for first byte of payload, e.g. (init seq# + stream byte offset) mod 2**16
• for a given segment, ack# = seq# of next byte expected from sender

TCP Connection setup : 3 way handshake

1. client-to-server connection request :
   • SYN bit set,
   • seq# is clients initial number (random selection)
   • empty payload
2. server-to-client response:
   • (allocates TCP buffer space and variables before responding)
   • SYN and ACK bits set
   • seq# is servers initial number (random selection)
   • ack# is clients initial number + 1
   • empty payload
3. client-to-server confirmation:
   • (allocates TCP buffer space and variables)
   • ACK bit set
   • seq# is clients initial number + 1
   • ack# is servers initial number + 1
   • empty payload

SYN Flood: Connection protocol makes server vulnerable to SYN flood denial of service attack: Malicious client sends flood of fake SYN requests, server allocates buffer space before verifying the request via handshake. Solution? SYN cookie: server does not allocate upon SYN request but instead crafts special initial Sequence number in its SYN response. If ACK response arrives, verify ack number then allocate buffers.

Double exchange to terminate connection

1. A is finished, sends B a segment with FIN bit set.
2. B sends acknowledgement to A, and deallocates its buffers

3. B sends A a segment with FIN bit set
4. A sends acknowledgement to B, waits awhile, then deallocates its buffers

TCP Flow and Congestion Control

• Flow control refers to flow of packets between adjacent nodes
• Congestion control refers to flow of packets throughout the network
• related but not the same...think of adjacent traffic lights (flow) versus the Columbus area interstate system (congestion)
• TCP Flow: receiver tells sender how much buffer space it has available, so sender can adjust flow if receiver overwhelmed
• TCP Congestion: no direct knowledge of network conditions, makes inferences from observed abnormal behavior (delayed or dropped deliveries)