Cn1 Ch8 Transport 4up

8/13/2019 Cn1 Ch8 Transport 4up

1/14

1

Computer Networks Group

Universitt Paderborn

Computer Networks

Chapter 8: Transport layer

Holger Karl

WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 2

Goal of this chapter

We will discuss the mechanisms in addition to congestioncontrol that are required to build a reliable, connection-

oriented, end-to-end transport protocol

With TCP as the evident case study, intermixed with thepresentation

We will draw heavily on the material from the link layer, as manysimilar problems are solved there in similar fashion e.g., sliding

window for error control

A brief discussion of other transport protocols complementsthe chapter

Namely, UDP and RPC


Overview

Services & addressing

Connection setup

Connection release

Flow control

Timer and timeouts

TCP summary UDP & RPC

Performance issues


Transport protocols Services to upper layer

Connection-less and connection-oriented transport service

Connection management necessary as auxiliary service setupand teardown

Reliable or unreliable transport

In-order, all packets

Be a good citizen in the network perform congestion

control Allow several transport endpoints in a single host

Demultiplexing

Support different interaction models

Byte stream, messages, remote procedure invocation


2/14

2


Addressing

Provide multiple serviceaccess points to

multiplex several

applications

SAPs can identify

connections or data

flows

E.g., port numbers

Dynamically allocated

Predefined for well-known services e.g., port 80 for Web

server


Overview


Connection setup

Connection release

Flow control

Timer and timeouts

TCP summary

UDP & RPC

Performance issues


Connection establishment

How to establish a joint context, a connection, betweensender and receiver?

Note: only relevant in end-system, network layer assumed to be

connection-less

Nave solution:

Sender sends a CONNECTION REQUEST

Receiver answers by a CONNECTION

ACCEPTED

Sender proceeds once that message is

received

CONNECTIONREQUEST

CONN

ACCEPTE

D

DATA


Failure of nave solution

Nave solution fails in realisticnetworks

Where packets can be lost,

stored/reordered, and duplicated

Example failure scenario

All packets are duplicated and

delayed Due to congestion, errors, ... and

re-routing, e.g.

In a banking application, e.g.

Result: two independenttransactions performed, where

only one was intended

Problem are delayed duplicates

Transfer

money CONNECTIONREQUEST

CONN

ACCEPTE

D

TRANSFER

OK

OK

CO

NN

ACCEPTE

D

???

DROP

OK

???

DROP

OK


3/14

3


Adding an additional handshake

First idea: the sender hasto re-confirm to the

receiver that it actually

wants to set up this

connection

Add a third message to

the connection setup

phase

Three-way handshake

This third message canalready carry data

CONNECTIONREQUEST

CONN

ACCEPTE

D

CONNCONFIRMED


Is three-way handshake sufficient?

No, it does not protect against delayed duplicates!

Problem: If both the connection request and the connection

confirmation are duplicated and delayed, receiver again has no

way to ascertain whether this is a fresh or an old copy

Solution: Have the sender answer a question that thereceiver asks!

Actually: Put sequence numbers into

connection request

connection acknowledgement,

and connection confirmation

Have to be copied by the receivingparty to the other side

Connection only established if thecorrect number is provided


Three-way handshake + sequence numbers

Two examples for critical cases (which are handledcorrectly):

Connection requestappears as an old

duplicate:

Connection request &

confirmation appear as

old duplicates:


Connection setup further issues

Further problems due to crashing nodes, need somememory

Sequence numbers negotiated here are also used for thefollowing data packets

Terminology for TCP

Connection setup SYN (synchronize) packet

Connection accepted SYN/ACK packet (because both the

previous sequence number is acknowledged and a new sequence

number from the receiver is proposed)

Connection confirmation ACK packet (combined with DATA, as a

rule)

Problem: SYN attack flooding with nonsense SYN packets


4/14

4


Connection identification in TCP

A TCP connection is set up Between a single sender and a single receiver

More precisely, between application processes running on these

systems

TCP can multiplex several such connections over the network

layer, using the port numbers as Transport SAP identifiers

A TCP connection is thus identified by a four tuple:

(Source Port, Source IP Address,

Destination Port, Destination IP Address)


Overview


Connection setup

Connection release

Flow control

Timer and timeouts

TCP summary

UDP & RPC

Performance issues


Connection release

Once connection context between two peers is established,releasing a connection should be easy

Goal: Only release connection when both peers have agreed that

they have received all data and have nothing more to say

I.e., both sides must have invoked a Close-like service primitive

It fact, it is impossible Problem: How to be sure that the other peer knows that you know

that it knows that you know that all data have been transmitted

and that the connection can now safely be terminated?

Analogy: Two army problem


Two army problem

Coordinated attack

Two armies form up for an attack against each other

One army is split into two parts that have to attack together alone theywill lose

Commanders of the parts communicate via messengers who might becaptured

Which rules shall the commanders use to agree on an attack date?

Provably unsolvable if the network can loose messages

How to coordinate?


5/14

5


Connection release in practice

Two army problem equivalent to connection release

But: when releasing a connection, bigger risks can betaken

Usual approach: Three-wayhandshake again

Send disconnect request (DR),

set timer,

wait for DR from peer,

acknowledge it


Problem cases for connection release with 3WHS

Lost ACKsolved by

(optimistic)

timer in Host 2

Lost secondDR solved by

retransmission

of first DR

Timer solves(optimistically)

case when 2nd

DR and ACK

are lost


State diagram of a TCP connection

TCP uses three-way handshake for connection setup and release

FIN, FIN/ACK for release

Complicated by ability to haveasymmetric, half-open

connections and data in transit

while close is in progress

(Partial) state diagram

Expresses bothserver and clientaspects

Each has aseparate copy

Legend:event/action,segments all caps,

local events normal

capitalization

CLOSED

LISTEN

SYN_RCVD SYN_SENT

ESTABLISHED

CLOSE_WAIT

LAST_ACKCLOSING

TIME_WAIT

FIN_WAIT_2

FIN_WAIT_1

Passive open Close

Send/SYN

SYN/SYN + ACK

SYN + ACK/ACK

SYN/SYN + ACK

ACK

Close/FIN

FIN/ACKClose/FIN

FIN/ACKACK+FIN

/ACK

Timeout after twosegment lifetimes

FIN/ACK

ACK

ACK

ACK

Close/FIN

Close

CLOSED

Active open/SYN

CLOSED

LISTEN

SYN_RCVD SYN_SENT

ESTABLISHED

CLOSE_WAIT

LAST_ACKCLOSING

TIME_WAIT

FIN_WAIT_2

FIN_WAIT_1

Passive open Close

Send/SYN

SYN/SYN + ACK

SYN + ACK/ACK

SYN/SYN + ACK

ACK

Close/FIN

FIN/ACKClose/FIN

FIN/ACKACK+FIN

/ACK

Timeout after twosegment lifetimes

FIN/ACK

ACK

ACK

ACK

Close/FIN

Close

CLOSED

Active open/SYN


TCP state sequence unfolding the state machine

Example scenario: Web server/client

Web server opens a socket and listens on a connection

Web browser connects to that socket

Browser sends a request for a web page and then closes its socket

for sending (remains open for receiving data)

Server receives request, sends Web page, then closes its socket

also for sending

How does the TCP state sequence look like?

Simplifying assumption:

No errors

No unusual behavior (closing a socket before establishingconnection, ) !

Note: Have a look at the netstat tool (Linux, Cygwin)


6/14

6


TCP MSC connection establishment

Webserver

appl.

TCP @Webserver

Network TCP @Webbrowser

Webbrowserappl.

CLOSED CLOSEDPassiveopen

LISTEN

SYN_SENT

Active

open

SYN

SYN

SYN_RCVD

SYN+ACK

SYN+ACK

ESTABLISHED

ACK

ACK

ESTABLISHEDWS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 22

TCP MSC connection release (1)

Webserver

appl.

TCP @Webserver

Network TCP @Webbrowser

Webbrowserappl.

ESTABLISHEDESTABLISHED Close

FIN_WAIT_1

FIN

FIN

CLOSE_WAIT

ACK

ACK

FIN_WAIT_2

(continued on next slide)


TCP MSC connection release (2)

Web

server

appl.

TCP @Web

server

NetworkTCP @

Web

browser

Webbrowser

appl.

FIN_WAIT_2CLOSE_WAIT

CLOSED

ACK

ACK

CLOSED

Close

LAST_ACK

FIN

FIN

TIME_WAIT

Timeout


Overview


Connection setup

Connection release

Flow control

Timer and timeouts


Performance issues


7/14

7


Flow control

Recall: Flow control = prevent a fast sender fromoverrunning a slow receiver

Similar issue in link and transport layer

In transport layer more complicated

Many connections, need to adapt the amount of buffer per

connection dynamically (instead of just simply allocating a fixed

amount of buffer space per outgoing link)

Transport layer PDUs can differ widely in size, unlike link layer

frames

Networks packet buffering capability clouds the picture


Flow control buffer allocation

In order to support outstanding packets, the sender either Has to rely on the receiver to process packets as they come in

(packets must not be reordered) unrealistic, or

Has to assume that the receiver has sufficient buffer space

available

The more buffer, the more outstanding packets

Necessary to obtain highly efficient transmission, recall bandwidth-

delay product!

How does sender have buffer assurance?

Sender can request buffer space

Receiver can tell sender: I have X buffers available at the

moment

For sliding window protocols: Influence size of senders send window


Example of flow control with ACK/permit separation

Arrows show direction of transmission, indicates lost packet

Potential deadlock in step 16 when control PDU is lost and notretransmitted


Flow control permits and acknowledgements

Distinguish

Receiver-Permits (Receiver has buffer space, go ahead and sendmore data)

Acknowledgements (Receiver has received certain packets)

Should be separated in real-world protocols!

Unfortunately, often intermixed TCP, e.g., uses ACKs as

Network-Permits; see congestion control chapter

Can be combined with dynamically changing buffer spaceat the receiver

Due to, e.g., different speed with which the application actuallyretrieves received data from the transport layer

Example: TCP


8/14

8


Send and receive buffers in TCP

TCP maintains buffer at Sender, to assist in error control

Receiver, to store packets not yet retrieved by application or

received out of order

Old TCP implementations used GoBack-N, discarded out-of-orderpackets

Sending application

LastByteWritten TCP

LastByteSentLastByteAcked

Receiving application

LastByteRead TCP

LastByteRcvdNextByteExpected

Sender Receiver


TCP flow control: Advertised window

In TCP, receiver can advertise size of its receiving buffer Buffer space occupied:

(NextByteExpected-1) LastByteRead

Maximum buffer space available: MaxRcvdBuffer

Advertised buffer space (Advertised window):

MaxRcvdBuffer ((NextByteExpected-1) LastByteRead)

Recall: Advertised window limits the amount of data that asender will inject into the network

TCP sender ensures thatLastByteSent LastByteAcked AdvertisedWindow

Equivalently:

EffectiveWindow = AdvertisedWindow (LastByteSent LastByteAcked)


Nagles algorithm self-clocking and windows

Recall TCP self-clocking: Arrival of an ACK is an indicationthat new data can be injected into the network

What happens when an ACK for only small amount of data(e.g., 1 byte) arrives?

Send immediately? Network will be burdened by small packets

(silly window syndrome) inefficient

Nagles algorithm describes how much data TCP isallowed to send

When application produces data to sendif both available data and advertised window MSS

send a full segment

else

if there is unacked data in flight, buffer new data until MSS is full

else send all the new data now


Overview


Connection setup

Connection release

Flow control

Timer and timeouts


Performance issues


9/14

9


How to select timeout values?

If round trip time between sender and receiver is a known constant d:Timeout = d +

small to allow for processing

Interesting case: What if round trip delay D is a random variable?

Select timeout such that

It is small enough not to wait too long in case of packet error

It is big enough not to prematurely send out a retransmission

Full analysis is complicated

Need to take into account both packet error rate and distribution of D

Let us look at some simple rules

Concentrate on the probability of prematurely sending out the firstretransmission

Assume this probability shall be bounded by a given probability p


A simple timeout selection rule

Possible rule: Timeout = c for some constant c > 1 Suppose expected value E[D] = is known

How to determine constant c?

Case 1: Distribution function FD of D is known

P (premature retrans.) = P (D > Timeout) = P (D > c) = 1- FD (c)

Required: p > 1-FD(c) c > 1/ FD-1(1-p)

Case 2: Distribution of D unknown

P(D > timeout) = P (D - > c -) < P(|D-| > (c-1))

< 2/ ((c-1))2 (Tschebyschow inqueality!)

Suppose this probability should be bounded by p Implies c < 1 + 2 / (p 2)

Or: Timeout = + 2 / (p )

Need also to know D for decent timeout selection!


Timeout values depend on delay distribution

Round trip time exponentially or lognormal distributed

10-5

10-4

10-3

10-2

10-1

0

2000

4000

6000

8000

10000

12000

14000

Bound on probability of prematurely

Requiredtimeoutvalue

exponential (mu=1)lognormal (mu=1, sigma=2)


Estimating delay parameters

Since usually distribution knowledge is not available, onlyTschebyscheff-based approximations feasible

Necessary: Estimates of the round trip time average andstandard deviation

Suppose d1, , dn RTT values have been observed

Estimating average: dd = 1/n di Estimating standard deviation: sd = ( 1/(n-1) (dd-di)

2 )1/2

Estimating distribution parameters easy as long as the

RTT distribution does not change

Not true in practice!

RTT can vary considerably over time (load patterns, failures, )


10/14

10


Estimating parameters when distribution changes

What to do when the RTT distribution changes over time? I.e., the samples di were not generated from independent,

identically distributed random variables

There is no longer the expected delay, the standard deviation

At best: attempt to find a good approximation of the current

distributions parameters

Danger: tracking changes too slowly, overreacting to temporary

fluctuations

Popular approach: autoregressive model

EstimatedRTT (i) = EstimatedRTT(i-1) + (1-) di (0,1) controls agility of the model, how quickly it tracks

changes in the underlying stochastic process

= 0.8 0.9, typically


Autoregressive estimation of mean values

Examplescenario:

Mean of RTTs

follows a sine

function

Each RTT

sample

generated by

an

exponential

distribution

with

appropriate

mean

= 0.8 0 50 100 150 2000

20

40

60

80

100

120

Time

RTT

Mean

RTT Sample

Estimated mean


Problem: Variance not considered

Previous estimation does not consider variance of RTTs

Autoregressive estimates of standard deviation have highoverhead

Instead: use deviation as a simple approximation

Jacobsen/Karels algorithm for new estimation:

Differencen = SampleRTTn EstimatedRTTn-1 EstimatedRTTn = EstimatedRTTn-1 + ( Differencen)

Deviationn = Deviationn-1 + (|Difference|n Deviationn-1)

Timeoutn = EstimatedRTTn + Deviationn

(0,1) a constant, typically = 1, = 4 (in TCP)

Deviation is an upper bound of standard deviation, but easier to

compute


Jacobsen/Karels algorithm Example

Same scenario

= 0.8 (forboth meanand deviationestimation)

= 4

600 RTTsamples

5% larger thantheir determinedtimeout!

Due toexponentialdistribution ofRTTs!

Not a practicalvalue!

0 100 200 300 400 500 6000

10

20

30

40

50

60

70

80

90

100

Time

RTT

MeanRTT Sample

Estimated meanEstimated deviationTimeout


11/14

11


Problem: ACKs do not refer to a transmission!

Simple algorithm described above cannot obtain correctRTT samples if packets have been retransmitted

ACKs refer to data/sequence numbers, not to individual packets!

Two examples:

Sender Receiver

Originaltransmission

ACKSampleR

TT

Retransmission

Sender Receiver

Originaltransmission

ACK

SampleR

TT

Retransmission

Solution: Do not take RTT samples for retransmittedpackets (Karn/Partridge algorithm)


Timer and packet loss

What happens after a packet loss? Recall Ethernet behavior: Become more and more careful, back off

Same idea here: After packet loss detected by timeout, use

successively larger timeout values

Exponential backoff: Double timeout value for each additional

retransmission

The estimation of RTT and basic timeout value isperformed as described on previous slide

The multiplicative factor for exponential backoff is resetupon ACK arrival


Timeouts & timer granularity

Timeout calculation can suffer from coarse-grained timerresolution in the operating system

Example: some Unixes only have 500 ms resolution

Also: firing a timer heavily depends on relatively precisetimer interrupts to be available

Sometimes, timeouts can happen only seconds after a packet hasbeen transmitted far too sluggish


Overview


Connection setup

Connection release

Flow control

Timer and timeouts


Performance issues


12/14

12


TCP Summary

TCP consists of Reliable byte stream error control via GoBack-N

or Selective Repeat (depending on version)

Congestion control window-based, AIMD, slow start, congestion

threshold

Flow control advertised receiver window

Connection management three-way handshake for setup and

teardown

TCP is perhaps the single most complicated and subtle

protocol in the internet Many little details and extensions are not discussed here

Interaction of TCP with other layers is more complicated than it

looks (e.g., wireless) because of hidden, implicit assumptions

pRTT

MSSDR

*

*93.0

max. TCP BandWidth

Max. Segment Size

Round Trip Time

loss probability


TCP fairness & TCP friendliness

TCP attempts to Adjust dynamically to the available bandwidth

Fairly share this bandwidth among all connections

I.e.: If n connections share a given bottleneck link, each connectionobtains 1/n of its bandwidth

Interaction with other protocols

Bottleneck bandwidth depends on load of other protocols as well,e.g., UDP which is NOT congestion-controlled

I.e., UDP traffic can push aside TCP traffic

Consequence: Transport protocols should be TCP friendly

They should not consume more bandwidth than a TCP connectionwould consume in a comparable situation


TCP header

Options (variable)

Data

Checksum

SrcPort DstPort

HdrLen 0 Flags

UrgPtr

AdvertisedWindow

SequenceNum

Acknowledgment

0 4 10 16 31


Overview


Connection setup

Connection release

Flow control

Timer and timeouts


Performance issues


13/14

13


A simple demultiplexer transport protocol UDP

An example for an unreliable, datagram protocol:User Datagram Protocol (UDP)

Only real function: (de)multiplex several data flows onto theIP layer and back to the applications

In addition: ensures packets correctness

Checksum out of UDP header + data + pseudoheader (pivotal IP

header fields)

SrcPort DstPort

Checksum Length

Data

0 16 31

UDPheader


Remote Procedure Call (RPC)

UDP and TCP have essentially simple semantics:Transport data from A to B

A bit like goto in sequential languages: no structure in data flow

More complex interactions can be directly captured incommunication primitives

Example: Invocation of a procedure as a primitive, as opposed totwo separate gotos

Remote procedure call Remote object invocation is really the same thing from a

communication perspective


Remote procedure call Structure

Important goal: transparency to caller/callee

Achieved (partially) by stubs

Client Server

Request

Reply

Computing

Blocked

Blocked

Blocked

Caller

(client)

Client

stub

RPC

protocol

Return

valueArguments

ReplyRequest

Callee

(server)

Server

stub

RPC

protocol

Return

valueArguments

ReplyRequest

Network


Overview


Connection setup

Connection release

Flow control

Timer and timeouts


Performance issues


14/14

14


A few words on performance

Performance is still important Measuring performance

Measure relevant metrics

Make sure that the sample size is big enough

Make sure that samples are representative

Be careful when using a coarse-grained clock

Be sure that nothing unexpected is going on during your tests

Caching can wreak havoc with measurements

Understand what you are measuring and what is going on

Be careful about extrapolating results Use a proper experimental design to finish in one human lifetime


System design for better performance

CPU speed is more important than network speed Or interfaces like NIC CPU

Reduce packet count to reduce software overhead

Minimize context switches

Minimize copying

You can buy more bandwidth but not lower delay

Avoiding congestion is better than recovering from it

Avoid timeouts

Optimize for the common case

Depending on network: design for speed, not utilization

Think about the right performance metric, it can be, e.g., energyefficiency rather than throughput or delay


Conclusion

Transport protocols can be anything from trivial to highlycomplex, depending on the purpose they serve

They determine to a large degree the dynamics of anetwork and in particular its stability

It is trivial to build faster than TCP protocols, but they are

unstable

The interdependencies of various mechanisms in atransport protocols can be very subtle with big

consequences

E.g., fairness, coexistence of different TCP versions

Documents

Cn1 Ch8 Transport 4up