Lab

1. Lab • The network simulator ns • Allows us to watch evolution of parameters like cwnd and ssthresh • ns output is in “raw” form; needs processing • awk is often very useful for this

2. Implication of a time-out • When a packet is lost, we stop getting new acks • Left edge stops moving to the right • Dup acks come; suppose no fast retransmit • Transmitter keeps sending till it exhausts the usable window • At this point, the transmitter stalls

3. Implication of a time-out • What is happening to the segments already in the pipe? • They keep progressing to the receiver, and acks keep getting generated • But these are all dup acks • As the transmitter is not putting new packets into the pipe, eventually the pipe empties out

4. Eventually, pipe is empty

5. Implication of a time-out • If RTO timer value is “appropriately” set, then by the time the timer fires, the pipe will have emptied out • This is because RTO is set sufficiently large • Same situation as when we began • Hence the need for Slow Start after time-out

6. Fast Retransmit • However, if we do a Fast Retransmit, then the pipe is notempty when we retransmit • In particular, if the duplicate ack threshold Kis a small fraction of the BDP, the pipe is almost full when the fast retransmit happens • Hence, no need for Slow Start!

7. Fast Retransmit • Further, K dup acks mean that Kpackets have left the network • By “packet conservation”, can send K more packets!

8. Fast recovery • Suppose that cwnd = C (packets) • This means that the source estimates that the pipe can hold C packets presently • Suppose that D dup acksare received • This means that D packets have left the pipe • A dup ack is generated as soon as the out-of-order packet reaches the receiver • So, D packets can be injected into the network

9. Fast recovery • Observation: • In order to send D packets, need to set cwnd = C + D • This is as if cwnd was inflated (by 1) for every dup ack received • So, upon receiving the Kth dup ack • ssthresh = (1/2)*cwnd (Usual step in CA) • Retransmit the lost packet

10. Fast Recovery • After Fast Retransmit, set cwnd = ssthresh + K • Keep increasing cwnd by 1 for every duplicate ack received • This is the idea ofFast Recovery • Keep transmitting packets whenever allowed by the value ofcwnd

11. Fast Recovery • When the (fast) retransmitted packet is acknowledged, set cwnd = ssthresh again (cwnd deflated) • Ready to begin next cycle • Note that we are not beginning in Slow Start • Beginning in Congestion Avoidance instead • Initial “slowness” of Slow Start avoided • Overall speed of data transfer improved

12. Fast Retransmit & Fast Recovery • Reasons for improved performance • Early detection of congestion (triple duplicate acks) and early retransmission • If retransmitted packet was successfully received, next cycle begins in Congestion Avoidance and not Slow Start • However, if retransmission is not successful, then next cycle begins in Slow Start again (no choice)

13. Fast Retransmit & Fast Recovery Hopefully, retransmission succeeded Triple duplicate ack cwnd= ssthresh SS cwnd=1 Loss detection (triple duplicate ack) Retransmission failed & timeout Beginning the next cycle in congestion avoidance ssthresh=(1/2)*cwnd SS Fast retransmit cwnd=ssthresh + 3 cwnd inflated for every duplicate ack; keep transmitting if possible Fast recovery

14. Retransmissions Measurements for obtaining RTT RTO calculations (parameters)

15. RTT measurements • Not all transmitted segments are timed • One connection is associated with one timer • If the timer is already in use when a segment S is transmitted, the segment S is not timed cwnd = 1 ack Segment not timed cwnd = 2 ack

16. RTT measurements • RTT: time between sending a byte with a particular sequence number and getting an ack covering that sequence number • Timing: counting ticks that occur every 500 ms • Only segments containing data are timed • A segment with only an Ack will not be timed

17. RTT measurements • If 1 tick between transmission of data and reception of ack, then RTT is taken to be 500 ms • If 2 ticks, then RTT taken to be 1000 ms • What should we do if a packet is retransmitted?

18. RTT Measurements • A packet is transmitted, a timeout occurs, the packet is retransmitted • Now an ack is received • Ack corresponding to the 1st transmission or the 2nd? • Retransmission ambiguity problem

19. RTT Measurements • Difficulty: Not sure if the 1st transmission was lost • Perhaps the RTO was too small and the retransmission happened too soon

20. Karn’s algorithm • Upon loss detected by time-out, back off the RTO timer • Exponential backoff: double the RTO interval upon a time-out • Continues till an upper limit is reached • Allowing time for congestion to clear out

21. Karn’s algorithm • Ack for a retransmitted packet arrives • No updates of the RTT estimates • No change in RTO values being used currently • Update estimates when ack received for a segment that was not retransmitted

22. RTT estimates and RTO • How long should the time-out interval (RTO) be? • Adaptive • Should depend on the round-trip time (RTT) experienced on a connection • Therefore, need to keep measuring RTTs

23. RTT estimates and RTO • Denote the measured RTT value by M • [RFC 793] R: “running” estimate of avg RTT • R <--- a R + (1-a)M • Smoothed estimator • a = 0.9(recommended) • Round-trip timeout • RTO = bR • b = 2(recommended) • Experience showed that this setting of RTO did not work well (Jacobson)

24. RTT estimates and RTO • Variability in RTT is not adequately captured • Leads to unnecessary retransmissions • Keep track of the variability in RTT • Calculate RTO based on both mean and mean deviation of RTT • A: running estimate of avg RTT • Err = (M - A) • “Error” between measured value and estimate

25. RTT estimates and RTO • Algorithm • Update A:A <-- (1 - g) A + g M • g = 0.125 • D: running estimate of deviation • Update D:D <-- (1 - h) D + h | Err | • h = 0.25 • RTO = A + 4D