This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG Note This document is not an IETF Internet Standard. It represents the individual opinion(s) of one or more members of the TMRG Research

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.

Abstract—Interest continues to grow in alternative transport protocols to the Transmission Control Protocol (TCP). These alternatives include protocols designed to give greater efficiency in high-speed, high-delay environments (so-called high-speed TCP variants), and protocols that provide congestion control without

Abstract. Over the past decades, the fundamental principles of the Internet architecture have not significantly changed. However, Internet evolution and its effects on participants ’ interests have triggered the need for re-defining these design principles. “Design for Tussle ” is an aspiration for future network designs, which enables the involved stakeholders to express their possibly conflicting socio-economic preferences on service instances. We performed a series of case studies examining whether established technologies are compatible with this new approach. Using the knowledge gained, we provide canonical examples and help protocol and network designers better to consider how to come up to the problem of “designing for tussle ” in order to realize a flexible architecture. Finally, we associate protocol success to adoption and show, using empirical evidences, that carefully embracing the “Design for Tussle ” paradigm can outweigh the higher complexity in protocol design.

Abstract—Many new transport protocols are being defined, including, for example, variants of the Transmission Control Protocol (TCP), to better match the requirements of new applications. A key issue in the evaluation of protocol flows, in terms of their performance, is how fair they are to other flows. Specifically, it is important to understand how a mix of existing and/or new protocols will interact with each other when using the same network resources. Such observations help to inform protocol design, and allow an assessment of potential impacts on users. We present a simple, yet effective, methodology for examining a specific case of inter-flow fairness based solely on measurements of flow performance. As well as using an existing fairness metric, we propose a new metric which provides a richer information summary for the evaluation of fairness. I.

ABSTRACT – Ideally, everyone should be free to use as much of the Internet resource pool as they can take. But, whenever too much load meets too little capacity, everyone's freedoms collide. We show that attempts to isolate users from each other have corrosive side-effects-discouraging mutually beneficial sharing of the resource pool and harming the Internet's evolvability. We describe an unusual form of traffic policing which only pushes back against those who use their freedom to limit the freedom of others. This offers a vision of how much better the Internet could be. But there are subtle aspects missing from the current Internet architecture that prevent this form of policing being deployed. This paper aims to shift the research agenda onto those issues, and away from earlier attempts to isolate users from each other. 1.

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG Note The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. This document presents some observations on "simple best-effort

In our previous position paper [Natarajan 2006], we hypothetically argued how reduced head-of-line (HOL) blocking in a multistreamed web transport, such as the Stream Control Transmission Protocol (SCTP), could improve web response times. We also proposed a design for HTTP over SCTP streams. We now have implemented HTTP/SCTP in the Apache web server and Firefox web browser. In this paper, we show response time improvements for HTTP 1.1 persistent, pipelined transfers between TCP vs. SCTP over high latency paths involving one or more long delay links (VSAT or HSDPA). Our experiments over an emulated network using Dummynet [Rizzo 1997] reveal that SCTP’s enhanced loss recovery improves page download times. A multistreamed web transport’s primary contribution to minimize response times is concurrent rendering, where multiple pipelined objects can be displayed in an interleaved fashion at the web browser. In this work, we explore the parameter space where concurrent rendering causes visually perceivable improvements to pipelined objects ’ response times. Concurrent rendering’s dramatic improvements while downloading progressive images can be viewed in the movies available online at [Movies]. We finally discuss the dynamics between concurrency level (number of transport layer streams) and the user’s perception of embedded objects, and propose concurrency level as a tunable parameter for HTTP over multistreamed transport. 1.

Abstract not found

Multipath transport protocols, which transmit data over multiple distinct paths in an end-to-end connection are introduced. However, they have a problem in terms of fairness. When the transmissions along several paths share the same bottleneck link, the multipath connection receives higher throughput than a competing regular TCP flow, because it executes congestion control per path with the same algorithm as TCP. We investigate a congestion control scheme that addresses this problem with the weighted congestion control approach. In our scheme, an end-to-end connection that uses flows along multiple paths can fairly compete with TCP flows at the shared bottleneck. Our scheme also maximizes the utilization of different path characteristics, such as bandwidth capacity and RTT. Our simulation results show that a bundle of multiple flows based on our scheme fairly competes with TCP flows at the shared bottleneck. 1.