Congestion Control for CoAP Cloud Services

Transcription

1 ongestion ontrol for oap loud Services August Betzler, arles Gomez, Ilker Demirkol, Matthias Kovatsch Wireless Network Group Universitat Politècnica de atalunya Barcelona, Spain Institute for Pervasive omputing ETH Zürich Zürich, Switzerland SONE

2 oap ommunications GPRS loud SMS SONE

3 Dealing with ongestion Delay Delay GPRS loud Delay SMS ongestion SONE

4 Introduction ooap, as an Internet protocol, needs to apply congestion control, mainly to keep the backbone network stable. Thus, the oap specification defines a conservative default congestion control () mechanism. o To achieve a better quality of service, the IETF is designing an advanced mechanism for oap called ooa. We implement ooa and carry out performance evaluations ooa for communications between the loud and networks of constrained devices. o First results show that ooa is able to better utilize the network capacity and benefits the performance. SONE

5 oap Default ongestion ontrol lient Server RTO timer expires RTO ([2s, 3s]) BEB -> RTO*2 t t SONE

6 Advanced for oap: ooa (1) o Premiss: Use Round-Trip Time (RTT) information of a oap exchange (ON-AK) to calculate an adaptive RTO like TP does (RF 6298) o ooa runs two RTO estimators: o Strong estimator: Uses AKs from packets without retransmission. o Weak estimator: Uses AKs from packets with retransmissions. o Strong estimator provides an update: o RRRRRR oooooooooooooo = 0.5 RRRRRR oooooooooooooo RRRRRR ssssssssssss o Weak estimator provides an update: o RRRRRR oooooooooooooo = 0.25 RRRRRR oooooooooooooo RRRRRR wwwwwwww SONE

7 Advanced for oap: ooa (2) o Blind RTO rule: If NSTART > 1 and no RTO estimation is available RRRRRR iiiiiiii = 2 ss 2 AAAAAA, where AT is # of ongoing exchanges. o Variable Backoff Factor (VBF) o Avoid exchanges with large initial RTOs to take very long o Avoid exchanges with short initial RTOs to retransmit too fast o RTO aging for small but old RTO values (RRRRRR oooooooooooooo < 1 s) RRRRRR oooooooooooooo = RRRRRR oooooooooooooo 16 SONE

8 oap Implementation in ontiki OS: Erbium (Er) oap UDP IPv6 / RPL 6LoWPAN MA PHY IETF communication protocol stack Erbium oap UDP (uipv6) uipv6 / ontiki RPL SISlowpan ontiki SMA + NullRD IEEE PHY ontiki implementation SONE

9 oap Implementation for Java: alifornium (f) Stage 3: Server Root A B A1 A2 B1 B2 Stage 3: lient mai n lient for X lient for Y Async.Handler ooa Stage 2: Protocol (oap) Exchange Store Blockwise Layer Observe Layer Token Layer Reliability Layer Matching & Deduplication Message Serialization Adds RemoteEndpoint Adds optional Layer Layer Remote Endpoint ooa Stage 1 Network onnector (UDP/DTLS/ ) SONE

10 Evaluation Scenarios o Four algorithms for reliable oap communication: o Default oap : [2 s, 3 s], BEB. o Aggressive Default oap : [1 s, 1.5 s], BEB (oap B ). o ooa: Strong + weak RTO estimators, VBF, RTO aging, NSTART=1. o ooa 4 : Stromg + weak RTO estimators, VBF, RTO aging, NSTART=4. o Three use cases are evaluated: o 1-to-1 Baseline scenario o Many-to-many scenario o ross traffic burst scenario SONE

11 Evaluation Setup: Use ase o WSN of constrained devices runs oap servers that offer resources o oap clients in the cloud access the resources offered by the servers WSN BR Testbed with oap Servers oap lients in the loud SONE

12 Experimental Setup: FlockLab o The FlockLab testbed is composed of 30 Tmote Sky motes o 1 RPL border router o 29 oap servers (Erbium oap) o The RPL border router acts as gateway between the WSN and the loud o Two operational modes for the radio: o No RD -> Radio always ON o ontikima -> Radio Duty ycling IEEE radio 10 kb RAM 48 kb ROM MPS430 MU SONE

13 1-to-1 Baseline Scenario o A single oap client on the P exchanges 50 ON-AK pairs with a single oap server in the FlockLab testbed. o This procedure is repeated for all oap servers in the testbed, one after another. o Throughput, average exchange duration and average number of retries are measured. FlockLab FlockLab FlockLab BR BR BR 50 ON-AK pairs 50 ON-AK pairs 50 ON-AK pairs etc... SONE

14 1-to-1 Baseline Scenario Results ontikima No RD SONE

15 Many-to-many Scenario FlockLab BR ontinuous, parallel exchanges of ON-AK pairs for each client-server combination Testbed with oap Servers loud with oap lients SONE

16 Many-to-many Scenario Results (1) ontikima No RD SONE

17 Many-to-many Scenario Results (2) SONE

18 ross Traffic Burst Scenario 4 oap clients exchange continuously ON-AK pairs with 4 oap servers. After a certain time, a burst of traffic is generated in form of 50 ON-AK pairs, exchanged with each of the remaining oap servers. FlockLab BR onstant Traffic ross Burst Traffic Testbed with oap Servers loud with oap lients SONE

19 ross Traffic Burst Scenario Results: oap SONE

20 ross Traffic Burst Scenario Results: ooa SONE

21 onclusions o ooa has been implemented as optional Layer for the f framework. o Experiments that involve communications between the loud and a WSN of constrained devices have been carried out to compare the performance of default oap mechanisms with ooa s mechanisms. o ooa utilizes the network better than default oap: o ooa is able to increase the amount of requests that can be processed in parallel. o The time required to fulfill a task is reduced with ooa. o With ooa, NSTART can be increased safely, even though it does not always deliver an optimal performance. SONE

22 Thank you! Questions? SONE

23 Future Work Traffic: Include non-confirmable messages in the traffic scenarios. Include observe mechanism in the evaluations. Include links with large delays, such as GPRS or satellite links. Evaluation: omparison of other well known RTO algorithms (Linux RTO, Peakhopper, etc.). Other performance metrics, like energy efficiency, should be analyzed as they are important for WSNs. ooa Internet Draft: Feedback from the community is required, more experiments or simulations can help to improve ooa further. SONE