CS 372 – introduction to computer networks* Thursday July 8
description
Transcript of CS 372 – introduction to computer networks* Thursday July 8
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)
=
Chapter 3, slide: 11
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:
U sender: utilization – fraction of time sender busy sending
U sender
= .008
30.008 = 0.00027
microseconds
L / R
RTT + L / R =
Chapter 3, slide: 12
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:
1kB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
network protocol limits use of physical resources!
Chapter 3, slide: 13
Pipelining: increased utilization
first packet bit transmitted, t = 0
sender receiver
RTT
last bit transmitted, t = L / R
first packet bit arriveslast packet bit arrives, send ACK
ACK arrives, send next packet, t = RTT + 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
Chapter 3, slide: 14
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
Chapter 3, slide: 15
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
Chapter 3, slide: 16
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)
Chapter 3, slide: 17
GBN in action
Chapter 3, slide: 18
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
Chapter 3, slide: 20
Selective repeat in action
GBN? GBN?
GBN?
Chapter 3, slide: 21
Selective repeat:dilemmaExample: seq #’s: 0, 1, 2, 3 window size=3
Chapter 3, slide: 22
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, slide: 23
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
Chapter 3, slide: 24
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
Chapter 3, slide: 25
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
Chapter 3, slide: 26
Technique: Exponential Weighted Moving Average (EWMA)
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
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
TCP Round Trip Time (RTT) and Timeout
Chapter 3, slide: 27
Technique: Exponential Weighted Moving Average (EWMA)
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
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
TCP Round Trip Time (RTT) and Timeout
Chapter 3, slide: 28
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
Chapter 3, slide: 29
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:
TCP Round Trip Time (RTT) and Timeout