International Symposium on Performance Evaluation of Computer and Telecommunication Systems (SPECTS 2014) 2014
DOI: 10.1109/spects.2014.6879992
|View full text |Cite
|
Sign up to set email alerts
|

Optimization of low-efficiency traffic in OpenFlow Software Defined Networks

Abstract: Abstract-

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
4
0

Year Published

2015
2015
2021
2021

Publication Types

Select...
3
2
1

Relationship

1
5

Authors

Journals

citations
Cited by 7 publications
(4 citation statements)
references
References 16 publications
0
4
0
Order By: Relevance
“…Saldana et al 15 proposed another scheme that implements header compression within an OpenFlowbased SDN. In this scheme, the static header fields that present in OpenFlow tuple are removed from packet headers, providing significant bandwidth savings.…”
Section: End-to-end Header Compressionmentioning
confidence: 99%
“…Saldana et al 15 proposed another scheme that implements header compression within an OpenFlowbased SDN. In this scheme, the static header fields that present in OpenFlow tuple are removed from packet headers, providing significant bandwidth savings.…”
Section: End-to-end Header Compressionmentioning
confidence: 99%
“…In the context of home networks, Kumar et al proposed to leverage SDN to enable ISPs to expose some controls to the users to manage service quality for specific devices and applications in their household [10]. In 2014, Saldana et al used SDN to identify flows of small packets (such as VoIP) for removing common header fields and multiplexing packets in the same frame in order to reduce the overhead [11]. A Network Services Abstraction Layer (NSAL) and a unified data model were introduced by Sieber et al for both SDN and legacy devices in order to achieve QoS for time-critical VoIP applications [12].…”
Section: Related Workmentioning
confidence: 99%
“…16 reports the bandwidth savings, obtained using equation (1). 1 The trace has been filtered with Wireshark using 'ip.src!=192.168.0.0/16' for obtaining the downlink packets. 2 The filter in this case is 'ip.dst!=192.168.0.0/16' It can be seen that for the two high-throughput traces (Chicago and DSL_uplink), the small packets can be almost totally avoided (see Fig.…”
Section: B Public Traffic Tracesmentioning
confidence: 99%