More Related Content
What's hot
What's hot (20)
Similar to Exp3mq
Similar to Exp3mq (20)
More from ARCFIRE ICT
More from ARCFIRE ICT (20)
Recently uploaded
Recently uploaded (20)
Exp3mq
- 1. Large scale RINA Experimentation on FIRE + ARCFIRE Final Review Experiment 3 September 2018
- 2. Goals • Explore how the QoS model proposed by the RINA architecture works in practice • Experiment with the QTAmux scheduling policies based on the deltaQ theory to differentially allocate loss and delay to multiple QoS classes • Demonstrate applicability of RINA as an effective solution for transporting IP traffic in provider-based IP VPN scenarios Large-scale RINA Experimentation on FIRE+ 2
- 3. RINA QoS model • Application requirements are explicit and communicated to the DIF via the IPC API at flow allocation time • DIF maps QoS request into a QoS cube, and marks EFCP traffic accordingly (qos-id) • Forwarding, scheduling, resource allocation & congestion mgmt policies applied consistently • An N-DIF requests a flow to an N-1 DIF exactly the same way (consistent QoS model from app to the wire) Large-scale RINA Experimentation on FIRE+ 3 queues sched. IPC Process queues sched. IPC Process queues sched. IPC Process flow flow N-1 DIF N-1 DIF N DIF flow Port-idPort-id App A App B Port-idPort-id
- 4. Capturing bounds on performance metrics • How to express requirements for bounds in performance metrics (loss, delay) and provide them as parameters of a flow request? Large-scale RINA Experimentation on FIRE+ 4 • Application QoE can be linked to a CDF that links required delay and packet loss – E.g. 50% of the SDUs in the flow should experience < 10 ms delay – 95 % of the SDUs in the flow should experience < 50 ms delay – 5% of the SDUs can be lost • Requirements on the CDF can be modelled with a series of <“percentage”, “max delay”> pairs
- 5. Methodology • DIFs in experiment 3 use QTAMux scheduling policies, which allow for the differentiation of delay and loss between multiple classes of traffic. • All scenarios in experiment 3 use a 2x2 QTAMux matrix, which supports 4 QoS cubes: – High urgency, high cherish (low latency, low loss) – High urgency, low cherish (low latency, higher loss) – Low urgency, high cherish (higher latency, low loss) – Low urgency, low cherish (best effort) Large-scale RINA Experimentation on FIRE+ 5 • Each experiment run (IP over RINA scenarios) features 3 steps: – Verification of connectivity and performance through the DIF (rina-echo, rinaperf) – Setup of Layer 3 VPN using the iporinad application – Verification of Layer 3 connectivity and performance (ping, iperf)
- 6. EXPERIMENTS SETUP & RESULTS Large-scale RINA Experimentation on FIRE+ 6
- 7. Scenario 1: Low-scale, single DIF, virtual Wall Large-scale RINA Experimentation on FIRE+ 7 CR CR CR PE PE PE PE PE PEPE PE PEPE CE PE CR CE CE CE CE CE Green customer CPE (IP) Blue customer CPE (IP) Purple customer CPE (IP) Orange customer CPE (IP) Red customer CPE (IP) Pink customer CPE (IP) CE CE CE CE CE CE CE CE CE CE Provider network (RINA-based) CE CE CE CE CE CE CE CE PE CRCR PEPE CECE Ethernet Ethernet EthernetEthernet Ethernet Backbone DIF IP (Green customer IP VPN)
- 8. Scenario1.a: RINA-based core DIF • Each PE allocates 4 rinaperf flows to another PE, each one with different loss/delay characteristics • Rinaperf generates traffic at constant rate • Generate traffic at different rates for different executions, to create different levels of offered load per QoS. Measure loss/delay per QoS using echo application. • Repeat with FIFO-based scheduling policy, compare. Large-scale RINA Experimentation on FIRE+ 8 CR CR CR PE PE PE PE PE PEPE PE PEPEPE CR PE 0 5 10 15 0.00.40.8 CDF of delay, flows@p2a, period=50us Delay(ms) Probability QoS1 QoS2 QoS3 QoS4 0 5 10 15 0.00.40.8 CDF of delay, flows@p2a no QoS, period=50us Delay(ms) Probability QoS1 QoS2 QoS3 QoS4 0 5 10 15 0.00.40.8 CDF of delay, flows@p2a, period=75us Delay(ms) Probability QoS1 QoS2 QoS3 QoS4 0 5 10 15 0.00.40.8 CDF of delay, flows@p2a no QoS, period=75us Delay(ms) Probability QoS1 QoS2 QoS3 QoS4 0 5 10 15 0.00.40.8 CDF of delay, flows@p2a, period=100us Delay(ms) Probability QoS1 QoS2 QoS3 QoS4 0 5 10 15 0.00.40.8 CDF of delay, flows@p2a no QoS, period=100us Delay(ms) Probability QoS1 QoS2 QoS3 QoS4 • Demo (part 1) • Demo (part 2)
- 9. Scenario1.b: IP VPN over a single DIF • IP VPN over the RINA core, each PE runs an iporinad instance. • Each CE starts iperf session with another router on a remote site of same VPN (first with TCP, next with UDP) • Ping also between the same pair of CEs while iperf is active Large-scale RINA Experimentation on FIRE+ 9
- 10. Scenario 1.b results (TCP) • Problem: buffers introduced by iporinad (TUN interface queues) and its scheduling are completely QoS unaware • Effects with TCP: while orange/green VPNs get a low latency (as expected), the penalty on the other ones is too high – High loss introduced by the iporinad subsystems causes TCP to be in congestion mode, increasing delay and decreasing goodput of affected iperf flows Large-scale RINA Experimentation on FIRE+ 10 0 200 400 600 800 1000 0.00.20.40.60.81.0 CDF of delay, site 1 Delay(ms) Probability s1c1 s1c2 s1c3 s1c4 s1c5 s1c6 0 500 1500 2500 0.00.20.40.60.81.0 CDF of delay, site 2 Delay(ms) Probability s2c1 s2c2 s2c3 s2c4 s2c5 s2c6 0 500 1500 2500 0.00.20.40.60.81.0 CDF of delay, site 3 Delay(ms) Probability s3c1 s3c2 s3c3 s3c4 s3c5 s3c6 0 500 1500 2500 0.00.20.40.60.81.0 CDF of delay, site 4 Delay(ms) Probability s4c1 s4c2 s4c3 s4c4 s4c5 s4c6
- 11. Scenario 1.b results (UDP) • Since UDP traffic is not flow controlled, iperf sends data at a constant bit rate, in spite of high packet loss in the TUN interface queues (30%) • When packets enter the RINA flows, the load level is low enough that there is almost no difference between QoS classes Large-scale RINA Experimentation on FIRE+ 11 1 2 3 4 5 6 0.00.20.40.60.81.0 CDF of delay, site 1 Delay(ms) Probability s1c1 s1c2 s1c3 s1c4 s1c5 s1c6 1 2 3 4 5 6 0.00.20.40.60.81.0 CDF of delay, site 2 Delay(ms) Probability s2c1 s2c2 s2c3 s2c4 s2c5 s2c6 1 2 3 4 5 6 0.00.20.40.60.81.0 CDF of delay, site 3 Delay(ms) Probability s3c1 s3c2 s3c3 s3c4 s3c5 s3c6 1 2 3 4 5 6 0.00.20.40.60.81.0 CDF of delay, site 4 Delay(ms) Probability s4c1 s4c2 s4c3 s4c4 s4c5 s4c6
- 12. Scenario 1.b results (rinaperf + ping) • Mix approach of scenario 1.a (rinaperf to generate traffic in the DIF between PEs), but measure delay between CEs using ping – QoS differentiation can be observed again • Conclusion: iporinad is a good tool to validate IP over RINA scenarios, but cannot guarantee quality under load – Needs to be improved Large-scale RINA Experimentation on FIRE+ 12 1 2 3 4 5 6 7 8 0.00.20.40.60.81.0 CDF of delay, site 1 Delay(ms) Probability s1c1 s1c2 s1c3 s1c4 s1c5 s1c6 1 2 3 4 5 6 7 8 0.00.20.40.60.81.0 CDF of delay, site 2 Delay(ms) Probability s2c1 s2c2 s2c3 s2c4 s2c5 s2c6 1 2 3 4 5 6 7 8 0.00.20.40.60.81.0 CDF of delay, site 3 Delay(ms) Probability s3c1 s3c2 s3c3 s3c4 s3c5 s3c6 1 2 3 4 5 6 7 8 0.00.20.40.60.81.0 CDF of delay, site 4 Delay(ms) Probability s4c1 s4c2 s4c3 s4c4 s4c5 s4c6
- 13. Scenario 2: multiple DIFs, RINA only Large-scale RINA Experimentation on FIRE+ 13 • Service provider scenario – 41 nodes – Two MAN networks – 1 core network – 3 levels of DIFs – 18 CPEs Access Router PtP DIF CPE Edge Service Router Metro Edge Router Metro Edge Router Metro BB DIF Metro service DIF PtP DIF PtP DIF PtP DIF PtP DIF Metro P router PTP DIF Residential customer service DIF Host PtP DIF Public Internet or App-specific or VPN DIF Backbon e Router Backbon e router PtP DIF PtP DIF Backbone DIF Provider Edge Router Provider Edge Router PtP DIF Customer network Service Prov. 2Service Prov. 1 network Access Aggregation Service Edge Core Internet Edge Public Internet or App-specific or VPN DIF Home DIF Customer Premises Equipment Access Router MAN Access Router MAN Core Router Edge Services Router Backbone router • Each CPE (per QoS level): – Rina-et flow with all other CPEs – Four 1 Mbps rinaperf flows • In total 1296 flows • Physical links running at 90%
- 14. Scenario 2 results • Clear differentiation between flows with high urgency and flows with low urgency • But latency is too high: probably due to the implementation of multiple queues in stacked DIFs within the IRATI prototype Large-scale RINA Experimentation on FIRE+ 14 0 500 1000 1500 0.00.20.40.60.81.0 CDF of delay, rina−et instances at system CPE63 Delay(ms) Probability ●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●● ● cpe11−hu cpe12−hu cpe13−hu cpe21−hu cpe22−hu cpe23−hu cpe31−hu cpe32−hu cpe33−hu cpe11−lu cpe12−lu cpe13−lu cpe21−lu cpe22−lu cpe23−lu cpe31−lu cpe32−lu cpe33−lu 0 500 1000 1500 0.00.20.40.60.81.0 CDF of delay, rina−et instances at system CPE41 Delay(ms) Probability ●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●● ● cpe11−hu cpe12−hu cpe13−hu cpe21−hu cpe22−hu cpe23−hu cpe31−hu cpe32−hu cpe33−hu cpe11−lu cpe12−lu cpe13−lu cpe21−lu cpe22−lu cpe23−lu cpe31−lu cpe32−lu cpe33−lu
- 15. Scenario 3: Large-scale, IP VPNs on CPEs, QEMU testbed • Scaled up version of scenario 2, but with CPEs supporting IP VPNs • Runs in QEMU testbed (not enough machines available on Virtual Wall or other FED4FIRE+ testbeds) • 144 systems: 96 running RINA and 48 IP only. Large-scale RINA Experimentation on FIRE+ 15 CPE Router MAN Access Router Access Router MAN backbone Router Edge Service Router Backbone router Host, Green VPN Host, Blue VPN Host, Purple VPN Host, Orange VPN Host, Red VPN Host, Pink VPN Host, Brown VPN Host, Black VPN Host, Yellow VPN Host, Cyan VPN Host, Grey VPN Host, Magenta VPN
- 16. Scenario 3 results • Too many nodes to get QoS differentiation results within a single physical machine. • Just focus on – checking that the scenario can be setup using IRATI – There is connectivity between the hosts in the same VPN (via ping) • Demo part 1 • Demo part 2 Large-scale RINA Experimentation on FIRE+ 16 0 10 20 30 40 05101520 Ping times between host nodes Ping sessions between nodes Delay(ms) min avg max
- 17. CONCLUSIONS Large-scale RINA Experimentation on FIRE+ 17
- 18. Implications • Consistent QoS model from app to wire: applications (if they wish to do so) can provide quality requirements to the network in a technology-independent way • No need to do DPI to identify classes of traffic and “infer” quality requirements • EFCP traffic marking enables resource allocation policies (routing, scheduling, congestion control) to act consistently across a DIF. • Layers (DIFs) provide QoS requirements to lower layers the same way, no need to standardise QoS cube identifiers across DIFs (but yes the semantics of quality parameters) • RINA can take the role of MPLS (and similar technologies) to address use cases such as provider-based IP / or Ethernet VPNs or networks slices, but with more flexibility to provide QoS, enhanced security and scalability • Not just virtual circuits, but any combination of routing, scheduling, forwarding and congestion control policies that works for the use case Large-scale RINA Experimentation on FIRE+ 18