Abstract

TCP elastic traffic is generated by the traditional “data” applications in the Internet, such as web browsing, peer-to-peer file sharing, ftp, e-mail and other. These applications are built on top of TCP, which provides reliable transfers and adjusts the sending rate to the network conditions to achieve the maximum possible throughput, a feature that makes TCP flows to be called “elastic”. From the point of view of the network, TCP elastic traffic requires the maximum possible throughput above a minimum value, a network service that we call the Minimum Throughput Service (MTS). In this paper we survey the main network schemes that have been proposed in the Internet to provide this service for TCP elastic traffic, classified in two broad groups, the ones that do not use Admission Control (AC) and the ones that do use it. For each network scheme we describe the main characteristics of the service (whether the minimum throughput can be different or is the same for all flows, whether isolation among flows is provided, etc.) and their architecture (the specific traffic conditioning, queue disciplines and AC mechanisms used, the required state, the use of signaling, etc.).

Highlights

  • The traditional “data” applications in the Internet transfer discrete messages or “documents”, which are partitioned into blocks and sent through the network into a sequence of packets or “flows” within TCP connections [1, 2, 3]

  • For each network scheme we describe the main characteristics of the service and their architecture

  • TCP flows generated by these applications are satisfactorily supported by a network service that provides a minimum throughput to the flow and if possible, an extra throughput

Read more

Summary

Introduction

The traditional “data” applications in the Internet (web browsing, peer-to-peer file sharing, ftp, e-mail and others) transfer discrete messages or “documents” (a web request, a basic web file, an embedded image, an ftp file, an ftp command, etc.), which are partitioned into blocks and sent through the network into a sequence of packets or “flows” within TCP connections [1, 2, 3]. The traditional network scheme in the Internet is based only on First-In-First-Out (FIFO) and Tail Drop queues, there is neither traffic conditioning nor AC mechanisms, and provisioning can be whatever The strength of this scheme is the simplicity. In the traditional network scheme, when resources in the followed network path are enough to satisfy the minimum throughput requirements of all flows, all of them are satisfied, but otherwise, i.e., during congestion situations, none of them is satisfied (it is said that this scheme provides the best-effort service, a service with no absolute guarantees). For each network scheme we describe the main characteristics of the service (whether the minimum throughput can be different or is the same for all flows, whether isolation among flows is provided, etc.) and their architecture (the specific traffic conditioning, queue disciplines and AC mechanisms used, the required state, the use of signaling, etc.).

TCP elastic traffic
QoS for elastic traffic
Reliability and resource sharing in TCP
Reliable delivery in TCP
Resource sharing in TCP
Characteristics of TCP elastic traffic
Network schemes for TCP elastic traffic without admission control
The “traditional” scheme
Schemes based on packet classes
The in and out scheme of the Assured Service
TCP-state based differentiation
Preferential treatment to short TCP flows
Network schemes for TCP elastic traffic with admission control
The scheme for a throughput service in Corelite
Implicit AC for TCP connections
The scheme for elastic traffic in Flow-Aware Networking
Findings
Conclusions
Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.