Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks

644 views

Published on

This paper proposes a method for optimizing bandwidth usage in Software Defined Networks (SDNs) based on OpenFlow. Flows of small packets presenting a high overhead, as the ones generated by emerging services, can be identified by the SDN controller, in order to remove header fields that are common to any packet in the flow, only during their way through the SDN. At the same time, several packets can be multiplexed together in the same frame, thus reducing the number of sent frames. Four kinds of small-packet traffic flows are considered (VoIP, UDP and TCP-based online games, and ACKs from TCP flows). Both IPv4 and IPv6 are tested, and significant bandwidth savings (up to 68 % for IPv4 and 78 % for IPv6) can be obtained for the considered kinds of traffic.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks

  1. 1. Optimization of Low-efficiency Traffic in OpenFlow Software Defined Networks SPECTS 2014, International Symposium on Performance Evaluation of Computer and Telecommunication Systems July 6-10, 2014, Monterey, CA, USA Jose Saldana, David de Hoz, Julián Fernández-Navajas, José Ruiz-Mas Fernando Pascual, Diego R. Lopez, David Florez, Juan A. Castell, Manuel Nuñez
  2. 2. SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs Index 1. Introduction 2. Proposed method 3. Results 4. Conclusions
  3. 3. SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs Index 1. Introduction 2. Proposed method 3. Results 4. Conclusions
  4. 4. Introduction SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Software Defined Networks  Separation of control and data planes  Programmability of control plane  Central control of the network as a whole  Used in cloud computing: flexibility, efficiency  Openflow: the most extended SDN standard
  5. 5. Introduction SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Small-packets in the Internet  Real-time services: High interactivity VoIP Online games (some of them use TCP)  TCP ACKs. Downloads, videos, etc.
  6. 6. Introduction SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  High rates of small packets (high header-to- payload ratio). Low efficiency:  VoIP  FPS game  MMORPG game  ACK
  7. 7. Introduction SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Header compression can be used to reduce the overhead:  Many header fields are the same for every packet in a flow: e.g., IP addresses, ports, etc.  These fields can be avoided, but:  a context must be stored in both sides in order to rebuild the packets  Tunneling is necessary, since a packet with a compressed header cannot be sent normally
  8. 8. Introduction SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  One solution: combining header compression with multiplexing:  The tunnel header is shared between a number of packets  A period is defined in order to gather a number of packets Period . . . . . . Native game traffic Optimized traffic Period Period . . . . . . . . . . . . . . . . . .
  9. 9. Introduction SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  TCM (Tunneling Compressed Multiplexed Traffic Flows) is a proposal for improving the efficiency of these flows by:  Header compression  Multiplexing  Tunneling  30% to 55% saving  Status: IETF draft IP IP IP No compr. / ROHC / IPHC / ECRTP PPPMux / Other GRE / L2TP / Other IP Compression layer Multiplexing layer Tunneling layer Real-time traffic Network Protocol UDP RTP payload UDPTCP payloadpayload
  10. 10. Introduction SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Tradeoff. Advantages:  Bandwidth savings  pps reduction (energy savings)  At the cost of Added processing requirements Additional multiplexing delay 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%
  11. 11. Introduction SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Objective of the present work: Proposal of an equivalent optimization method, especially focused on SDNs. Advantages:  the tunneling layer is not necessary, since the SDN provides it in a natural way  the avoidance of the use of standard header compression techniques  multiplexing reduces the number of frames, so a number of Ethernet fields (header, inter- frame gap) are only sent once
  12. 12. SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs Index 1. Introduction 2. Proposed method 3. Results 4. Conclusions
  13. 13. Proposed method SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  In Openflow 1.0:  all the switches are connected to a central controller  each packet is associated to a flow by means of a 12-field tuple, used for assigning the output port SA,DA,Prot,ToS In port SA, DA, type Ethernet IP TCP Sport, DPortID, prio VLAN
  14. 14. Proposed method SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  When a flow traverses a path, the IP and TCP tuple fields of all the packets are the same for all the tables of the switches of that path, and also in the controller.  Thus, the IP and TCP protocol fields already included in the tuple are not necessary for switching decisions but only for matching the packets with a flow.
  15. 15. Proposed method SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  First step: we can remove the fields included in the tuple and substitute them by a flow identifier (FID), so the packet can travel in an optimized manner within the SDN (e.g. TCP/IP: 13 bytes saved, and 3 bytes added for the FID. Total 10 bytes): PayloadNative headers Payload Compressed headers FID SDN controller Ingress EgressIP TCP TCPIP IP TCPTCPIP Optimization within SDN
  16. 16. Proposed method SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Openflow 1.1 allows switches and controllers to agree on different flow matching syntaxes  Second step: The inclusion in the tuple of other NOCHANGE fields of Transport and Network layers.  These fields are not required for identifying the flow  But including them in the tuple would make it possible to remove them from all the packets, thus allowing even higher header compression ratios  Counterpart: slight increase of the storage requirements of the switches and the controller (about 40 bytes per flow)  We can also include in the tuple application-layer fields (e.g. RTP), obtaining more savings
  17. 17. Proposed method SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Third step: the SDN controller can match groups of flows sharing a common path segment within the SDN.  Packets belonging to different flows can be multiplexed together and sent as a single Eth frame.  We need a Multiplexing protocol (e.g. PPPMux). E E IPv4 header: 20 bytes TCP header: 20 bytes Inter-frame gap: 12 bytes PPP Common header: 1 byte PPPMux header: 2 bytes T IP Payload IPTwo Eth/IPv4/TCP frames with P=20bytes: T P E IP T P T P IP T P GIP F G F GF One Eth PPP frame including the two packets: E Eth header: 26 bytes* G FID: 3 bytes F Eth FCS: 4 bytes P PH M FID M FID M PH FID * The Eth header includes 4 bytes of VLAN 802.1Q
  18. 18. SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs Index 1. Introduction 2. Proposed method 3. Results 4. Conclusions
  19. 19. Results SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Four traffic patterns have been tested:  a) VoIP using IP/UDP/RTP (40 bytes header for IPv4 and 60 for IPv6) and G.729 codec with 2 samples per packet (20 bytes payload) every 20 ms.  b) Client-to-server flows of a UDP-based online game (28 or 48 bytes header), with 24.65 packets per second, and an average payload of 41.09 bytes.  c) Client-to-server flows of a TCP-based online game (40 or 60 bytes header) of 9.51 packets per second with an average payload of 8.74 bytes.  d) IP/TCP ACKs of 40 or 60 bytes
  20. 20. Results SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Fields considered as NOCHANGE: IPv4 IPv6 TCP/UDP RTP Version Version Source Port Version IHL Traffic Class Dest. Port P DSCP Flow Label Data Offset X ECN Next Header Reserved CC Time To Live Hop Limit Urgent Pointer M Protocol Source Address PT Source Address Dest. Address SSRC id Dest. Address
  21. 21. Results SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Maximum savings for each pattern (asymptote if the number of multiplexed packets is high): VoIP UDP game TCP game TCP ACKs IPv4 62.75% 52.21% 65.02% 72.62% IPv6 72.13% 62.55% 74.95% 81.37%
  22. 22. Results SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Savings as a function of the number of multiplexed packets 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Bandwidthsavingpercentage number of packets Bandwidth savings IPv4 VoIP UDP game TCP game ACKs
  23. 23. Results SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  Savings as a function of the number of multiplexed packets 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Bandwidthsavingpercentage number of packets Bandwidth savings IPv6 VoIP UDP game TCP game ACKs
  24. 24. SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs Index 1. Introduction 2. Proposed method 3. Results 4. Conclusions
  25. 25. Conclusions SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs  The SDN controller can find a number of flows sharing a common path  The flows that are constant can be avoided, using an identifier  With this method we can save bandwidth and reduce the number of pps: 68% for IPv4 and 78% for IPv6  Counterpart: additional latency. It can be kept under tolerable limits for services sending high packet rates
  26. 26. Thank you very much! Jose Saldana, David de Hoz, Julián Fernández-Navajas, José Ruiz-Mas Fernando Pascual, Diego R. Lopez, David Florez, Juan A. Castell, Manuel Nuñez

×