participants
play

Participants University of Wrzburg Thomas Zinner, Dominik Klein, - PDF document

Institute of Computer Science Chair of Communication Systems Prof. Dr.-Ing. P. Tran-Gia MultiNext: Measuring Concurrent Multipath Transmissions in an Experimental Facility T. Zinner (Uni Wrzburg), K. Tutschku (Uni Vienna), T. Zseby


  1. Institute of Computer Science Chair of Communication Systems Prof. Dr.-Ing. P. Tran-Gia MultiNext: Measuring Concurrent Multipath Transmissions in an Experimental Facility T. Zinner (Uni Würzburg), K. Tutschku (Uni Vienna), T. Zseby (Fraunhofer) 7 th EURO-NF CONFERENCE ON NEXT GENERATION INTERNET NGI 2011 Participants � University of Würzburg Thomas Zinner, Dominik Klein, Christian Schwartz, Daniel Schlosser, Phuoc Tran-Gia � University of Vienna Kurt Tutschku, Albert Rafetseder � Fraunhofer Fokus Tanja Zseby, Carsten Schmoll, Christian Henke (TU Berlin) � Tel Aviv University Yuval Shavitt � http://www3.informatik.uni-wuerzburg.de/research/projects/multinext/ Thomas Zinner 2

  2. Agenda � Aims of the project MultiNext � Architecture and transport mechanisms � Federation concept � Concurrent multipath transmission � Measurements and results � Comparision of different testbeds � Active and passive measurements � Lessons learned and conclusion Thomas Zinner 3 Aims of the MULTINEXT Project � Gain experience in the usability of federated testbeds � Possibility to setup a (larger scale) routing overlay to emulate multipath transport � Large distributed set of nodes to get a high QoS diversity � Federated measurements with the most appropriate measurement equipment � Advanced measurement methods for high precision and hop-by-hop one-way delay measurements � Validate a performance model for multipath transport in a Federated Future Internet Thomas Zinner 4

  3. ARCHITECTURE AND TRANSPORT MECHANISM Thomas Zinner 5 Enhanced Federation Concept (Tutschku, 2009, Geni) Application-specific Compute Slice Cluster #1 ISP 3 Backbone #1 Backbone #1 ISP 4 Compute ISP 1 Cluster #2 Application ISP 5 ISP 2 Backbone #2 Backbone #2 ISP 6 Compute ISP 7 Cluster #3 Application which coordinates the slice Quality islands, e.g. obtained by DiffServ or Overprovisioning � Federation: Selection of co-operative resources (networks, links, nodes) for the life time of application-specific virtual network (aka !slice") � Medium variability of slice (not flow-by-flow not static, not VPN-like) � Account for limited life-time and variable performance of resources � Challenge: optimal resource selection needs to measure temporal behavior of e.g. churn of resource networks or variability of E2E delay Thomas Zinner 6

  4. Concurrent Multipath Transmission � Concurrent Multipath Transmission: � Resource pooling: $ Parallel usage of resources $ Forming a virtualized single !transport resource" � Aiming for: � Improved resilience � High capacity (e.g. for video streaming) � New business models e.g. $ Combine multiple operators $ Dynamic resource selection Thomas Zinner 7 Concurrent Multi-Path Transfer Logical topology Aim: Very high and reliable transmission between two end hosts Solution: Transport Virtualization: Combine multiple paths (even from different providers) Aim: Very high and reliable throughput between two end hosts Routing topology of provider II pooled transport pipe Routing topologies of provider I POP Superset of available physical resources Thomas Zinner 8

  5. Performance Parameters � Input: � Number of paths � Path delay distributions � Scheduling � Path capacity delay distribution buffer Source Destination occupancy delay distribution � Output: Steady-state re-sequencing buffer occupancy distribution Thomas Zinner 9 Assumptions � Each time unit, a packet is transmitted over each path � Constraint: packets do not overtake each other on a single path, i.e. current delay � previous delay $ interdeparture time � But: packets overtake each other on other paths: time % 1 3 5 path 1 destination path 2 % 2 4 6 2 4 4 4 6 packets in 2 2 3 5 re-sequencing buffer 1 Thomas Zinner 10

  6. MEASUREMENTS AND RESULTS Thomas Zinner 11 Experimental Facilities � Investigation of different testbeds � Find most suitable testbed w.r.t. experimental requirements Feature G-Lab PLE PLC VINI Scope Germany Europe World Mainly US Exclusive Yes No No No Reservation Routing with own tools with own tools with own tools Yes Bandwidth and with own tools Planned Planned Yes (service) QoS Openess/ No (tests Yes (SFA) Yes (SFA) Yes (SFA) Federation planned) Tools/Packet individually Yes (service) individually individually Tracking Clock Sync NTP NTP, some GPS NTP NTP Thomas Zinner 12

  7. Measurement Setup � Active measurements � ETOMIC boxes at end points � Application layer overlay enables routing � Passive measurements � Measurements with multi-hop packet tracking � VINI overlay routing Thomas Zinner 13 Multi-hop Packet Tracking Thomas Zinner 14

  8. Active Measurements – Results � Varying one way delays on the paths � Higher delays via Tromso � Good fit between model and measurements Thomas Zinner 15 Passive Measurements – Results � Variable path delay via VINI (due to an additional queue) � Constant delay via GLAB path � Good fit between model and measurements Thomas Zinner 16

  9. SUMMARY Thomas Zinner 17 Lessons Learned – Experiments � Booking of resources o.k. � Easy booking of PLE, PLC and VINI nodes via PlanetLab SFA � G-Lab manually connected via overlay � Routing needs more support � PlanetLab restrictions: Overlay of end systems, only one interface configurable � VINI provides preconfigured topology � Observation tools as a joint effort � Tools needed for precise measurements (active / passive) � Agreements on tools essential for comparability and share- ability of results, standardization � Clock sync support across testbeds Thomas Zinner 18

  10. Lessons Learned – Testbeds � G-Lab is exclusive resource � PRO: exclusive, better controllable, arbitrary software � CON: closed, small number of nodes, scope Germany � PLE offers many additional functions � PRO: many research tools, high precision measurement infrastructure (passive & active) � CON: routing support � VINI is best for routing � PRO: Routing support, easy booking via SFA � CON: few nodes, not all nodes on public Internet � VINI is too good (low delays, low jitter) � high precision tools required � delay variation achieved by additional queue Thomas Zinner 19 Conclusion � Aims of MultiNext Project � Gain experience in the usability of federated testbeds � High precision and hop-by-hop one-way delay measurements � Validation of a performance model for multipath transport in a Federated Future Internet � Discussion of testbeds and experimental setup � Presentation of results for active and passive measurements � Lessons learned � Future Work: � Combination of active and passive measurements � Investigation of more complex scenarios Thomas Zinner 20

  11. Questions? Thank you' Thomas Zinner 21

Recommend


More recommend