Protocol ossification: Difference between revisions

Revision as of 09:20, 7 July 2023

Latest revision as of 14:52, 22 June 2025

(9 intermediate revisions by 6 users not shown)

Line 1:

{{Short description|Reduction in the flexibility of network protocol design due to middleboxes}}

'''Protocol ossification''' is the loss of flexibility, [[extensibility]] and evolvability of [[network protocols]]. This is largely due to [[middlebox]]es that are sensitive to the [[wire image (networking)|wire image]] of the protocol, and which can interrupt or interfere with messages that are valid but which the middlebox does not correctly recognise. This is a violation of the [[end-to-end principle]]. Secondary causes include inflexibility in endpoint implementations of protocols.

Ossification is a major issue in [[Internet]] protocol design and deployment, as it can prevent new protocols or extensions from being deployed on the Internet, or place strictures on the design of new protocols; new protocols may have to be [[encapsulation (networking)|encapsulated]] in an already-deployed protocol or mimic the wire image of another protocol. Because of ossification, the [[Transmission Control Protocol]] (TCP) and [[User Datagram Protocol]] (UDP) are the only practical choices for [[transport protocol]]s on the Internet, and TCP itself has significantly ossified, making extension or modification of the protocol difficult.

Recommended methods of preventing ossification include [[encryption|encrypting]] protocol metadata, and ensuring that extension points are exercised and wire image variability is exhibited as fully as possible; remedying existing ossification requires coordination across protocol participants. [[QUIC]] is the first [[IETF]] transport protocol to have been designed with deliberate anti-ossification properties.

== History ==

Line 24 ⟶ 25:

The primary cause of protocol ossification is [[middlebox]] interference,{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=619}} invalidating the [[end-to-end principle]].{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=620}} 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.{{sfn|Edeline|Donnet|2019|p=171}} Not all middlebox modifications are necessarily ossifying; of those which are potentially harmful, they are disproportionately towards the [[network edge]].{{sfn|Edeline|Donnet|2019|p=173-175}} Middleboxes are deployed by network operators unilaterally to solve specific problems,{{sfn|Edeline|Donnet|2019|p=169}} including performance optimisation, security requirements (e.g., firewalls), [[network address translation]] or enhancing control of networks.{{sfn|Honda|Nishida|Raiciu|Greenhalgh|2011|p=1}} 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]].{{sfn|Edeline|Donnet|2019|p=169}}

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 [[vicious cycle]] as novel [[wire image (networking)|wire images]] cannot gain wide enough deployment to make middleboxes tolerate the new wire image across the entire Internet.{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=620}} Even all participants tolerating the protocol is no guarantee of use: in the absence of a negotiation or discovery mechanism, the endpoints may default to a protocol that is considered more reliable.{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=621}}

Beyond middleboxes, ossification can also be caused by insufficient flexibility within the endpoint's implementation. [[Operating system kernels]] are slow to change and deploy,{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=621}} and protocols implemented in hardware can also inappropriately fix protocol details.{{sfn|Corbet|2015}} A widely- used [[application programming interface|API]] (API) that makes assumptions about the operation of underlying protocols can hinder the deployment of protocols that do not share those assumptions.{{sfn|Papastergiou|Fairhurst|Ros|Brunstrom|2017|p=620}}

== Prevention and remediation ==

Line 59 ⟶ 60:

* [[Hyrum's law]]

* [[Network effect]]

* [[Robustness principle]]

* [[Vendor lock-in]]

Line 76 ⟶ 78:

* {{ cite conference | doi = 10.1145/2068816.2068834 | title = Is It Still Possible to Extend TCP? | date = 2011 | conference = 2011 ACM SIGCOMM Conference on Internet Measurement | last1 = Honda | first1 = Michio | last2 = Nishida | first2 = Yoshifumi | last3 = Raiciu | first3 = Costin | last4 = Greenhalgh | first4 = Adam | last5 = Handley | first5 = Mark | authorlink5 = Mark Handley (computer scientist) | last6 = Tokuda | first6 = Hideyuki }}

* {{ cite conference | url = https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu | title = How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP | date = 2012 | conference = 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12) | last1 = Raiciu | first1 = Costin | last2 = Paasch | first2 = Christoph | last3 = Barre | first3 = Sebastien | last4 = Ford | first4 = Alan | last5 = Honda | first5 = Michio | last6 = Duchene | first6 = Fabien | last7 = Bonaventure | first7 = Olivier | last8 = Handley | first8 = Mark | authorlink8 = Mark Handley (computer scientist) }}

* {{ cite conference | doi = 10.1145/2535828.2535830 | title = Are TCP extensions middlebox-proof? | date = 2013 | conference = HotMiddlebox '13 | last1 = Hesmans | first1 = Benjamin | last2 = Duchene | first2 = Fabien | last3 = Paasch | first3 = Christoph | last4 = Detal | first4 = Gregory | last5 = Bonaventure | first5 = Olivier | citeseerx = 10.1.1.679.6364 }}

* {{ cite web | url = https://lwn.net/Articles/667059/ | title = Checksum offloads and protocol ossification | date = 8 December 2015 | last = Corbet | first = Jonathan | work = [[LWN.net]] }}

* {{ cite web | url = https://lwn.net/Articles/691887/ | title = Transport-level protocols in user space | date = 20 June 2016 | last = Corbet | first = Jonathan | work = [[LWN.net]] }}

Line 82 ⟶ 84:

* {{ cite journal | doi = 10.1109/COMST.2016.2626780 | title = De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives | date = 2017 | journal = [[IEEE Communications Surveys & Tutorials]] | last1 = Papastergiou | first1 = Giorgos | last2 = Fairhurst | first2 = Gorry | last3 = Ros | first3 = David | last4 = Brunstrom | first4 = Anna | last5 = Grinnemo | first5 = Karl-Johan | last6 = Hurtig | first6 = Per | last7 = Khademi | first7 = Naeem | last8 = Tüxen | first8 = Michael | last9 = Welzl | first9 = Michael | last10 = Damjanovic | first10 = Dragana | last11 = Mangiante | first11 = Simone | volume = 19 | pages = 619–639 | hdl = 2164/8317 | s2cid = 1846371 | hdl-access = free }}

* {{Cite web|url=https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/|title=Why TLS 1.3 isn't in browsers yet|date=2017-12-26|website=The Cloudflare Blog|language=en|access-date=2020-03-14|last = Sullivan | first = Nick }}

* {{ cite journal | doi = 10.1145/3211852.3211861 | title = Ex Uno Pluria: The Service-Infrastructure Cycle, Ossification, and the Fragmentation of the Internet | date = January 2018 | last = Ammar | first = Mostafa | journal = [[ACM SIGCOMM Comput. Commun. Rev.]] | s2cid = 12169344 }}

* {{ cite web | url = https://lwn.net/Articles/745590/ | title = QUIC as a solution to protocol ossification | date = 29 January 2018 | last = Corbet | first = Jonathan | work = [[LWN.net]] }}

* {{ cite conference | doi = 10.23919/TMA.2019.8784690 | title = A Bottom-Up Investigation of the Transport-Layer Ossification | date = 2019 | conference = 2019 Network Traffic Measurement and Analysis Conference (TMA) | last1 = Edeline | first1 = Korian | last2 = Donnet | first2 = Benoit }}