Protocol ossification
Protocol ossification is the loss of flexibility,
Ossification is a major issue in
Recommended methods of preventing ossification include
History
This section needs expansion. You can help by adding to it. (November 2022) |
Significant ossification had set in on the Internet by 2005, with analyses of the problem also being published in that year;[1] Ammar (2018) suggests that ossification was a consequence of the Internet attaining global scale and becoming the primary communication network.[2]
Multipath TCP was the first extension to a core Internet protocol to deeply confront protocol ossification during its design.[3]
The IETF created the Transport Services (taps) working group in 2014.
The Internet Architecture Board identified design considerations around the exposure of protocol information to network elements as a "developing field" in 2023.[7]
Causes
The primary cause of protocol ossification is middlebox interference,[8] invalidating the end-to-end principle.[9] Middleboxes may entirely block unknown protocols or unrecognised extensions to known protocols, interfere with extension or feature negotiation, or perform more invasive modification of protocol metadata.[10] Not all middlebox modifications are necessarily ossifying; of those which are potentially harmful, they are disproportionately towards the network edge.[11] Middleboxes are deployed by network operators unilaterally to solve specific problems,[12] including performance optimisation, security requirements (e.g., firewalls), network address translation or enhancing control of networks.[13] These middlebox deployments provide localised short-term utility but degrade the global long-term evolvability of the Internet in a manifestation of the tragedy of the commons.[12]
Changes to a protocol must be tolerated by all on-path intermediaries; if wide Internet deployment of the change is desired, then this extends to a large portion of intermediaries on the Internet. A middlebox must tolerate widely-used protocols as they were being used at the time of its deployment, but is liable not to tolerate new protocols or changes to extant ones, effectively creating a
Beyond middleboxes, ossification can also be caused by insufficient flexibility within the endpoint's implementation.
Prevention and remediation
The Internet Architecture Board recommended in 2019 that implicit signals to observers should be replaced with signals deliberately intended for the consumption of those observers, and signals not intended for their consumption should not be available to them (e.g., by encryption); and also that the protocol metadata should be integrity protected so that it cannot be modified by middleboxes.[16] However, even fully encrypted metadata may not entirely prevent ossification in the network, as the wire image of a protocol can still show patterns that come to be relied upon.[17] Network operators use metadata for a variety of benign management purposes,[18] and Internet research is also informed by data gathered from protocol metadata;[19] a protocol's designer must balance ossification resistance against observability for operational or research needs.[17] Arkko et al. (2023) provides further guidance on these considerations: disclosure of information by a protocol to the network should be intentional,[20] performed with the agreement of both recipient and sender,[21] authenticated to the degree possible and necessary,[22] only acted upon to the degree of its trustworthiness,[23] and minimised and provided to a minimum number of entities.[24][25]
Active use of extension points is required if they are not to ossify.
A new protocol may be designed to mimic the wire image of an existing ossified protocol;[32] alternatively, a new protocol may be encapsulated within an existing, tolerated protocol. A disadvantage of encapsulation is that there is typically overhead and redundant work (e.g., outer checksums made redundant by inner integrity checks).[33]
Besides middleboxes, other sources of ossification can also be resisted.
With sufficient effort and coordination, ossification can be directly reversed. A
Examples
The
The
See also
- Backward compatibility
- Collective action problem
- De facto standard
- Forward compatibility
- Interoperability
- Hyrum's law
- Network effect
- Vendor lock-in
References
- ^ Ammar 2018, p. 57-58.
- ^ Ammar 2018, p. 59.
- ^ a b Raiciu et al. 2012, p. 1.
- IETF.
- IETF.
- ^ a b Trammell & Kuehlewind 2019, p. 2.
- ^ Arkko et al. 2023, 3. Further Work.
- ^ Papastergiou et al. 2017, p. 619.
- ^ a b c d Papastergiou et al. 2017, p. 620.
- ^ Edeline & Donnet 2019, p. 171.
- ^ Edeline & Donnet 2019, p. 173-175.
- ^ a b Edeline & Donnet 2019, p. 169.
- ^ Honda et al. 2011, p. 1.
- ^ a b Papastergiou et al. 2017, p. 621.
- ^ Corbet 2015.
- ^ Hardie 2019, p. 7-8.
- ^ a b Fairhurst & Perkins 2021, 7. Conclusions.
- ^ Fairhurst & Perkins 2021, 2. Current Uses of Transport Headers within the Network.
- ^ Fairhurst & Perkins 2021, 3. Research, Development, and Deployment.
- ^ Arkko et al. 2023, 2.1. Intentional Distribution.
- ^ Arkko et al. 2023, 2.2. Control of the Distribution of Information.
- ^ Arkko et al. 2023, 2.3. Protecting Information and Authentication.
- ^ Arkko et al. 2023, 2.5. Limiting Impact of Information.
- ^ Arkko et al. 2023, 2.4. Minimize Information.
- ^ Arkko et al. 2023, 2.6. Minimum Set of Entities.
- ^ Thomson & Pauly 2021, 3. Active Use.
- ^ Thomson & Pauly 2021, 4. Complementary Techniques.
- ^ Thomson & Pauly 2021, 3.1. Dependency Is Better.
- ^ Trammell & Kuehlewind 2019, p. 7.
- ^ a b Thomson & Pauly 2021, 3.3. Falsifying Active Use.
- ^ Thomson & Pauly 2021, 3.4. Examples of Active Use.
- ^ Papastergiou et al. 2017, p. 623.
- ^ Papastergiou et al. 2017, p. 623-4.
- ^ Papastergiou et al. 2017, p. 630.
- ^ Corbet 2016.
- ^ Papastergiou et al. 2017, p. 629.
- ^ Thomson & Pauly 2021, 3.5. Restoring Active Use.
- ^ a b Thomson & Pauly 2021, A.5. TCP.
- ^ Edeline & Donnet 2019, p. 175-176.
- ^ Hesmans et al. 2013, p. 1.
- ^ Rybczyńska 2020.
- ^ Papastergiou et al. 2017, p. 627.
- ^ McQuistin, Perkins & Fayed 2016, p. 1.
- ^ Sullivan 2017.
- ^ a b Corbet 2018.
- ^ Thomson 2021, 2. Fixed Properties of All QUIC Versions.
- ^ Kühlewind & Trammell 2022, 2. The Necessity of Fallback.
Bibliography
- Trammell, Brian; Kuehlewind, Mirja (April 2019). The Wire Image of a Network Protocol. .
- Hardie, Ted, ed. (April 2019). Transport Protocol Path Signals. .
- Thomson, Martin (May 2021). Version-Independent Properties of QUIC. .
- Fairhurst, Gorry; Perkins, Colin (July 2021). Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols. .
- Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. .
- Kühlewind, Mirja; Trammell, Brian (September 2022). Applicability of the QUIC Transport Protocol. .
- Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). Considerations on Application - Network Collaboration Using Path Signals. .
- Honda, Michio; Nishida, Yoshifumi; Raiciu, Costin; Greenhalgh, Adam; .
- Raiciu, Costin; Paasch, Christoph; Barre, Sebastien; Ford, Alan; Honda, Michio; Duchene, Fabien; Bonaventure, Olivier; Handley, Mark (2012). How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP. 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12).
- Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). Are TCP extensions middlebox-proof?. HotMiddlebox '13. .
- Corbet, Jonathan (8 December 2015). "Checksum offloads and protocol ossification". LWN.net.
- Corbet, Jonathan (20 June 2016). "Transport-level protocols in user space". LWN.net.
- McQuistin, Stephen; Perkins, Colin; Fayed, Marwan (July 2016). Implementing Real-Time Transport Services over an Ossified Network. 2016 Applied Networking Research Workshop. hdl:1893/26111.
- Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tüxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives". S2CID 1846371.
- Sullivan, Nick (2017-12-26). "Why TLS 1.3 isn't in browsers yet". The Cloudflare Blog. Retrieved 2020-03-14.
- Ammar, Mostafa (January 2018). "Ex Uno Pluria: The Service-Infrastructure Cycle, Ossification, and the Fragmentation of the Internet". S2CID 12169344.
- Corbet, Jonathan (29 January 2018). "QUIC as a solution to protocol ossification". LWN.net.
- Edeline, Korian; Donnet, Benoit (2019). A Bottom-Up Investigation of the Transport-Layer Ossification. 2019 Network Traffic Measurement and Analysis Conference (TMA). .
- Rybczyńska, Marta (13 March 2020). "A QUIC look at HTTP/3". LWN.net.
Further reading
- Trammell, Brian; Kuehlewind, Mirja, eds. (October 2015). Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI). .