Filipe Abrantes and Manuel Ricardo {fla,mricardo}@inescporto.pt

1. 2007 OCT 22 A Simulation Study of XCP-b Performance in Wireless Multi-Hop Networks Filipe Abrantes and Manuel Ricardo {fla,mricardo}@inescporto.pt

2. Overview • Overview • TCP limitations & XCP background • XCP-b • Performance in Wireless Multi-hop Networks • Conclusions • Future work Local/Evento

3. TCP limitations • Unstable throughput • Increased queuing delay • Limited fairness • Inefficient in high bandwidth delay product networks Local/Evento

4. XCP background • eXplicit Control Protocol • Routers tell sources how to adjust sending rate • New layer (L3.5) → host-to-network Local/Evento

5. XCP algorithm • Efficiency controller (MIMD) → fast adaptation • calculates the aggregated feedback every control interval • BW-allocation controller (AIMD) → fairness • on each packet departure • If (feedback_left > 0) • Delta_Throughput = F/n_flows * pkt_size/flow_throughput • // Additive Increase • else • Delta_Throughput = F * pkt_size/input_bw • // Multiplicative Decrease (bit/s) Local/Evento

6. No per-flow state needed • Efficient way of measuring the number of flows without keeping connection state!! Inter-packet interval (normalized to the ctrl_itvl) 1/3 1/3 1/3 Flow1 1/2 1/2 Flow2 1/4 1/4 1/4 1/4 Flow3 0 (sec) ctl_itvl (sec) Number of active flows Local/Evento

7. Assuming an error in the capacity estimate • XCP compensates capacity error with queue build-up • Queue proportional to avg RTT and estimation error • e=0.5Mbit/s, d=100ms -> q=11Kbyte Local/Evento

8. Why XCP-b • Capacity is hard to measure in shared access media → depends on: • Number of active stations • Collisions • Handshake mechanism • Rates used • MAC idle time • May differ from technology to technology Local/Evento

9. XCP-Blind • Measure spare bandwidth from queue oscillations • Fixed amount of feedback when queue cannot be measured • Minimize oscillations, by stabilizing queue at positive value and performing late reaction Local/Evento

10. XCP-blind Parameters • χ – set so that queue never exceeds (Qmax) (d=rtt) • n – set to match half of the period of the queue response frequency to errors • κ – not a general rule, but simulations say that it can be set as low as 3 for reasonable values of bandwidth, nodes... recent developments show that queue variance may be used to set κ Local/Evento

11. Validation in WMN • Studied and validated in single-hop scenarios • Access point scenario • We extend this validation to Wireless Multi-hop Networks • Differences • More complex – multiple bottleneck • Does it still work? • 802.11 problems are more severe in MH scenarios • Hidden node, medium capture may cause extreme unfairness • Can XCP-b minimize them? Local/Evento

12. Performance • Results • XCP-b vs TCP • lower queing delay • fairness increases • stable throughput • Multi-hop vs. SingleHop • Queue variance increases – more jitter... • Losses or no-losses • Reacting to losses seems as the wise decision • XCP-b parameter sensitivty • Lower χ usually better for smoother results • K should not be too high • n does not impact much, but shouldn’t be too high Local/Evento

13. Chain Topology • Throughput • Queuing delay Local/Evento

14. Mesh Access Network – Dynamics (Seq.No.) • XCP-b BDP variance • TCP NewReno Local/Evento

15. Mesh Access Network – Delay & Fairness • Queuing Delay • Fairness Index Local/Evento

16. XCP-b parameter sensitivity • too high -> longer periods under-utilized • too high -> inc. only delay • too high -> just MAC drops increases Local/Evento

17. Conclusions • XCP-b maintains most of it’s properties in WMN • Pros • Reduces latency • Stable throughput • Increases Fairness • Can minimize 802.11 problems to some extent • Efficiency in high BPD networks (good for next-gen 802.11) • Cons: • Complexity • Comparing to the standard XCP • Extra delay - stabilizing queue above zero • Adaption proportional to Qmax/BDP • Queue peaks may occur / oscillation • Differences to single-hop • Higher variance (in queue, delay, throughput, ...) • XCP reacting to losses achieved better results • Only collision and queue drops were simulated (no transmission error losses) Local/Evento

18. Future work • Compare with L2-aware approach • MAC idle-time • Collisions • Data rates • Try to apply to other forms of explicit congestion control (RCP, ...) Local/Evento

19. Thank you Questions? Local/Evento

20. No per-flow state needed (avoiding the division) • Efficient way of measuring the number of flows without keeping connection state!!... And avoiding per-packet divisions!! Inter-packetinterval 0.3 0.3 0.3 0.5 0.5 0.25 0.25 0.25 0.25 1 (sec) 0 (sec) Local/Evento

21. Local/Evento

22. The new age of congestion control • Implicit Feedback • Vegas (‘94) – the old rtt vs. loss dilemma • TFRC (‘98/’03) – stable throughput • SCTP(‘00) – session cong. control • FAST(’03) – vegas part II (faster version) • BIC(’04) – stable and efficient • Explicit feedback • ECN(’01) – loss differentiation • XCP(’02) – shares bandwidth • TCP-QS(’02) – approves requests from hosts • EWA(’02) – shares buffer size Local/Evento

23. XCP system model • The XCP system model • Proven stability for any bandwidth, delay and number of stations Local/Evento

24. Bandwidth estimation error • XCP model in the presence of estimation error Local/Evento

25. XCP-b vs XCP • Basic Dynamics Local/Evento

26. XCP-b vs XCP • Dynamic bandwidth Local/Evento

27. XCP-b • Different data rates simultaneously Local/Evento

28. XCP-b vs. TCP • Queuing delay • Fairness • Utilization • Utilization with mice Local/Evento

29. Architectural Issues • Processing at input-queues in half-duplex media • Layer 2 equipment needs to “look at” an header between IP and transport layer Local/Evento