From 958aad87ab5181df25cd61a080fa99152adaea2f Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Wed, 19 Oct 2022 14:53:32 +0200 Subject: [PATCH] Initial commit of Path MTU protoXEP --- inbox/pathmtu.xml | 193 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 193 insertions(+) create mode 100644 inbox/pathmtu.xml diff --git a/inbox/pathmtu.xml b/inbox/pathmtu.xml new file mode 100644 index 00000000..152f03e0 --- /dev/null +++ b/inbox/pathmtu.xml @@ -0,0 +1,193 @@ + + +%ents; +]> + +
+Stanza size limit discovery +This documents describes a mechanism for communicating stanza size limits across streams in order to help avoid reaching those limits. +&LEGALNOTICE; +xxxx +ProtoXEP +Standards Track +Standards + + + +NOT_YET_ASSIGNED + +Kim +Alvefur +zash@zash.se +zash@zash.se + + +0.0.1 +2021-08-20 +ka + +

Early draft

+ + + +nil +2021-08-25 +ka + +

more work

+ + + +nil +2021-08-28 +ka + +

more words

+ + +
+ + +

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.

+ + + +

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.

+ +

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.

+ +

Especially vCard and Avatar stanzas may be very large and sometimes +exceed the stanza size limit imposed.

+ + + +
    +
  • Enable discovery of the stanza size limit in use on a stream.
    • +
+ + + +
    +
  • bi-directional?
    • +
  • disco too?
    • +
  • some sort of path mtu discovery method?
    • +
  • error condition?
    • +
  • rewrite large iq-result to error?
    • +
+ + + +

OPTIONAL.

+ + + +
    +
  • An XMPP client could attempt to apply more compression if it sees +that an avatar it is about to upload would be too large.
    • +
  • A PubSub server could limit the number of items in an <items/> +query to ensure it can be delivered.
    • +
+ + + +

If after serialization to XML a stanza is too large, like, don’t send +it. Synthesize an error condition, most likely a (modify, +policy-violation), and pretend the remote entity replied with this.

+ + + +

Something about margins, due to variations in XML serialization, added +attributes (e.g. the from attribute stamped by servers) or elements +(delay tags)

+ +

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.

+ +

A client could for example try to apply more compression to an avatar or +ask the user to select a smaller picture.

+ + + +

OPTIONAL.

+ +

Not relevant?

+ + + +

OPTIONAL.

+ +

Not relevant?

+ + + +

The responding entity advertises the stanza size limit it enforces +by including it as an integer in a stream feature element +stanza-size-limit in the namespace urn:xmpp:tmp:TBD. An example of +stream features prior to authentication follows:

+ + + + SCRAM-SHA-1 + PLAIN + + 10000 +]]> + +

Entities may wish to have hire limits after authentication and would +advertise it the same way after the stream restart:

+ + + + + + 262144 +]]> + + + +

REQUIRED.

+ +

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.

+ +

Also see https://xmpp.org/rfcs/rfc6120.html#rfc.section.13.12

+ +

TBD Recommendations for limits?

+ + + +

None.

+ + + +

Need the stream feature registered.

+ + + +

RECOMMENDED.

+ +

Design? I just typed words and code into my computer!

+ + + +

REQUIRED for protocol specifications.

+ + + + +