Chapter 3 Transport Layer - University of Nevada, Reno

Transport Layer 3-1

Chapter 3Transport Layer

Computer Networking: A Top Down Approach 6th edition Jim Kurose, Keith RossAddison-WesleyMarch 2012

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 see the animations; and 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) that you mention their source

(after all, we’d like people to use our book!) If you post any slides 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-2013J.F Kurose and K.W. Ross, All Rights Reserved

Lecture 7

University of Nevada – RenoComputer Science & Engineering Department

Fall 2015

CPE 400 / 600Computer Communication Networks

Prof. Shamik SenguptaOffice SEM 204

[email protected]://www.cse.unr.edu/~shamik/

Chapter 3Transport Layer

Transport LayerOur goals: understand principles behind transport layer services learn about transport layer protocols in the Internet:

UDP: connectionless unreliable transport TCP: connection-oriented reliable transport

TCP: connection oriented reliable transport Principles of reliability Connection management flow control congestion control

Transport services and protocols provide logical communication

between processes running on different hosts

transport protocols run in end systems

End-to-end communications send side: breaks app

messages into segments, passes to network layer

rcv side: reassembles segments into messages, passes to app layer

applicationtransportnetworkdata linkphysical


Internet transport-layer protocols

reliable, in-order delivery: TCP Connection oriented

unreliable, unordered delivery: UDP Mostly used for streaming

services DNS queries

More delay sensitive than loss sensitive


networkdata linkphysical







UDP: User Datagram Protocol [RFC 768]

At a quick glance: “no frills,” “bare bones”

Internet transport protocol “best effort” service, UDP

segments may be: lost delivered out of order to

app connectionless:

no handshaking between UDP sender, receiver

each UDP segment handled independently of others

Why is there a UDP? no connection establishment

(which can add delay) simple: no connection state at

sender, receiver small segment header – only 8

bytes compared to TCP’s 20 bytes

no congestion control: UDP can blast away as fast as desired

UDP: more

often used for streaming multimedia apps loss tolerant rate sensitive

other UDP uses DNS SNMP DHCP Majorly in control comn.

source port # dest port #

32 bits

Applicationdata (message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header

UDP checksum

Sender: treat segment contents as

sequence of 16-bit integers checksum: addition of

segment contents and then take 1’s complement

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?

Goal: detect “errors” (e.g., flipped bits) in transmitted segment

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 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

wraparound

sumchecksum

Internet Checksum Example

Suppose that we have the following: 0110011001100000 0101010101010101 1000111100001100

What is the checksum?

Transport Layer Protocolfor reliable data transfer

Principles of Reliable data transfer

Sender sends one packet, then waits for receiver response

stop and wait

Sender needs to know whether receiver has received the packets

Simplest implementation:

A very interesting case of sequence numbers!

Stop & Wait protocol

14

World is not ideal

Practical scenario: underlying channel can lose packets (data or ACKs) because of many reasons What if data packet gets

lost? What if Ack packet gets

lost?

Stop & wait protocol with loss

16

World is not ideal

Practical scenario: underlying channel can lose packets (data or ACKs) because of many reasons

What if data packet gets lost?

What if Ack packet gets lost?

Approach: sender waits “reasonable” amount of time for ACK

retransmits if no ACK received in this time

17

ACK packet lost

18

New constraint: Stop & wait protocol with delay

Practical scenario: What if Ack packet just

delayed (not lost)

Approach: sender waits “reasonable” amount of time for ACK

retransmits if no ACK received in this time

if pkt (or ACK) just delayed (not lost): retransmission will be

duplicate

Sender, receiver need to specify seq # of pkt being handled

19

Stop & wait protocol with delay

20

Performance of stop-and-wait

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

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

U sender =

.008 30+.008

= 0.00027

L / R RTT + L / R

=

Packet size = 8 KbTransmission rate = 1 Mbps

= 30 sec.

Not very efficient!!!

Lecture 8


Fall 2015




Transport Layer 3-23

Pipelined protocols

pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver

two generic forms of pipelined protocols: go-Back-N, selective repeat


Pipelining: increased utilization

first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

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

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

3-packet pipelining increasesutilization by a factor of 3

U sender =

.0024 30.008

= 0.00081 3L / R

RTT + L / R =


Pipelined protocols: overview

Go-back-N: sender can have up to

N unacked packets in pipeline

receiver only sends cumulative ack doesn’t ack packet if

there’s a gap sender has timer for

oldest unacked packet when timer expires,

retransmit all unacked packets

Selective Repeat: sender can have up to N

unack’ed packets in pipeline

rcvr sends individual ackfor each packet

sender maintains timer for each unacked packet when timer expires,

retransmit only that unacked packet


Go-Back-N: sender k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed

ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs (see receiver)

timer for oldest in-flight pkt timeout(n): retransmit packet n and all higher seq # pkts in

window


ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum

out-of-order pkt: discard (don’t buffer): no receiver buffering! re-ACK pkt with highest in-order seq #

GBN: receiver


GBN in action

send pkt0send pkt1send pkt2send pkt3

(wait)

sender receiver

receive pkt0, send ack0receive pkt1, send ack1

receive pkt3, discard, (re)send ack1rcv ack0, send pkt4

rcv ack1, send pkt5

pkt 2 timeoutsend pkt2send pkt3send pkt4send pkt5

Xloss

receive pkt4, discard, (re)send ack1

receive pkt5, discard, (re)send ack1

rcv pkt2, deliver, send ack2rcv pkt3, deliver, send ack3rcv pkt4, deliver, send ack4rcv pkt5, deliver, send ack5

ignore duplicate ACK

0 1 2 3 4 5 6 7 8

sender window (N=4)

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8


Selective repeat

receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery

to upper layer

sender only resends pkts for which ACK not received sender timer for each unACKed pkt

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


Selective repeat

data from above: if next available seq # in

window, send pkttimeout(n): resend pkt n, restart timerACK(n): mark pkt n as received if n smallest unACKed pkt,

advance window base to next unACKed seq #

senderpkt n send ACK(n) out-of-order: buffer in-order: deliver (also

deliver buffered, in-order pkts), advance window to next not-yet-received pkt

otherwise: ignore

receiver


Selective repeat in action

send pkt0send pkt1send pkt2send pkt3

(wait)

sender receiver

receive pkt0, send ack0receive pkt1, send ack1

receive pkt3, buffer, send ack3rcv ack0, send pkt4

rcv ack1, send pkt5

pkt 2 timeoutsend pkt2

Xloss

receive pkt4, buffer, send ack4

receive pkt5, buffer, send ack5

rcv pkt2; deliver pkt2,pkt3, pkt4, pkt5; send ack2

record ack3 arrived

0 1 2 3 4 5 6 7 8

sender window (N=4)

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

record ack4 arrived

record ack5 arrived

Q: what happens when ack2 arrives?


Selective repeat:dilemma

example: seq #’s: 0, 1, 2, 3 window size=3

receiver window(after receipt)

sender window(after receipt)

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

pkt0

pkt1

pkt2

0 1 2 3 0 1 2 pkt0

timeoutretransmit pkt0

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2XXX

will accept packetwith seq number 0

(b) oops!

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

pkt0

pkt1

pkt2

0 1 2 3 0 1 2pkt0

0 1 2 3 0 1 2

0 1 2 3 0 1 2

0 1 2 3 0 1 2

X

will accept packetwith seq number 0

0 1 2 3 0 1 2 pkt3

(a) no problem

receiver can’t see sender side.receiver behavior identical in both cases!something’s (very) wrong!

receiver sees no difference in two scenarios!

duplicate data accepted as new in (b)

Q: what relationship between seq # size and window size to avoid problem in (b)?


Reliable Data Transfer Mechanisms

Acknowledgement to tell the sender that a

packet or set of packets has been received correctly.

Pipelining to improve sender

utilization over a stop- and-wait mode of operation.

Checksum to detect bit errors in a

transmitted packet

Timer to timeout/ retransmit a

packet, possibly because the packet ( or its ACK) was lost within the channel

Sequence Number for sequential numbering

of packets of data flowing from sender to receiver.


TCP: Overview RFCs: 793,1122,1323, 2018, 2581

full duplex data: bi-directional 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

point-to-point: one sender, one receiver

reliable, in-order byte steam: no “message boundaries”

pipelined: TCP congestion and flow

control set window size

Lecture 9


Fall 2015




Homework 1 submission due

Introduction 1-36


TCP segment structure


32 bits

applicationdata (variable length)

sequence numberacknowledgement number

receive window

Urg data pointerchecksumFSRPAUhead

lennotused

options (variable length)

URG: urgent data (generally not used)

ACK: ACK # valid

PSH: push data now(generally not used)

RST, SYN, FIN:connection estab(setup, teardown

commands)

# bytes rcvr willingto accept

counting by bytes of data(not segments!)

Internetchecksum

(as in UDP)


TCP seq. numbers, ACKssequence numbers:byte stream “number” of first byte in segment’s data

acknowledgements:seq # of next byte expected from other sidecumulative ACK

Q: how receiver handles out-of-order segmentsA: TCP spec doesn’t say, - up to implementor



checksum

rwndurg pointer

incoming segment to sender

A

sent ACKed

sent, not-yet ACKed(“in-flight”)

usablebut not yet sent

not usable

window sizeN

sender sequence number space



checksum

rwndurg pointer

outgoing segment from sender


TCP seq. numbers, ACKs

Usertypes ‘c’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of ‘c’, echoes back ‘C’

simple telnet scenario

Host BHost A

Seq=42, ACK=79, data = ‘c’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80


TCP round trip time, timeout

Q: how to set TCP timeout value?

longer than RTT but RTT varies

too short: premature timeout, unnecessary retransmissions

too long: slow reaction to segment loss

Q: 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


RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(milli

seco

nds)

EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT

exponential weighted moving average influence of past sample decreases exponentially fast typical value: α = 0.125

TCP round trip time, timeoutRT

T (m

illis

econ

ds)

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

sampleRTT

EstimatedRTT

time (seconds)


timeout interval: EstimatedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin

estimate SampleRTT deviation from EstimatedRTT: DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT|

TCP round trip time, timeout

(typically, β = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”


TCP RTT calculation

Q: Initial estimate of RTT = 52ms. After 3 stages of measurements, sample RTTs=36, 32, 32ms. What is the new estimated RTT at the beginning of 4th stage?

Assume α = 0.25. Repeat with α = 0.5.Comment on your answer.

Q: Repeat the above with sample=36, 500, 52ms.


TCP RTT calculation comment

Comment 1: Choosing α-value close to 0 makes the weighted average immune to high fluctuations for short time

Comment 2: Choosing α-value close to 1 makes the weighted average respond to high fluctuations quickly


TCP: reliable data transfer


TCP reliable data transfer

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

let’s initially consider simplified TCP sender: ignore duplicate acks ignore flow control,

congestion control


TCP sender events:data rcvd from app: create segment with

seq # seq # is byte-stream

number of first data byte in segment

start timer if not already running think of timer as for

oldest unacked segment

expiration interval: TimeOutInterval

timeout: retransmit segment

that caused timeout restart timerack rcvd: if ack acknowledges

previously unacked segments update what is known

to be ACKed start timer if there are

still unacked segments


TCP: retransmission scenarios

lost ACK scenario

Host BHost A

Seq=92, 8 bytes of data

ACK=100


Xtimeo

ut

ACK=100

premature timeout

Host BHost A


ACK=100

Seq=92, 8bytes of data

timeo

ut

ACK=120


ACK=120

SendBase=100

SendBase=120

SendBase=120

SendBase=92


TCP: retransmission scenarios

X

cumulative ACK

Host BHost A


ACK=100


timeo

ut


ACK=120


TCP ACK generation [RFC 1122, RFC 2581]

event at receiver

arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

arrival of in-order segment withexpected seq #. One other segment has ACK pending

arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

arrival of segment that partially or completely fills gap

TCP receiver action

delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

Send cumulative ACK, ACKing both in-order segments

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

immediate send ACK, provided thatsegment starts at lower end of gap


TCP fast retransmit

time-out period often relatively long: long delay before

resending lost packet

detect lost segments via duplicate ACKs. sender often sends

many segments back-to-back

if segment is lost, there will likely be many duplicate ACKs.

if sender receives 3 ACKs for same data(“triple duplicate ACKs”),resend unacked segment with smallest seq # likely that unacked

segment lost, so don’t wait for timeout

TCP fast retransmit


X

fast retransmit after sender receipt of triple duplicate ACK

Host BHost A


ACK=100

timeo

ut ACK=100

ACK=100

ACK=100

TCP fast retransmit



Project Discussion

Introduction 2-53

Sample Project Topics

CPE 400 Simulation

WiFi Medium access control ARP and ARP spoofing Statistical multiplexing in flow

control of routers in a network Optimized Link State Routing

(OLSR) Protocol Better Approach To Mobile Adhoc

Networking (B.A.T.M.A.N.) Routing in VANET/FANET Multicasting and group management

CPE 600 Research Survey Topics

D2D Communication for future 5G networks

Platoon-Based Vehicular Cyber-Physical Systems• Architecture and Challenges

Internet-of-Things (IoT)• Self-organization• Security and privacy issues

Software Defined Networks Interference mitigation in Femtocells Crowdsourcing in Heterogeneous

Networked Environments

Introduction 2-54


TCP congestion control


congestion: informally: “too many sources sending too much

data too fast for network to handle”

result: lost packets

• buffer overflow at routers

long delays• queueing in router buffers

a top-10 problem!

Principles of congestion control

Causes/costs of congestion: scenario 1

two senders, two receivers one router, infinite buffers output link capacity: R no retransmission

unlimited shared output link buffers

Host A

original data: λin

Host B

throughput: λout


one router, finite buffers sender retransmission of timed-out packet transport-layer input includes retransmissions

finite shared output link buffers

Host A

λin : original data

Host B

λoutλ'in: original data, plusretransmitted data



four senders multihop paths timeout/retransmit

Q: what happens as λin and λin’

increase ?

finite shared output link buffers

Host A λout


Host B

Host CHost D

λin : original dataλ'in: original data, plus

retransmitted data

A: as red λin’ increases, all arriving

blue pkts at upper queue are dropped, blue throughput 0


Approaches towards congestion control

two broad approaches towards congestion control:

end-end congestion control:

no explicit feedback from network

congestion inferred from end-system observed loss, delay

approach taken by TCP

network-assisted congestion control:

routers provide feedback to end systems single bit indicating

congestionexplicit rate for

sender to send at

61

TCP congestion control: bandwidth probing

“probing for bandwidth”: increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate continue to increase on ACK, decrease on loss (since

available bandwidth is changing, depending on other connections in network)

ACKs being received, so increase rate

X

X

XX

X loss, so decrease rate

send

ing

rate

time

Q: how fast to increase/decrease? details to follow

TCP’s“sawtooth”behavior

TCP congestion control:

two “phases” slow start congestion avoidance

important variables: Congestion window (cwnd) threshold: defines threshold between two slow

start phase, congestion control phase

62

63

TCP Slow StartHost A

RTT

Host B

time

64

TCP: congestion avoidanceIncreasing sending rate:

How far would the doubling of cwnd go?

Till, it reaches a threshold

After that it increases linearly

Decrease sending rate

Set the threshold value to half of current cwnd

loss: decrease cwnd

But by how much?

What if a loss happens?

65

TCP Congestion Control: more details

segment loss event: reducing cwnd

Loss by timeout: no response from receiver cut cwnd to 1 TCP Tahoe principle

Loss by 3 duplicate ACKs: at least some segments getting through (recall fast retransmit) cut cwnd in half, less aggressively than on timeout TCP Reno greedy heuristic

TCP Congestion Control: TCP Tahoe

Slow start followed by additive increase in TCP Tahoe.

TCP Congestion Control: TCP Reno

Fast recovery and the sawtooth pattern of TCP Reno.

68

Summary: TCP Congestion Control

when cwnd < ssthresh, sender in slow-startphase, window grows exponentially.

when cwnd >= ssthresh, sender is in congestion-avoidance phase, window grows linearly.

when triple duplicate ACK occurs, ssthresh set to cwnd/2, cwnd set to ~ ssthresh

when timeout occurs, ssthresh set to cwnd/2, cwnd set to 1 MSS.

TCP Congestion Control

Numerical example: Assume TCP Tahoe

Initial ssthreshold = 14

First loss occurrence after 9 transmissions. What would be the current congestion window and ssthreshold?

69

Documents

Chapter 3 Transport Layer - University of Nevada, Reno