Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Protocol ossification
open-in-new
<h2 id="history">History</h2> <p>Significant ossification had set in on the <a href="/facts/Internet/Xw1rVvJU">Internet</a> by 2005, with analyses of the problem also being published in that year;<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a> Ammar (2018) suggests that ossification was a consequence of the Internet attaining global scale and becoming the primary communication network.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> </p><p><a href="/facts/Multipath_TCP/PrTmCrqp">Multipath TCP</a> was the first extension to a core Internet protocol to deeply confront protocol ossification during its design.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> </p><p>The IETF created the Transport Services (taps) working group in 2014.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> It has a mandate to mitigate ossification at the <a href="/facts/Transport_protocol/UmIGUCeK">transport protocol</a> layer.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> </p><p><a href="/facts/QUIC/nQt0oLRW">QUIC</a> is the first <a href="/facts/IETF/tIcCsFhX">IETF</a> transport protocol to deliberately minimise its wire image to avoid ossification.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> </p><p>The <a href="/facts/Internet_Architecture_Board/JV2M6FNP">Internet Architecture Board</a> identified design considerations around the exposure of protocol information to network elements as a "developing field" in 2023.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> </p> <h2 id="causes">Causes</h2> <p>The primary cause of protocol ossification is <a href="/facts/Middlebox/NQTBjrDr">middlebox</a> interference,<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> invalidating the <a href="/facts/End-to-end_principle/6RkKmdUm">end-to-end principle</a>.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> 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.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> Not all middlebox modifications are necessarily ossifying; of those which are potentially harmful, they are disproportionately towards the network edge.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> Middleboxes are deployed by network operators unilaterally to solve specific problems,<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> including performance optimisation, security requirements (e.g., firewalls), <a href="/facts/Network_address_translation/nFweFNfN">network address translation</a> or enhancing control of networks.<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a> These middlebox deployments provide localised short-term utility but degrade the global long-term evolvability of the Internet in a manifestation of the <a href="/facts/Tragedy_of_the_commons/ctXVyh8r">tragedy of the commons</a>.<a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a> </p><p>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 <a href="/facts/Vicious_cycle/jGAJzfQX">vicious cycle</a> as novel <a href="/facts/Wire_image_(networking)/jkWl9TzV">wire images</a> cannot gain wide enough deployment to make middleboxes tolerate the new wire image across the entire Internet.<a class="footnote-ref" id="fnref:15" href="#fn:15"><sup>15</sup></a> 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.<a class="footnote-ref" id="fnref:16" href="#fn:16"><sup>16</sup></a> </p><p>Beyond middleboxes, ossification can also be caused by insufficient flexibility within the endpoint's implementation. <a href="/facts/Operating_system_kernels/uEj4U3Rz">Operating system kernels</a> are slow to change and deploy,<a class="footnote-ref" id="fnref:17" href="#fn:17"><sup>17</sup></a> and protocols implemented in hardware can also inappropriately fix protocol details.<a class="footnote-ref" id="fnref:18" href="#fn:18"><sup>18</sup></a> A widely-used <a href="/facts/Application_programming_interface/GMlN4vUr">application programming interface</a> (API) that makes assumptions about the operation of underlying protocols can hinder the deployment of protocols that do not share those assumptions.<a class="footnote-ref" id="fnref:19" href="#fn:19"><sup>19</sup></a> </p> <h2 id="prevention-and-remediation">Prevention and remediation</h2> <p>The <a href="/facts/Internet_Architecture_Board/JV2M6FNP">Internet Architecture Board</a> 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 <a href="/facts/Message_authentication/0B6FG1bV">integrity protected</a> so that it cannot be modified by middleboxes.<a class="footnote-ref" id="fnref:20" href="#fn:20"><sup>20</sup></a> 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.<a class="footnote-ref" id="fnref:21" href="#fn:21"><sup>21</sup></a> Network operators use metadata for a variety of benign management purposes,<a class="footnote-ref" id="fnref:22" href="#fn:22"><sup>22</sup></a> and Internet research is also informed by data gathered from protocol metadata;<a class="footnote-ref" id="fnref:23" href="#fn:23"><sup>23</sup></a> a protocol's designer must balance ossification resistance against observability for operational or research needs.<a class="footnote-ref" id="fnref:24" href="#fn:24"><sup>24</sup></a> Arkko et al. (2023) provides further guidance on these considerations: disclosure of information by a protocol to the network should be intentional,<a class="footnote-ref" id="fnref:25" href="#fn:25"><sup>25</sup></a> performed with the agreement of both recipient and sender,<a class="footnote-ref" id="fnref:26" href="#fn:26"><sup>26</sup></a> authenticated to the degree possible and necessary,<a class="footnote-ref" id="fnref:27" href="#fn:27"><sup>27</sup></a> only acted upon to the degree of its trustworthiness,<a class="footnote-ref" id="fnref:28" href="#fn:28"><sup>28</sup></a> and minimised and provided to a minimum number of entities.<a class="footnote-ref" id="fnref:29" href="#fn:29"><sup>29</sup></a><a class="footnote-ref" id="fnref:30" href="#fn:30"><sup>30</sup></a> </p><p>Active use of extension points is required if they are not to ossify.<a class="footnote-ref" id="fnref:31" href="#fn:31"><sup>31</sup></a> Reducing the number of extension points, documenting invariants that protocol participants can rely on as opposed to incidental details that must not be relied upon, and prompt detection of issues in deployed systems can assist in ensuring active use.<a class="footnote-ref" id="fnref:32" href="#fn:32"><sup>32</sup></a> However, even active use may only exercise a narrow portion of the protocol and ossification can still occur in the parts that remain invariant in practice despite theoretical variability.<a class="footnote-ref" id="fnref:33" href="#fn:33"><sup>33</sup></a><a class="footnote-ref" id="fnref:34" href="#fn:34"><sup>34</sup></a> "Greasing" an extension point, where some implementations indicate support for non-existent extensions, can ensure that actually-existent-but-unrecognised extensions are tolerated (cf. <a href="/facts/Chaos_engineering/7A6L9qoA">chaos engineering</a>).<a class="footnote-ref" id="fnref:35" href="#fn:35"><sup>35</sup></a> <a href="/facts/HTTP_headers/hEkcQe2f">HTTP headers</a> are an example of an extension point that has successfully avoided significant ossification, as participants will generally ignore unrecognised headers.<a class="footnote-ref" id="fnref:36" href="#fn:36"><sup>36</sup></a> </p><p>A new protocol may be designed to mimic the wire image of an existing ossified protocol;<a class="footnote-ref" id="fnref:37" href="#fn:37"><sup>37</sup></a> alternatively, a new protocol may be <a href="/facts/Encapsulation_(networking)/xttAQnu0">encapsulated</a> 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).<a class="footnote-ref" id="fnref:38" href="#fn:38"><sup>38</sup></a> </p><p>Besides middleboxes, other sources of ossification can also be resisted. <a href="/facts/User-space/0yIzMY8t">User-space</a> implementation of protocols can lead to more rapid evolution. If the new protocol is encapsulated in UDP, then user-space implementation is possible.<a class="footnote-ref" id="fnref:39" href="#fn:39"><sup>39</sup></a><a class="footnote-ref" id="fnref:40" href="#fn:40"><sup>40</sup></a> Where support for protocols is uncertain, participants may simultaneously try alternative protocols, at the cost of increasing the amount of data sent.<a class="footnote-ref" id="fnref:41" href="#fn:41"><sup>41</sup></a> </p><p>With sufficient effort and coordination, ossification can be directly reversed. A <a href="/facts/Flag_day_(computing)/EIJcGtvK">flag day</a>, where protocol participants make changes in concert, can break the vicious cycle and establish active use. This approach was used to deploy <a href="/facts/EDNS/KUKTkVtx">EDNS</a>, which had formerly not been tolerated by servers.<a class="footnote-ref" id="fnref:42" href="#fn:42"><sup>42</sup></a> </p> <h2 id="examples">Examples</h2> <p>The <a href="/facts/Transmission_Control_Protocol/WW4sPrt9">Transmission Control Protocol</a> has suffered from ossification.<a class="footnote-ref" id="fnref:43" href="#fn:43"><sup>43</sup></a> One measurement found that a third of paths across the Internet encounter at least one intermediary that modifies TCP metadata, and 6.5% of paths encounter harmful ossifying effects from intermediaries.<a class="footnote-ref" id="fnref:44" href="#fn:44"><sup>44</sup></a> Extensions to TCP have been affected: the design of <a href="/facts/MPTCP/PrTmCrqp">MPTCP</a> was constrained by middlebox behaviour,<a class="footnote-ref" id="fnref:45" href="#fn:45"><sup>45</sup></a><a class="footnote-ref" id="fnref:46" href="#fn:46"><sup>46</sup></a> and the deployment of <a href="/facts/TCP_Fast_Open/CdHx00Es">TCP Fast Open</a> has been likewise hindered.<a class="footnote-ref" id="fnref:47" href="#fn:47"><sup>47</sup></a><a class="footnote-ref" id="fnref:48" href="#fn:48"><sup>48</sup></a> </p><p>The <a href="/facts/Stream_Control_Transmission_Protocol/s8tmzUhz">Stream Control Transmission Protocol</a> has been little-deployed on the Internet due to intolerance from middleboxes,<a class="footnote-ref" id="fnref:49" href="#fn:49"><sup>49</sup></a> and also due to the very widespread <a href="/facts/BSD_sockets_API/edRVDP8C">BSD sockets API</a> ill-fitting its capabilities.<a class="footnote-ref" id="fnref:50" href="#fn:50"><sup>50</sup></a> In practice, TCP and UDP are the only usable Internet <a href="/facts/Transport_protocol/UmIGUCeK">transport protocols</a>.<a class="footnote-ref" id="fnref:51" href="#fn:51"><sup>51</sup></a> </p><p><a href="/facts/Transport_Layer_Security/pGy16TnA">Transport Layer Security</a> (TLS) has experienced ossification. TLS was the original context for the introduction of greasing extension points. <a href="/facts/TLS_1.3/pGy16TnA">TLS 1.3</a>, as originally designed, proved undeployable on the Internet: middleboxes had ossified the protocol's version parameter. This was discovered late in the protocol design process, during experimental deployments by <a href="/facts/Web_browsers/2pfyymLs">web browsers</a>. As a result, version 1.3 mimics the wire image of version 1.2.<a class="footnote-ref" id="fnref:52" href="#fn:52"><sup>52</sup></a> </p><p><a href="/facts/QUIC/nQt0oLRW">QUIC</a> has been specifically designed to be deployable, evolvable and to have anti-ossification properties;<a class="footnote-ref" id="fnref:53" href="#fn:53"><sup>53</sup></a> it is the first <a href="/facts/IETF/tIcCsFhX">IETF</a> transport protocol to deliberately minimise its wire image for these ends.<a class="footnote-ref" id="fnref:54" href="#fn:54"><sup>54</sup></a> It is greased,<a class="footnote-ref" id="fnref:55" href="#fn:55"><sup>55</sup></a> it has protocol invariants explicitly specified,<a class="footnote-ref" id="fnref:56" href="#fn:56"><sup>56</sup></a> it is encapsulated in UDP, and its protocol metadata is encrypted.<a class="footnote-ref" id="fnref:57" href="#fn:57"><sup>57</sup></a> Still, applications using QUIC must be prepared to fall back to other protocols, as UDP is blocked by some middleboxes.<a class="footnote-ref" id="fnref:58" href="#fn:58"><sup>58</sup></a> </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Backward_compatibility/FbHFBu5y">Backward compatibility</a></li> <li><a href="/facts/Collective_action_problem/Bxvbeas7">Collective action problem</a></li> <li><a href="/facts/De_facto_standard/TRELHVwI"><i>De facto</i> standard</a></li> <li><a href="/facts/Forward_compatibility/EvGkMPCm">Forward compatibility</a></li> <li><a href="/facts/Interoperability/7WgqUbXU">Interoperability</a></li> <li><a href="/facts/Hyrum%27s_law/GMlN4vUr">Hyrum's law</a></li> <li><a href="/facts/Network_effect/IvxIDA2d">Network effect</a></li> <li><a href="/facts/Robustness_principle/Mw0PygBF">Robustness principle</a></li> <li><a href="/facts/Vendor_lock-in/BLndHDVl">Vendor lock-in</a></li></ul> <h2 id="bibliography">Bibliography</h2> <ul><li>Trammell, Brian; Kuehlewind, Mirja (April 2019). <a href="https://datatracker.ietf.org/doc/html/rfc8546"><i>The Wire Image of a Network Protocol</i></a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.17487%2FRFC8546">10.17487/RFC8546</a>. <a href="/facts/Request_for_Comments/esftTvE7">RFC</a> <a href="https://datatracker.ietf.org/doc/html/rfc8546">8546</a>.</li> <li>Hardie, Ted, ed. (April 2019). <a href="https://datatracker.ietf.org/doc/html/rfc8558"><i>Transport Protocol Path Signals</i></a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.17487%2FRFC8558">10.17487/RFC8558</a>. <a href="/facts/Request_for_Comments/esftTvE7">RFC</a> <a href="https://datatracker.ietf.org/doc/html/rfc8558">8558</a>.</li> <li>Thomson, Martin (May 2021). <a href="https://datatracker.ietf.org/doc/html/rfc8999"><i>Version-Independent Properties of QUIC</i></a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.17487%2FRFC8999">10.17487/RFC8999</a>. <a href="/facts/Request_for_Comments/esftTvE7">RFC</a> <a href="https://datatracker.ietf.org/doc/html/rfc8999">8999</a>.</li> <li>Fairhurst, Gorry; Perkins, Colin (July 2021). <a href="https://datatracker.ietf.org/doc/html/rfc9065"><i>Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols</i></a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.17487%2FRFC9065">10.17487/RFC9065</a>. <a href="/facts/Request_for_Comments/esftTvE7">RFC</a> <a href="https://datatracker.ietf.org/doc/html/rfc9065">9065</a>.</li> <li>Thomson, Martin; Pauly, Tommy (December 2021). <a href="https://datatracker.ietf.org/doc/html/rfc9170"><i>Long-Term Viability of Protocol Extension Mechanisms</i></a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.17487%2FRFC9170">10.17487/RFC9170</a>. <a href="/facts/Request_for_Comments/esftTvE7">RFC</a> <a href="https://datatracker.ietf.org/doc/html/rfc9170">9170</a>.</li> <li>Kühlewind, Mirja; Trammell, Brian (September 2022). <a href="https://datatracker.ietf.org/doc/html/rfc9308"><i>Applicability of the QUIC Transport Protocol</i></a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.17487%2FRFC9308">10.17487/RFC9308</a>. <a href="/facts/Request_for_Comments/esftTvE7">RFC</a> <a href="https://datatracker.ietf.org/doc/html/rfc9308">9308</a>.</li> <li>Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). <a href="https://datatracker.ietf.org/doc/html/rfc9419"><i>Considerations on Application - Network Collaboration Using Path Signals</i></a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.17487%2FRFC9419">10.17487/RFC9419</a>. <a href="/facts/Request_for_Comments/esftTvE7">RFC</a> <a href="https://datatracker.ietf.org/doc/html/rfc9419">9419</a>.</li> <li>Honda, Michio; Nishida, Yoshifumi; Raiciu, Costin; Greenhalgh, Adam; <a href="/facts/Mark_Handley_(computer_scientist)/HpMbLTBq">Handley, Mark</a>; Tokuda, Hideyuki (2011). <i>Is It Still Possible to Extend TCP?</i>. 2011 ACM SIGCOMM Conference on Internet Measurement. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F2068816.2068834">10.1145/2068816.2068834</a>.</li> <li>Raiciu, Costin; Paasch, Christoph; Barre, Sebastien; Ford, Alan; Honda, Michio; Duchene, Fabien; Bonaventure, Olivier; <a href="/facts/Mark_Handley_(computer_scientist)/HpMbLTBq">Handley, Mark</a> (2012). <a href="https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu"><i>How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP</i></a>. 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12).</li> <li>Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). <i>Are TCP extensions middlebox-proof?</i>. HotMiddlebox '13. <a href="/facts/CiteSeerX_(identifier)/SceDmd3c">CiteSeerX</a> <a href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.679.6364">10.1.1.679.6364</a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F2535828.2535830">10.1145/2535828.2535830</a>.</li> <li>Corbet, Jonathan (8 December 2015). <a href="https://lwn.net/Articles/667059/">"Checksum offloads and protocol ossification"</a>. <i><a href="/facts/LWN.net/8uTsltvM">LWN.net</a></i>.</li> <li>Corbet, Jonathan (20 June 2016). <a href="https://lwn.net/Articles/691887/">"Transport-level protocols in user space"</a>. <i><a href="/facts/LWN.net/8uTsltvM">LWN.net</a></i>.</li> <li>McQuistin, Stephen; Perkins, Colin; Fayed, Marwan (July 2016). <i>Implementing Real-Time Transport Services over an Ossified Network</i>. 2016 Applied Networking Research Workshop. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F2959424.2959443">10.1145/2959424.2959443</a>. <a href="/facts/Hdl_(identifier)/rdebSxmC">hdl</a>:<a href="https://hdl.handle.net/1893%2F26111">1893/26111</a>.</li> <li>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". <i><a href="/facts/IEEE_Communications_Surveys_%26_Tutorials/ePJz0rHD">IEEE Communications Surveys & Tutorials</a></i>. 19: 619–639. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1109%2FCOMST.2016.2626780">10.1109/COMST.2016.2626780</a>. <a href="/facts/Hdl_(identifier)/rdebSxmC">hdl</a>:<a href="https://hdl.handle.net/2164%2F8317">2164/8317</a>. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:1846371">1846371</a>.</li> <li>Sullivan, Nick (2017-12-26). <a href="https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/">"Why TLS 1.3 isn't in browsers yet"</a>. <i>The Cloudflare Blog</i>. Retrieved 2020-03-14.</li> <li>Ammar, Mostafa (January 2018). "Ex Uno Pluria: The Service-Infrastructure Cycle, Ossification, and the Fragmentation of the Internet". <i>ACM SIGCOMM Comput. Commun. Rev.</i> <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F3211852.3211861">10.1145/3211852.3211861</a>. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:12169344">12169344</a>.</li> <li>Corbet, Jonathan (29 January 2018). <a href="https://lwn.net/Articles/745590/">"QUIC as a solution to protocol ossification"</a>. <i><a href="/facts/LWN.net/8uTsltvM">LWN.net</a></i>.</li> <li>Edeline, Korian; Donnet, Benoit (2019). <i>A Bottom-Up Investigation of the Transport-Layer Ossification</i>. 2019 Network Traffic Measurement and Analysis Conference (TMA). <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.23919%2FTMA.2019.8784690">10.23919/TMA.2019.8784690</a>.</li> <li>Rybczyńska, Marta (13 March 2020). <a href="https://lwn.net/Articles/814522/">"A QUIC look at HTTP/3"</a>. <i><a href="/facts/LWN.net/8uTsltvM">LWN.net</a></i>.</li></ul> <h2 id="further-reading">Further reading</h2> <ul><li>Trammell, Brian; Kuehlewind, Mirja, eds. (October 2015). <a href="https://datatracker.ietf.org/doc/html/rfc7663"><i>Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)</i></a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.17487%2FRFC7663">10.17487/RFC7663</a>. <a href="/facts/Request_for_Comments/esftTvE7">RFC</a> <a href="https://datatracker.ietf.org/doc/html/rfc7663">7663</a>.</li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>Ammar 2018, p. 57-58. - Ammar, Mostafa (January 2018). "Ex Uno Pluria: The Service-Infrastructure Cycle, Ossification, and the Fragmentation of the Internet". ACM SIGCOMM Comput. Commun. Rev. doi:10.1145/3211852.3211861. S2CID 12169344. <a href="https://doi.org/10.1145%2F3211852.3211861" target="_blank">https://doi.org/10.1145%2F3211852.3211861</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>Ammar 2018, p. 59. - Ammar, Mostafa (January 2018). "Ex Uno Pluria: The Service-Infrastructure Cycle, Ossification, and the Fragmentation of the Internet". ACM SIGCOMM Comput. Commun. Rev. doi:10.1145/3211852.3211861. S2CID 12169344. <a href="https://doi.org/10.1145%2F3211852.3211861" target="_blank">https://doi.org/10.1145%2F3211852.3211861</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Raiciu et al. 2012, p. 1. - 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). <a href="https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu" target="_blank">https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>"Transport Services (taps) – Group history". IETF. <a href="https://datatracker.ietf.org/wg/taps/history/" target="_blank">https://datatracker.ietf.org/wg/taps/history/</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>"Transport Services – charter-ietf-taps-02". IETF. <a href="https://datatracker.ietf.org/doc/charter-ietf-taps/" target="_blank">https://datatracker.ietf.org/doc/charter-ietf-taps/</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Trammell & Kuehlewind 2019, p. 2. - Trammell, Brian; Kuehlewind, Mirja (April 2019). The Wire Image of a Network Protocol. doi:10.17487/RFC8546. RFC 8546. <a href="https://datatracker.ietf.org/doc/html/rfc8546" target="_blank">https://datatracker.ietf.org/doc/html/rfc8546</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Arkko et al. 2023, 3. Further Work. - Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). Considerations on Application - Network Collaboration Using Path Signals. doi:10.17487/RFC9419. RFC 9419. <a href="https://datatracker.ietf.org/doc/html/rfc9419" target="_blank">https://datatracker.ietf.org/doc/html/rfc9419</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>Papastergiou et al. 2017, p. 619. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>Papastergiou et al. 2017, p. 620. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>Edeline & Donnet 2019, p. 171. - Edeline, Korian; Donnet, Benoit (2019). A Bottom-Up Investigation of the Transport-Layer Ossification. 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:10.23919/TMA.2019.8784690. <a href="https://doi.org/10.23919%2FTMA.2019.8784690" target="_blank">https://doi.org/10.23919%2FTMA.2019.8784690</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>Edeline & Donnet 2019, p. 173-175. - Edeline, Korian; Donnet, Benoit (2019). A Bottom-Up Investigation of the Transport-Layer Ossification. 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:10.23919/TMA.2019.8784690. <a href="https://doi.org/10.23919%2FTMA.2019.8784690" target="_blank">https://doi.org/10.23919%2FTMA.2019.8784690</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>Edeline & Donnet 2019, p. 169. - Edeline, Korian; Donnet, Benoit (2019). A Bottom-Up Investigation of the Transport-Layer Ossification. 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:10.23919/TMA.2019.8784690. <a href="https://doi.org/10.23919%2FTMA.2019.8784690" target="_blank">https://doi.org/10.23919%2FTMA.2019.8784690</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>Honda et al. 2011, p. 1. - Honda, Michio; Nishida, Yoshifumi; Raiciu, Costin; Greenhalgh, Adam; Handley, Mark; Tokuda, Hideyuki (2011). Is It Still Possible to Extend TCP?. 2011 ACM SIGCOMM Conference on Internet Measurement. doi:10.1145/2068816.2068834. <a href="https://doi.org/10.1145%2F2068816.2068834" target="_blank">https://doi.org/10.1145%2F2068816.2068834</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>Edeline & Donnet 2019, p. 169. - Edeline, Korian; Donnet, Benoit (2019). A Bottom-Up Investigation of the Transport-Layer Ossification. 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:10.23919/TMA.2019.8784690. <a href="https://doi.org/10.23919%2FTMA.2019.8784690" target="_blank">https://doi.org/10.23919%2FTMA.2019.8784690</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> <li id="fn:15"><p>Papastergiou et al. 2017, p. 620. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></p></li> <li id="fn:16"><p>Papastergiou et al. 2017, p. 621. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></p></li> <li id="fn:17"><p>Papastergiou et al. 2017, p. 621. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></p></li> <li id="fn:18"><p>Corbet 2015. - Corbet, Jonathan (8 December 2015). "Checksum offloads and protocol ossification". LWN.net. <a href="https://lwn.net/Articles/667059/" target="_blank">https://lwn.net/Articles/667059/</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></p></li> <li id="fn:19"><p>Papastergiou et al. 2017, p. 620. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></p></li> <li id="fn:20"><p>Hardie 2019, p. 7-8. - Hardie, Ted, ed. (April 2019). Transport Protocol Path Signals. doi:10.17487/RFC8558. RFC 8558. <a href="https://datatracker.ietf.org/doc/html/rfc8558" target="_blank">https://datatracker.ietf.org/doc/html/rfc8558</a> <a href="#fnref:20" class="footnote-back-ref">↩</a></p></li> <li id="fn:21"><p>Fairhurst & Perkins 2021, 7. Conclusions. - Fairhurst, Gorry; Perkins, Colin (July 2021). Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols. doi:10.17487/RFC9065. RFC 9065. <a href="https://datatracker.ietf.org/doc/html/rfc9065" target="_blank">https://datatracker.ietf.org/doc/html/rfc9065</a> <a href="#fnref:21" class="footnote-back-ref">↩</a></p></li> <li id="fn:22"><p>Fairhurst & Perkins 2021, 2. Current Uses of Transport Headers within the Network. - Fairhurst, Gorry; Perkins, Colin (July 2021). Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols. doi:10.17487/RFC9065. RFC 9065. <a href="https://datatracker.ietf.org/doc/html/rfc9065" target="_blank">https://datatracker.ietf.org/doc/html/rfc9065</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></p></li> <li id="fn:23"><p>Fairhurst & Perkins 2021, 3. Research, Development, and Deployment. - Fairhurst, Gorry; Perkins, Colin (July 2021). Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols. doi:10.17487/RFC9065. RFC 9065. <a href="https://datatracker.ietf.org/doc/html/rfc9065" target="_blank">https://datatracker.ietf.org/doc/html/rfc9065</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></p></li> <li id="fn:24"><p>Fairhurst & Perkins 2021, 7. Conclusions. - Fairhurst, Gorry; Perkins, Colin (July 2021). Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols. doi:10.17487/RFC9065. RFC 9065. <a href="https://datatracker.ietf.org/doc/html/rfc9065" target="_blank">https://datatracker.ietf.org/doc/html/rfc9065</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></p></li> <li id="fn:25"><p>Arkko et al. 2023, 2.1. Intentional Distribution. - Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). Considerations on Application - Network Collaboration Using Path Signals. doi:10.17487/RFC9419. RFC 9419. <a href="https://datatracker.ietf.org/doc/html/rfc9419" target="_blank">https://datatracker.ietf.org/doc/html/rfc9419</a> <a href="#fnref:25" class="footnote-back-ref">↩</a></p></li> <li id="fn:26"><p>Arkko et al. 2023, 2.2. Control of the Distribution of Information. - Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). Considerations on Application - Network Collaboration Using Path Signals. doi:10.17487/RFC9419. RFC 9419. <a href="https://datatracker.ietf.org/doc/html/rfc9419" target="_blank">https://datatracker.ietf.org/doc/html/rfc9419</a> <a href="#fnref:26" class="footnote-back-ref">↩</a></p></li> <li id="fn:27"><p>Arkko et al. 2023, 2.3. Protecting Information and Authentication. - Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). Considerations on Application - Network Collaboration Using Path Signals. doi:10.17487/RFC9419. RFC 9419. <a href="https://datatracker.ietf.org/doc/html/rfc9419" target="_blank">https://datatracker.ietf.org/doc/html/rfc9419</a> <a href="#fnref:27" class="footnote-back-ref">↩</a></p></li> <li id="fn:28"><p>Arkko et al. 2023, 2.5. Limiting Impact of Information. - Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). Considerations on Application - Network Collaboration Using Path Signals. doi:10.17487/RFC9419. RFC 9419. <a href="https://datatracker.ietf.org/doc/html/rfc9419" target="_blank">https://datatracker.ietf.org/doc/html/rfc9419</a> <a href="#fnref:28" class="footnote-back-ref">↩</a></p></li> <li id="fn:29"><p>Arkko et al. 2023, 2.4. Minimize Information. - Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). Considerations on Application - Network Collaboration Using Path Signals. doi:10.17487/RFC9419. RFC 9419. <a href="https://datatracker.ietf.org/doc/html/rfc9419" target="_blank">https://datatracker.ietf.org/doc/html/rfc9419</a> <a href="#fnref:29" class="footnote-back-ref">↩</a></p></li> <li id="fn:30"><p>Arkko et al. 2023, 2.6. Minimum Set of Entities. - Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (July 2023). Considerations on Application - Network Collaboration Using Path Signals. doi:10.17487/RFC9419. RFC 9419. <a href="https://datatracker.ietf.org/doc/html/rfc9419" target="_blank">https://datatracker.ietf.org/doc/html/rfc9419</a> <a href="#fnref:30" class="footnote-back-ref">↩</a></p></li> <li id="fn:31"><p>Thomson & Pauly 2021, 3. Active Use. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:31" class="footnote-back-ref">↩</a></p></li> <li id="fn:32"><p>Thomson & Pauly 2021, 4. Complementary Techniques. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:32" class="footnote-back-ref">↩</a></p></li> <li id="fn:33"><p>Thomson & Pauly 2021, 3.1. Dependency Is Better. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:33" class="footnote-back-ref">↩</a></p></li> <li id="fn:34"><p>Trammell & Kuehlewind 2019, p. 7. - Trammell, Brian; Kuehlewind, Mirja (April 2019). The Wire Image of a Network Protocol. doi:10.17487/RFC8546. RFC 8546. <a href="https://datatracker.ietf.org/doc/html/rfc8546" target="_blank">https://datatracker.ietf.org/doc/html/rfc8546</a> <a href="#fnref:34" class="footnote-back-ref">↩</a></p></li> <li id="fn:35"><p>Thomson & Pauly 2021, 3.3. Falsifying Active Use. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:35" class="footnote-back-ref">↩</a></p></li> <li id="fn:36"><p>Thomson & Pauly 2021, 3.4. Examples of Active Use. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:36" class="footnote-back-ref">↩</a></p></li> <li id="fn:37"><p>Papastergiou et al. 2017, p. 623. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:37" class="footnote-back-ref">↩</a></p></li> <li id="fn:38"><p>Papastergiou et al. 2017, p. 623-4. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:38" class="footnote-back-ref">↩</a></p></li> <li id="fn:39"><p>Papastergiou et al. 2017, p. 630. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:39" class="footnote-back-ref">↩</a></p></li> <li id="fn:40"><p>Corbet 2016. - Corbet, Jonathan (20 June 2016). "Transport-level protocols in user space". LWN.net. <a href="https://lwn.net/Articles/691887/" target="_blank">https://lwn.net/Articles/691887/</a> <a href="#fnref:40" class="footnote-back-ref">↩</a></p></li> <li id="fn:41"><p>Papastergiou et al. 2017, p. 629. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:41" class="footnote-back-ref">↩</a></p></li> <li id="fn:42"><p>Thomson & Pauly 2021, 3.5. Restoring Active Use. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:42" class="footnote-back-ref">↩</a></p></li> <li id="fn:43"><p>Thomson & Pauly 2021, A.5. TCP. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:43" class="footnote-back-ref">↩</a></p></li> <li id="fn:44"><p>Edeline & Donnet 2019, p. 175-176. - Edeline, Korian; Donnet, Benoit (2019). A Bottom-Up Investigation of the Transport-Layer Ossification. 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:10.23919/TMA.2019.8784690. <a href="https://doi.org/10.23919%2FTMA.2019.8784690" target="_blank">https://doi.org/10.23919%2FTMA.2019.8784690</a> <a href="#fnref:44" class="footnote-back-ref">↩</a></p></li> <li id="fn:45"><p>Raiciu et al. 2012, p. 1. - 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). <a href="https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu" target="_blank">https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu</a> <a href="#fnref:45" class="footnote-back-ref">↩</a></p></li> <li id="fn:46"><p>Hesmans et al. 2013, p. 1. - Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). Are TCP extensions middlebox-proof?. HotMiddlebox '13. CiteSeerX 10.1.1.679.6364. doi:10.1145/2535828.2535830. <a href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.679.6364" target="_blank">https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.679.6364</a> <a href="#fnref:46" class="footnote-back-ref">↩</a></p></li> <li id="fn:47"><p>Rybczyńska 2020. - Rybczyńska, Marta (13 March 2020). "A QUIC look at HTTP/3". LWN.net. <a href="https://lwn.net/Articles/814522/" target="_blank">https://lwn.net/Articles/814522/</a> <a href="#fnref:47" class="footnote-back-ref">↩</a></p></li> <li id="fn:48"><p>Thomson & Pauly 2021, A.5. TCP. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:48" class="footnote-back-ref">↩</a></p></li> <li id="fn:49"><p>Papastergiou et al. 2017, p. 620. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:49" class="footnote-back-ref">↩</a></p></li> <li id="fn:50"><p>Papastergiou et al. 2017, p. 627. - 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". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. S2CID 1846371. <a href="https://doi.org/10.1109%2FCOMST.2016.2626780" target="_blank">https://doi.org/10.1109%2FCOMST.2016.2626780</a> <a href="#fnref:50" class="footnote-back-ref">↩</a></p></li> <li id="fn:51"><p>McQuistin, Perkins & Fayed 2016, p. 1. - McQuistin, Stephen; Perkins, Colin; Fayed, Marwan (July 2016). Implementing Real-Time Transport Services over an Ossified Network. 2016 Applied Networking Research Workshop. doi:10.1145/2959424.2959443. hdl:1893/26111. <a href="https://doi.org/10.1145%2F2959424.2959443" target="_blank">https://doi.org/10.1145%2F2959424.2959443</a> <a href="#fnref:51" class="footnote-back-ref">↩</a></p></li> <li id="fn:52"><p>Sullivan 2017. - Sullivan, Nick (2017-12-26). "Why TLS 1.3 isn't in browsers yet". The Cloudflare Blog. Retrieved 2020-03-14. <a href="https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/" target="_blank">https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/</a> <a href="#fnref:52" class="footnote-back-ref">↩</a></p></li> <li id="fn:53"><p>Corbet 2018. - Corbet, Jonathan (29 January 2018). "QUIC as a solution to protocol ossification". LWN.net. <a href="https://lwn.net/Articles/745590/" target="_blank">https://lwn.net/Articles/745590/</a> <a href="#fnref:53" class="footnote-back-ref">↩</a></p></li> <li id="fn:54"><p>Trammell & Kuehlewind 2019, p. 2. - Trammell, Brian; Kuehlewind, Mirja (April 2019). The Wire Image of a Network Protocol. doi:10.17487/RFC8546. RFC 8546. <a href="https://datatracker.ietf.org/doc/html/rfc8546" target="_blank">https://datatracker.ietf.org/doc/html/rfc8546</a> <a href="#fnref:54" class="footnote-back-ref">↩</a></p></li> <li id="fn:55"><p>Thomson & Pauly 2021, 3.3. Falsifying Active Use. - Thomson, Martin; Pauly, Tommy (December 2021). Long-Term Viability of Protocol Extension Mechanisms. doi:10.17487/RFC9170. RFC 9170. <a href="https://datatracker.ietf.org/doc/html/rfc9170" target="_blank">https://datatracker.ietf.org/doc/html/rfc9170</a> <a href="#fnref:55" class="footnote-back-ref">↩</a></p></li> <li id="fn:56"><p>Thomson 2021, 2. Fixed Properties of All QUIC Versions. - Thomson, Martin (May 2021). Version-Independent Properties of QUIC. doi:10.17487/RFC8999. RFC 8999. <a href="https://datatracker.ietf.org/doc/html/rfc8999" target="_blank">https://datatracker.ietf.org/doc/html/rfc8999</a> <a href="#fnref:56" class="footnote-back-ref">↩</a></p></li> <li id="fn:57"><p>Corbet 2018. - Corbet, Jonathan (29 January 2018). "QUIC as a solution to protocol ossification". LWN.net. <a href="https://lwn.net/Articles/745590/" target="_blank">https://lwn.net/Articles/745590/</a> <a href="#fnref:57" class="footnote-back-ref">↩</a></p></li> <li id="fn:58"><p>Kühlewind & Trammell 2022, 2. The Necessity of Fallback. - Kühlewind, Mirja; Trammell, Brian (September 2022). Applicability of the QUIC Transport Protocol. doi:10.17487/RFC9308. RFC 9308. <a href="https://datatracker.ietf.org/doc/html/rfc9308" target="_blank">https://datatracker.ietf.org/doc/html/rfc9308</a> <a href="#fnref:58" class="footnote-back-ref">↩</a></p></li> </ol>