1 #6 in Mid-Term  Most answered:  many users thru the same bottleneck -> increased queueing delay -> increased e2e latency  Possible reasons behind much delay  queueing delay on a bottleneck link  retransmission delay due to packet losses  server located far away; increased prop delay  server located on a slow network; increased tx delay  server overload  How to detect a bottleneck?  traceroute  comparison with other downlaods  assume a role of a network manager: more info available

 Last Class  TCP connection set up  TCP connection tear-down  Sliding window revisited  This Class  Triggering transmission

3 Triggering Transmission  TCP has to decide when to tx

4 TCP Send Buffer TCP Sending Application LastByteAcked LastByteSent LastByteWritten

5 Triggering Transmission  TCP has to decide when to tx  When it has more than MSS  When it is told “PUSH”  When a timer expires * Without worrying about flow control

6 Silly Window Syndrome  When AdvertisedWindow < MSS  if sender transmits aggressively

7 Silly Window SenderReceiver ACK opens win=10 ACK opens win=1000 data=10 data=1000 ACK data=10

8 Silly Window Syndrome  When AdvertisedWindow < MSS  if sender transmits aggressively  How to avoid it?  not to introduce a small segment  receiver waits till MSS space is available before advertizing a window open from zero

9 Then what about Telnet?  What should we do when we have only a few bytes to send?  use a clock-based timer or self-clocking  Nagle’s Algorithm if available data and window >= MSS send a full segment else if unACKed data in flight buffer new data till a new ACK else send all the new data now

10 Adaptive Retransmission  RTT estimation EstRTT = a X EstRTT + (1-a) x SampleRTT TO = 2 x EstRTT  Karn/Patridge Algorithm SampleRTT for those segments sent only once  Jacobson/Karels Algorithm  Take the variance of SampleRTT into consideration Diff = SampleRTT – EstRTT EstRTT = EstRTT + (b x Diff) Dev = Dev + b(|Diff|-Dev) TO = A x EstRTT + B x Dev

11 TCP Header Destination Port NumberSource Port Number Sequence Number Urgent Pointer Acknowledgement Number Header Length ReservedWindow Size TCP Checksum URGURG ACKACK PSHPSH RSTRST SYNSYN FINFIN

12 TCP Extension  TCP 32-bit Sequence Number  Add a 32-bit timestamp  TCP 16-bit Window Size  Add a scaling factor  Timestamp  course timer granularity = 500ms  Add a system clock to the data pkt

13 Keeping the pipe full  Time until 32-bit number space wraps around  1.5 Mbps – 6.4 hr  100 Mbps – 13 min  1.2 Gbps – 28 sec  Window size for 100 ms RTT  1.5 Mbps – 18 KB  100 Mbps – 1.2 MB  1.2 Gbps – 14.8 MB

14 Alternative Design Choices  TCP is not a panacea for all applications  Consider  Explicit connection setup/tear-down  Byte-stream vs message-stream  window-based vs rate-based

15 Congestion Control  End-to-end approach in detecting congestion  No ack for some time  Duplicate acks  Network-assisted approach  Routers provide explicit feedback  IBM SNA, DEC DECnet, ATM ABR, TCP ECN

16 Scheduling vs. Drop Policies  Schduling policy  determines the order in which packets are transmitted  FIFO, Priority Queueing, Fair Queueing  Drop policy  determines which packets to drop  Tail drop (drop-tail), RED

17 FIFO

18 Priority Queueing  Main idea: mark each packet with a priority  Routers implement multiple FIFO queues  Packets in a queue with the highest priority are served first  Problem?  Bad people mark their packets with a high priority  High-priority queue can starve out all other queues

19 Fair Queueing  Main idea: maintain a separate queue per flow to isolate. Round-robin Service

20  Calculate F i =max(F i-1, A i ) + P i and process packets with lowest F i first  F i : expected finish time if done bit-by-bit  A i : arrival time of packet i  P i : # of bit-rounds for packet i Currently served Which packet should finish first, blue or yellow?

21 Time Bit-round Yellow should be served first! FFF

22 FQ and WFQ  FQ  Sources are not aware of FQ  WFQ  It assigns different weights to queues  It can assign queue not per flow, but per class  How do you assign fair weights?  Both are work-conserving  Never idle when there is work to do

23 senderreceiver At what rate to send? How do you figure out the bottleneck bandwidth?

24 Sending rate increases linearly TIME RTT Additive increase

25 What about doubling each time? TIME RTT Cwnd=1Cwnd=2Cwnd=4Cwnd=8 Multiplicative increase

26 When to stop increasing?  Finite world, finite beginning  ssthresh = set to an arbitrary large number (65KB)  Sender rate exceeds RcvWindow  Only transmit min(cwnd, RcvWindow)  Packets start to be dropped at the bottleneck  Sending rate exceeds bottleneck b/w  Another user shares the bottleneck  Contention for shared resource