Chapter 3 Transport Layer

A note on the use of these ppt slides:
We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright 1996-2004 J.F Kurose and K.W. Ross, All Rights Reserved

Computer Networking: A Top Down Approach Featuring the Internet,
3rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Transport Layer

3-1

Chapter 3: Transport Layer
Our goals: understand the principles behind the transport layer services:
multiplexing/demultipl exing reliable data transfer flow control congestion control

learn about transport layer protocols in the Internet:
UDP: connectionless transport TCP: connection-oriented transport TCP congestion control

Transport Layer

3-2

Chapter 3 outline
3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP
segment structure reliable data transfer flow control connection management

3.6 Principles of congestion control 3.7 TCP congestion control

Transport Layer

3-3

Transport services and protocols
provide logical communication application between application processes transport network running on different hosts data link physical transport protocols run in end systems send side: breaks app messages into segments, adds headers, then passes them to the network layer receive side: reassembles segments into messages, passes them to the application layer network routers act only on the network layer fields of the datagram more than one transport layer protocol available to applications Internet: TCP and UDP
network data link physical network data link physical network data link physical

g lo

d en den al ic

network data link physical

Transport Layer

t or sp an tr

network data link physical application transport network data link physical

3-4

Transport vs. network layer
network layer: logical communication between hosts transport layer: logical communication between
processes within hosts
relies on and enhances the network layer services

Transport Layer

3-5

Internet transport-layer protocols
reliable, in-order delivery (TCP)
congestion control flow control connection setup
application transport network data link physical network data link physical network data link physical

network data link physical

g lo

d en den al ic

unreliable, unordered delivery (UDP)
no-frills extension of “best-effort” IP

network data link physical

t or sp an tr

network data link physical application transport network data link physical

services not available:
delay guarantees bandwidth guarantees

both TCP & UDP provide data integrity checking
Transport Layer 3-6

Chapter 3 outline
3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP
segment structure reliable data transfer flow control connection management

3.6 Principles of congestion control 3.7 TCP congestion control

Transport Layer

3-7

Multiplexing/demultiplexing
Multiplexing at send host:
gathering data from multiple sockets, enveloping data with header (later used for demultiplexing)

Demultiplexing at rcv host:
delivering received segments to the correct socket

Transport Layer

3-8

How demultiplexing works
host receives IP datagrams each datagram has source IP address & destination IP address each datagram carries 1 transport-layer segment each segment has 16-bit source & destination port numbers host uses IP addresses & port numbers to direct segment to appropriate socket

IANA (Internet Assigned Number Authority) Port Number ranges TCP/UDP segment format
Transport Layer 3-9

Connectionless demultiplexing
Create sockets with port numbers:
DatagramSocket clientSocket = new DatagramSocket(); (typically, client port number is automatically assigned) DatagramSocket serverSocket = new DatagramSocket(46428); (server port number specifically assigned by developer)

UDP socket identified by two-tuple: (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 may be directed to the same destination socket Why do we need the source port number for?
Transport Layer 3-10

Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(46428);

Transport Layer

3-11

Connection-oriented demux
TCP socket identified by 4-tuple:
source IP address source port number destination IP address destination port number

Server host may support many simultaneous TCP sockets:

recall that the TCP socket is a two-ended “pipe” destination host uses all four values to direct segment to appropriate socket

Web servers have different sockets for each connecting client

each socket identified by its own 4-tuple

non-persistent HTTP will have different socket for each request

Transport Layer

3-12

Connection-oriented demux (cont)

Transport Layer

3-13

Chapter 3 outline
3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP
segment structure reliable data transfer flow control connection management

3.6 Principles of congestion control 3.7 TCP congestion control

Transport Layer

3-14

UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol “best effort” service, UDP segments may be: lost delivered out of order to app

Why is there a UDP?
faster: less overhead
no connection establishment, which can add delay small segment header no congestion control: UDP can blast away as fast as desired

connectionless:

simpler: less resource usage
no connection state at sender or receiver hosts

no handshaking between UDP sender, receiver each UDP segment handled independently of the others

more clients per server finer control by application:
what data is sent and when add more features as needed
Transport Layer 3-15

UDP: more
often used for streaming multimedia apps loss tolerant rate sensitive
Length, in bytes of UDP segment, including header

32 bits source port # length dest port # checksum

other UDP uses

DNS: for faster response SNMP: usually needed when network is stressed out reliable transfer over UDP:
add reliability at app layer

problems with UDP:

application-specific error recovery! no congestion control

Application data (message) UDP segment format

• high UDP packet loss rates • crowding out TCP sessions
Transport Layer 3-16

UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment Sender:
treat segment contents as sequence of 16-bit integers checksum: addition (1’s complement sum) of segment contents 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?

• some even number of flipped bits • synchronous errors (e.g. same bit in two segments)
Transport Layer 3-17

Internet Checksum Example
Note When adding numbers, a carryout from the most significant bit needs to be added to the result Example: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Transport Layer 3-18

Why error detection in UDP?
no guarantee that all links in between will provide error checking bit errors may happen at the router’s buffer rather than during transfer end-to-end principle in system design in case of segment error detected, damaged segment may be either:
discarded, or passed to the application with warning

Transport Layer

3-19

Chapter 3 outline
3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP
segment structure reliable data transfer flow control connection management

3.6 Principles of congestion control 3.7 TCP congestion control

Transport Layer

3-20

Principles of Reliable data transfer
important in application, transport, and link layers top-10 list of important networking topics!

characteristics of the unreliable channel will determine the complexity of the reliable data transfer protocol (rdt)
Transport Layer 3-21

Reliable data transfer: getting started
rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data(): called by rdt to deliver data to upper

send side

receive side

udt_send(): called by rdt, to transfer packet over unreliable channel to receiver

rdt_rcv(): called when packet arrives on rcv-side of channel
Transport Layer 3-22

Reliable data transfer: getting started
We’ll: incrementally develop the sender and receiver sides of the reliable data transfer protocol (rdt) consider only unidirectional data transfer
but control info will flow on both directions!

use finite state machines (FSM) to specify the sender and receiver
event causing state transition actions taken on state transition event actions state: when in this “state”, the next state is uniquely determined by the next event

state 1

state 2

Transport Layer

3-23

Rdt1.0: reliable transfer over a reliable channel
(the trivial case)
the underlying channel is perfectly reliable
no bit errors no loss of packets

separate FSMs for the sender and receiver:
sender sends data into underlying channel receiver read data from underlying channel

Wait for call from above

rdt_send(data) packet = make_pkt(data) udt_send(packet)

Wait for call from below

rdt_rcv(packet) extract (packet,data) deliver_data(data)

sender

receiver
Transport Layer 3-24

Rdt2.0: channel with bit errors
the underlying channel may flip some bits in the packet

the question is: how to recover from errors?

add a checksum to detect bit errors

new mechanisms in rdt2.0 (beyond rdt1.0):

sender that the packet has been received OK negative acknowledgements (NAKs): the receiver explicitly tells the sender that the packet had errors the sender retransmits the packet on the receipt of a NAK error detection receiver feedback: control msgs (ACK,NAK) receiver retransmission of packets in error

acknowledgements (ACKs): the receiver explicitly tells the

sender

reliable data transfer protocols that are based on retransmission are called ARQ (Automatic Repeat reQuest) protocols
Transport Layer 3-25

rdt2.0: FSM specification
rdt_send(data) sndpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK

receiver
rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ

sender

Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
Transport Layer 3-26

rdt2.0: operation with no errors
rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ

Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
Transport Layer 3-27

rdt2.0: error scenario
rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for Wait for call from ACK or udt_send(sndpkt) above NAK

rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt) Λ

Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)
Transport Layer 3-28

rdt2.0 has a fatal flaw!
What happens if ACK/NAK is corrupted? Handling duplicates:
the sender doesn’t know what happened at the receiver! if it just retransmits, this may possibly cause packet duplication at the receiver the problem is that the receiver doesn’t know whether the ACK/NAK has been delivered correctly! is the arriving packet carrying new data or is it a retransmission? sender retransmits the current packet if ACK/NAK is garbled sender adds a sequence number to each packet receiver discards (doesn’t deliver up) the duplicate packet

stop and wait the sender sends one packet, then waits for the receiver’s response

Transport Layer

3-29

rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Wait for Wait for isNAK(rcvpkt) ) ACK or call 0 from udt_send(sndpkt) NAK 0 above rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Λ Wait for ACK or NAK 1 rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) Wait for call 1 from above If ACK is corrupt or negative, then retransmit Otherwise, wait for the next call for packet with different sequence number

Λ

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)

Transport Layer

3-30

rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) previous packet is received again (i.e.; the previous ACK/NAK is corrupt). Therefore, resend the ACK Transport Layer 3-31

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

rdt2.1: discussion
Sender: a sequence number is added to the packet two sequence numbers (0,1) will suffice. Why? must check if the received ACK/NAK is corrupted twice as many states
state must “remember” whether the “current” packet has a sequence number of 0 or 1

Receiver: must check if the received packet is a duplicate
the state indicates whether the expected sequence number of the next packet is 0 or 1

note: the receiver does not know whether its last ACK/NAK was received OK at the sender

Transport Layer

3-32

rdt2.2: a NAK-free protocol
rdt2.2 has the same functionality as rdt2.1 except that it is using only ACKs (i.e.; no NAKs) instead of sending a NAK, the receiver sends an ACK for the last packet that was received OK
the receiver must explicitly include the sequence number of the packet being ACKed

the duplicate ACK at the sender results in the same action as the NAK (i.e.; retransmit the

current packet)

Transport Layer

3-33

rdt2.2: sender, receiver fragments
rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt)
Wait for call 0 from above Wait for ACK 0

The last good packet had seq #1. Retransmit

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) Λ

sender FSM fragment
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt)

Wait for 0 from below

receiver FSM fragment

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)

Transport Layer

3-34

rdt3.0: channels with errors and loss
New assumption: the underlying channel can also lose packets (data or ACKs)
checksum, sequence numbers, ACKs, and retransmissions will be of help, but will not be enough

Approach: the sender waits a “reasonable” amount of time for the ACK
retransmits if no ACK is received within this time if the packet (or ACK) is just delayed (not lost): the retransmission will be a duplicate, but the use of sequence numbers already handles this issue the receiver must specify the sequence number of the packet being ACKed this requires a countdown timer
Transport Layer 3-35

rdt3.0 sender
rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer Wait for call 0 from above Wait for ACK0 rdt_rcv(rcvpkt)

Duplicate ACK delayed ACK or premature timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )

Λ
timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer

Λ

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer Wait for ACK1 rdt_send(data)

timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )

Wait for call 1 from above

rdt_rcv(rcvpkt)

Λ

Λ

sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer

Transport Layer

3-36

rdt3.0 in action

Transport Layer

3-37

rdt3.0 in action

Transport Layer

3-38

rdt3.0: stop-and-wait operation
sender first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R RTT first packet bit arrives last packet bit arrives, send ACK receiver

ACK arrives, send next packet, t = RTT + L / R
effective transmission time

utilization of the sender

U

sender

=

L/R RTT + L / R

=

.008
30.008

= 0.00027
total time

U sender: utilization – fraction of time sender busy sending
Transport Layer 3-39

Performance of rdt3.0
rdt3.0 works, but performance is very bad example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
Ttransmit = L (packet length in bits) 8kb/pkt = = 8 microsec R (transmission rate, bps) 10**9 b/sec

U

sender

=

L/R RTT + L / R

=

.008
30.008

= 0.00027

1KB pkt every 30 msec 267 Kbps throughput over 1 Gbps link in this case, the network protocol limits the use of the physical resources!
Transport Layer 3-40

Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged packets
range of sequence numbers must be increased buffering at sender and/or receiver must be added

Two generic forms of pipelined protocols: Go-Back-N (GBN) Selective Repeat (SR)

Transport Layer

3-41

Pipelining: increased utilization
sender first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK receiver

RTT

ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3!

U

sender

=

3*L/R RTT + L / R

=

.024
30.008

= 0.0008

Transport Layer

3-42

Go-Back-N (GBN): Sliding Window Protocol
Sender:
add a k-bit sequence # in the packet header “sliding window” of up to N, consecutive unacknowledged packets allowed

ACK(n): indicates that all packets up to and including seq # n have been acknowledged – this is called “cumulative ACK” timer for the first un-ACK packet (first in the window) timeout(n): retransmit packet n and all higher seq # packets in the window
Transport Layer 3-43

GBN: sender extended FSM
rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer Keep track of the nextseqnum++ oldest un-ACK packet } (1st in window). One else timer for all. refuse_data(data) timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) No more un-ACK packets left

Λ
base=1 nextseqnum=1

Wait
rdt_rcv(rcvpkt) && corrupt(rcvpkt)

Λ
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer

Transport Layer

3-44

GBN: receiver extended FSM
only send ACK for correctly-received packet with highest in-order seq # packet are delivered in order out-of-order packet:
may generate duplicate ACKs need only remember expectedseqnum

discard (don’t buffer) -> no receiver buffering! re-ACK packet with highest in-order seq #

Λ
expectedseqnum=0 sndpkt = make_pkt (2k-1,ACK,chksum) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ Transport Layer 3-45

Wait

default udt_send(sndpkt)

GBN in action (window size = 4)

Transport Layer

3-46

Performance issues of GBN protocol
good out-of-order packets are discarded by the receiver and then retransmitted!!
however, this simplifies the receiver design
• no buffering • only keep track of the “expectedseqnum” variable

Performance problems when:

window size and bandwidth-delay product are big a single error causes a retransmission of large number of all previously un-ACK packets as the packet error probability increases, the pipeline will be more filled
Transport Layer 3-47

• many packets may be in the pipeline

Selective Repeat
the receiver individually acknowledges all correctly received packets
buffers packets, as needed, for eventual in-order delivery to the upper layer

the sender only resends the packets for which the ACK has not been received
a sender timer is needed for each unACKed packet

sender window
N consecutive seq #’s again limits seq #’s of sent, unACKed pakets

Transport Layer

3-48

Selective repeat: sender, receiver windows

Transport Layer

3-49

Selective repeat
sender data from above :
if next available seq # is within window, send packet

receiver pkt n in [rcvbase, rcvbase+N-1]
send ACK(n) if out-of-order, buffer it if in-order, deliver it (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt

timeout(n):
resend packet n and restart the timer

ACK(n) in [sendbase,sendbase+N-1]:
mark packet n as received if n is the smallest unACKed packet, advance window base to next unACKed seq #

pkt n in [rcvbase-N,rcvbase-1]
ACK(n) (why??)

otherwise:
ignore (why??)

Transport Layer

3-50

Selective repeat in action

Transport Layer

3-51

Selective repeat: dilemma
Example:
seq #’s: 0, 1, 2, 3 window size=3 receiver sees no difference in two scenarios! incorrectly passes duplicate data as new in (a) Q: what relationship between seq # size and window size?
Transport Layer 3-52

Chapter 3 outline
3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP
segment structure reliable data transfer flow control connection management

3.6 Principles of congestion control 3.7 TCP congestion control

Transport Layer

3-53

TCP: Overview
logical point-to-point: reliable, in-order byte steam:
one sender, one receiver MSS: Maximum Segment Size (max application msg size) MTU: Maximum Trans. Unit (max. data-link frame length) TCP congestion and flow control set the window size

RFCs: 793, 1122, 1323, 2018, 2581 full duplex data:
bi-directional data flow in same connection 3-way handshaking (exchange of control msgs) initializes sender and receiver states before the data exchange the sender will not overwhelm the receiver

connection-oriented:

pipelined:

flow controlled:

send & receive buffers

socket door

application writes data TCP send buffer
segment

application reads data TCP receive buffer

socket door

Transport Layer

3-54

TCP segment structure
32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

source port #

dest port #

sequence number
head not UA P R S F len used

acknowledgement number
Receive window Urg data pointer checksum

Counting by the # of bytes of data (not segments!) the # bytes the receiver is willing to accept (used for flow control)

Options (variable length) application data (variable length)

Transport Layer

3-55

Numbering Bytes in TCP
Example:
File size = 500,000 bytes MMS = 1,000 bytes 500 segments First byte number = 0 (typically randomly selected) First segment sequence number = 0 Second segment sequence number = 1000 Last segment sequence number = 499,000

Transport Layer

3-56

TCP seq. #’s and ACKs
Seq. #’s: is the byte stream “number” of first byte in segment’s data ACKs: the seq # of the next byte expected from the other side cumulative ACK Q: how does the receiver handle out-of-order segments A: TCP spec doesn’t specify. It leaves it up to implementer
Transport Layer 3-57

ACK can be Piggybacked on data segment

Chapter 3 outline
3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP
segment structure reliable data transfer flow control connection management

3.6 Principles of congestion control 3.7 TCP congestion control

Transport Layer

3-58

TCP reliable data transfer
TCP creates rdt service on top of IP’s unreliable service Pipelined segments Cumulative Ack’s TCP uses single retransmission timer Initially consider a simplified TCP sender:
ignore duplicate Ack’s ignore flow control, congestion control

Retransmissions are triggered by:
timeout events duplicate Ack’s

Transport Layer

3-59

TCP sender events:
data received from application: create segment with the next seq # the seq # is the bytestream number of first data byte in segment start the timer if not already running (a timer for the oldest unAck’ed segment) expiration interval: TimeOutInterval timeout: retransmit the segment that caused the timeout restart the timer Ack recieved: if it Acknowledges previously unAck’ed segments
update what is known to be acknowledged start timer if there are outstanding segments

Transport Layer

3-60

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */

TCP sender

(simplified)
Comment: • SendBase-1: last cumulatively ack’ed byte

Transport Layer

3-61

TCP: retransmission scenarios
Host A
Seq=9 2

Host B
, 8 byt es da

Host A
Seq=9 2

Host B
, 8 byt es da

ta

Seq=92 timeout

Seq= 1

timeout

100 CK= A

00, 2 0 byt

ta
ta

es da

loss
Seq=9 2 , 8 byt es da ta

X

00 0 =1 CK CK=12 A A

Seq=9 2
Sendbase = 100 SendBase = 120

, 8 byt es da

ta

100 C K= A
SendBase = 100 SendBase = 120

A

=1 2 CK

0

time

lost ACK scenario

time

premature timeout

Transport Layer

3-62

TCP retransmission scenarios (more)
Host A
Seq=9 2

Host B
, 8 byt es da

ta

timeout

Seq=1 0

loss
120 C K= A

X

100 CK= A 0, 20 bytes data

SendBase = 120

Doubling Timeout Interval: Congestion happens when a router receives too many packets that start filling the queue and causing drop outs or extended delays Timeout is most likely caused by traffic congestion Whenever a timeout occurs, the timeout interval is doubled (exponentially grows)
Limited form of congestion control

time Cumulative ACK scenario

This applies to current segment only.
Transport Layer 3-63

TCP ACK generation
Event at Receiver
Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. # . Gap detected Arrival of segment that partially or completely fills gap

[RFC 1122, RFC 2581]

TCP Receiver action
Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments

Immediately send duplicate ACK, indicating seq. # of next expected byte

Immediate send ACK, provided that segment starts at lower end of gap
Transport Layer 3-64

Fast Retransmit
Time-out period is often relatively long:
there is a long delay before resending a lost packet

Detect lost segments via duplicate ACKs.
Sender often sends many segments back-toback If a segment is lost, there will likely be many duplicate ACKs.

If the sender receives 3 ACKs for the same data, it supposes that the segment after the ACKed data was lost:
fast retransmit: resend the segment before the timer expires

Transport Layer

3-65

Fast retransmit algorithm:
event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment

fast retransmit

Transport Layer

3-66

IS TCP RDT GBN or SR Protocol?
cumulative ACK (GBN) single timer for oldest unACK segment (GBN) mostly buffers good but out-of-order segments (SR) Retransmit only one segment (SR) Result: TCP RDT is an enhanced hybrid of GBN and SR

Transport Layer

3-67

Chapter 3: Summary
principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control instantiation and implementation in the Internet UDP TCP

Next: leaving the network “edge” (application, transport layers) into the network “core”
Transport Layer 3-68