Budapest icc 2013_presentation

376 views

Published on

Jose Saldana, Luigi Iannone, Diego R. Lopez, Julian Fernandez-Navajas, Jose Ruiz-Mas, "Enhancing Throughput Efficiency via Multiplexing and Header Compression over LISP Tunnels" . In Proc. Second IEEE Workshop on Telecommunication Standards: From Research to Standards, Collocated with IEEE ICC 2013, Budapest, Hungary. ISBN 9781467357524

This article explores the possibility of using traffic optimization techniques within the context of the LISP (Locator/ Identifier Separation Protocol) framework. These techniques use Tunneling, Multiplexing and header Compression of Traffic Flows (TCMTF) in order to save bandwidth and to reduce the amount of packets per time unit. Taking into account that encapsulation is necessary in LISP, bandwidth can be drastically reduced in flows using small packets, which are typical of many real-time services. The ability of the LISP framework to manage the signaling of TCMTF options is also studied. An analytical expression of the savings, as a function of the different header sizes, is devised and used to calculate the maximum expected savings. Different services and scenarios of interest are identified, and this allows the consideration of tests with real traffic traces, showing the savings as a function of the multiplexing period, and demonstrating that the additional delays can be acceptable for real-time services.

Published in: Technology, Travel
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
376
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Budapest icc 2013_presentation

  1. 1. Enhancing Throughput Efficiencyvia Multiplexing and HeaderCompression over LISP TunnelsSecond IEEE Workshop on Telecommunication Standards: From Research to StandardsIEEE ICC 2013, Budapest, Hungary, 9th of June 2013Jose SaldanaJulián Fernández-NavajasJosé Ruiz-MasLuigi Iannone Diego R. Lopez
  2. 2. Enhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013Index1. Introduction2. Context and Scenarios of Application3. Multiplexing/Compression Signaling4. Expected Bandwidth Savings5. Conclusions and Future Work
  3. 3. Enhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013Index1. Introduction2. Context and Scenarios of Application3. Multiplexing/Compression Signaling4. Expected Bandwidth Savings5. Conclusions and Future Work
  4. 4. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Emerging real-time services High interactivity requirements Delay is important, so frequent informationupdates are needed
  5. 5. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Emerging real-time services High rates (10 to 50 pps) Small packets (some tens of bytes) Low efficiencyPacket size and inter-packet time for Counter Strike 140 50 60 70 80 90 100 110bytes0 10 20 30 40 50 60 70ms
  6. 6. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 TCMTF (Tunneling Compressed MultiplexedTraffic Flows) is a proposal for improving theefficiency of these flows by: Header compression Multiplexing Tunneling Status: IETF draftIP IP IPNo compr. / ROHC / IPHC / ECRTPPPPMux / OtherGRE / L2TP / OtherIPCompression layerMultiplexing layerTunneling layerReal-time trafficNetwork ProtocolUDPRTPpayloadUDPTCPpayloadpayload
  7. 7. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 TCMTF optimization exampleOne IPv4/TCP packet 1500 bytesη=1460/1500=97%One IPv4/UDP/RTP VoIP packet with two samples of 10 bytesη=20/60=33%Five IPv4/UDP/RTP VoIP packets with two samples of 10 bytesη=100/300=33%savingOne IPv4 TCMTF Packet multiplexing five two sample packetsη=100/161=62%
  8. 8. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 2006: The IAB (Internet Architecture Board)felt the need for new architectures able toovercome the scalability of the routing system LISP: Locator/ID Separation Protocol, is anarchitecture designed to this aim Getting a growing interest from the Industry
  9. 9. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 LISP distinguishes two address spaces: Routing Locator (RLOC): border routers Endpoint Identifiers (EID): hosts inside stubnetworksInternetRLOC Address SpaceStub 1Stub 2Border routersEID 1EID 2EID 3EID AddressSpaceStub 3EID 1EID 2EID 2EID 1EID AddressSpaceEID AddressSpaceRLOC RLOCRLOC
  10. 10. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 A stub network only routes packets to andfrom itselfInternetStub 1Stub 2Border routersEID 1EID 2EID 3Stub 3EID 1EID 2EID 2EID 1
  11. 11. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 A stub network only routes packets to andfrom itself Border routers do a “map and encap” processwhen sending a packet to other stub networkInternetStub 1Stub 2Border routersEID 1EID 2EID 3Stub 3EID 1EID 2EID 2EID 1
  12. 12. IntroductionEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 A tunnel is necessary between stub networksOne IPv4/TCP packet 1500 bytesOne IPv4/UDP/RTP VoIP packet with two samples of 10 bytesIP RLOC20 bytesUDP8 bytesLISP8 bytesIP stub+UDP+RTP40 bytesVoIP: 76 header bytesfor 20 bytes payloadIn a MTU-sized packet the extraoverhead is not significant
  13. 13. Enhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013Index1. Introduction2. Context and Scenarios of Application3. Multiplexing/Compression Signaling4. Expected Bandwidth Savings5. Conclusions and Future Work
  14. 14. Scenarios of applicationEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Services generating high rates of small packets: VoIPMultiplexing schemes exist (RFC4170) First Person Shooter games MMORPG games ACKs traveling to:Content Delivery NetworksTCP-based video streaming web
  15. 15. Scenarios of applicationEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Can we find simultaneous flows between thesame pair of stub networks?InternetRLOC Address SpaceStub 1Stub 3Stub 2Border routersWeb serveraggregation network ofa network operator
  16. 16. Scenarios of applicationEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Can we find simultaneous flows between thesame pair of stub networks?InternetRLOC Address SpaceStub 1Stub 3Stub 2Border routersCompany headquartersOffice in a country
  17. 17. Scenarios of applicationEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Let’s group packets in the border router, inorder to share the overhead of the tunnelInternetRLOC Address SpaceStub 1Stub 3Stub 2Border routers4 IP/UDP/LISP headers
  18. 18. Scenarios of applicationEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Let’s group packets in the border router, inorder to share the overhead of the tunnelInternetRLOC Address SpaceStub 1Stub 3Stub 2Border routers1 IP/UDP/LISP header
  19. 19. Enhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013Index1. Introduction2. Context and Scenarios of Application3. Multiplexing/Compression Signaling4. Expected Bandwidth Savings5. Conclusions and Future Work
  20. 20. Multiplexing/Compression SignalingEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 We have to negotiate different parameters betweenmux and demux Maximum added delay Header compression scheme LISP signalling for EID-RLOC mappings can be usedfor this aim Able to carry meta-information Which flows can be multiplexed, based on (e.g.), IP addresses ToS application
  21. 21. Multiplexing/Compression SignalingEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Standard format for signalling Start or adapt multiplexing on demand, dependingon network traffic status
  22. 22. Enhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013Index1. Introduction2. Context and Scenarios of Application3. Multiplexing/Compression Signaling4. Expected Bandwidth Savings5. Conclusions and Future Work
  23. 23. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Let’s multiplex packets, avoiding LISP headersThree IPv4/UDP client-to-server packets of Counter StrikeTCMTF multiplexmultiplex savingFour IPv4/UDP/RTP VoIP packets with two samples of 10 bytesmultiplex savingTCMTF multiplexFour IPv4/TCP client-to-server packets of World of Warcraft. E[P]=20bytesTCP ACK without payloadTCMTF multiplexmultiplex savingFive IPv4/TCP ACKsTCMTF multiplexmultiplex saving
  24. 24. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 What if the router also compresses headers?Three IPv4/UDP client-to-server packets of Counter StrikeTCMTF multiplex and compressmultiplex + compress savingFour IPv4/UDP/RTP VoIP packets with two samples of 10 bytesTCMTF multiplex and compressFour IPv4/TCP client-to-server packets of World of Warcraft. E[P]=20bytesmultiplex + compress savingTCP ACK without payloadmultiplex + compress savingmultiplex savingTCMTF multiplexTCMTF multiplexmultiplex savingTCMTF multiplex and compressTCMTF multiplexmultiplex saving
  25. 25. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 What if the router also compresses headers?Three IPv4/UDP client-to-server packets of Counter StrikeTCMTF multiplex and compressmultiplex + compress savingFour IPv4/UDP/RTP VoIP packets with two samples of 10 bytesTCMTF multiplex and compressFour IPv4/TCP client-to-server packets of World of Warcraft. E[P]=20bytesmultiplex + compress savingTCP ACK without payloadmultiplex + compress savingmultiplex savingTCMTF multiplexTCMTF multiplexmultiplex savingTCMTF multiplex and compressTCMTF multiplexmultiplex saving
  26. 26. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Asymptotic savings for each service0%10%20%30%40%50%60%70%80%90%100%VoIP FPS MMORPG ACKsBandwidthSavingBandwidth Saving IPv4 on IPv4IPv6 on IPv4IPv4 on IPv6IPv6 on IPv6No headercompressionUDP/RTPUDPTCP
  27. 27. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 VoIP G.729a0%10%20%30%40%50%60%70%80%0 5 10 15 20 25 30 35 40 45 50BandwidthsavingNumber of VoIP flowsBandwidth saving, VoIP, G729a, 2 samples per packetIPv4 on IPv4 only MuxIPv4 on IPv4 Mux + comprIPv4 on IPv6 Only MuxIPv4 on IPv6 Mux + Compr
  28. 28. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 VoIP G.729a0%10%20%30%40%50%60%70%80%0 5 10 15 20 25 30 35 40 45 50BandwidthsavingNumber of VoIP flowsBandwidth saving, VoIP, G729a, 2 samples per packetIPv4 on IPv4 only MuxIPv4 on IPv4 Mux + comprIPv4 on IPv6 Only MuxIPv4 on IPv6 Mux + ComprNo headercompressionOne packetfrom each flow
  29. 29. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 First Person Shooter game (Counter Strike 1)0%10%20%30%40%50%60%70%80%5 10 15 20 25 30 35 40 45 50BandwidthSavingperiod (ms)Bandwidth Saving. FPS Game. IPv4 on IPv420 players 20 players, no compr15 players 15 players, no compr10 players 10 players, no compr5 players 5 players, no compr
  30. 30. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 First Person Shooter game (Counter Strike 1)0%10%20%30%40%50%60%70%80%5 10 15 20 25 30 35 40 45 50BandwidthSavingperiod (ms)Bandwidth Saving. FPS Game. IPv4 on IPv420 players 20 players, no compr15 players 15 players, no compr10 players 10 players, no compr5 players 5 players, no comprAdditional delayis half the period
  31. 31. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 MMORPG (World of Warcraft)0%10%20%30%40%50%60%70%80%10 20 30 40 50 60 70 80 90 100BandwidthSavingperiod (ms)Bandwidth Saving. MMORPG Game. IPv4 on IPv4100 players 100 pl, no compr50 players 50 pl, no compr20 players 20 pl, no compr10 players 10 pl, no compr
  32. 32. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 MMORPG (World of Warcraft)0%10%20%30%40%50%60%70%80%10 20 30 40 50 60 70 80 90 100BandwidthSavingperiod (ms)Bandwidth Saving. MMORPG Game. IPv4 on IPv4100 players 100 pl, no compr50 players 50 pl, no compr20 players 20 pl, no compr10 players 10 pl, no compr56% of thepackets are ACKs
  33. 33. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 ACKs between stub networks (no compress)0%10%20%30%40%50%60%70%80%5 10 15 20 25 30 35 40 45 50BandwidthSavingperiod (ms)Bandwidth Saving. ACKs. IPv4 on IPv41000ACK/sec500ACK/sec200ACK/sec100ACK/sec
  34. 34. Expected Bandwidth SavingsEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 ACKs between stub networks (no compress)0%10%20%30%40%50%60%70%80%5 10 15 20 25 30 35 40 45 50BandwidthSavingperiod (ms)Bandwidth Saving. ACKs. IPv4 on IPv41000ACK/sec500ACK/sec200ACK/sec100ACK/secAdditional delayhas to be limited
  35. 35. Enhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013Index1. Introduction2. Context and Scenarios of Application3. Multiplexing/Compression Signaling4. Expected Bandwidth Savings5. Conclusions and Future Work
  36. 36. Conclusions and Future WorkEnhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013 Possibility of using TCMTF multiplexing andcompressing in LISP: mutual benefit Ability of LISP signaling for negotiatingTCMTF parameters Throughput can be highly improved by packetgrouping Additional savings by means of compression Depending on the capacity of the router Future: TCMTF-able LISP border routers
  37. 37. Thank you very much!Jose SaldanaJulián Fernández-NavajasJosé Ruiz-MasLuigi Iannone Diego R. Lopez

×