Chapter 3, slide: 1 CS 372 – introduction to computer networks* Thursday July 8 Announcements: r Lab 3 is posted and due is Monday July 19. r Midterm is

Chapter 3, slide: 1

CS 372 – introduction to computer networks*Thursday July 8

Announcements: Lab 3 is posted and due is Monday July 19. Midterm is Wednesday July 21.

Acknowledgement: slides drawn heavily from Kurose & Ross

* Based in part on slides by Bechir Hamdaoui and Paul D. Paulson.

Chapter 3, slide: 2

rdt2.0 has a fatal flaw!

What happens if ACK/NAK is corrupted? That is, sender receives garbled ACK/NAK

sender doesn’t know what happened at receiver!

can’t sender just retransmit? Sure: sender retransmits current

pkt if ACK/NAK garbled Any problem with this ??

Handling duplicates: sender adds sequence

number to each pkt receiver discards

(doesn’t deliver up) duplicate pkt

Sender sends one packet, then waits for receiver response

stop and waitstop and waitSender sends one packet, then waits for receiver response

stop and wait

Receiver doesn’t know whether received pkt is a retransmit or a new pkt

Problem: duplicate

Chapter 3, slide: 3

rdt2.1: sender, handles garbled ACK/NAKs

Wait for call 0 from

above

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

rdt_send(data)

Wait for ACK or NAK 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)

rdt_send(data)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

Wait for call 1 from

above

Wait for ACK or NAK 1

Chapter 3, slide: 4

rdt2.1: receiver, handles garbled ACK/NAKs

Wait for 0 from below

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

Wait for 1 from below

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)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)

rdt_rcv(rcvpkt) && (corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)

Chapter 3, slide: 5

rdt2.1: discussion

Sender: seq # added to pkt two seq. #’s (0,1) will

suffice. Why? New pkt Retransmitted pkt

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

Chapter 3, slide: 6

rdt2.2: a NAK-free protocol

do we really need NAKs??

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

rdt2.2: same functionality as rdt2.1, using ACKs only

Chapter 3, slide: 7

rdt3.0: channels with errors and loss

New assumption: packet may be lost: underlying channel can also lose packets (data or ACKs)

checksum, seq. #, ACKs, retransmissions will be of help, but not enough

What else is needed?

Approach: timeout policy:

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

Chapter 3, slide: 8

rdt3.0 in action (still stop-n-wait w/ (0,1) sn)

Chapter 3, slide: 9

rdt3.0 in action (still stop-n-wait w/ (0,1) sn)

rcv ACK1do nothing

Chapter 3, slide: 10

Performance of rdt3.0: stop-n-wait

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

rdt3.0 works, but performance stinks example: R=1 Gbps, 15 ms e-e prop. delay, L=1000Byte packet:

Ttransmit

= 8.103 b/pkt109 b/sec

= 8 microsecL (packet length in bits)R (transmission rate, bps)

=




sender receiver

RTT





U sender: utilization – fraction of time sender busy sending

U sender

= .008

30.008 = 0.00027

microseconds

L / R

RTT + L / R =




sender receiver

RTT





1kB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link

network protocol limits use of physical resources!


Pipelining: increased utilization


sender receiver

RTT

last bit transmitted, t = L / R



last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

U sender

= .024

30.008 = 0.0008

microseconds

3 * L / R

RTT + L / R =

Increase utilizationby a factor of 3!

Question: What is the link utilization Usender


Pipelined protocolsPipelining: sender allows multiple, “in-flight”, yet-to-be-ACK’ed

pkts what about the range of sequence numbers then?? What about buffering at receiver??

Two generic forms of pipelined protocols: go-Back-N and selective repeat

Go-Back-N: sender

Sender: k-bit seq # in pkt header “window” of up to N, consecutive unACKed pkts allowed


ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs (see receiver)

timeout(n): retransmit pkt n and all higher seq # pkts in window


GBN: receiver extended FSM

ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum

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

Wait

udt_send(sndpkt)

default

rdt_rcv(rcvpkt)

&& notcurrupt(rcvpkt)

&& hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data)

deliver_data(data)

sndpkt = make_pkt(expectedseqnum,ACK,chksum)

udt_send(sndpkt)

expectedseqnum++

expectedseqnum=1

sndpkt =

make_pkt(expectedseqnum,ACK,chksum)


GBN in action


Selective Repeat

receiver individually acknowledges 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 again limits seq #s of sent, unACKed pkts


Selective repeat in action

GBN? GBN?

GBN?


Selective repeat:dilemmaExample: seq #’s: 0, 1, 2, 3 window size=3


Selective repeat:dilemmaExample: seq #’s: 0, 1, 2, 3 window size=3

receiver sees no difference in two scenarios! Even though, (a) is a retransmit pkt (b) is a new pkt

in (a), receiver incorrectly passes old data as new

Is this a pb in GBN? Why?doesn’t buffer out-of-order

Q: what relationship between seq # size and window size to avoid duplication problem??


Chapter 3 outline

1 Transport-layer services

2 Multiplexing and demultiplexing

3 Connectionless transport: UDP

4 Principles of reliable data transfer

5 Connection-oriented transport: TCP

6 Principles of congestion control

7 TCP congestion control


TCP Round Trip Time (RTT) and TimeoutWhy need to estimate RTT? “timeout” and “retransmit”

needed to address pkt loss

need to know when to timeout and retransmit

Ideal world: exact RTT is needed

Real world: RTTs change over time

bcause pkts may take different paths network load changes over

time RTTs can only be estimated

Some intuition What happens if too

short: premature timeout unnecessary

retransmissions

What happens if too long: slow reaction to

segment loss


Technique: Exponential Weighted Moving Average (EWMA)

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

0 < < 1; typical value: = 0.125

SampleRTT: measured time from segment transmission until ACK

receipt current value of RTT Ignore retransmission

EstimatedRTT: estimated based on past & present; smoother than

SampleRTT to be used to set timeout period

TCP Round Trip Time (RTT) and Timeout




0 < < 1; typical value: = 0.125

ExampleSuppose 3 ACKs returned with SampleRTT1, SampleRTT2, and SampleRTT3.

Question: What would be EstimatedRTT after receiving the 3ACKs ? Assume that EstimatedRTT1 = SampleRTT1





0 < < 1; typical value: = 0.125

What happens if is too small (say very close 0): A sudden, real change in network load does not get

reflected in EstimatedRTT fast enough May lead to under- or overestimation of RTT for a long

time

What happens if is too large(say very close 1): Transient fluctuations/changes in network load affects

EstimatedRTT and makes it unstable when it should not Also leads to under- or overestimation of RTT



Example RTT estimation:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

isec

onds

)

SampleRTT Estimated RTT


Setting the timeout timeout = EstimtedRTT, any problem with this???

add a “safety margin” to EstimtedRTT large variation in EstimatedRTT -> larger safety margin

see how much SampleRTT deviates from EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|(typically, = 0.25)

Then set timeout interval:


Documents

Chapter 3, slide: 1 CS 372 – introduction to computer networks* Thursday July 8 Announcements: r Lab 3 is posted and due is Monday July 19. r Midterm is