Simulation Evaluation of Peer Link Management Protocol September 2007 Simulation Evaluation of Peer Link Management Protocol Date: 2007-09-19 Authors: Meiyuan Zhao, Intel Corp.

September 2007 Abstract This submission reports status of ongoing work on evaluating performance of PLM protocol. The preliminary simulation model and experimental results are reported. Feedbacks and collaboration are welcome. Meiyuan Zhao, Intel Corp.

September 2007 PLM Protocol Overview Unique link instance: <myMAC, peerMAC, myLinkID, peerLinkID> Messages binds with the instance identifier Open/Confirm messages to establish a link Confirm sent in response to Open Link established when Each MP send Open and Confirm messages Each MP receive Open and Confirm messages Close messages to tear down a link Holding state for grace period of close Holding timer to control Retry mechanism to manage failures Retry timer and counter Additional confirm timer to prevent deadlock and livelock Fully specified using finite state machine (FSM) Unique link instance identifiers enable simultaneous link instance handling and avoid deadlock situations. Meiyuan Zhao, Intel Corp.

Performance Evaluation Goals September 2007 Performance Evaluation Goals Intensive design consideration is still not fully satisfying Need performance analysis to validate – protocol behaviors match design goals Questions How long does it take to establish a link under normal/abnormal conditions? How long does it take to tear down a link under normal/abnormal conditions? What timeout value and retry counter limit can enable robust protocol execution? Timeout value relationships? (retryTimeout, confirmTimeout, holdingTimeout) Network overhead of establishing/tearing down a peer link? Meiyuan Zhao, Intel Corp.

PLM Finite State Machine in OPNET September 2007 PLM Finite State Machine in OPNET Meiyuan Zhao, Intel Corp.

Timers Retry Timer Confirm Timer Holding Timer September 2007 Set to a default value of 40 ms (for a 11Mbps link) after a open message is sent. The timer is reset every time till the dot11MeshMaxRetries expires. Retrytimeout = return Retrytimeout + (getRandom mod timeout) Confirm Timer Theoretically, it can be governed by the equation Confirmtimeout = (dot11MeshMaxRetries + 1) * Retrytimeout Need simulation results to validate this setting Holding Timer Confirmtimeout = (dot11MeshMaxRetries ) * Retrytimeout Meiyuan Zhao, Intel Corp.

Performance Evaluation Criterion September 2007 Performance Evaluation Criterion System model Two nodes, one link (11Mbps) Default beaconing and retransmission Performance metrics Latency of establish/tear down a link Success rate of establishing a link Scenario A MP1 and MP2 work properly Examine performance with various radio channel condition Default: 10% drop rate Scenario B MP2 respond significantly slower Slow processing delay: exponential distribution with  = 5 ms (default) Meiyuan Zhao, Intel Corp.

Latency for Establishing a Link September 2007 61 % Mean latency Variance Case A with 82 Simulation runs, default timeout values, default Maxretries=3 One retry slows down the link establishment ~ 30 ms Retry 0 – 61% , Retry 1 – 33%, Retry 2 – 6% Meiyuan Zhao, Intel Corp.

September 2007 Success Rate Case A: Two mesh nodes, 82 Simulation runs, Retry Timeout = 40 ms, Confirm Timeout = 160 ms, Holding Timeout = 120 ms, Maxretries=3 The Success rate was 100% for establishing the links. The Retry_Counter value is 3 at the Peer Link Management level apart from the MAC level retransmissions. Success Rate for Scenario B (Abnormal Conditions) has to be analyzed to understand protocol robustness. Meiyuan Zhao, Intel Corp.

Mean Latency for Closing a link September 2007 Mean Latency for Closing a link Two setups with same parameters as in Scenario A: Case 1: Both MPs randomly close the peer link Case 2: One MP closes the peer link Mean Latency for closing a link (X state -> Idle state) The last conclusion suggest an additional experiment to measure how effective the holding timer is: Measure how many close messages sent by the MP while in the holding state If the number > 0, this means holding state can really help to speed up the link tear down procedure.\ Mean Latency Variance Closing a link is ~ 5X slower than establishing a link Bound failure variance Meiyuan Zhao, Intel Corp.

Confirm Timeout Experiment 1: Experiment 2: Conclusions September 2007 Default radio channel noise (10%) Vary ConfirmTimeout value [80,200] ms Evaluate establishment success rate Result: The confirm timer never expires. 7 retransmission is sufficient to ensure Open frame delivery Experiment 2: Vary drop rate [0.1, 0.8] Fix ConfirmTimeout value: 120 ms Result: The confirm timer never expires. MAC retransmission reports error and drops the link before confirm timer expires Conclusions Value of confirm timeout is not sensitive to network condition Conjecture: ConfirmTimer used for worst case when no Open frame is caused by failure @ peer MP Meiyuan Zhao, Intel Corp.

Next Steps Enhancement and thorough validation of simulation model September 2007 Next Steps Enhancement and thorough validation of simulation model OPNET model Experiment configurations (channel, processing delay, interference, background traffic…) More experiments Experiment 1: Latency and Success Rate in Scenario B Experiment 2: Understand Retry timeout value’s impact on Success rate Experiment 3: Identify the tradeoffs on Max Retries and Success rate Experiment 4: Parameter Negotiation failure handling Experiment 5: Latency and the Overhead of establishing secure link Various topology More than two nodes and heterogeneous nodes Bootstrapping evaluation Link establishment behavior Stability of topology Meiyuan Zhao, Intel Corp.

September 2007 Summary We have started effort on evaluating PLM and AbbrHS using simulation Have some interesting preliminary results Welcome feedbacks and collaboration Meiyuan Zhao, Intel Corp.

September 2007 Questions? Meiyuan Zhao, Intel Corp.