ECSE-4670: Computer

Communication Networks (CCN) Chapter Goals

• Understand principles behind
Chapter 3a: Transport Layer transport layer services:
– multiplexing/demultiplexing
Shivkumar Kalyanaraman: [email protected] – reliable data transfer
Biplab Sikdar: [email protected] – flow control
– congestion control
• Instantiation and implementation in
the Internet

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 1 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 2
Adapted in part from J. Kurose (Umass)

Chapter Overview Transport services and

• Transport layer services protocols
• Multiplexing/demultiplexing • Provide logical communication between
• Connectionless transport: UDP app’ processes running on different hosts
• Principles of reliable data transfer • Transport protocols run in end systems
• Connection-oriented transport: TCP • Transport vs. network layer services:
– reliable transfer – network layer: data transfer between end
systems
– flow control
– transport layer: data transfer between
– connection management
processes
• Principles of congestion control – Relies on, enhances, network layer services
• TCP congestion control
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 3 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 4

Transport Services and Transport-layer protocols

Protocols Internet transport services:
application
transport
network
• Reliable, in-order unicast delivery (TCP)
data link network
physical
network
data link
physical
– congestion
lo

data link
gi

– flow control
ca

physical
l

network
en

data link
d-

physical network – connection setup

en

data link
d

physical
tr

• Unreliable (“best-effort”), unordered

an

network
sp

data link
unicast or multicast delivery: UDP
or

physical
t

application
transport
• Services not available:
network
data link
physical – real-time
– bandwidth guarantees
– reliable multicast
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 5 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 6

1
 Multiplexing / demultiplexing Multiplexing / demultiplexing
Multiplexing:
Recall: segment - unit of data Demultiplexing: delivering
exchanged between gathering data from multiple 32 bits
received segments to
transport layer entities app processes, enveloping
correct app layer processes data with header (later used source port # dest port #
– aka TPDU: transport
protocol data unit for demultiplexing)
receiver other header fields
P3 P4 multiplexing/demultiplexing:
application-layer M M
data • based on sender, receiver
application port numbers, IP
segment P1 transport P2
header M addresses application
M network
application application – source, dest port #s in data
segment Ht M transport transport
each segment (message)
network
Hn segment network
– recall: well-known port
numbers for specific
applications TCP/UDP segment format
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 7 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 8

Multiplexing/demultiplexing: UDP: User Datagram Protocol

source port: x
examples [RFC 768]
Web client
host A dest. port: 23 server B host C
• “no frills,” “bare bones” Internet transport
protocol
source port:23 • “best effort” service, UDP segments may be:
dest. port: x
Source IP: C Source IP: C – lost
Dest IP: B Dest IP: B
source port: y source port: x – delivered out of order to app
port use: simple telnet app dest. port: 80 dest. port: 80
• connectionless:
– no handshaking between UDP sender,
Source IP: A
Dest IP: B Web receiver
Web client source port: x server B – each UDP segment handled independently
host A dest. port: 80
port use: Web server of others
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 9 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 10

UDP: User Datagram Protocol UDP: more

[RFC 768] • Often used for streaming multimedia
apps
Why is there a UDP? – loss tolerant
• no connection establishment (which – rate sensitive
can add delay)
• Other UDP uses (why?):
• simple: no connection state at
sender, receiver – DNS
• small segment header – SNMP
• no congestion control: UDP can blast • Reliable transfer over UDP: add
away as fast as desired. reliability at application layer
– May not be a good idea, though! – application-specific error recovery!
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 11 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 12

2
 UDP: more Error Detection and Correction
• Single bit-errors vs Burst Errors
32 bits
110101 → 100101 vs 100001
Length, in source port # dest port #
• n-bit codeword = m message bits + r check bits
bytes of UDP length checksum
segment, • Hamming Distance = # of different bits
including 1010101
header
1001010
Application
0011111 ⇒ Hamming distance = 5
data • Distance d code = minimum Hamming distance
(message) between any two code words written in the code
• To detect d-bit errors, distance d+1 code required
UDP segment format • To correct d-bit errors, distance 2d+1 code required

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 13 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 14

Parity Checks UDP checksum

10111010 Goal: detect “errors” (e.g., flipped bits) in
1 2 3 4 5 6 7 8 9 transmitted segment
Odd Parity Sender:
• treat segment contents as sequence of 16-
10111010 0 001110100
1 2 3 4 5 6 7 89 1 2 3 4 5 6 7 89 bit integers
1-bit error • checksum: addition (1’s complement sum)
000100100 00011010 0 of segment contents
1 2 3 4 5 6 7 89 1 2 3 4 5 6 7 89
• sender puts checksum value into UDP
3-bit error 2-bit error
Even Parity checksum field
• In reality some IP header fields are
101110110 included w/ the UDP segment for
1 2 3 4 5 6 7 89
Parity is a distance 2 code => can detect 1-bit errors checksumming.
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 15 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 16

UDP checksum UDP Checksum Example

Receiver: • Consider three 16-bit words:
0110011001100110
• compute checksum of received segment
0101010101010101
• check if computed checksum equals 0000111100001111
checksum field value:
• (1’s complement) sum of first two 16-bit words is:
– NO - error detected 1011101110111011
– YES - no error detected. • Adding the third word to the above sum gives:
• But maybe errors nonetheless? 1100101011001010
• More in chap 5 on stronger error • 1’s complement of this sum => invert 0’s and 1’s
detection methods 0011010100110101 (this is the checksum field)
• If no errors, sum of all four 16-bit words (incl.
Checksum) will be all 1s, I.e., 1111111111111111
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 17 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 18

3
 Principles of Reliable Data
UDP Servers
Transfer
• Most UDP servers are “iterative” => a • Important in app., transport, link layers
single server process receives and • top-10 list of important networking topics!
handles incoming requests on a “well-
known” port.
• Can filter client requests based on
incoming IP/port addresses or wild card
filters
• Port numbers may be reused, but packet
is delivered to at most one end-point.
• Queues to hold requests if server busy • Characteristics of unreliable channel will determine
complexity of reliable data transfer protocol (rdt)
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 19 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 20

Reliable Data Transfer: Reliable Data Transfer:

Getting Started Getting Started
rdt_send(): called from above, deliver_data(): called by rdt
(e.g., by app.). Passed data to to deliver data to upper We’ll:
deliver to receiver upper layer
• incrementally develop sender,
receiver sides of reliable data
send receive transfer protocol (rdt)
side side • consider only unidirectional data
transfer
– but control info will flow on both
directions!
udt_send(): called by rdt,
to transfer packet over
rdt_rcv(): called when packet
arrives on rcv-side of channel
• use finite state machines (FSM) to
unreliable channel to specify sender, receiver
receiver
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 21 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 22

Reliable Data Transfer:

Rdt1.0: Reliable Transfer
Getting Started
over a Reliable Channel
• underlying channel perfectly reliable
event causing state transition
actions taken on state transition
– no bit errors
state: when in – no loss of packets
state state
this “state” 1 event
2 • separate FSMs for sender, receiver:
next state actions
uniquely – sender sends data into underlying
determined by channel
next event – receiver read data from underlying
channel

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 23 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 24

4
 Rdt1.0: Reliable Transfer over Rdt2.0: Channel with Bit Errors
a Reliable Channel (cont.)
• 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

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 25 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 26

Rdt2.0: Channel with Bit Errors Temporal Redundancy Model

(cont.) Packets • Sequence Numbers
– negative acknowledgements (NAKs): • CRC or Checksum
receiver explicitly tells sender that pkt Timeout
had errors • ACKs
Status Reports
– sender retransmits pkt on receipt of • NAKs,
NAK • SACKs
• Bitmaps
Retransmissions
• new mechanisms in Rdt2.0 (beyond • Packets
Rdt1.0): • FEC information
– error detection
– receiver feedback: control msgs
(ACK,NAK) rcvr->sender
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 27 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 28

Reliability Models Rdt2.0: FSM Specification

• Reliability => requires redundancy to recover from
uncertain loss or other failure modes.

• Two types of redundancy:

– Spatial redundancy: independent backup copies
• Forward error correction (FEC) codes
• Problem: requires huge overhead, since the
FEC is also part of the packet(s) it cannot
recover from erasure of all packets
sender FSM
– Temporal redundancy: retransmit if packets
lost/error
• Lazy: trades off response time for reliability
receiver FSM
• Design of status reports and retransmission
optimization important
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 29 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 30

5
 Rdt2.0: In Action (no errors) Rdt2.0: In action (error
scenario)

sender FSM receiver FSM

sender FSM receiver FSM
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 31 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 32

Reliability mechanisms learnt Rdt2.0 has a Fatal Flaw!

so far… What happens if ACK/NAK corrupted
• Mechanisms: • Reverse channel bit-errors
– Checksum in pkts: detects pkt corruption • Sender doesn’t know what happened at
– ACK: “packet correctly received” receiver!
– NAK: “packet incorrectly received”
– [aka: stop-and-wait Automatic Repeat What to do?
reQuest (ARQ) protocols] • Sender ACKs/NAKs receiver’s ACK/NAK?
Problem: What if sender ACK/NAK lost?
• Reliability capabilities achieved:
• Retransmit packet.
– An error-free channel
Problem: if original pkt correctly received, this
– A forward channel which has bit-errors
is a duplicate.
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 33 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 34

Rdt2.0 has a Fatal Flaw! (cont.) Rdt2.1: Sender, Handles

Garbled ACK/NAKs
Handling duplicates, garbled ACK/NAKs:
• sender adds sequence number to each pkt
• sender retransmits current pkt if ACK/NAK
garbled
• receiver discards (doesn’t deliver up)
duplicate pkt
stop and wait
Sender sends one packet,
then waits for receiver
response

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 35 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 36

6
 Rdt2.1: Receiver, Handles
Rdt2.1: Discussion
Garbled ACK/NAKs
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. #

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 37 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 38

Reliability mechanisms learnt

Rdt2.1: Discussion so far…
• Mechanisms:
Receiver: – Checksum: detects corruption in pkts & acks
– ACK: “packet correctly received”
• must check if received packet is
– NAK: “packet incorrectly received”
duplicate – Sequence number: identifies packet or ack
– state indicates whether 0 or 1 is – 1-bit sequence number used only in forward
expected pkt seq # channel [aka: alternating-bit protocols]
• Note: receiver cannot know if its last • Reliability capabilities achieved:
ACK/NAK received OK at sender – An error-free channel
– A forward & reverse channel with bit-errors
– Detects duplicates of packets/acks/naks
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 39 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 40

Rdt2.2: a NAK-free Protocol

Rdt2.2: a NAK-free Protocol
• Same functionality as rdt2.1, using ACKs sender
only. FSM
– Why bother ?
• 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

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 41 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 42

7
 Mechanisms learnt so far… Rdt3.0: Channels with Errors
• Mechanisms:
– Checksum: detects corruption in pkts & acks
and Loss
– ACK: “packet correctly received” New assumption: underlying channel
– Duplicate ACK: “packet incorrectly received” can also lose packets (data or ACKs)
– Sequence number: identifies packet or ack – What’s the difference, anyway?
• 1-bit sequence number used both in – Checksum, seq. #, ACKs, retransmissions
forward & reverse channel will help, but not enough
• Reliability capabilities achieved:
– An error-free channel Q: how to deal with loss?
– A forward & reverse channel with bit-errors – Sender waits until certain data or ACK
– Detects duplicates of packets/acks lost, then retransmits
– NAKs eliminated – Yuck: drawbacks?
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 43 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 44

Rdt3.0: Channels with Errors Rdt3.0 Sender

and Loss
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
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 45 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 46

Rdt3.0 in Action Rdt3.0 in Action

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 47 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 48

8
 Mechanisms learnt so far…
• Mechanisms: Performance of Rdt3.0
– Checksum: detects corruption in pkts & acks
• rdt3.0 works, but performance stinks!
– ACK: “packet correctly received”
– Duplicate ACK: “packet incorrectly received” • example: 1 Gbps link, 15 ms e2e prop.
– Sequence number: identifies packet or ack delay, 1KB packet:
• 1-bit sequence number used both in forward & 8kb/pkt
Ttransmit = = 8 microsec
reverse channel 10**9 b/sec
– Timeout only at sender fraction of time
=
8 microsec
= 0.00015
Utilization = U =
• Reliability capabilities achieved: sender busy sending 30.016 msec

– An error-free channel
– 1KB pkt every 30 msec -> 33kB/sec thruput
– A forward & reverse channel with bit-errors
over 1 Gbps link
– Detects duplicates of packets/acks
– NAKs eliminated – Problem: network protocol limits use of
– A forward & reverse channel with packet-errors (loss) physical resources!
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 49 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 50

Stop and Wait Efficiency

No loss or bit-errors! Utilization: More Examples
tframe
U=
2tprop+tframe • Satellite Link:
tframe Data
1 – Propagation Delay tprop = 270 ms
tprop =
2α + 1 Frame Size = 4000 bits = 500 bytes
Data Ack U Data rate = 56 kbps ⇒ tframe = 4/56 = 71 ms
α = tprop/tframe = 270/71 = 3.8
α U = 1/(2αα +1) = 0.12 (too low !!)
Light in vacuum
Ack
= 300 m/µs • Short Link (eg: LAN): Note: no loss
tprop Distance/Speed of Signal Light in fiber – 1 km = 5 µ s, or bit-errors!
α= = = 200 m/µs Rate=10 Mbps,
Frame size /Bit rate
tframe Electricity Frame=500 bytes ⇒ tframe= 4k/10M= 400 µ s
Distance × Bit rate = 250 m/µs α =tprop/tframe=5/400=0.012 ⇒ U=1/(2α
α +1)= 0.98 (great!)
=
Frame size × Speed of Signal
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 51 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 52

Stop-and-Wait ARQ: w/ loss

• P=Probability of
Pipelined protocols
bit-error
Tf 0 Pipelining: sender allows multiple,
§ α = Tp/Tf Tp “in-flight”, yet-to-be-
• U=Tf/[Nr(Tf+2Tp)] Nak 0
acknowledged pkts
α )]
= 1/[Nr(1+2α – range of sequence numbers must
be increased
Σ i Pi-1(1-P)
• Nr=Σ Nak
=1/(1-P) 0 – buffering at sender and/or receiver
– Also called “sliding window”
α)
• U=(1-P)/(1+2α Ack protocols
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 53 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 54

9
 Sliding Window Protocols: Efficiency
Pipelined protocols
Ntframe
U=
2tprop+tframe
tframe Data
tprop N
= 2α+1

1 if N>2α+1
Ack

• Two generic forms of pipelined protocols: Note: no loss

1. go-Back-N
or bit-errors!
2. selective repeat
A.k.a “sliding window” protocols
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 55 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 56

Go-Back-N Go-Back-N
Sender: • ACK(n): ACKs all pkts up to, including
• k-bit seq # in pkt header seq # n - “cumulative ACK”
– Allows upto N = 2k – 1 packets in-flight, – Sender may receive duplicate ACKs
unacked
(see receiver)
• “Window”: limit on # of consecutive unacked pkts
– Robust to losses on the reverse channel
– In GBN, window = N
– Can pinpoint the first packet lost, but
cannot identify blocks of lost packets in
window
• One timer for oldest-in-flight pkt
• Timeout => retransmit pkt “base” and all
higher seq # pkts in window
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 57 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 58

GBN: Sender Extended FSM GBN: Receiver Extended FSM

Receiver:
• ACK-only: always send ACK for
correctly-received pkt with highest in-
order seq #
– may generate duplicate ACKs
– need only remember expectedseqnum
– A.k.a. “receiver window”
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 59 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 60

10
 GBN: Receiver Extended FSM

• out-of-order pkt:
– discard (don’t buffer) -> no receiver GBN in
buffering! action
– ACK pkt with highest in-order seq #

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 61 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 62

Mechanisms learnt so far… Capabilities learnt so far…

• Checksum: detects corruption in pkts & acks
• ACK: “packet correctly received” • Reliability capabilities achieved:
– Duplicate ACK: “packet incorrectly received” – An error-free channel
– Cumulative ACK: acks all pkts upto & incl. seq # – A forward & reverse channel with bit-errors
• Sequence number: identifies packet or ack
– 1-bit sequence number used both in forward &
– Detects duplicates of packets/acks
reverse channels – NAKs eliminated
– k-bit sequence number in both forward & reverse – A forward & reverse channel with packet-
channels
• Timeout only at sender.
errors (loss)
– One timer for entire window – Pipelining efficiency.
• Window: sender and receiver side. Limits on what can • Go-back-N: Entire outstanding window
be sent (or expected to be received).
retransmitted if pkt loss/error
• Buffering at sender only
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 63 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 64

Selective Repeat Selective Repeat: Sender,

• Receiver individually acknowledges
Receiver Windows
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
– Limits seq #s of sent, unACKed pkts

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 65 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 66

11
 Selective Repeat Selective repeat
Sender Receiver
Data from above : Pkt n in [rcvbase, rcvbase+N-1]
• if next available seq # in window, send pkt • send ACK(n): “selective ack”
• out-of-order: buffer
• timeout(n):
• in-order: deliver (also deliver buffered, in-
– resend pkt n, restart timer
order pkts), advance window to next not-
• ACK(n) in [sendbase,sendbase+N]: yet-received pkt
– mark pkt n as received pkt n in [rcvbase-N,rcvbase-1]
– if n smallest unACKed pkt, advance window
• ACK(n)
base to next unACKed seq #
otherwise:
• ignore
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 67 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 68

Selective Repeat: Performance

Selective repeat in action
• Error Free:
α +1
U = 1 if N>2α
α +1) otherwise
N/(2α 1

Nak 1
• With Errors: 1
Σ i Pi-1(1-P)
Nr=Σ
=1/(1-P)
• U= (1-P) if N>(1+2α α)
α ) otherwise
N(1-P)/(1+2α
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 69 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 70

Selective repeat: dilemma

Example:
Selective • seq #’s: 0, 1, 2, 3
• window size=3
Repeat: • receiver sees no difference in two
Dilemma scenarios!
• incorrectly passes duplicate data as new
in (a)

Q: what relationship between seq # size and

window size?
A: sequence # space >= 2*window
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 71 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 72

12
 Reliability Mechanisms: Summary Reliability Mechanisms: Summary
• Checksum: detects corruption in pkts & acks
• Timeout only at sender.
• ACK: “packet correctly received”
– One timer for entire window (go-back-N)
– Duplicate ACK: “packet incorrectly received”
– One timer per pkt (selective repeat)
– Cumulative ACK: acks all pkts upto & incl. seq #
(GBN) • Window: sender and receiver side.
– Selective ACK: acks pkt “n” only (selective repeat) – Limits on what can be sent (or expected to be
received).
• Sequence number: identifies packet or ack
– Window size (W) upto N –1 (Go-back-N)
– 1-bit sequence number used both in forward &
reverse channels – Window size (W) upto N/2 (Selective Repeat)
– k-bit sequence number in both forward & reverse • Buffering
channels. – Only at sender (Go-back-N)
• Let N = 2k – 1 = sequence number space size – Out-of-order buffering at sender & receiver
(Selective Repeat)

Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 73 Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 74

Reliability capabilities: Summary

• Reliability capabilities achieved:
– An error-free channel
– A forward & reverse channel with bit-errors
– Detects duplicates of packets/acks
– NAKs eliminated
– A forward & reverse channel with packet-errors
(loss)
– Pipelining efficiency.
• Go-back-N: Entire outstanding window
retransmitted if pkt loss/error
• Selective Repeat: only lost packets
retransmitted
– performance penalty if ACKs lost (because
acks non-cumulative) & more complexity
Rensselaer Polytechnic Institute © Shivkumar Kalvanaraman & © Biplab Sikdar 75

13