Lecture 3

Transport Layer 3-1

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

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

Transport Layer 3-4

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

state 1

state 2

event causing state transition

actions taken on state transition

state: when in this “state” next state

uniquely determined by next event

event

actions

Transport Layer 3-5

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

call from

above frame = make_frm(data)

udt_send(frame)

rdt_send(data)

extract (frame,data)

deliver_data(data)

Wait for

call from

below

rdt_rcv(frame)

sender receiver

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

Transport Layer 3-7

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

negative acknowledgements (NAKs): receiver explicitly tells sender that frm 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

Q: How do humans recover from “errors” during conversation?

Transport Layer 3-8



Assume (for now) that frames are never lost







Transport Layer 3-9









Transport Layer 3-10

rdt2.0: FSM specification

Wait for

call from

above

sndfrm = make_frm(data, checksum)

udt_send(sndfrm)

extract(rcvfrm,data)

deliver_data(data)

udt_send(ACK)

rdt_rcv(rcvfrm) &&

notcorrupt(rcvfrm)

rdt_rcv(rcvfrm) && isACK(rcvfrm)

udt_send(sndfrm

)

rdt_rcv(rcvfrm) &&

isNAK(rcvfrm)

udt_send(NAK)

rdt_rcv(rcvfrm) &&

corrupt(rcvfrm)

Wait for

ACK or

NAK

Wait for

call from

below sender

receiver rdt_send(data)

L


rdt2.0: operation with no errors

Wait for

call from

above

snkfrm = make_frm(data, checksum)

udt_send(sndfrm)


deliver_data(data)

udt_send(ACK)

rdt_rcv(rcvfrm) &&

notcorrupt(rcvfrm)


udt_send(sndfrm

)

rdt_rcv(rcvfrm) &&

isNAK(rcvfrm)

udt_send(NAK)

rdt_rcv(rcvfrm) &&

corrupt(rcvfrm)

Wait for

ACK or

NAK

Wait for

call from

below

rdt_send(data)

L

Note: This protocol implements flow control. (How?)


rdt2.0: error scenario

Wait for

call from

above


udt_send(sndfrm)


deliver_data(data)

udt_send(ACK)

rdt_rcv(rcvfrm) &&

notcorrupt(rcvfrm)


udt_send(sndfrm

)

rdt_rcv(rcvfrm) &&

isNAK(rcvfrm)

udt_send(NAK)

rdt_rcv(rcvfrm) &&

corrupt(rcvfrm)

Wait for

ACK or

NAK

Wait for

call from

below

rdt_send(data)

L


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

How to fix:

handle duplicates: sender retransmits current

frm if ACK/NAK garbled

sender adds sequence number to each frm

receiver discards (doesn’t deliver up) duplicate frm

Sender sends one frame, then waits for receiver response

stop and wait Wait for call

from above


udt_send(sndfrm)


udt_send(sndfrm)

rdt_rcv(rcvfrm) &&

isNAK(rcvfrm)

Wait for

ACK or NAK

sender

rdt_send(data)

L


rdt2.1: sender, handles garbled ACK/NAKs

Wait for

call 0 from

above

sndfrm = make_frm(0, data, checksum)

udt_send(sndfrm)

rdt_send(data)

Wait for

ACK or

NAK udt_send(sndfrm)

rdt_rcv(rcvfrm) &&

( corrupt(rcvfrm) ||

isNAK(rcvfrm) )


udt_send(sndfrm)

rdt_send(data)

rdt_rcv(rcvfrm)

&& notcorrupt(rcvfrm)

&& isACK(rcvfrm)

udt_send(sndfrm)

rdt_rcv(rcvfrm) &&


isNAK(rcvfrm) )

rdt_rcv(rcvfrm)


&& isACK(rcvfrm)

Wait for

call 1 from

above

Wait for

ACK or

NAK

L L


rdt2.1: receiver, handles garbled ACK/NAKs

Wait for

0 from

below

sndfrm = make_frm(NAK, chksum)

udt_send(sndfrm)

rdt_rcv(rcvfrm) &&

not corrupt(rcvfrm) &&

has_seq0(rcvfrm)

rdt_rcv(rcvfrm) && notcorrupt(rcvfrm)

&& has_seq1(rcvfrm)


deliver_data(data)

sndfrm = make_frm(ACK, chksum)

udt_send(sndfrm)

Wait for

1 from

below


&& has_seq0(rcvfrm)


deliver_data(data)


udt_send(sndfrm)

rdt_rcv(rcvfrm) && (corrupt(rcvfrm)


udt_send(sndfrm)

rdt_rcv(rcvfrm) &&

not corrupt(rcvfrm) &&

has_seq1(rcvfrm)



udt_send(sndfrm)

sndfrm = make_frm(NAK, chksum)

udt_send(sndfrm)


rdt2.1: discussion

Sender:

seq # added to frm

two seq. #’s (0,1) will suffice. Why? Sender stops and waits

• frame n won’t be sent until frame n-1 is acknowledged

must check if received ACK/NAK corrupted

twice as many states state must “remember”

whether “current” frm has 0 or 1 seq. #

Receiver:

must check if received frame is duplicate state indicates whether

0 or 1 is expected frm seq #

note: receiver can not know if its last ACK/NAK received OK at sender


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

Wait for

call 0 from

above


udt_send(sndfrm)

rdt_send(data)

Wait for

ACK or

NAK udt_send(sndfrm)

rdt_rcv(rcvfrm) &&


isACK(rcvfrm,1))


udt_send(sndfrm)

rdt_send(data)

rdt_rcv(rcvfrm)


&& isACK(rcvfrm,0)

udt_send(sndfrm)

rdt_rcv(rcvfrm) &&


isACK(rcvfrm,0) )

rdt_rcv(rcvfrm)


&& isACK(rcvfrm,1)

Wait for

call 1 from

above

Wait for

ACK or

NAK

L L


||has_seq0(rcvfrm))


rdt2.2: Receiver

Wait for

0 from

below

udt_send(sndfrm)


&& has_seq1(rcvfrm)


deliver_data(data)

sndfrm = make_frm(ACK1, chksum)

udt_send(sndfrm)

Wait for

1 from

below


&& has_seq0(rcvfrm)


deliver_data(data)

sndfrm = make_frm(ACK0, chksum)

udt_send(sndfrm) rdt_rcv(rcvfrm) && (corrupt(rcvfrm)

|| has_seq1(rcvfrm))

udt_send(sndfrm)


rdt3.0: channels with errors and loss

New assumption: underlying channel can also lose frames (data or ACKs) checksum, seq. #, ACKs,

retransmissions will be of help, but not enough

Sender can get stuck waiting forever for ack!!

Approach: sender waits “reasonable” amount of time for ACK

retransmits if no ACK received in this time

if frm (or ACK) just delayed (not lost):

retransmission will be duplicate, but use of seq. #’s already handles this

receiver must specify seq # of frm being ACKed

requires countdown timer


rdt3.0 sender


udt_send(sndfrm)

start_timer

rdt_send(data)

Wait

for

ACK0

rdt_rcv(rcvfrm) &&


isACK(rcvfrm,1) )

Wait for

call 1 from

above


udt_send(sndfrm)

start_timer

rdt_send(data)

rdt_rcv(rcvfrm)


&& isACK(rcvfrm,0)

rdt_rcv(rcvfrm) &&


isACK(rcvfrm,0) )

rdt_rcv(rcvfrm)


&& isACK(rcvfrm,1)

stop_timer

stop_timer

udt_send(sndfrm)

start_timer

timeout

udt_send(sndfrm)

start_timer

timeout

rdt_rcv(rcvfrm)

Wait for

call 0from

above

Wait

for

ACK1

L

rdt_rcv(rcvfrm)

L

L

L

Soukk

Note

retransmit

Soukk

Note

ignore duplicate ACK's

Edited by Foxit Reader Copyright(C) by Foxit Corporation,2005-2009 For Evaluation Only.

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?



Performance of rdt3.0

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:

U sender: utilization = fraction of time sender busy sending

U sender

= .008

30.008 = 0.00027

microsec

onds

L / R

RTT + L / R =

if RTT=30 msec, 1KB frm every 30 msec -> 33kB/sec thruput over 1 Gbps link

network protocol limits use of physical resources!

sec8bps10

bits80009

R

Ldelaytrans

Soukk

Note

RTT: Round Trip Time

Edited by Foxit Reader Copyright(C) by Foxit Corporation,2005-2009 For Evaluation Only.


rdt3.0: stop-and-wait operation

first frame bit transmitted, t = 0

sender receiver

RTT

last frame bit transmitted, t = L / R

first frame bit arrives

last frame bit arrives, send ACK

ACK arrives, send next

frame, t = RTT + L / R

U sender

= .008

30.008 = 0.00027

microsec

onds

L / R

RTT + L / R =


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

first frame bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first frame bit arrives

last frame bit arrives, send ACK

ACK arrives, send next

frame, t = RTT + L / R

last bit of 2nd frame arrives, send ACK

last bit of 3rd frame arrives, send ACK

U sender

= .024

30.008 = 0.0008

microsecon

ds

3 * L / R

RTT + L / R =

Increase utilization by a factor of 3!


Pipelined Protocols

Go-back-N: big picture: sender can have up to

N unack’ed frames in pipeline

rcvr only sends cumulative acks doesn’t ack frame if

there’s a gap

sender has timer for oldest unacked frame if timer expires,

retransmit all unack’ed frames

Selective Repeat: big pic sender can have up to

N unack’ed frames in pipeline

rcvr sends individual ack for each frame

sender maintains timer for each unacked frame when timer expires,

retransmit only unack’ed frame


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

Wait start_timer

udt_send(sndfrm[base])

udt_send(sndfrm[base+1])

…

udt_send(sndfrm[nextseqnum-

1])

timeout

rdt_send(data)

if (nextseqnum < base+N) {

if (base == nextseqnum){

start_timer

}

sndfrm[nextseqnum] = make_frm(nextseqnum,data,chksum)

udt_send(sndfrm[nextseqnum])

nextseqnum++

}

else

refuse_data(data)

base = getacknum(rcvfrm)+1

If (base == nextseqnum)

stop_timer

else

start_timer

rdt_rcv(rcvfrm) &&

notcorrupt(rcvfrm)

base=1

nextseqnum=1

rdt_rcv(rcvfrm)

&& corrupt(rcvfrm)

L


GBN receiver: extended FSM

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 #

Wait

udt_send(sndfrm)

default

rdt_rcv(rcvfrm)

&& notcurrupt(rcvfrm)

&& hasseqnum(rcvfrm,expectedseqnum)


deliver_data(data)

sndfrm = make_frm(expectedseqnum,ACK,chksum)

udt_send(sndfrm)

expectedseqnum++

expectedseqnum=1

sndfrm =

make_frm(expectedseqnum,ACK,chksum)

L


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

data from above : if next available seq # in

window, send frm

timeout(n): resend frm n, restart

timer

ACK(n) in [sendbase,sendbase+N]:

mark frm n as received

if n smallest unACKed frm, advance window base to next unACKed seq #

sender

frm n in [rcvbase, rcvbase+N-1]

send ACK(n)

out-of-order: buffer

in-order: deliver (also deliver buffered, in-order frms), advance window to next not-yet-received frm

frm n in [rcvbase-N,rcvbase-1]

ACK(n) If old ACK’s got lost…

Enables sender to advance its window

otherwise: ignore

receiver


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

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


5: DataLink Layer 5-44

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

shared wire (e.g., cabled Ethernet)

shared RF (e.g., 802.11 WiFi)

shared RF (satellite)

humans at a cocktail party

(shared air, acoustical)


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

1 3 4 1 3 4

6-slot frame


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

frequ

enc

y ban

ds

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: all frames same size time divided into equal

size slots (time to transmit 1 frame)

nodes start to transmit only @ slot beginning

nodes are synchronized if 2 or more nodes

transmit in slot, all nodes detect collision

Operation: when node obtains fresh

frame, transmits in next slot if no collision: node can

send new frame in next slot

if collision: node retransmits frame in each subsequent slot with prob. p until success


Slotted ALOHA

Pros

single active node can continuously transmit at full rate of channel

highly decentralized: only slots in nodes need to be in sync

simple

Cons collisions, wasting slots idle slots nodes may be able to

detect collision in less than time to transmit packet

clock synchronization


Slotted Aloha efficiency

suppose: N nodes with many frames to send, each transmits in slot with probability p

prob that given node has success in a slot = p(1-p)N-1

prob that any node has a success = Np(1-p)N-1

max efficiency: find p* that maximizes Np(1-p)N-1

for many nodes, take limit of Np*(1-p*)N-1

as N goes to infinity, gives:

Max efficiency = 1/e = .37

Efficiency : long-run fraction of successful slots (many nodes, all with many

frames to send)

At best: channel used for useful

transmissions 37% of time!

!


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

collisions can still occur: propagation delay means two nodes may not hear

each other’s transmission

collision: entire packet transmission

time wasted

spatial layout of nodes

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!


“Taking Turns” MAC protocols

Polling:

master node “invites” slave nodes to transmit in turn

typically used with “dumb” slave devices

concerns: polling overhead

latency

single point of failure (master)

master

slaves

poll

data

data


“Taking Turns” MAC protocols

Token passing:

control token passed from one node to next

sequentially.

token message

concerns: token overhead

latency

single point of failure (token)

T

data

(nothing to send)

T


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

Date post:	24-Nov-2014
Category:	Documents
Upload:	souvlaki2
View:	446 times
Download:	1 times

Lecture 3

Documents