1. Transmission & Error control
ARQ

2. Two scenarios network End to End Hop by Hop (transport protocol issue)
(datalink protocol issue)

3. Coping with rx errors Forward Error Correction Retransmission
Extra overhead capable of CORRECTING errors
Large overhead depending on protection capability
Retransmission
Extra overhead capable of DETECTING errors
Small constant overhead (2-4 bytes)
Called:
Frame Check Sequence
Cyclic Redundance Check

4. Retransmission scenarios referred to as ARQ schemes (Automatic Retransmission reQuest)
COMPONENTS: a) error checking at receiver; b) feedback to sender; c) retx
SRC
DST
SRC
DST
DATA
DATA
Error
Check: OK
Error
Check:
corrupted
ACK
NACK
Automatic
retransmit
DATA
Basic ACK idea
Basic NACK idea
SRC
DST
SRC
DST
SRC
DST
DATA
DATA
DATA
Retx
Timeout
(RTO)
Error
Check:
corrupted
ACK
DATA
DATA
DATA
Basic ACK/Timeout idea

5. Sequence numbers – a must
Sender side:
Receiver side:
DATA
DATA
RTO
ACK
DATALINK or
NETWORK
(ACK lost)
rtx
DATA
DATA
New data?
Old data?
Need to univocally “label” all packets circulating in the network between two end points.
1 bit (0-1) enough for Stop-and-wait

6. Link-level model C bits/sec
In e2e scenario, C approximated by bottleneck link rate
Stop & Wait 
one frame/packet at a time
Pipelining (continuous ARQ) 
more than one frame/packet

7. Stop & Wait

8. stop-and-wait sender receiver One way delay MSG/C RTT e ACK/C e
For simplicity all MSG of same size; extension to != size  use mean value
RTT e
ACK/C e
REMARK: throughput always lower than
Available link rate!
time
time

9. Upper bound
No processing
e = 0
ACK size negligible
ACK = 0

10. stop-and-wait: upper bound /1 MSG = 1500 bytes
Under-utilization with: 1) high capacity links, 2) large RTT links

11. stop-and-wait: upper bound /2 MSG = 1500 bytes
Under-utilization with: 1) high capacity links, 2) large RTT links

12. Dealing with errors sender receiver
IMPORTANT ISSUE: setting the Time Out right!
Too short  unnecessary rtx
Too short  inconsistent protocol operation
Too long  waste of time
Ideally: TO = RTT+ACK/C (+2 e)
Easy to say, but harder to do if RTT is not known (e.g. in e2e scenario) e TO e

13. Inconsistent protocol operation
sender
receiver
M=1
M=2  will be NEVER received!
Consequence: ACK MUST be also numbered
To always guarantee consistent operation TO
M=1
M=2
M=3

14. Performance with loss (upper bound)
No processing time, negligible ACK
Per packet loss probability P
Assumed indipendent
P(immediate success) = (1-P)
P(success at second tx) = P(1-P)
P(success at third tx) = P2(1-P)

15. Pipelining (Continuous ARQ)

16. Pipelining idea Up to W>1 frames can be “in fly”
In fly = frames transmitted but not yet ACKed
Sliding Window
Size W
“Slides” forward at each received ACK

17. Pipelining cases W=4 RTT (+1tx) ? W=10 time time
WINDOW SIZING that allows
CONTINUOUS TRANSMISSION
UNDER-SIZED
WINDOW: THROUGHPUT INEFFICIENCY

18. Esercizio (fatelo) MSG=500 bytes W=4 C= 2 Mbps Propagation = 16 ms
How much time to transmit 6 messages?
Which message size for continuous tx?

19. Continuous transmission
Condition in which link rate is fully utilized
Time to transmit
W frames
Time to receive
Ack of first frame
We may elaborate:
This means that full link utilization is possible when window size (in bits) is
Greater than the bandwidth (C bit/s) delay (RTT s) product!

20. Bandwidth-delay product
Network: like a pipe
C [bit/s] x D [s]
number of bits “flying” in the network
number of bits injected in the network by the tx, before that the first bit is rxed
64Kbps
A (64000x0.240) bits
“worm” in the air!!
bandwidth-delay product = no of bytes that saturate network pipe

21. Long Fat Networks LFNs (el-ef-an(t)s): large bandwidth-delay product
RTT (ms)
rate (kbps)
BxD (bytes)
Ethernet 3
10.000
3.750
T1, transUS 60
1.544
11.580
T1 satellite
480
1.544
92.640
T3 transUS 60
45.000
Gigabit transUS 60

22. Throughput for pipelining MSS = 1500 bytes

23. Maximum achievable throughput (assuming infinite speed line…)
W = bytes