cn1 ch8 transport 4up
TRANSCRIPT
-
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 3
Overview
Services & addressing
Connection setup
Connection release
Flow control
Timer and timeouts
TCP summary UDP & RPC
Performance issues
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 4
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
-
8/13/2019 Cn1 Ch8 Transport 4up
2/14
2
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 5
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 6
Overview
Services & addressing
Connection setup
Connection release
Flow control
Timer and timeouts
TCP summary
UDP & RPC
Performance issues
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 7
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 8
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
-
8/13/2019 Cn1 Ch8 Transport 4up
3/14
3
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 9
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 10
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 11
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:
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 12
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
-
8/13/2019 Cn1 Ch8 Transport 4up
4/14
4
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 13
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)
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 14
Overview
Services & addressing
Connection setup
Connection release
Flow control
Timer and timeouts
TCP summary
UDP & RPC
Performance issues
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 15
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 16
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?
-
8/13/2019 Cn1 Ch8 Transport 4up
5/14
5
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 17
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 18
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 19
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 20
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)
-
8/13/2019 Cn1 Ch8 Transport 4up
6/14
6
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 21
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)
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 23
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 24
Overview
Services & addressing
Connection setup
Connection release
Flow control
Timer and timeouts
TCP summary UDP & RPC
Performance issues
-
8/13/2019 Cn1 Ch8 Transport 4up
7/14
7
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 25
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 26
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 27
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 28
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/13/2019 Cn1 Ch8 Transport 4up
8/14
8
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 29
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 30
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)
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 31
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 32
Overview
Services & addressing
Connection setup
Connection release
Flow control
Timer and timeouts
TCP summary UDP & RPC
Performance issues
-
8/13/2019 Cn1 Ch8 Transport 4up
9/14
9
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 33
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 34
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!
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 35
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)
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 36
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, )
-
8/13/2019 Cn1 Ch8 Transport 4up
10/14
10
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 37
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 38
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 39
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 40
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
-
8/13/2019 Cn1 Ch8 Transport 4up
11/14
11
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 41
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)
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 42
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 43
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 44
Overview
Services & addressing
Connection setup
Connection release
Flow control
Timer and timeouts
TCP summary UDP & RPC
Performance issues
-
8/13/2019 Cn1 Ch8 Transport 4up
12/14
12
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 45
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 46
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 47
TCP header
Options (variable)
Data
Checksum
SrcPort DstPort
HdrLen 0 Flags
UrgPtr
AdvertisedWindow
SequenceNum
Acknowledgment
0 4 10 16 31
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 48
Overview
Services & addressing
Connection setup
Connection release
Flow control
Timer and timeouts
TCP summary UDP & RPC
Performance issues
-
8/13/2019 Cn1 Ch8 Transport 4up
13/14
13
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 49
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 50
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 51
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 52
Overview
Services & addressing
Connection setup
Connection release
Flow control
Timer and timeouts
TCP summary UDP & RPC
Performance issues
-
8/13/2019 Cn1 Ch8 Transport 4up
14/14
14
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 53
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 54
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
WS 09/10, v 1.2 Computer Networks - Ch. 8 - Transport layer 55
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