On the Usage of Transport Features Provided by IETF Transport Protocols

Khademi, Navid; Welzl, Michael

doi:10.17487/rfc8303

Cited by 6 publications

(7 citation statements)

References 23 publications

(72 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The first handshake of the SCTP association succeeds shortly after the TCP connection does, so the latter is aborted. group (TAPS) [119], [127] provides a unique opportunity to develop this sort of consensus.…”

Section: Transparent Transport Protocol Selectionmentioning

confidence: 99%

“…• The IETF TAPS working group seeks to specify how applications could express their transport requirements, instead of being tied to a specific protocol, and how a transport system based on such requirements specifications could be constructed. 4 This work begins with identifying the services that current IETF transport protocols provide [119], [127], [159]. An outcome of TAPS could include a new abstract API, and it will include recommendations on how to perform selection between protocols.…”

Section: Future Research Directionsmentioning

confidence: 99%

See 1 more Smart Citation

De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives

Παπαστεργίου

Fairhurst

Ros

et al. 2017

IEEE Commun. Surv. Tutorials

View full text Add to dashboard Cite

It is widely recognized that the Internet transport layer has become ossified, where further evolution has become hard or even impossible. This is a direct consequence of the ubiquitous deployment of middleboxes that hamper the deployment of new transports, aggravated further by the limited flexibility of the application programming interface (API) typically presented to applications. To tackle this problem, a wide range of solutions have been proposed in the literature, each aiming to address a particular aspect. Yet, no single proposal has emerged that is able to enable evolution of the transport layer. In this paper, after an overview of the main issues and reasons for transportlayer ossification, we survey proposed solutions and discuss their potential and limitations. The survey is divided into five parts, each covering a set of point solutions for a different facet of the problem space: 1) designing middlebox-proof transports; 2) signaling for facilitating middlebox traversal; 3) enhancing the API between the applications and the transport layer; 4) discovering and exploiting end-to-end capabilities; and 5) enabling user-space protocol stacks. Based on this analysis, we then identify further development needs toward an overall solution. We argue that the development of a comprehensive transport layer framework, able to facilitate the integration and cooperation of specialized solutions in an application-independent and flexible way, is a necessary step toward making the Internet transport architecture truly evolvable. To this end, we identify the requirements for such a framework and provide insights for its development.

show abstract

Section: Transparent Transport Protocol Selectionmentioning

confidence: 99%

Section: Future Research Directionsmentioning

confidence: 99%

De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives

Παπαστεργίου

Fairhurst

Ros

et al. 2017

IEEE Commun. Surv. Tutorials

View full text Add to dashboard Cite

show abstract

“…Instead, TAPS used a methodology that started from a survey of the services offered by available IETF transport protocols [9]. It is currently documenting the primitives and parameters used to access features of a subset of these protocols [10] to form a basis for the design of a protocol-independent API. NEAT developers have been actively contributing to this initiative based on experience of using the NEAT API, which shares many of the goals behind development of TAPS.…”

Section: Standardizationmentioning

confidence: 99%

NEAT: A Platform- and Protocol-Independent Internet Transport API

et al. 2017

View full text Add to dashboard Cite

The sockets Applications Programming Interface (API) has become the standard way that applications access the transport services offered by the Internet Protocol stack. This paper presents NEAT, a user-space library that can provide an alternate transport API. NEAT allows applications to request the service they need using a new design that is agnostic to the specific choice of transport protocol underneath. This not only allows applications to take advantage of common protocol machinery, but also eases introduction of new network mechanisms and transport protocols. The paper describes the components of the NEAT library and illustrates the important benefits that can be gained from this new approach. NEAT is a software platform for developing advanced network applications that was designed in accordance with the standardization efforts on Transport Services (TAPS) in the Internet Engineering Task Force (IETF), but its features exceed the envisioned functionality of a TAPS system.

show abstract

“…The description in Section 3 follows the methodology defined by the IETF TAPS Working Group in [RFC8303]. Specifically, this document provides the first pass of this process, which discusses the relevant RFC text describing primitives for each protocol.…”

Section: Introductionmentioning

confidence: 99%

“…Specifically, this document provides the first pass of this process, which discusses the relevant RFC text describing primitives for each protocol. [RFC8303] [RFC6935] and [RFC6936] define an update to the UDP transport originally specified in [RFC2460] (note that RFC 2460 has been obsoleted by RFC 8200). This enables use of a zero UDP checksum mode with a tunnel protocol, providing that the method satisfies the requirements in the corresponding applicability statement [RFC6936].…”

Section: Introductionmentioning

confidence: 99%

Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)

Fairhurst¹,

Jones²

2018

View full text Add to dashboard Cite

On the Usage of Transport Features Provided by IETF Transport Protocols

Cited by 6 publications

References 23 publications

De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives

De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives

NEAT: A Platform- and Protocol-Independent Internet Transport API

Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)

Contact Info

Product

Resources

About