1. EEC-484/584 Computer Networks
Lecture 6
Wenbing Zhao
(Part of the slides are based on Drs. Kurose & Ross’s slides for their Computer Networking book)

2. EEC-484/584: Computer Networks
Outline
Quiz#1 result
Introduction to transport layer
Multiplexing/demultiplexing
Reliable data transfer
1/3/2019
EEC-484/584: Computer Networks

3. EEC-484/584: Computer Networks
EEC584 (S1) Quiz#1 Result
High 100, low 30, average: 73.5
Q1: 37.5/50, Q2: 6.3/10, Q3: 15.3/20, Q4: 14.4/20
1/3/2019
EEC-484/584: Computer Networks
Wenbing Zhao

4. EEC-484/584: Computer Networks
EEC584 (S2) Quiz#1 Result
High 100, low 71, average: 84
Q1: 39/50, Q2: 9.3/10, Q3: 16.1/20, Q4: 19.4/20
1/3/2019
EEC-484/584: Computer Networks
Wenbing Zhao

5. EEC-484/584: Computer Networks
Transport Layer
Our goals:
Understand principles behind transport layer services:
multiplexing/ demultiplexing
reliable data transfer
flow control
congestion control
Learn about transport layer protocols in the Internet:
UDP: connectionless transport
TCP: connection-oriented transport
TCP congestion control
1/3/2019
EEC-484/584: Computer Networks

6. Internet 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
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
logical end-end transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
1/3/2019
EEC-484/584: Computer Networks

7. Multiplexing/Demultiplexing
Multiplexing at send host:
Demultiplexing at rcv host:
delivering received segments
to correct socket
gathering data from multiple
sockets, enveloping data with
header (later used for
demultiplexing)
= socket
= process
application
application P4
Ip enables comm between host and host
application P3 P1 P1 P2
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
host 3
host 1
host 2
1/3/2019
EEC-484/584: Computer Networks

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
32 bits
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP segment format
1/3/2019
EEC-484/584: Computer Networks

9. Connectionless Demultiplexing
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
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)
1/3/2019
EEC-484/584: Computer Networks

10. EEC-484/584: Computer Networks
Connectionless Demux
DatagramSocket serverSocket = new DatagramSocket(6428);
Client
IP:B P2
client
IP: A P1 P3
server
IP: C
SP: 6428
DP: 9157
SP: 9157
DP: 6428
DP: 5775
SP: 5775
SP provides “return address”
1/3/2019
EEC-484/584: Computer Networks

11. 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
1/3/2019
EEC-484/584: Computer Networks

12. Connection-Oriented DemuxP1
client
IP: A P4 P5 P6 P2 P1 P3
DP: 80
SP: 5775
S-IP: B
D-IP:C
SP: 9157
SP: 9157
DP: 80
DP: 80
Client
IP:B
server
IP: C
S-IP: A
S-IP: B
D-IP:C
D-IP:C
1/3/2019
EEC-484/584: Computer Networks

13. Connection-oriented demux: Multi-Threaded Web ServerP1
client
IP: A P4 P2 P1 P3
SP: 5775
DP: 80
S-IP: B
D-IP:C
SP: 9157
SP: 9157
DP: 80
DP: 80
Client
IP:B
server
IP: C
S-IP: A
S-IP: B
D-IP:C
D-IP:C
1/3/2019
EEC-484/584: Computer Networks

14. Principles of Reliable Data Transfer
Important in app., Transport, link layers
Top-10 list of important networking topics!
Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
1/3/2019
EEC-484/584: Computer Networks

15. Reliable Data Transfer: Getting Started
rdt_send(): called from above, (e.g., by app.). Passed data to
deliver to receiver upper layer
deliver_data(): called by rdt to deliver data to upper
send
side
receive
side
udt_send(): called by rdt,
to transfer packet over
unreliable channel to receiver
rdt_rcv(): called when packet arrives on rcv-side of channel
1/3/2019
EEC-484/584: Computer Networks

16. 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 1
state: when in this “state” next state uniquely determined by next event
state 2
event
actions
1/3/2019
EEC-484/584: Computer Networks

17. 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
rdt_rcv(packet)
Wait for call from above
rdt_send(data)
Wait for call from below
extract (packet,data)
deliver_data(data)
packet = make_pkt(data)
udt_send(packet)
sender
receiver
1/3/2019
EEC-484/584: Computer Networks

18. rdt2.0: channel with bit errors
Underlying channel may flip bits in packet
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
1/3/2019
EEC-484/584: Computer Networks

19. rdt2.0: FSM specification
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
receiver
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for ACK or NAK
Wait for call from above
udt_send(NAK)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Wait for call from below L
sender
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
1/3/2019
EEC-484/584: Computer Networks

20. rdt2.0: operation with no errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for ACK or NAK
Wait for call from above
udt_send(NAK)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Wait for call from below L
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
1/3/2019
EEC-484/584: Computer Networks

21. rdt2.0: error scenario L rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for ACK or NAK
Wait for call from above
udt_send(NAK)
rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
Wait for call from below L
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
1/3/2019
EEC-484/584: Computer Networks

22. EEC-484/584: Computer Networks
rdt2.0 has a fatal flaw!
What happens if ACK/NAK corrupted?
sender doesn’t know what happened at receiver!
can’t just retransmit: possible duplicate
Handling duplicates:
sender retransmits current pkt if ACK/NAK garbled
sender adds sequence number to each pkt
receiver discards (doesn’t deliver up) duplicate pkt
Stopped here 2/22/12
stop and wait
Sender sends one packet,
then waits for receiver
response
1/3/2019
EEC-484/584: Computer Networks

23. rdt2.1: sender handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
Wait for ACK or NAK 0
Wait for call 0 from above
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt) L L
Wait for ACK or NAK 1
Wait for
call 1 from above
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
udt_send(sndpkt)
1/3/2019
EEC-484/584: Computer Networks

24. rdt2.1: receiver handles garbled packets
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
Stopped here 9/28/2009
Wait for
0 from below
Wait for
1 from below
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
1/3/2019
EEC-484/584: Computer Networks

25. EEC-484/584: Computer Networks
rdt2.1: discussion
Sender:
seq # added to pkt
two seq. #’s (0,1) will suffice. Why?
must check if received ACK/NAK corrupted
twice as many states
state must “remember” whether “current” pkt has 0 or 1 seq. #
Receiver:
must check if received packet is duplicate
state indicates whether 0 or 1 is expected pkt seq #
note: receiver can not know if its last ACK/NAK received OK at sender
1/3/2019
EEC-484/584: Computer Networks

26. rdt2.2: a NAK-free protocol
Same functionality as rdt2.1, using acks only
Instead of NAK, receiver sends ACK for last pkt received OK
Receiver must explicitly include seq # of pkt being acked
Duplicate ACK at sender results in same action as NAK: retransmit current pkt
1/3/2019
EEC-484/584: Computer Networks

27. rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
Wait for ACK
Wait for call 0 from above
udt_send(sndpkt)
sender FSM
fragment
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt)) L
Wait for
0 from below
receiver FSM
fragment
udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
1/3/2019
EEC-484/584: Computer Networks

28. 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
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
1/3/2019
EEC-484/584: Computer Networks

29. EEC-484/584: Computer Networks
rdt3.0 sender
rdt_send(data)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) L L
Wait for
call 0from above
Wait for ACK0
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
Wait for ACK1
Wait for
call 1 from above
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) L
rdt_send(data)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer L
1/3/2019
EEC-484/584: Computer Networks

30. EEC-484/584: Computer Networks
rdt3.0 in action
1/3/2019
EEC-484/584: Computer Networks

31. EEC-484/584: Computer Networks
rdt3.0 in action
1/3/2019
EEC-484/584: Computer Networks

32. EEC-484/584: Computer Networks
Performance of rdt3.0
rdt3.0 works, but performance stinks
ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:
U sender: utilization – fraction of time sender busy sending
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
network protocol limits use of physical resources!
1/3/2019
EEC-484/584: Computer Networks

33. rdt3.0: stop-and-wait operation
sender
receiver
first packet bit transmitted, t = 0
last packet bit transmitted, t = L / R
first packet bit arrives
RTT
last packet bit arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
1/3/2019
EEC-484/584: Computer Networks