1.1 Introduction and Transport-Layer Services

Principles:

• multiplexing, demultiplexing
• reliable data transfer
• flow control
• congestion control

Protocols:

• UDP: connectionless transport

• TCP: connection-oriented reliable transport

• provide logical communication between app processes running on different hosts

• transport protocols run in end systems

  • sender side: breaks app messages into segments, passes to network layer
  • receiver side: reassembles segments into messages, passes to app layer

Transport vs. network layer

network layer:

• communication between hosts

transport layer:

• logical communication between processes (relies on, enhances, network layer services)

Internet transport-layer protocols

TCP:

• reliable, in-order delivery
• congestion-control
• flow control
• connection setup

UDP

• unreliable, unordered delivery
• no frills, extension of "best-effort" IP

Services NOT available:

• delay guarantees
• bandwidth guarantees
• security guarantees

1.2 Multiplexing and Demultiplexing

multiplexing at sender: handle data from multiple sockets, add transport header (later used for demultiplexing)

demultiplexing at receiver: use header info to deliver received segments to correct

Demultiplexing

Host receives IP datagram (at the network layer):

• each datagram has a source and destination IP address
• each datagram carries one transport layer-segment
• each segment has source, destination port number

Host uses IP address and port numbers to direct to appropriate socket

Connectionless demultiplexing (UDP)

• Only cares for the destination not source
• UDP socket is identifed by two-touple (dest IP, dest port)
• When host receives UDP segment:
  • checks dest port
  • directs segment to socket with that port number
• IP datagrams with different source IP addresses and/or source port numbers directed to same socket

Connection-oriented demux (TCP)

• TCP socket identified by 4-tuple (source IP, source port, dest IP, dest port)
• demux: receiver uses all four values to direct segment to appropriate socket
• Server host, may support many simultaneous TCP sockets, each identified by its own 4-tuple
• web servers have different sockets for each connecting client

1.3 UDP - Connectionless transport

• connectionless - no handshake (low delay)
• small header size
• unreliable
• no congestion control
• EX: streaming media apps (loss tolerant, rate sensitive)

Reliability:

• add reliability at appliaction layer
• application-specific error recovery

1.4 TCP - Connection-Oriented transport

• point-to-point: one sender, one receiver
• reliable, in order byte stream: ordered by bytes, not packet numbers
• pipelined: TCP congestion and flow control set window size
• full duplex data: -> bi-diretional data flow in same connection -> MSS: maximum segment size
• connection-oriented: handshaking (exchange of control msgs) inits sender, receiver state before data exchange
• flow controlled: sender will not overwhelm receiver. If the receiver buffer is overwhelmed, it informs the sender to slow down, so that there is no packet drop in each end

Packet Format

TCP seq. numbers, ACKS

sequence numbers:

• byte stream "number" of first byte in segment' s data

acknowledgements:

• seq # of next byte expected from other side
• cumulative ACK

How does the receiver handle out-of-order segments? TCP spec doesn't say, up to implementor/programmer

Reliable data transfer

RTT (Round trip time)

how to estimate RTT: SampleRTT: measured time from segment transmission until Ack receipt, ignore retransmissions

SampleRTT will vary, want estimated RTT "smoother", average several recent measurements, not just current SampleRTT

$EstimatedRTT = (1- a) * EstimatedRTT + a*SampleRTT$

a typically is 0.125

TCP creates rdt service on top of IP's unreliable service:

• pipelined segments
• cumulative acks
• single retransmission timer

retransmissions triggered by:

• timeout events
• duplicate acks (fast retransmission)

let's initially consider simplified TCP sender:

• ignore flow control
• ignore flow control, congestion control

TCP sender:

Stop and wait ARQ

• After transmitting a frame the sender waits for an ack before transmitting the next frame
• If it does not receive the ack after a timeout it resends the original frame

Drawbacks:

• poor performance as it sends a frame at a time, therefore poor utilization of bandwidth

Sliding window protocol

• Send multiple frames at a time
• The number of frames sent is based on the window size
• Each frame is numbered → sequence number

If window size is 4 it means 4 frames can be sent without getting an ack

Go-Back-N ARQ

N → sender window size

• uses concept of protocol pipelining, send multiple fames before getting the ack of the first frame
• finite number of frames numbered sequencially
• number of frames sent depend on window size
• If the ack of a frame does not arrive before timeout, all frames in current window are retransmitted

Congestion Control

• makes sure avery flow gets a fare share of the bandwidth by ajusting the window size

• when a loss occurs, cuts the window size by half

• window size is increased linearly when ack comes back, until a loss occurs

Uses three methods to minimize congestion:

• AIMD (Additive Increase/Multiplicative Decrease)
• SlowStart
• Conservative after timeoout

Janela de Congestão (CongWin): LastByteSent – LastByteAcked <= MIN ( RecvWin,CongWin)

cwnd → congestion window size

AIMD (Addictive Increase Multiplicative Decrease)

Slow Start

Congestion Avoidance (CA)