1 Networking Primer - Transport Layer ECE 256 Spring 2009 Romit Roy Choudhury Dept. of ECE and CS.
-
Upload
francine-richard -
Category
Documents
-
view
215 -
download
2
Transcript of 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