Optimization of Low-efficiency Traffic in OpenFlowSoftware Defined Networks

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

SPECTS 2014 Optimization of Low-efficiency Traffic in OpenFlow SDNs

Index

1. Introduction

2. Proposed method

3. Results

4. Conclusions

Introduction


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

Introduction


Small-packets in the Internet

Real-time services: High interactivity

VoIP

Online games (some of them use TCP)

TCP ACKs. Downloads, videos, etc.

Introduction


High rates of small packets (high header-to-

payload ratio). Low efficiency:

VoIP

FPS game

MMORPG game

ACK

Introduction


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

Introduction


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

. . .

. . .

. . .

. . .

. . .

. . .

Introduction


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

Introduction


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%

Introduction


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


Index

1. Introduction

2. Proposed method

3. Results

4. Conclusions

Proposed method


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,ToSIn port

SA, DA, type

Ethernet IP TCP

Sport, DPortID, prio

VLAN

Proposed method


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.

Proposed method


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

PayloadCompressed

headers

FID

SDN controller

Ingress

EgressIP TCP TCPIP IP TCPTCPIP

Optimization within SDN

Proposed method


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

Proposed method


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


Index

1. Introduction

2. Proposed method

3. Results

4. Conclusions

Results


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

Results


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

Results


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%

Results


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

Ba

nd

wid

th s

avin

g p

erc

en

tag

e

number of packets

Bandwidth savings IPv4

VoIP

UDP game

TCP game

ACKs

Results


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

Ban

dw

idth

savin

g p

erc

en

tag

e

number of packets

Bandwidth savings IPv6

VoIP

UDP game

TCP game

ACKs


Index

1. Introduction

2. Proposed method

3. Results

4. Conclusions

Conclusions


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

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

Optimization of Low-efficiency Traffic in OpenFlowSoftware Defined Networks

Technology

Transcript of Optimization of Low-efficiency Traffic in OpenFlowSoftware Defined Networks