Transcript slides - Fei Hu

1 of 44
Week 2 Lecture 2 – Network Layers
Transport Layer – Example: TCP/UDP
2
Transport layer location
• application: supporting network
applications
– FTP, SMTP, STTP
• transport: host-host data transfer
– TCP, UDP
• network: routing of datagrams from
source to destination
application
transport
network
link
– IP, routing protocols
• link: data transfer between
neighboring network elements
– PPP, Ethernet
• physical: bits “on the wire”
physical
3 of 44
TCP/UDP Analogy
5 brothers
Mum
IP Layer
(routing)
Data link
layer
City
P.O.
-- Mum, please make sure
our sisters receive our
Christmas cards…
(Application Layer)
-- No problem, darling.
(TCP)
-- I’ll try my best, but …
(UDP)
5 Sisters
City
P.O.
NY Post
Office
Router
CA Post
Office
Dad
-- Dad, please make sure
our brothers receive our
Christmas cards…
(Application Layer)
-- No problem, darling.
(TCP)
-- I’ll try my best, but …
(UDP)
4 of 44
Likewise, in Internet …
Router 1A
network
data link
physical
Host A:
Christmas
Picture
application
transport
network
data link
physical
B IP Add
Host 1 Add
F
I
T
Host 1
Router 1
Router 2
Host 2
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
B socket #
Pic
0101010101111000 …
Host B:
Christmas
Picture
Identify a frame from
stream; Remove Frame
Header(FH); Analyze FH
and do sth like error
correction; It founds out
that frame is not to itself,
it will install new FH and
deliver it to Router 1.
Identify a frame; Remove
FH; do sth. based on FH;
Remove IP header; Analyze
IP header and do sth like
figuring out best route;
Install new IP header;
Install new frame header;
deliver it to next host
(Route 2).
Note: each node finally needs to form new frame !
application
transport
network
data link
physical
Anyway, Host 1 and
Route 1 do not look at
TCP header and message
(Picture); Only end hosts
(Host A & B look at TCP
header and do sth. So we
say TCP is end-to-end
protocol.
5 of 44
TCP is core Internet protocol
•
•
•
•
•
•
•
TCP shows the real network tricks !
Software-controlled
Lots of ideas
Lots of Algorithms
Lots of Protocols
Attract 30% networking research
Thousands of PhD students
6 of 44
Transport services and protocols
• provide logical
communication between app
processes running on
different hosts
• transport protocols run in
end systems
– send side: breaks app
messages into segments,
passes to network layer
– receive side: reassembles
segments into messages,
passes to app layer
• more than one transport
protocol available to apps
– Internet: TCP and UDP
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
7 of 44
Internet transport-layer protocols
• reliable, in-order delivery
(TCP)
– congestion control
– flow control
– connection setup
• unreliable, unordered
delivery: UDP
– no-frills extension of “besteffort” IP
• services not available:
– delay guarantees
– bandwidth guarantees
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
8 of 44
UDP: User Datagram Protocol : Unreliable Transport!
• “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 (no
pipe)
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
9 of 44
TCP – Reliable Transfer
10 of 44
Principles of Reliable data transfer
• important in app., transport, link layers
• top-10 list of important networking topics !
Needed in
Project #2
• characteristics of “unreliable channel” will determine
complexity of reliable data transfer protocol (rdt)
11 of 44
Reliable data transfer: getting started
rdt_send(): called from above,
(e.g., by app.). Passed data to
deliver to receiver upper layer
send
side
udt_send(): called by rdt,
to transfer packet over
unreliable channel to receiver
deliver_data(): called by
rdt to deliver data to upper
receive
side
rdt_rcv(): called when packet
arrives on rcv-side of channel
12 of 44
Reliable data transfer: getting started
We’ll:
• incrementally develop sender, receiver sides of reliable
data transfer protocol (rdt)
• consider only unidirectional data transfer
– but control info will flow on both directions!
• use finite state machines (FSM) to specify sender,
receiver
event causing state transition
actions taken on state transition
state: when in this “state”
next state uniquely
determined by next event
state
1
event
actions
state
2
13 of 44
Rdt1.0: reliable transfer over a reliable channel
• underlying channel perfectly reliable
– no bit errors
– no loss of packets
• separate FSMs for sender, receiver:
– sender sends data into underlying channel
– receiver read data from underlying channel
Wait for
call from
above
rdt_send(data)
packet = make_pkt(data)
udt_send(packet)
sender
Wait for
call from
below
rdt_rcv(packet)
extract (packet,data)
deliver_data(data)
receiver
14 of 44
Rdt2.0: channel with bit errors (but no loss)
• underlying channel may flip bits in packet
– recall: UDP checksum to detect bit errors
• the question: how to recover from errors:
– acknowledgements (ACKs): receiver explicitly tells sender that pkt
received OK
– negative acknowledgements (NAKs): receiver explicitly tells sender that
pkt had errors
-- sender retransmits pkt on receipt of NAK
• new mechanisms in rdt2.0 (beyond rdt1.0):
– error detection
– receiver feedback: control msgs (ACK,NAK) rcvr->sender
15 of 44
rdt2.0: FSM specification
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
Wait for
call from
ACK or
udt_send(sndpkt)
App
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
sender
receiver
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Wait for
call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
16 of 44
rdt2.0: operation with no errors
1
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
Wait for
call from
ACK or
udt_send(sndpkt)
above
NAK
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
3
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Wait for
call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
2
17 of 44
rdt2.0: error scenario
1
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
Wait for
call from
ACK or
udt_send(sndpkt)
above
NAK
3
rdt_rcv(rcvpkt) && isACK(rcvpkt)
L
5
2
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(NAK)
Wait for
call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
4
rdt3.0: channels with errors
and “loss”
New assumption: underlying
channel can also lose
packets (data or ACKs)
– checksum, seq. #, ACKs,
retransmissions will be of
help, but not enough
Q: how to deal with loss?
– sender waits until certain
data or ACK lost, then
retransmits
– yuck: drawbacks?
18 of 44
Approach: sender waits
“reasonable” amount of time
for ACK
• retransmits if no ACK received in
this time
• if pkt (or ACK) just delayed (not
lost):
– retransmission will be duplicate,
but use of seq. #’s already
handles this
– receiver must specify seq # of
pkt being ACKed
• requires countdown timer
19 of 44
rdt3.0 sender
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
L
Wait for
call 0 from
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
L
Wait
for
ACK0
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
Wait
for
ACK1
Wait for
call 1 from
above
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
L