Results 1 - 10
of
60
Structured Streams: a New Transport Abstraction
, 2007
"... Internet applications currently have a choice between stream and datagram transport abstractions. Datagrams efficiently support small transactions and streams are suited for longrunning conversations, but neither abstraction adequately supports applications like HTTP that exhibit a mixture of transa ..."
Abstract
-
Cited by 21 (6 self)
- Add to MetaCart
Internet applications currently have a choice between stream and datagram transport abstractions. Datagrams efficiently support small transactions and streams are suited for longrunning conversations, but neither abstraction adequately supports applications like HTTP that exhibit a mixture of transaction sizes, or applications like FTP and SIP that use multiple transport instances. Structured Stream Transport (SST) enhances the traditional stream abstraction with a hierarchical hereditary structure, allowing applications to create lightweight child streams from any existing stream. Unlike TCP streams, these lightweight streams incur neither 3-way handshaking delays on startup nor TIME-WAIT periods on close. Each stream offers independent data transfer and flow control, allowing different transactions to proceed in parallel without head-of-line blocking, but all streams share one congestion control context. SST supports both reliable and best-effort delivery in a way that semantically unifies datagrams with streams and solves the classic “large datagram ” problem, where a datagram’s loss probability increases exponentially with fragment count. Finally, an application can prioritize its streams relative to each other and adjust priorities dynamically through out-of-band signaling. A user-space prototype shows that SST is TCP-friendly to within 2%, and performs comparably to a user-space TCP and to within 10 % of kernel TCP on a WiFi network.
Breaking up the transport logjam
- In HOTNETS
, 2008
"... Current Internet transports conflate transport semantics with endpoint addressing and flow regulation, creating roadblocks to Internet evolution that we propose to address with a new layering model. Factoring endpoint addressing (port numbers) into a separate Endpoint Layer permits incremental rollo ..."
Abstract
-
Cited by 14 (5 self)
- Add to MetaCart
Current Internet transports conflate transport semantics with endpoint addressing and flow regulation, creating roadblocks to Internet evolution that we propose to address with a new layering model. Factoring endpoint addressing (port numbers) into a separate Endpoint Layer permits incremental rollout of new or improved transports at OS or application level, enables transport-oblivious firewall/NAT traversal, improves transport negotiation efficiency, and simplifies endpoint address space administration. Factoring congestion control into a separate Flow Layer cleanly enables in-path performance optimizations such as on satellite or wireless links, permits incremental rollout of new congestion control schemes within administrative domains, frees congestion control evolution from the yoke of “TCP-friendliness, ” and facilitates multihoming and multipath communication. Though this architecture is ambitious, existing protocols can act as starting points for the new layers— UDP or UDP-Lite for the Endpoint Layer, and Congestion Manager or DCCP for the Flow Layer—providing both immediate deployability and a sound basis for long-term evolution. 1.
Applying TCP-Friendly Congestion Control to Concurrent Multipath Transfer
- PROCEEDINGS OF THE 24TH IEEE INTERNATIONAL CONFERENCE ON ADVANCED INFORMATION NETWORKING AND APPLICATIONS (AINA)
, 2010
"... The steadily growing importance of Internetbased applications and their resilience requirements lead to a rising number of multi-homed sites. The idea of Concurrent Multipath Transfer (CMT) is to exploit the existence of multiple paths among endpoints to increase application data throughput. However ..."
Abstract
-
Cited by 12 (9 self)
- Add to MetaCart
The steadily growing importance of Internetbased applications and their resilience requirements lead to a rising number of multi-homed sites. The idea of Concurrent Multipath Transfer (CMT) is to exploit the existence of multiple paths among endpoints to increase application data throughput. However, handling the congestion control of each path independently lacks of fairness against non-CMT flows. In this paper, we describe our approach of combining CMT with the idea of Resource Pooling (RP) in order to achieve a performance improvement over non-CMT transfer while still remaining fair to concurrent flows on congested links. Unlike existing approaches which adapt classic TCP to a multi-homed CMT protocol, our approach does not depend on specific characteristics of TCP. Instead, we base on already entrenched functional blocks of CMT transfer, on the example of the CMT-enabled SCTP (Stream Control Transmission Protocol). In a simulative proof-of-concept analysis, we show that our approach – while relatively simple – is already quite effective.
Implementation and Evaluation of Concurrent Multipath Transfer for SCTP in the INET Framework
"... The steadily growing importance of resilience-critical Internet applications leads to a rising number of multi-homed sites and systems. But since the protocols of the classical Internet – particularly TCP – assume a single access path only, the number of programs supporting multiple network paths is ..."
Abstract
-
Cited by 10 (10 self)
- Add to MetaCart
The steadily growing importance of resilience-critical Internet applications leads to a rising number of multi-homed sites and systems. But since the protocols of the classical Internet – particularly TCP – assume a single access path only, the number of programs supporting multiple network paths is still small. The Stream Control Transport Protocol (SCTP), which is an advanced general-purpose transport protocol and the possible successor of TCP, brings the support of multi-homing into the applications. For technical reasons, SCTP uses one network path for data transmission and utilizes the other paths for backup only. An extension to support the load balancing of user data onto multiple paths in order to increase the payload throughput is Concurrent Multipath Transfer for SCTP, denoted as CMT-SCTP. In this paper, we describe our CMT-SCTP extension for the SCTP model provided by the INET framework. By using proof-of-concept simulations, we furthermore demonstrate its usability and configuration parameters.
Retransmission policies for multihomed transport protocols
, 2006
"... We evaluate three retransmission policies for transport protocols that support multihoming (e.g. SCTP). The policies dictate whether retransmissions are sent to the same peer IP address as the original transmission, or sent to an alternate peer IP address. Each policy presents tradeoffs based on the ..."
Abstract
-
Cited by 9 (4 self)
- Add to MetaCart
We evaluate three retransmission policies for transport protocols that support multihoming (e.g. SCTP). The policies dictate whether retransmissions are sent to the same peer IP address as the original transmission, or sent to an alternate peer IP address. Each policy presents tradeoffs based on the paths ’ bandwidth, delay, loss rate, and IP destination reachability. We find that sending all retransmissions to an alternate peer IP address is useful when the primary IP address becomes unreachable, but often degrades performance in non-failure scenarios. On the other hand, sending all retransmissions to the same peer IP address as the original transmission reverses the tradeoffs. We balance the tradeoffs by proposing a hybrid policy that sends fast retransmissions to the same peer IP address as the original transmission, and sends timeout retransmissions to an alternate peer IP address. We show that even with extensions which we proposed to improve the policies’ performance, the hybrid policy is the best performing policy in failure and non-failure scenarios.
1 Non-Renegable Selective Acknowledgments (NR-SACKs) for SCTP
"... Abstract — In both TCP and SCTP, selectively acked (SACKed) out-of-order data is implicitly renegable; that is, the receiver can later discard SACKed data. The possibility of reneging forces the transport sender to maintain copies of SACKed data in the send buffer until they are cumulatively acked. ..."
Abstract
-
Cited by 9 (1 self)
- Add to MetaCart
Abstract — In both TCP and SCTP, selectively acked (SACKed) out-of-order data is implicitly renegable; that is, the receiver can later discard SACKed data. The possibility of reneging forces the transport sender to maintain copies of SACKed data in the send buffer until they are cumulatively acked. In this paper, we investigate the situation where all out-oforder data is non-renegable, such as when the data has been delivered to the application, or when the receiver simply never reneges. Using simulations, we show that SACKs result in inevitable send buffer wastage, which increases as frequency of loss events and loss recovery durations increase. We introduce a fundamentally new ack mechanism, Non-Renegable Selective Acknowledgments (NR-SACKs), for SCTP. Using NR-SACKs, an SCTP receiver can explicitly identify some or all out-of-order data as being non-renegable, allowing the sender to free up send buffer sooner than if the data were only SACKed. We compare and show that NR-SACKs enable efficient utilization of a transport sender’s memory. We further investigate the effects of using NR-SACKs in Concurrent Multipath Transfer (CMT). CMT is an experimental SCTP extension that exploits multihoming for simultaneous data transfer over multiple paths [4]. Using simulations, we show that NR-SACKs not only reduce transport sender’s memory requirements, but also improve throughput in CMT.
On the Use of Concurrent Multipath Transfer over Asymmetric Paths
- PROCEEDINGS OF THE IEEE GLOBAL COMMUNICATIONS CONFERENCE (GLOBECOM)
, 2010
"... With the deployment of more and more resilience-critical Internet applications, there is a rising demand for multihomed network sites. This leads to the desire for simultaneously utilising all available access paths to improve application data throughput. This is commonly known as Concurrent Multipa ..."
Abstract
-
Cited by 9 (8 self)
- Add to MetaCart
With the deployment of more and more resilience-critical Internet applications, there is a rising demand for multihomed network sites. This leads to the desire for simultaneously utilising all available access paths to improve application data throughput. This is commonly known as Concurrent Multipath Transfer (CMT); approaches for several Transport Layer protocols have been proposed. Combined with Resource Pooling (RP), CMT can also fairly coexist with concurrent non-CMT flows. Current approaches focus on symmetric paths (i.e. similar bandwidth, delay and error rate). However, asymmetric paths are much more likely – particularly for realistic Internet setups – and efficient CMT usage on such paths is therefore crucial. In this paper, we first show the challenges of plain as well as RP-aware CMT data transport over asymmetric paths. After that, we introduce mechanisms for efficient transport over such paths. Finally, we analyse the performance of our approaches by using simulations.
Design, implementation and evaluation of congestion control for multipath TCP
- in Proc. Networked Systems Design and Implementation, March/April
, 2011
"... Multipath TCP, as proposed by the IETF working group mptcp, allows a single data stream to be split across multiple paths. This has obvious benefits for reliability, and it can also lead to more efficient use of networked resources. We describe the design of a multipath congestion control algorithm, ..."
Abstract
-
Cited by 7 (3 self)
- Add to MetaCart
Multipath TCP, as proposed by the IETF working group mptcp, allows a single data stream to be split across multiple paths. This has obvious benefits for reliability, and it can also lead to more efficient use of networked resources. We describe the design of a multipath congestion control algorithm, we implement it in Linux, and we evaluate it for multihomed servers, data centers and mobile clients. We show that some ‘obvious ’ solutions for multipath congestion control can be harmful, but that our algorithm improves throughput and fairness compared to single-path TCP. Our algorithm is a drop-in replacement for TCP, and we believe it is safe to deploy. 1.
SCTP: An Innovative Transport Layer Protocol for The Web
- 15th International conference on World Wide Web
, 2006
"... We propose using the Stream Control Transmission Protocol (SCTP), a recent IETF transport layer protocol, for reliable web transport. Although TCP has traditionally been used, we argue that SCTP better matches the needs of HTTP-based network applications. This position paper discusses SCTP features ..."
Abstract
-
Cited by 6 (3 self)
- Add to MetaCart
We propose using the Stream Control Transmission Protocol (SCTP), a recent IETF transport layer protocol, for reliable web transport. Although TCP has traditionally been used, we argue that SCTP better matches the needs of HTTP-based network applications. This position paper discusses SCTP features that address: (i) head-of-line blocking within a single TCP connection, (ii) vulnerability to network failures, and (iii) vulnerability to denial-of-service SYN attacks. We discuss our experience in modifying the Apache server and the Firefox browser to benefit from SCTP, and demonstrate our HTTP over SCTP design via simple experiments. We also discuss the benefits of using SCTP in other web domains through two example scenarios ─ multiplexing user requests, and multiplexing resource access. Finally, we highlight several SCTP features that will be valuable to the design and implementation of current HTTP-based client-server applications.
Concurrent multipath transfer using transport layer multihoming: Performance under network failures
- MILCOM 2006, WASHINGTON D. C
, 2006
"... Recent research on Concurrent Multipath Transfer using SCTP multihoming (CMT) proposed various retransmission policies to minimize the negative impacts of receiver buffer (rbuf) blocking that occur during congestion. Here we investigate CMT’s throughput degradation caused by rbuf blocking during com ..."
Abstract
-
Cited by 6 (5 self)
- Add to MetaCart
Recent research on Concurrent Multipath Transfer using SCTP multihoming (CMT) proposed various retransmission policies to minimize the negative impacts of receiver buffer (rbuf) blocking that occur during congestion. Here we investigate CMT’s throughput degradation caused by rbuf blocking during complete and/or short-term network failures. To improve CMT’s performance during failure, we introduce a new state for each destination called the “Potentially Failed ” (PF) state and propose a retransmission policy that takes the PF state into account. Using simulation, we evaluate our solution (called CMT-PF), and demonstrate its improved throughput over CMT in failure-prone networks such as FCS battlefield networks.

