Initial commit of Path MTU protoXEP

This commit is contained in:
Kim Alvefur 2022-10-19 14:53:32 +02:00 committed by Jonas Schäfer
parent 7eaa3962a8
commit 958aad87ab
1 changed files with 193 additions and 0 deletions

193
inbox/pathmtu.xml Normal file
View File

@ -0,0 +1,193 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep><header>
<title>Stanza size limit discovery</title>
<abstract>This documents describes a mechanism for communicating stanza size limits across streams in order to help avoid reaching those limits.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies/>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Kim</firstname>
<surname>Alvefur</surname>
<email>zash@zash.se</email>
<jid>zash@zash.se</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2021-08-20</date>
<initials>ka</initials>
<remark>
<p>Early draft</p>
</remark>
</revision>
<revision>
<version>nil</version>
<date>2021-08-25</date>
<initials>ka</initials>
<remark>
<p>more work</p>
</remark>
</revision>
<revision>
<version>nil</version>
<date>2021-08-28</date>
<initials>ka</initials>
<remark>
<p>more words</p>
</remark>
</revision>
</header>
<section1 topic="Introduction" anchor="intro">
<p>This documents describes a mechanism for communicating the stanza size
limit that is in effect on a particular stream, in order to allow the
other party to avoid reaching those limits.</p>
<section2 topic="Problem statement" anchor="problem-statement">
<p>When stanza size limits have been deployed, very often this leads to
problems with large stanzas causing connection outages, most often
vCards and Avatar stanzas.</p>
<p>If stanza size limit violations are met with stream errors then this may
lead to temporary connection outage, which may a few seconds to recover
from.</p>
<p>Especially vCard and Avatar stanzas may be very large and sometimes
exceed the stanza size limit imposed.</p>
</section2></section1><section1 topic="Requirements" anchor="reqs">
<ul>
<li>Enable discovery of the stanza size limit in use on a stream.</li>
</ul>
<section2 topic="TODO" anchor="todo">
<ul>
<li>bi-directional?</li>
<li>disco too?</li>
<li>some sort of path mtu discovery method?</li>
<li>error condition?</li>
<li>rewrite large iq-result to error?</li>
</ul>
</section2></section1><section1 topic="Glossary" anchor="glossary">
<p>OPTIONAL.</p>
</section1><section1 topic="Use Cases" anchor="usecases">
<ul>
<li>An XMPP client could attempt to apply more compression if it sees
that an avatar it is about to upload would be too large.</li>
<li>A PubSub server could limit the number of items in an <tt>&lt;items/&gt;</tt>
query to ensure it can be delivered.</li>
</ul>
</section1><section1 topic="Business Rules" anchor="rules">
<p>If after serialization to XML a stanza is too large, like, dont send
it. Synthesize an error condition, most likely a (modify,
policy-violation), and pretend the remote entity replied with this.</p>
</section1><section1 topic="Implementation Notes" anchor="impl">
<p>Something about margins, due to variations in XML serialization, added
attributes (e.g. the <tt>from</tt> attribute stamped by servers) or elements
(delay tags)</p>
<p>Because the stanza size limit is known ahead of time, entities can check
this against stanzas they are about to send and take appropriate action,
such as preemptively pretending that the stanza was rejected by the
receiving entity.</p>
<p>A client could for example try to apply more compression to an avatar or
ask the user to select a smaller picture.</p>
</section1><section1 topic="Accessibility Considerations" anchor="access">
<p>OPTIONAL.</p>
<p>Not relevant?</p>
</section1><section1 topic="Internationalization Considerations" anchor="i18n">
<p>OPTIONAL.</p>
<p>Not relevant?</p>
</section1><section1 topic="Determining support" anchor="determining-support">
<p>The responding entity advertises the stanza size limit it enforces
by including it as an integer in a stream feature element
<tt>stanza-size-limit</tt> in the namespace <tt>urn:xmpp:tmp:TBD</tt>. An example of
stream features prior to authentication follows:</p>
<example><![CDATA[<stream:features>
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
<stanza-size-limit xmlns="urn:xmpp:tmp:TBD">10000</stanza-size-limit>
</stream:features>]]></example>
<p>Entities may wish to have hire limits after authentication and would
advertise it the same way after the stream restart:</p>
<example><![CDATA[<stream:features>
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
<required/>
</bind>
<stanza-size-limit xmlns="urn:xmpp:tmp:TBD">262144</stanza-size-limit>
</stream:features>]]></example>
</section1><section1 topic="Security Considerations" anchor="security">
<p>REQUIRED.</p>
<p>Very large stanzas may incur memory and processing costs on the
receiving entity. Advertising the actual limits could inform an attacker
of how large a stanza to construct in order to maximize e.g. DoS
effectiveness. Best combined with network level rate limits on raw
bytes.</p>
<p>Also see https://xmpp.org/rfcs/rfc6120.html#rfc.section.13.12</p>
<p>TBD Recommendations for limits?</p>
</section1><section1 topic="IANA Considerations" anchor="iana">
<p>None.</p>
</section1><section1 topic="XMPP Registrar Considerations" anchor="registrar">
<p>Need the stream feature registered.</p>
</section1><section1 topic="Design Considerations" anchor="design">
<p>RECOMMENDED.</p>
<p>Design? I just typed words and code into my computer!</p>
</section1><section1 topic="XML Schema" anchor="schema">
<p>REQUIRED for protocol specifications.</p>
<code><![CDATA[type: integer
xml:
name: stanza-size-limit
namespace: urn:xmpp:tmp:TBD]]></code>
</section1>
</xep>