1 networking primer - transport layer ece 256 spring 2009 romit roy choudhury dept. of ece and cs

1

Networking Primer - Transport Layer

ECE 256 Spring 2009

Romit Roy ChoudhuryDept. of ECE and CS

2

Agenda

Transport Layer Multiplexing / Demultiplexing

Reliable Transport Stop-and-wait Pipelined

• Go back N

• Selective Request

TCP Congestion Control Flow Control

3

Need for Transport Layer

Network Layer offers connections Connections not reliable

•Losses, delays due to out-of-order, queue overflow, …

Transport Layer Goals: End to end reliability In Order delivery Performance

•Congestion control

•Flow control

4

Transport services and protocols

logical communication between processes

transport protocols run in end systems breaks app messages into

segments reassembles segments into

messages, passes to app layer

more than one transport protocol available to apps Internet: TCP and UDP

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical

networkdata linkphysical

networkdata linkphysical

networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

5

TCP, UDP: transport-layer protocols

reliable, in-order delivery (TCP) congestion control flow control connection setup

unreliable, unordered delivery: UDP no-frills extension of

“best-effort” IP

services not available: delay guarantees bandwidth guarantees

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical

networkdata linkphysical

networkdata linkphysical

networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

6

Agenda

Transport Layer Multiplexing / Demultiplexing

Reliable Transport Stop-and-wait Pipelined

• Go back N

• Selective Request

TCP Congestion Control Flow Control

7

Multiplexing/demultiplexing

application

transport

network

link

physical

P1 application

transport

network

link

physical

application

transport

network

link

physical

P2P3 P4P1

host 1 host 2 host 3

= process= socket

delivering received segmentsto correct socket

Demultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)

Multiplexing at send host:

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 source,

destination port number

host uses IP addresses & port numbers to direct segment to appropriate socket

source port # dest port #

32 bits

applicationdata

(message)

other header fields

TCP/UDP segment format

Analogous to car rentals at airports

Shuttles MUX passengers and take themTo rental office -- DeMUX to diff cars

Analogous to car rentals at airports

Shuttles MUX passengers and take themTo rental office -- DeMUX to diff cars

9

Agenda

Transport Layer Multiplexing / Demultiplexing

Reliable Transport Stop-and-wait Pipelined

• Go back N

• Selective Request

TCP Congestion Control Flow Control

10

Some transmission methods

Stop & Wait Pipelined

Go Back N Selective Repeat

11

Stop-and-wait operation

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

microseconds

L / R

RTT + L / R =

12

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

13

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

U sender

= .024

30.008 = 0.0008

microseconds

3 * L / R

RTT + L / R =

Increase utilizationby a factor of 3!

14

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

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

15

GBN inaction

16

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 again limits seq #s of sent, unACKed pkts

17

Selective Request

Makes sense to transmit only the lost packets But this is true under what assumption ?

Can you say a case in which Go-BACK-N might be better

18

Selective repeat: sender, receiver windows

19

Selective repeat

data from above : if next available seq # in

window, send pkt

timeout(n): resend pkt n, restart timer

ACK(n) in [sendbase,sendbase+N]:

mark pkt n as received if n smallest unACKed pkt,

advance window base to next unACKed seq #

sender

pkt n in [rcvbase, rcvbase+N-1]

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

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

pkt n in [rcvbase-N,rcvbase-1]

ACK(n)

otherwise: ignore

receiver

20

Selective repeat in action

21

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?

What if pkts go out of orderWhat if pkts go out of order

22

Agenda

Transport Layer Multiplexing / Demultiplexing

Reliable Transport Stop-and-wait Pipelined

• Go back N

• Selective Request

TCP Congestion Control Flow Control

23

TCP: Connection-Oriented Transport

TCP has 3 main components Reliable transmission Congestion Control Flow Control

24

Reliable Transmission

TCP is connection-oriented Sender sends control packets (SYN) and

receiver replies (ACK) Receiver also opens a similar connection

Sender sends a small burst of packets Receiver ACKs: ACK contains the next

expected packet (actually byte) Sender receives ACK, and sends a bigger burst

Called “Self-clocking” behavior

25

Reliable Transmission

If train of packets lost Sender will not get any ACKs Will timeout (gets alarmed) Retransmit from first un-ACK-ed packet, Drastically reduces window size

If packet n lost, but (n+1) successful Receiver will send Duplicate ACK If many DupACKs, then receiver not alarmed Resends (n+1) Cuts window size by half

26

Congstion Control

27

TCP Congestion Control

Problem Definition How much data should I pump into the network

to ensure• Intermediate router queues not filling up

•Fairness achieved among multiple TCP flows

Why is this problem difficult? TCP cannot have information about the

network Only TCP receiver can give some feedbacks

28

The TCP Intuition

Pourwater

Collectwater

29

The TCP Protocol (in a nutshell)

T transmits few packets, waits for ACK Called slow start

R acknowledges all packet till seq #i by ACK i (optimizations possible) ACK sent out only on receiving a packet Can be Duplicate ACK if expected packet not received

ACK reaches T indicator of more capacity T transmits larger burst of packets (self clocking) … so on Burst size increased until packet drops (i.e., DupACK or

timeout)

When T gets DupACK or waits for longer than RTO Assumes congestion reduces burst size (congestion

window)

30

TCP Timeline

Host A

one segment

RTT

Host B

time

two segments

four segments

Think of a blindperson trying tostand up in a lowceiling room

Objective:Don’t bang yourhead, but standup quickly

Think of a blindperson trying tostand up in a lowceiling room

Objective:Don’t bang yourhead, but standup quickly

31

Timeout -- function of RTT

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

SampleRTT will vary, want estimated RTT “smoother” average several recent

measurements, not just current SampleRTT

32

TCP Round Trip Time and Timeout

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

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

33

Example RTT estimation:

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 (milliseconds)

SampleRTT Estimated RTT

34

TCP Round Trip Time and Timeout

Setting the timeout EstimtedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety margin

first estimate of how much SampleRTT deviates from EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|

(typically, = 0.25)

Then set timeout interval:

35

When waited for > RTO

0

5

10

15

20

25

0 3 6 9 12 15 20 22 25

Time (round trips)

Congestion window

(segments)ssthresh = 8 ssthresh = 10

cwnd = 20

After RTO timeout

double CongWin every RTT

done by incrementing CongWin

for every ACK received

double CongWin every RTT

done by incrementing CongWin

for every ACK received

36

The TCP Protocol (in a nutshell)

DupACK not necessarily indicator of congestion Can happen due to out of order (OOO) delivery of packets

If 3 OOO pkts, then CW need not be cut drastically The DupACK packet retransmitted Continue with same pace of transmission as before

(fast recovery)

R advertizes its receiver window in ACKs If filling up, T reduces congestion window

Why ?

37

Fast Recovery on 3 OOO DupACKs

0123456789

0 2 4 6 8 10 12 14

Time (round trips)

Window size (segments)

Receiver’s advertized window

After fast recovery

38

Why is TCP fair?

Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

congestion avoidance: additive increaseloss: decrease window by factor of 2

congestion avoidance: additive increaseloss: decrease window by factor of 2

39

TCP Flow Control

Problem Definition The receiver has limits on buffer If many nodes transmitting to same receiver

•Losses may happen at receiver

Need to avoid such losses

Solution Receiver tells transmitter how much space left Transmitter chooses its congestion window

accordingly

40

TCP Flow control: how it works

(Suppose TCP receiver discards out-of-order segments)

spare room in buffer= RcvWindow

= RcvBuffer-[LastByteRcvd - LastByteRead]

Rcvr advertises spare room by including value of RcvWindow in segments

Sender limits unACKed data to RcvWindow guarantees receive

buffer doesn’t overflow

41

Why is it different in Wireless?

42

Questions?

…

43

Announcements

Reviews: Please send as plain text in email No other data in the review email

Class ppt Please start picking slots

44

TCP Slow Start (more)

When connection begins, increase rate exponentially until first loss event: double CongWin every

RTT done by incrementing CongWin for every ACK received

Summary: initial rate is slow but ramps up exponentially fast

Host A

one segment

RTT

Host B

time

two segments

four segments

45

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) init’s 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

send & receive bufferssocketdoor

TCPsend buffer

TCPreceive buffer

socketdoor

segment

applicationwrites data

applicationreads data

46

TCP segment structure

source port # dest port #

32 bits

applicationdata

(variable length)

sequence number

acknowledgement numberReceive window

Urg data pnterchecksum

FSRPAUheadlen

notused

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

countingby bytes of data(not segments!)

Internetchecksum

(as in UDP)

47

TCP seq. #’s and ACKs

Seq. #’s: byte stream

“number” of first byte in segment’s data

ACKs: seq # of next byte

expected from other side

cumulative ACKQ: how receiver handles

out-of-order segments A: TCP spec

doesn’t say, - up to implementor

Host A Host B

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

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

Seq=43, ACK=80

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of

‘C’, echoesback ‘C’

timesimple telnet scenario

48

Connectionless demultiplexing

Create sockets with port numbers:

DatagramSocket mySocket1 = new DatagramSocket(99111);

DatagramSocket mySocket2 = new DatagramSocket(99222);

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 directed to same socket

49

Connectionless demux (cont)

DatagramSocket serverSocket = new DatagramSocket(6428);

ClientIP:B

P2

client IP: A

P1P1P3

serverIP: C

SP: 6428

DP: 9157

SP: 9157

DP: 6428

SP: 6428

DP: 5775

SP: 5775

DP: 6428

SP provides “return address”

50

Connection-oriented demux

TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number

recv host uses all four values to direct segment to appropriate socket

Server host may support many simultaneous TCP sockets: each socket identified

by its own 4-tuple

Web servers have different sockets for each connecting client non-persistent HTTP will

have different socket for each request

51

Connection-oriented demux (cont)

ClientIP:B

P1

client IP: A

P1P2P4

serverIP: C

SP: 9157

DP: 80

SP: 9157

DP: 80

P5 P6 P3

D-IP:CS-IP: A

D-IP:C

S-IP: B

SP: 5775

DP: 80

D-IP:CS-IP: B

52

Connection-oriented demux: Threaded Web Server

ClientIP:B

P1

client IP: A

P1P2

serverIP: C

SP: 9157

DP: 80

SP: 9157

DP: 80

P4 P3

D-IP:CS-IP: A

D-IP:C

S-IP: B

SP: 5775

DP: 80

D-IP:CS-IP: B

53

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

54

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 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 no congestion control: UDP

can blast away as fast as desired

55

UDP: more

often used for streaming multimedia apps loss tolerant rate sensitive

other UDP uses DNS SNMP

reliable transfer over UDP: add reliability at application layer application-specific error

recovery!

source port # dest port #

32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header

56

TCP seq. #’s and ACKs

Seq. #’s: byte stream

“number” of first byte in segment’s data

ACKs: seq # of next

byte expected from other side

cumulative ACK

Host A Host B

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

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

Seq=43, ACK=80

Usertypes

‘C’

host ACKsreceipt

of echoed‘C’

host ACKsreceipt of

‘C’, echoesback ‘C’

timesimple telnet scenario

57

TCP Connection Management (cont.)

After session over,

Both sender and receiver exchange control signals to terminate the connection

client

FIN

server

ACK

ACK

FIN

close

close

closed

tim

ed w

ait