Lecture 3

Lecture 3
Data Link Layer (II)
COE5330 – Computer Networks

Winter 2010
Prof. Torres
Some material copyright 1996-2010
J.F Kurose and K.W. Ross, All Rights Reserved
Transport Layer 3-1

Announcements
 Homework #3
 Out today, due Sat
 Due Saturday, Dec. 18, 2010
 Homework #2 Solutions
 Out today
Transport Layer 3-2

Today
 Reliable data transfer protocols
 Stop-and-wait
 ARQ (Automatic Repeat Request)
 Pipelined protocols
• Go-back-N
• Selective Repeat
 Medium Access Control (MAC) Sublayer
Transport Layer 3-3

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 define
sender & receiver
event causing state transition
actions taken on state transition
state: when in this
“state” next state state state
1 event
uniquely determined 2
by next event actions
Transport Layer 3-4

Rdt1.0: reliable transfer over a reliable channel
 underlying channel perfectly reliable
 no bit errors
 no loss of frames
 separate FSMs for sender, receiver:
 sender sends data into underlying channel
 receiver read data from underlying channel
Wait for rdt_send(data) Wait for rdt_rcv(frame)

call from call from extract (frame,data)
above frame = make_frm(data) below deliver_data(data)
udt_send(frame)
sender receiver
Transport Layer 3-5

Problems with rdt 1.0:
 What can go wrong?
 frame arrives corrupted

• No re-transmission mechanism!
 frame never arrives
• Receiver can’t even detect this!
 Receiver is busy
• Sender has no way to stop!
Transport Layer 3-6

Rdt2.0: channel with bit errors
 underlying channel may flip bits in frame
 Employ an error detection method
 Assume (for now) that frames are never lost
 the question: how to recover from errors:
 acknowledgements (ACKs): receiver explicitly tells sender
that frm received OK
Q: How do
 negative humans recover
acknowledgements from
(NAKs): “errors”
receiver explicitly
tells senderduring
that frmconversation?
had errors
 sender retransmits frm on receipt of NAK
 new mechanisms in rdt2.0 (beyond rdt1.0):
 error detection
 receiver feedback: control msgs (ACK,NAK) rcvr->sender
Transport Layer 3-7

 Assume (for now) that frames are never lost
 negative acknowledgements (NAKs): receiver explicitly
tells sender that frm had errors
 error detection
Transport Layer 3-8

 negative acknowledgements (NAKs): receiver explicitly
tells sender that frm had errors
 error detection
Transport Layer 3-9

rdt2.0: FSM specification
rdt_send(data)
sndfrm = make_frm(data, checksum) receiver
udt_send(sndfrm)
rdt_rcv(rcvfrm) &&
isNAK(rcvfrm)
Wait for Wait for rdt_rcv(rcvfrm) &&
call from ACK or udt_send(sndfrm corrupt(rcvfrm)
above NAK )
udt_send(NAK)
rdt_rcv(rcvfrm) && isACK(rcvfrm)

Wait for
L
call from
sender below
rdt_rcv(rcvfrm) &&
notcorrupt(rcvfrm)
extract(rcvfrm,data)
deliver_data(data)
udt_send(ACK)
Transport Layer 3-10

rdt2.0: operation with no errors
rdt_send(data)
snkfrm = make_frm(data, checksum)
udt_send(sndfrm)
rdt_rcv(rcvfrm) &&
isNAK(rcvfrm)
above NAK )
udt_send(NAK)

Wait for
L call from
below
rdt_rcv(rcvfrm) &&
notcorrupt(rcvfrm)
Note: This protocol implements flow extract(rcvfrm,data)
control. (How?) deliver_data(data)
udt_send(ACK)

rdt2.0: error scenario
rdt_send(data)
udt_send(sndfrm)
rdt_rcv(rcvfrm) &&
isNAK(rcvfrm)
above NAK )
udt_send(NAK)

Wait for
L call from
below
rdt_rcv(rcvfrm) &&
notcorrupt(rcvfrm)
deliver_data(data)
udt_send(ACK)

rdt2.0 has a fatal flaw!
What happens if How to fix:
ACK/NAK corrupted?  handle duplicates:
 sender doesn’t know what  sender retransmits current
happened at receiver! frm if ACK/NAK garbled
 can’t just retransmit:  sender adds sequence
possible duplicate number to each frm
rdt_send(data)  receiver discards (doesn’t
udt_send(sndfrm) deliver up) duplicate frm
stop and wait
rdt_rcv(rcvfrm) &&
isNAK(rcvfrm)
Wait for call Wait for Sender sends one frame,

then waits for receiver
from above ACK or NAK udt_send(sndfrm)
response
L
sender
rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data)
sndfrm = make_frm(0, data, checksum)
udt_send(sndfrm) rdt_rcv(rcvfrm) &&
( corrupt(rcvfrm) ||
Wait for Wait for
ACK or
isNAK(rcvfrm) )
call 0 from
NAK udt_send(sndfrm)
above
rdt_rcv(rcvfrm)
&& notcorrupt(rcvfrm) rdt_rcv(rcvfrm)
&& isACK(rcvfrm) && notcorrupt(rcvfrm)
&& isACK(rcvfrm)
L
L
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvfrm) && NAK above
isNAK(rcvfrm) ) rdt_send(data)
udt_send(sndfrm) sndfrm = make_frm(1, data, checksum)

udt_send(sndfrm)

rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvfrm) && notcorrupt(rcvfrm)
&& has_seq0(rcvfrm)
deliver_data(data)
sndfrm = make_frm(ACK, chksum)
udt_send(sndfrm)
rdt_rcv(rcvfrm) && (corrupt(rcvfrm) rdt_rcv(rcvfrm) && (corrupt(rcvfrm)
sndfrm = make_frm(NAK, chksum) sndfrm = make_frm(NAK, chksum)
udt_send(sndfrm) udt_send(sndfrm)
Wait for Wait for
rdt_rcv(rcvfrm) && 0 from 1 from rdt_rcv(rcvfrm) &&
not corrupt(rcvfrm) && below below not corrupt(rcvfrm) &&
has_seq1(rcvfrm) has_seq0(rcvfrm)
sndfrm = make_frm(ACK, chksum) sndfrm = make_frm(ACK, chksum)
&& has_seq1(rcvfrm)
deliver_data(data)
sndfrm = make_frm(ACK, chksum)
udt_send(sndfrm)

rdt2.1: discussion
Sender: Receiver:
 seq # added to frm  must check if received
 two seq. #’s (0,1) will frame is duplicate
suffice. Why?  state indicates whether
0 or 1 is expected frm
 Sender stops and waits
seq #
• frame n won’t be sent
until frame n-1 is  note: receiver can not
acknowledged
know if its last
 must check if received ACK/NAK received OK
ACK/NAK corrupted at sender
 twice as many states
 state must “remember”
whether “current” frm
has 0 or 1 seq. # Transport Layer 3-16
rdt2.2: a NAK-free protocol
 same functionality as rdt2.1, using ACKs only

 instead of NAK, receiver sends ACK for last frm
received OK
 receiver must explicitly include seq # of frm being ACKed
 duplicate ACK at sender results in same action as
NAK: retransmit current frm

rdt2.2: sender
rdt_send(data)
sndfrm = make_frm(0, data, checksum)
udt_send(sndfrm) rdt_rcv(rcvfrm) &&
Wait for Wait for
ACK or
isACK(rcvfrm,1))
call 0 from
NAK udt_send(sndfrm)
above
rdt_rcv(rcvfrm)
&& isACK(rcvfrm,1) && notcorrupt(rcvfrm)
&& isACK(rcvfrm,0)
L
L
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvfrm) && NAK above
isACK(rcvfrm,0) ) rdt_send(data)
udt_send(sndfrm) sndfrm = make_frm(1, data, checksum)

udt_send(sndfrm)

rdt2.2: Receiver
&& has_seq0(rcvfrm)
deliver_data(data)
sndfrm = make_frm(ACK0, chksum)
udt_send(sndfrm)
rdt_rcv(rcvfrm) && (corrupt(rcvfrm) rdt_rcv(rcvfrm) && (corrupt(rcvfrm)
|| has_seq1(rcvfrm)) ||has_seq0(rcvfrm))
Wait for Wait for
0 from 1 from
below below

&& has_seq1(rcvfrm)
deliver_data(data)
sndfrm = make_frm(ACK1, chksum)
udt_send(sndfrm)

rdt3.0: channels with errors and loss
New assumption: Approach: sender waits

underlying channel can “reasonable” amount of
also lose frames (data time for ACK
or ACKs)  retransmits if no ACK
 checksum, seq. #, ACKs, received in this time
retransmissions will be  if frm (or ACK) just delayed
of help, but not enough (not lost):
 Sender can get stuck  retransmission will be
waiting forever for ack!! duplicate, but use of seq.
#’s already handles this
 receiver must specify seq
# of frm being ACKed
 requires countdown timer

Edited by Foxit Reader
Copyright(C) by Foxit Corporation,2005-2009
rdt3.0 sender
For Evaluation Only.
rdt_send(data)
rdt_rcv(rcvfrm) &&
sndfrm = make_frm(0, data, checksum) ( corrupt(rcvfrm) ||
udt_send(sndfrm) isACK(rcvfrm,1) )
rdt_rcv(rcvfrm) start_timer L
L Wait for Wait
for timeout
call 0from
ACK0 udt_send(sndfrm)
above
start_timer
rdt_rcv(rcvfrm)
&& isACK(rcvfrm,1) && notcorrupt(rcvfrm)
stop_timer && isACK(rcvfrm,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndfrm) ACK1 above
start_timer rdt_rcv(rcvfrm)
rdt_send(data) L
rdt_rcv(rcvfrm) &&
( corrupt(rcvfrm) || sndfrm = make_frm(1, data, checksum)
isACK(rcvfrm,0) ) udt_send(sndfrm)
start_timer
L

rdt 3.0 receiver
 Homework problem 

rdt 3.0 is….
 An example of an ARQ (automatic repeat
request) protocol
 Also called PAR (positive acknowledgement w/
retransmission)
 An example of a stop-and-wait protocol
 A frame is not send until preceding frame has
been sent

rdt3.0 in action
Note: in these diagrams, the
word “packet” means frame.

rdt3.0 in action

Premature timeout
 What can cause this?

Edited by Foxit Reader
Copyright(C) by Foxit Corporation,2005-2009
Performance of rdt3.0
For Evaluation Only.
 rdt3.0 works, but performance stinks

 Sender must wait for ack before sending next frame
 ex: 1 Gbps link, 15 ms propagation delay (transit time),
8000 bit frame:
L 8000bits
delaytrans   9
 8  sec
R 10 bps
 U sender: utilization = fraction of time sender busy sending
U L/R .008
= = = 0.00027
sender 30.008
RTT + L / R microsec
onds
 if RTT=30 msec, 1KB frm every 30 msec -> 33kB/sec thruput
over 1 Gbps link
 network protocol limits use of physical resources!

rdt3.0: stop-and-wait operation
sender receiver
first frame bit transmitted, t = 0
last frame bit transmitted, t = L / R
first frame bit arrives

RTT last frame bit arrives, send ACK
ACK arrives, send next

frame, t = RTT + L / R
U L/R .008
sender
= = = 0.00027
RTT + L / R 30.008 microsec
onds

Pipelined protocols
pipelining: sender allows multiple, “in-flight”, yet-to-
be-acknowledged frms
 range of sequence numbers must be increased
 buffering at sender and/or receiver
 two generic forms of pipelined protocols: go-Back-N,

selective repeat
Pipelining: increased utilization
sender receiver
first frame bit transmitted, t = 0
last bit transmitted, t = L / R
first frame bit arrives

RTT last frame bit arrives, send ACK
last bit of 2nd frame arrives, send ACK
last bit of 3rd frame arrives, send ACK
ACK arrives, send next
frame, t = RTT + L / R
Increase utilization
by a factor of 3!
U 3*L/R .024
sender
= = = 0.0008
RTT + L / R 30.008 microsecon
ds

Pipelined Protocols
Go-back-N: big picture: Selective Repeat: big pic
 sender can have up to  sender can have up to
N unack’ed frames in N unack’ed frames in
pipeline pipeline
 rcvr only sends  rcvr sends individual
cumulative acks ack for each frame
 doesn’t ack frame if  sender maintains timer
there’s a gap for each unacked
 sender has timer for frame
oldest unacked frame  when timer expires,
 if timer expires, retransmit only
retransmit all unack’ed unack’ed frame
frames

Go-Back-N
Sender:
 k-bit seq # in frm header
 “window” of up to N, consecutive unack’ed frms allowed
 ACK(n): ACKs all frms up to, including seq # n - “cumulative ACK”

 may receive duplicate ACKs (see receiver)
 timer for each in-flight frm
 timeout(n): retransmit frm n and all higher seq # frms in window

GBN sender: extended FSM
rdt_send(data)
if (nextseqnum < base+N) {
if (base == nextseqnum){
start_timer
}
sndfrm[nextseqnum] = make_frm(nextseqnum,data,chksum)
udt_send(sndfrm[nextseqnum])
nextseqnum++
}
L else
base=1 refuse_data(data)
nextseqnum=1
timeout
start_timer
Wait
udt_send(sndfrm[base])
rdt_rcv(rcvfrm) udt_send(sndfrm[base+1])
&& corrupt(rcvfrm) …
udt_send(sndfrm[nextseqnum-
1])
rdt_rcv(rcvfrm) &&
notcorrupt(rcvfrm)
base = getacknum(rcvfrm)+1
If (base == nextseqnum)
stop_timer
else
start_timer
GBN receiver: extended FSM
default
udt_send(sndfrm) rdt_rcv(rcvfrm)
&& notcurrupt(rcvfrm)
L && hasseqnum(rcvfrm,expectedseqnum)
expectedseqnum=1 Wait extract(rcvfrm,data)
sndfrm = deliver_data(data)
make_frm(expectedseqnum,ACK,chksum) sndfrm = make_frm(expectedseqnum,ACK,chksum)
udt_send(sndfrm)
expectedseqnum++
ACK-only: always send ACK for correctly-received frm

with highest in-order seq #
 may generate duplicate ACKs
 need only remember expectedseqnum
 out-of-order frm:
 discard (don’t buffer) -> no receiver buffering!
 Re-ACK frm with highest in-order seq #
GBN in
action

Selective Repeat
 receiver individually acknowledges all correctly
received frms
 buffers frms, as needed, for eventual in-order delivery
to upper layer
 sender only resends frms for which ACK not
received
 sender timer for each unACK’ed frm
 sender window
 N consecutive seq #’s
 again limits seq #s of sent, unACK’ed frms

Selective repeat: sender, receiver windows

Selective repeat
sender receiver
data from above : frm n in [rcvbase, rcvbase+N-1]
 if next available seq # in  send ACK(n)
window, send frm  out-of-order: buffer
in-order: deliver (also deliver
timeout(n): 
buffered, in-order frms),
 resend frm n, restart advance window to next not-
timer yet-received frm
ACK(n) in [sendbase,sendbase+N]: frm n in [rcvbase-N,rcvbase-1]
 mark frm n as received  ACK(n)
If old ACK’s got lost…
 if n smallest unACKed frm, 
 Enables sender to advance
advance window base to its window
next unACKed seq #
otherwise:
 ignore

Selective repeat in action

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?
MAX_SEQ >= 2*win_size Transport Layer 3-41
Section 3.5:
Example Layer 2 Protocols
 PPP: Point-to-point protocol
 Used with SONET (Synchronous Optical
Network)
• Fiber optic media
 Dial-up connections
 ATM: Asynchronous Transfer Mode
 Used in combination with PPP for ADSL
connections
• Called PPPoA (PPP over ATM)
• DMAX DSL service uses this
 Details in textbook (Read)
Chapter 4: Medium Access
Control (MAC) Sublayer

Multiple Access Links and Protocols
Two types of “links”:
 point-to-point
 PPP for dial-up access
 point-to-point link between Ethernet switch and host
 broadcast (shared wire or medium)
 old-fashioned Ethernet
 upstream HFC
 802.11 wireless LAN
humans at a
shared wire (e.g., shared RF shared RF cocktail party
cabled Ethernet) (e.g., 802.11 WiFi) (satellite) (shared air, acoustical)
5: DataLink Layer 5-44
Multiple Access protocols
 single shared broadcast channel
 two or more simultaneous transmissions by nodes:
interference
 collision if node receives two or more signals at the same time
multiple access protocol
 distributed algorithm that determines how nodes
share channel, i.e., determine when node can transmit
 communication about channel sharing must use channel
itself!
 no out-of-band channel for coordination

Ideal Multiple Access Protocol
Broadcast channel of rate R bps
1. when one node wants to transmit, it can send at
rate R.
2. when M nodes want to transmit, each can send at
average rate R/M
3. fully decentralized:
 no special node to coordinate transmissions
 no synchronization of clocks, slots
4. Simple
(Ideal…. Doesn’t exist)

MAC Protocols: a taxonomy
Three broad classes:
 Channel Partitioning (Static Allocation)
 divide channel into smaller “pieces” (time slots,
frequency, code)
 allocate piece to node for exclusive use
 Random Access (Dynamic Allocation)
 channel not divided, allow collisions
 “recover” from collisions
 “Taking turns” (Dynamic Allocation – Collision Free)
 nodes take turns, but nodes with more to send can take
longer turns

Channel Partitioning MAC protocols: TDMA
TDMA: time division multiple access

 access to channel in "rounds"
 each station gets fixed length slot (length = pkt
trans time) in each round
 unused slots go idle
 example: 6-station LAN, 1,3,4 have pkt, slots 2,5,6
idle
6-slot
frame
1 3 4 1 3 4

Channel Partitioning MAC protocols: FDMA
FDMA: frequency division multiple access
 channel spectrum divided into frequency bands
 each station assigned fixed frequency band
 unused transmission time in frequency bands go idle
 example: 6-station LAN, 1,3,4 have pkt, frequency
bands 2,5,6 idle
frequency bands
FDM cable

Random Access Protocols
 When node has packet to send
 transmit at full channel data rate R.
 no a priori coordination among nodes
 two or more transmitting nodes ➜ “collision”,
 random access MAC protocol specifies:
 how to detect collisions
 how to recover from collisions (e.g., via delayed
retransmissions)
 Examples of random access MAC protocols:
 slotted ALOHA
 ALOHA
 CSMA, CSMA/CD, CSMA/CA

Slotted ALOHA
Assumptions: Operation:
 all frames same size  when node obtains fresh
 time divided into equal frame, transmits in next
size slots (time to slot
transmit 1 frame)  if no collision: node can
 nodes start to transmit send new frame in next
only @ slot beginning slot
 nodes are synchronized  if collision: node
 if 2 or more nodes
retransmits frame in
transmit in slot, all each subsequent slot
nodes detect collision with prob. p until
success

Slotted ALOHA
Pros Cons
 single active node can  collisions, wasting slots
continuously transmit  idle slots
at full rate of channel  nodes may be able to
 highly decentralized: detect collision in less
only slots in nodes than time to transmit
packet
need to be in sync
 clock synchronization
 simple
Slotted Aloha efficiency
Efficiency : long-run  max efficiency: find
fraction of successful slots p* that maximizes
(many nodes, all with many Np(1-p)N-1
frames to send)  for many nodes, take
limit of Np*(1-p*)N-1
 suppose: N nodes with as N goes to infinity,
many frames to send, gives:
each transmits in slot Max efficiency = 1/e = .37
with probability p
!
 prob that given node At best: channel
has success in a slot = used for useful
p(1-p)N-1 transmissions 37%
 prob that any node has of time!
a success = Np(1-p)N-1
Pure (unslotted) ALOHA
 unslotted Aloha: simpler, no synchronization
 when frame first arrives
 transmit immediately
 collision probability increases:
 frame sent at t0 collides with other frames sent in [t0-1,t0+1]

Pure Aloha efficiency
P(success by given node) = P(node transmits) x
P(no other node transmits in [t0-1,t0] x

P(no other node transmits in [t0,t0+1]
= p . (1-p)N-1 . (1-p)N-1
= p . (1-p)2(N-1)
… choosing optimum p and then letting n -> infty ...
= 1/(2e) = .18
even worse than slotted Aloha!

CSMA (Carrier Sense Multiple Access)
CSMA: listen before transmit:

If channel sensed idle: transmit entire frame
 If channel sensed busy, defer transmission
 human analogy: don’t interrupt others!

CSMA collisions spatial layout of nodes
collisions can still occur:

propagation delay means
two nodes may not hear
each other’s transmission
collision:
entire packet transmission
time wasted
note:
role of distance & propagation
delay in determining collision
probability
(bandwidth-delay product!)

CSMA/CD (Collision Detection)
CSMA/CD: carrier sensing, deferral as in CSMA
 collisions detected within short time
 colliding transmissions aborted, reducing channel
wastage
 collision detection:
 easy in wired LANs: measure signal strengths,
compare transmitted, received signals
 difficult in wireless LANs: received signal strength
overwhelmed by local transmission strength
 human analogy: the polite conversationalist

CSMA/CD collision detection

“Taking Turns” MAC protocols
(a.k.a. Collision-Free)
channel partitioning MAC protocols:
 share channel efficiently and fairly at high load
 inefficient at low load: delay in channel access,
1/N bandwidth allocated even if only 1 active
node!
Random access MAC protocols
 efficient at low load: single node can fully
utilize channel
 high load: collision overhead
“taking turns” protocols
look for best of both worlds!
Polling:
 master node
“invites” slave nodes data
to transmit in turn poll
 typically used with master
“dumb” slave devices data
 concerns:
 polling overhead
 latency slaves
 single point of
failure (master)

Token passing:
T
 control token passed
from one node to next
sequentially.
 token message (nothing
to send)
 concerns:
T
 token overhead
 latency
 single point of failure
(token)
data
Summary of MAC protocols
 channel partitioning, by time, frequency or code
 Time Division, Frequency Division
 random access (dynamic),
 ALOHA, S-ALOHA, CSMA, CSMA/CD
 carrier sensing: easy in some technologies (wire), hard in
others (wireless)
 CSMA/CD used in Ethernet
 CSMA/CA used in 802.11
 taking turns
 polling from central site, token passing
 Bluetooth, FDDI, IBM Token Ring

Lecture 3

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Lecture 3

Transféré par

Droits d'auteur :

Formats disponibles

Lecture 3

Data Link Layer (II)

COE5330 – Computer Networks

Transport Layer 3-1

Transport Layer 3-2

 Medium Access Control (MAC) Sublayer

Transport Layer 3-3

Transport Layer 3-4

Wait for rdt_send(data) Wait for rdt_rcv(frame)

Transport Layer 3-5

 frame arrives corrupted

Transport Layer 3-6

Transport Layer 3-7

Transport Layer 3-8

Transport Layer 3-9

rdt_rcv(rcvfrm) && isACK(rcvfrm)

Transport Layer 3-10

rdt_rcv(rcvfrm) && isACK(rcvfrm)

Transport Layer 3-11

rdt_rcv(rcvfrm) && isACK(rcvfrm)

Transport Layer 3-12

Wait for call Wait for Sender sends one frame,

udt_send(sndfrm) sndfrm = make_frm(1, data, checksum)

Transport Layer 3-14

Transport Layer 3-15

 same functionality as rdt2.1, using ACKs only

Transport Layer 3-17

udt_send(sndfrm) sndfrm = make_frm(1, data, checksum)

Transport Layer 3-19

rdt_rcv(rcvfrm) && notcorrupt(rcvfrm)

Transport Layer 3-20

New assumption: Approach: sender waits

Transport Layer 3-21

Transport Layer 3-22

Transport Layer 3-23

Transport Layer 3-24

Transport Layer 3-25

Transport Layer 3-26

Transport Layer 3-27

 rdt3.0 works, but performance stinks

Transport Layer 3-28

first frame bit arrives

ACK arrives, send next

Transport Layer 3-29

 two generic forms of pipelined protocols: go-Back-N,

first frame bit arrives

Transport Layer 3-31

Transport Layer 3-32

 ACK(n): ACKs all frms up to, including seq # n - “cumulative ACK”

Transport Layer 3-33

ACK-only: always send ACK for correctly-received frm

Transport Layer 3-36

Transport Layer 3-37

Transport Layer 3-38

Transport Layer 3-39

Transport Layer 3-40

Transport Layer 3-43

5: DataLink Layer 5-45

(Ideal…. Doesn’t exist)

5: DataLink Layer 5-47

TDMA: time division multiple access

5: DataLink Layer 5-48

5: DataLink Layer 5-49