Upload
haneesha-muddasani
View
230
Download
0
Embed Size (px)
Citation preview
7/29/2019 Transp Layer1
1/35
1
Transport LayerTransport Layer
7/29/2019 Transp Layer1
2/35
Transport LayerTransport Layer
Goals:
understand principles behindtransport layer services:
-multiplexing/demultiplexing-reliable data transfer-flow control-congestion control
learn about transport layerprotocols in the Internet:UDP: connectionless
transportTCP: connection-orientedtransportTCP congestion control
7/29/2019 Transp Layer1
3/35
Transport services and protocolsTransport services and protocols
- provide logical communicationbetween app processes runningon different hosts- transport protocols run in endsystems
send side: breaks app messagesinto segments, passes tonetwork layerrcv side: reassembles segmentsinto messages, passes to applayer- more than one transportprotocol available to appsInternet: TCP and UDP
application
transport
network
data link
physical
application
transport
networkdata link
physical
network
data link
physical
networkdata link
physical
network
data link
physical
network
data link
physicalnetwork
data link
physical
logicalend-endtransport
7/29/2019 Transp Layer1
4/35
Transport vs. network layerTransport vs. network layer
-network layer:logicalcommunication betweenhosts
-transport layer:logicalcommunication between
processes
relies on, enhances,network layer services
application
transport
network
data link
physical
application
transport
networkdata link
physical
network
data link
physical
networkdata link
physical
network
data link
physical
network
data link
physicalnetwork
data link
physical
7/29/2019 Transp Layer1
5/35
Multiplexing/demultiplexingMultiplexing/demultiplexing
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4
P1
host 1 host 2host 3
= process= socket
delivering received segmentsto correct socket
Demultiplexing at rcv host: gathering data from multiplesockets, enveloping data withheader (later used fordemultiplexing)
Multiplexing at send host:
7/29/2019 Transp Layer1
6/35
How demultiplexing worksHow demultiplexing works
-host receives IP datagrams-each datagram has sourceIP address, destination IPaddress-each datagram carries 1
transport-layer segment-each segment has source,destination port number-host uses IP addresses &port numbers to direct
segment to appropriatesocket
source port # dest port #
32 bits
application
data
(message)
other header fields
TCP/UDP segment format
7/29/2019 Transp Layer1
7/35
Connectionless demultiplexingConnectionless demultiplexing
Create sockets with port numbers:DatagramSocket mySocket1 = new
DatagramSocket(12534);
DatagramSocket mySocket2 = new
DatagramSocket(12535);
UDP socket identified by two-tuple:
(dest IP address, dest port number)
When host receives UDPsegment:
checks destination port numberin segmentdirects UDP segment to socketwith that port number
7/29/2019 Transp Layer1
8/35
Connectionless demux (cont)Connectionless demux (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
ClientIP:B
P2
client
IP: A
P1P1P3
server
IP: C
SP: 6428
DP: 9157
SP: 9157
DP: 6428
SP: 6428
DP: 5775
SP: 5775
DP: 6428
SP provides return address
7/29/2019 Transp Layer1
9/35
Connection-oriented demuxConnection-oriented demux
TCP socket identified by4-tuple:source IP addresssource port number
dest IP addressdest port number
recv host uses all fourvalues to direct segment
to appropriate socket
Server host may supportmany simultaneous TCPsockets:each socket identified by its own
4-tupleWeb servers havedifferent sockets for eachconnecting clientnon-persistent HTTP will havedifferent socket for eachrequest
7/29/2019 Transp Layer1
10/35
UDP: User Datagram ProtocolUDP: User Datagram Protocol [RFC 768][RFC 768]
-best effort service, UDPsegments may be:Lostdelivered out of order to appconnectionless:
-no handshaking between UDPsender, receiver-each UDP segment handledindependently of others
Why is there a UDP?
no connection establishment(which can add delay)
simple: no connection state atsender, receiver
small segment headerno congestion control: UDP
can blast away as fast asdesired
7/29/2019 Transp Layer1
11/35
UDP: moreUDP: more
-often used for streamingmultimedia appsloss tolerantrate sensitive
-other UDP usesDNSSNMP-reliable transfer over UDP:add reliability at applicationlayer-application-specific errorrecovery!
source port # dest port #
32 bits
Application
data
(message)
UDP segment format
length checksum
Length, in
bytes of UDP
segment,
includingheader
7/29/2019 Transp Layer1
12/35
UDP checksumUDP checksum
Sender:
treat segment contents assequence of 16-bitintegers
checksum: addition (1scomplement sum) ofsegment contents
sender puts checksum valueinto UDP checksum field
Receiver:
compute checksum of receivedsegmentcheck if computed checksum
equals checksum field value:NO - error detected
YES - no error detected. Butmaybe errors nonetheless?More later .
Goal: detect errors (e.g., flipped bits) in transmittedsegment
7/29/2019 Transp Layer1
13/35
Internet Checksum ExampleInternet Checksum ExampleNote
When adding numbers, a carryout from the mostsignificant 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 0
1 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 0
1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
wraparound
sum
checksum
7/29/2019 Transp Layer1
14/35
TCP: OverviewTCP: Overview RFCs: 793, 1122, 1323, 2018, 2581RFCs: 793, 1122, 1323, 2018, 2581
full duplex data:bi-directional data flow insame connectionMSS: maximum segment size
connection-oriented:handshaking (exchange ofcontrol msgs) inits sender,receiver state before dataexchange
flow controlled:sender will not overwhelmreceiver
point-to-point:one sender, one receiver
reliable, in-order bytesteam:
no message boundariespipelined:TCP congestion and flow controlset window size
send & receive buffers
s o c k e t
d o o r
T C P
s e n d b u f f e r
T C P
r e c e i v e b u f f e r
s o c k e t
d o o r
s e g m e n t
a p p l i c a t i o n
w r i t e s d a t aa p p l i c a t i o n
r e a d s d a t a
7/29/2019 Transp Layer1
15/35
TCP segment structureTCP segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence number
acknowledgement number
Receive window
Urg data pnterchecksum
FSRPAUhead
len
not
used
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)
# bytesrcvr willing
to accept
counting
by bytes
of data
(not segments!)
Internet
checksum
(as in UDP)
7/29/2019 Transp Layer1
16/35
TCP seq. #s and ACKsTCP seq. #s and ACKs
Seq. #s:byte stream number offirst byte in segmentsdataACKs:
seq # of next byteexpected from other sidecumulative ACKQ: how receiver handles
out-of-order segments
A: TCP spec doesnt say, -up to implementor
Host A Host B
Seq=42,ACK=79,data=C
Seq=79,A
CK=43,data=C
Seq=43,ACK=80
User
types
C
host ACKs
receipt
of echoedC
host ACKs
receipt of
C, echoes
back C
timesimple telnet scenario
7/29/2019 Transp Layer1
17/35
TCP Round Trip Time and TimeoutTCP Round Trip Time and Timeout
Q: how to set TCPtimeout value?
longer than RTTbut RTT varies
too short: premature
timeoutunnecessaryretransmissionstoo long: slow reaction to
segment loss
Q: how to estimate RTT?SampleRTT: measured time from
segment transmission until ACKreceipt
ignore retransmissions
SampleRTTwill vary, wantestimated RTT smoother
average several recentmeasurements, not just currentSampleRTT
7/29/2019 Transp Layer1
18/35
TCP Round Trip Time and TimeoutTCP Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Exponential weighted moving average influence of past sample decreases exponentially fast
typical value: =
0.125
7/29/2019 Transp Layer1
19/35
Example RTT estimation: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
7/29/2019 Transp Layer1
20/35
TCP Round Trip Time andTCP Round Trip Time andTimeoutTimeout
Setting the timeoutEstimtedRTTplus safety marginlarge variation in EstimatedRTT -> larger safety margin
first estimate of how much SampleRTT deviates fromEstimatedRTT:
TimeoutInterval = EstimatedRTT + 4*DevRTT
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|(typically, = 0.25)Then set timeout interval:
7/29/2019 Transp Layer1
21/35
TCP reliable data transferTCP reliable data transfer
-TCP creates rdt service ontop of IPs unreliableservice
-Pipelined segments
-Cumulative acks-TCP uses singleretransmission timer
Retransmissions are triggeredby:
-timeout events-duplicate acks
Initially consider simplifiedTCP sender:-ignore duplicate acks-ignore flow control, congestioncontrol
7/29/2019 Transp Layer1
22/35
TCP sender events:TCP sender events:data rcvd from app:
Create segment with seq #seq # is byte-stream
number of first databyte in segment
start timer if not alreadyrunning (think of timeras for oldest unackedsegment)
expiration interval:
TimeOutInterval
timeout:
retransmit segment thatcaused timeout
restart timer
Ack rcvd:
If acknowledges previouslyunacked segments
update what is known to be ackedstart timer if there areoutstanding segments
7/29/2019 Transp Layer1
23/35
TCP: retransmission scenariosTCP: retransmission scenarios
Host A
Seq=100,20bytesdata
ACK=100
timepremature timeout
Host B
Seq=92,8bytesdata
ACK=120
Seq=92,8bytesdataSeq=92tim
eout
ACK=12
0
Host A
Seq=92,8bytesdata
ACK=10
0
loss
timeo
ut
lost ACK scenario
Host B
X
Seq=92,8bytesdata
ACK=100
time
Seq=92
timeout
SendBase
= 100
SendBase
= 120
SendBase
= 120
Sendbase
= 100
7/29/2019 Transp Layer1
24/35
TCP retransmission scenarios (more)TCP retransmission scenarios (more)
Host A
Seq=92,8bytesdata
ACK=10
0
loss
timeo
ut
Cumulative ACK scenario
Host B
X
Seq=100,20bytesdata
ACK=12
0
time
SendBase
= 120
7/29/2019 Transp Layer1
25/35
Fast RetransmitFast Retransmit
Time-out period oftenrelatively long:-long delay before resendinglost packet
Detect lost segments viaduplicate ACKs.-Sender often sends manysegments back-to-back-If segment is lost, there will
likely be many duplicate ACKs.
If sender receives 3 ACKsfor the same data, itsupposes that segment afterACKed data was lost:
fast retransmit: resend segmentbefore timer expires
7/29/2019 Transp Layer1
26/35
TCP Flow ControlTCP Flow Control
receive side of TCPconnection has a receivebuffer:
speed-matching service:matching the send rateto the receiving appsdrain rate
app process may beslow at reading frombuffer
sender wont overflowreceivers buffer bytransmitting too much,too fast
flow control
7/29/2019 Transp Layer1
27/35
TCP Flow control: how itTCP Flow control: how itworksworks
(Suppose TCP receiver discardsout-of-order segments)
spare room in buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]
Rcvr advertises spare roomby including value ofRcvWindow in segments
Sender limits unACKed datato RcvWindow
guarantees receive buffer doesntoverflow
7/29/2019 Transp Layer1
28/35
TCP Connection ManagementTCP Connection Management
Recall:TCP sender, receiverestablish connection beforeexchanging data segments
initialize TCP variables:seq. #s buffers, flow controlinfo (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 host sends TCPSYN segment to server
specifies initial seq #no data
Step 2:server host receivesSYN, replies with SYNACKsegment
server allocates buffersspecifies server initial seq. #
Step 3: client receives SYNACK,replies with ACK segment,which may contain data
7/29/2019 Transp Layer1
29/35
TCP Connection Management (cont.)TCP Connection Management (cont.)
Closing a connection:
client closes socket:clientSocket.close();
Step 1:client end systemsends TCP FIN controlsegment to server
Step 2:server receives
FIN, replies with ACK.Closes connection, sendsFIN.
client
FIN
server
ACK
ACK
FIN
close
close
closed
timedwait
7/29/2019 Transp Layer1
30/35
TCP Connection Management (cont.)TCP Connection Management (cont.)
Step 3:client receives FIN,replies with ACK.
Enters timed wait - willrespond with ACK to received
FINs
Step 4:server, receivesACK. Connection closed.
Note:with smallmodification, can handlesimultaneous FINs.
client
FIN
server
ACK
ACK
FIN
closing
closing
closed
timedwait
closed
7/29/2019 Transp Layer1
31/35
TCP Connection Management (cont)TCP Connection Management (cont)
TCP client
lifecycle
TCP server
lifecycle
7/29/2019 Transp Layer1
32/35
Congestion:Congestion:-informally: too many sources sending too much data toofast for networkto handle
-different from flow control!
-manifestations:
+lost packets (buffer overflow at routers)
+long delays (queueing in router buffers)
Principles of Congestion ControlPrinciples of Congestion Control
7/29/2019 Transp Layer1
33/35
Causes/costs of congestion: scenario 1Causes/costs of congestion: scenario 1two senders, tworeceiversone router, infinitebuffers
no retransmission
large delays when
congestedmaximumachievablethroughput
unlimited shared
output link buffers
Host A
in : original data
Host B
out
7/29/2019 Transp Layer1
34/35
Causes/costs of congestion: scenario 2Causes/costs of congestion: scenario 2
-one router, finitebuffers-sender retransmission of lost packet
finite shared output
link buffers
Host
A
in : original data
Host B
out
'in : original data, plus
retransmitted data
7/29/2019 Transp Layer1
35/35
Causes/costs of congestion: scenario 3Causes/costs of congestion: scenario 3
four sendersmultihop pathstimeout/retransmit
inQ:what happens asand increase ?in
finite shared
output link
buffers
Host Ain : original data
Host B
out
'in : original data, plus
retransmitted data