csci 3335: computer networks chapter 3 transport layer

CSCI 3335: COMPUTER NETWORKS

CHAPTER 3 TRANSPORT LAYER

Vamsi ParuchuriUniversity of Central Arkansas

http://faculty.uca.edu/vparuchuri/3335.htm

Some of the material is adapted from J.F Kurose and K.W. Ross

http://faculty.uca.edu/vparuchuri/3335.htm

Transport Layer 3-2

Chapter 3 outline3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection

management3.6 Principles of

congestion control3.7 TCP congestion

control

Transport Layer 3-3

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

send & receive buffers

socketdoor

T C Psend buffer

TC Preceive buffer

socketdoor

segm en t

app licationwrites data

applicationreads data

Transport Layer 3-4

TCP segment structure

source port # dest port #32 bits

applicationdata

(variable length)

sequence numberacknowledgement

numberReceive windowUrg 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)

Transport Layer 3-5

TCP segment structure - Quiz

source port # dest port #32 bits

applicationdata

(variable length)



FSRPAUheadlen

notused


What is the significance of each fieldWhat is TCP Header sizeWhat is max Receiver Window Size?

Is it large enough?Which field should be larger “Seq#”

or “Receive window”? Why?What is the maximum # options?Which flags are set in first message

in connection set up? Second message? Third message?

Why are initial Seq # set randomly?

Flags: SYN, FIN, RESET, PUSH, URG, ACK

TCP Header: Flags (6 bits) Connection establishment/termination

SYN – establish; sequence number field contains valid initial sequence number

FIN - terminate RESET - abort connection because one

side received something unexpected PUSH - sender invoked push to send URG – indicated urgent pointer field is

valid; special data - record boundary ACK - indicates Acknowledgement field

is valid3: Transport Layer 3b-6

TCP Header: ACK flag ACK flag – if on then acknowledgement

field valid Once connection established no reason

to turn off Acknowledgment field is always in header

so acknowledgements are free to send along with data

3: Transport Layer 3b-7

TCP Header: PUSH Intention: use to indicate not to leave

the data in a TCP buffer waiting for more data before it is sent

Receiver is supposed to interpret as deliver to application immediately; most TCP/IP implementations don’t delay delivery in the first place though


TCP Header: Header Length Header Length (4 bits)

needed because options field make header variable length

Expressed in number of 32 bit words = 4 bytes

4 bits field => 4 bytes*24 = 60 bytes; 20 bytes of required header gives 40 bytes possible of options

Recall UDP header was 8 bytes


source port # dest port #

32 bits

applicationdata

(variable length)



FSRPAUheadlen

notused


Implications of Field Length 32 bits for sequence number (and

acknowledgement); 16 bits for advertised window size

Implication for maximum window size? Window size <= ½ SequenceNumberSpace Requirement easily satisfied because

receiver advertised window field is 16 bits• 232 >> 2* 216

• Even if increase possible advertised window to 231

that would still be ok


Implications of Field Length (cont) Advertised Window is 16 bit field

=> maximum window is 64 KB Is this enough to fill the pipeline? Not

always Pipeline = delay*BW product 100 ms roundtrip and 100 Mbps =>

1.19 MB


TCP Header: Common Options Options used to extend and test TCP Each option is:

1 byte of option kind 1 byte of option length

Examples window scale factor: if don’t want to be limited to 216

bytes in receiver advertised window timestamp option: if 32 bit sequence number space

will wrap in MSL; add 32 bit timestamp to distinguish between two segments with the same sequence number

Maximum Segment Size can be set in SYN packets


TCP Connection Management

Recall: TCP sender, receiver establish “connection” before exchanging data segments

initialize TCP variables: seq. #s buffers, flow control

info (e.g. RcvWindow) client: connection

initiator Socket clientSocket = new

Socket("hostname","port number");

server: contacted by client

Socket connectionSocket = welcomeSocket.accept();

Three way handshake:

Step 1: client end system sends TCP SYN control segment to server specifies initial seq #

Step 2: server end system receives SYN, replies with SYNACK control segment ACKs received SYN allocates buffers specifies server->

receiver initial seq. #Step 3: client acknowledges

servers initial seq. #3: Transport Layer 3b-13

Three-Way Handshake


Active participant(client)

Passive participant(server)

SYN, SequenceNum = x

SYN + ACK, SequenceNum = y,

ACK, Acknowledgment = y + 1

Acknowledgment = x + 1

SequenceNum = x+1

Connection Establishment Both data channels opened at once Three-way handshake used to agree on a

set of parameters for this communication channel Initial sequence number for both sides

(random) Receiver advertised window size for both

sides Optionally, Maximum Segment Size (MSS) for

each side; if not specified MSS of 536 bytes is assumed to fit into 576 byte datagram


Initial Sequence Numbers Chosen at random in the sequence

number space? Well not really randomly; intention of

RFC is for initial sequence numbers to change over time 32 bit counter incrementing every 4

microseconds Vary initial sequence number to avoid

packets that are delayed in network from being delivered later and interpreted as a part of a newly established connection (to avoid reincarnations) 3: Transport Layer 3b-16

Transport Layer 3-17

TCP seq. #’s and ACKsSeq. #’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

Connection Termination Each side of the bi-directional

connection may be closed independently 4 messages: FIN message and ACK of that

FIN in each direction Each side closes the data channel it can

send on One side can be closed and data can

continue to flow in the other direction, but not usually

FINs consume sequence numbers like SYNs 3: Transport Layer 3b-18

TCP Connection Management (cont.)

Closing a connection:client closes socket:

clientSocket.close();

Step 1: client end system sends TCP FIN control segment to server

Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.


client

FIN

server

ACK

ACK

FIN

close

close

closed

timed

wai

t






control


TCP reliable data transfer TCP creates rdt service on top of IP’s unreliable

service pipelined segments cumulative acks TCP uses single retransmission timer

retransmissions are triggered by: timeout events duplicate acks

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 timer Ack rcvd: If acknowledges

previously unacked segments update what is known

to be acked start timer if there are

outstanding segments

TCP: retransmission scenariosHost A

Seq=100, 20 bytes data

ACK=100

timepremature timeout

Host B


ACK=120


Seq=

92 ti

meo

ut

ACK=120

Host A


ACK=100

losstimeo

ut

lost ACK scenario

Host B

X


ACK=100

time

Seq=

92 ti

meo

utSendBase

= 100

SendBase= 120

SendBase= 120

SendBase= 100


TCP retransmission scenarios (more)

Host A


ACK=100

losstimeo

ut

Cumulative ACK scenario

Host B

X


ACK=120

time

SendBase= 120


TCP Round Trip Time and TimeoutQ: 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


TCP Round Trip Time and TimeoutEstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

Exponential weighted moving average influence of past sample decreases exponentially

fast typical value: = 0.125


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 106time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT


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 the same data, it supposes that segment after ACKed data was lost: fast retransmit: resend

segment before timer expires


Host A

timeo

ut

Host B

time

X

resend 2nd segment: Seq=100, 20 bytes data

Figure 3.37 Resending a segment after triple duplicate ACK


ACK=100


ACK=100

ACK=100

ACK=100

Seq=120, 20 bytes dataSeq=140, 20 bytes dataSeq=160, 20 bytes data

ACK=180


TCP Quiz -2 What are “Cumulative Acks”? What is advantage of having short time outs? What is advantage of having long time outs? Describe the method(s) TCP uses to detect

packet losses. What is Fast Retransmit?






control


TCP Flow Control receive side of TCP

connection has a receive buffer:

speed-matching service: matching the send rate to the receiving app’s drain rate

app process may be slow at reading from buffer

sender won’t overflow

receiver’s buffer bytransmitting too

much, too fast

flow control

Quiz Why does TCP use time outs? How does timeout impact the performance of TCP? What are pros and cons for short (long) timeouts? How is RTT estimated by TCP? What is need for "flow control" in TCP? Describe "flow control" mechanism. What is the primary cause of congestion? Mention 3 costs of congestion. What is difference between flow and congestion

control.







control


Principles of Congestion Control

Congestion: informally: “too many sources sending too

much data too fast for network to handle” different from flow control! manifestations:

lost packets (buffer overflow at routers) long delays (queueing in router buffers)

a top-10 problem!


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

congestion (SNA, DECbit, TCP/IP ECN, ATM)

explicit rate sender should send at

Two broad approaches towards congestion control:






control


TCP congestion control: additive increase, multiplicative decrease

approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs additive increase: increase cwnd by 1 MSS

every RTT until loss detected multiplicative decrease: cut cwnd in half after

loss

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

time

cwnd

: con

gest

ion

win

dow

siz

e

saw toothbehavior: probing

for bandwidth


TCP Congestion Control: details

sender limits transmission:

LastByteSent-LastByteAcked cwnd roughly,

cwnd is dynamic, function of perceived network congestion

How does sender perceive congestion?

loss event = timeout or 3 duplicate acks

TCP sender reduces rate (cwnd) after loss event

three mechanisms: AIMD slow start conservative after

timeout events

rate = cwnd

RTT Bytes/sec


TCP Slow Start when connection begins, increase rate

exponentially until first loss event: initially cwnd = 1 MSS double cwnd every RTT done by incrementing cwnd 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


Refinement: inferring loss after 3 dup ACKs:

cwnd is cut in half window then grows

linearly but after timeout event:

cwnd instead set to 1 MSS;

window then grows exponentially

to a threshold, then grows linearly

3 dup ACKs indicates network capable of delivering some segments

timeout indicates a “more alarming” congestion scenario

Philosophy:


RefinementQ: when should the

exponential increase switch to linear?

A: when cwnd gets to 1/2 of its value before timeout.

Implementation: variable ssthresh on loss event, ssthresh

is set to 1/2 of cwnd just before loss event

Can you identify different phases?

Connection Timeline



Summary: TCP Congestion Control

timeoutssthresh = cwnd/2

cwnd = 1 MSSdupACKcount = 0

retransmit missing segment

Lcwnd > ssthresh

congestionavoidance

cwnd = cwnd + MSS (MSS/cwnd)dupACKcount = 0

transmit new segment(s), as allowed

new ACK.

dupACKcount++duplicate ACK

fastrecovery

cwnd = cwnd + MSStransmit new segment(s), as allowed

duplicate ACK

ssthresh= cwnd/2cwnd = ssthresh + 3


dupACKcount == 3

timeoutssthresh = cwnd/2cwnd = 1 dupACKcount = 0retransmit missing segment

ssthresh= cwnd/2cwnd = ssthresh + 3retransmit missing segment

dupACKcount == 3cwnd = ssthreshdupACKcount = 0

New ACK

slow start

timeoutssthresh = cwnd/2

cwnd = 1 MSSdupACKcount = 0


cwnd = cwnd+MSSdupACKcount = 0transmit new segment(s), as allowed

new ACKdupACKcount++duplicate ACK

Lcwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

NewACK!

NewACK!

NewACK!


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”

Netstat netstat –a –n

Shows open connections in various states Example:

Active Connections

Proto LocalAddr ForeignAddr StateTCP 0.0.0.0:23 0.0.0.0:0 LISTENINGTCP 192.168.0.100:139 207.200.89.225:80 CLOSE_WAITTCP 192.168.0.100:1275 128.32.44.96:22 ESTABLISHEDUDP 127.0.0.1:1070 *:*

Quiz What are three primary mechanisms of

TCP Congestion Control What are the two TCP loss events How many packets are transmitted in

the first 4 RTT durations after a TCP connection is established.


Quiz (cont)


csci 3335: computer networks chapter 3 transport layer

Documents

urgent data

data flow

data exchangeflow

duplex data

tcp header sizewhat

transport layer3b

connectionoriented transport

options field