[Standards] XEP-0301 0.5 comments [resetting versus randomizing 'seq' attribute]

Mark Rejhon markybox at gmail.com
Fri Jul 27 16:45:56 UTC 2012

[For people who plan to review XEP-0301]

This is in reference to the 'seq' attribute:
Background knowledge of "Keeping Real-Time Text Synchronized" is
relevant to understanding this email reply:

On Fri, Jul 27, 2012 at 10:19 AM, Mark Rejhon <markybox at gmail.com> wrote:
>>>> "The bounds of seq is 31-bits, the range of positive values of a
>>>> signed integer" - I'd be inclined to make this something like "The seq
>>>> attribute  has an upper bound of 2147483647 (2^31 - 1). If this upper
>>>> bound is reached the following RTT element will reset the seq
>>>> attribute to 0, i.e. at the upper bound the values would be (in
>>>> successive stanzas) 2147483646, 2147483647, 0, 1)" or words to that
>>>> effect.
>>> [Comment & Question]
>>> I agree, but I don't think it is worthwhile cluttering it by explaining
>>> wraparound:
>>> -- Incrementing only occurs once every second or slightly less (0.7
>>> seconds).  In practical situations, wraparounds will never happen.
>> If you're starting from a random point, wraparounds may happen. If
>> you're starting from zero they're effectively impossible, as you note.
> [Comment]
> In the subsequent sentence in the spec document, It already says you
> should be randomizing to a small number (e.g. we're nowhere near
> maximum integer), so wraparounds won't be happening either.
> So we're getting the best of both worlds.
> Also, for simultaneous logins in MUC, the full JID may not even exist,
> and there may not be <thread/> either.
> Resetting to 0 will then cause message corruption far more often than
> simply letting it continue to increment, or even better, randomizing.
> Therefore, resetting to 0 is not an acceptable recommendation, even if
> it will generally work in any implementation.
> Any other ideas / comments?    I think it's not a high priority during
> LC, because I do say that any seq value can be used, just that
> randomizing is the best practice here.   More field testing would seem
> to be required.   It is worded in a way so that changing the standard
> of resetting seq in the future, will not break compatibility.   So I
> think the randomization can stay for LC -- unless there's a superior
> idea (robust and simple for implementers)

Although this would not seem to be important to address for the LC
until more field testing is done, here's some detailed feedback about
seq incrementing:

Note that incrementing seq every 0.7 second (default transmission
interval), would require more than 47.6 years of composing a single
real-time message before wraparound occured near 2^31 (2,147,483,647).
 A whole chat session almost certainly doesn't even last long, and
even in a wraparound situation, wraparound is not very harmful. A
wraparound would only causes a message stall only for 10 seconds,
thanks to section "Keeping Real-Time Text Synchronized"

Currently, the way the standard is written, recipients don't care
where 'seq' begins -- they use the value specified by the sender for
new messages or message resets.  It is mainly of concern for senders
on how senders decide to start a new 'seq' value during starting a new
real-time message.  Here are different methodologies of 'seq':

List of methodologies:
- Resetting 'seq' to 0 every new message (riskiest)
- Letting 'seq' continue to increment for the whole chat session (safer)
- Randomize 'seq' every new message, and for message resets (safest)
- Always REQUIRE <thread/> for all senders using <rtt/> (might be
onerous for some)
Each has pros and cons, all listed below:

METHOD: Resetting 'seq' to 0 every new message
- Simple implementation, works
- Causes rare corruption (occasionally observed in practice) during
conflicting <rtt/> situations during simultaneous typing during
simultaneous logins and MUC.  This is especially in MUC where full JID
is not always available, and <thread/> may not be available. The
corruption occurs because "Keeping Real-Time Text Synchronized"
happens to occasionally "by chance" see an incrementing 'seq' from two
different <rtt/> elements sent from separate resources (or even the
same resources; see below).   (good reason)
- Even with full JID tracking, still can cause corruption if you reset
to 0 during message resets, in situations of congestion concerns (e.g.
message stanza containing reset attribute gets lost, and the next
successfully-received stanza happens to line up with the recipient's
last known incoming 'seq' value.).   (poor reason)
- A slight risk reduction occurs if resetting to 0 only for new
messages, rather than message resets.

METHOD: Letting 'seq' continue to idrement for the whole chat session
- Simple implementation, works
- May require me to mention wrap-around scenario, but incrementing an
integer every 0.7 second (default transmission interval), would
require more than 47.6 years of composing a single real-time message
before wraparound occured near 2^31 (2,147,483,647).  A whole chat
session doesn't even last long.

METHOD: Randomize 'seq' every new message, and message resets
- Simple implementation, works
- Requires detailed explanations in the specification, confusing and
not obvious for first-time readers of XEP-0301.
- Need to either explain increased wraparound risk with randomization,
or need to mention to randomize to a value significantly lower than
maximum integer (e..g. half or less) so that risk of wraparound is
virtually eliminated. (e.g. takes more than 23 years to wraparound

METHOD: Always REQUIRE <thread/> for all senders
- Eliminates potential of conflicts for <rtt/>, and seq can safely be reset to 0
- Complicates implementation.  Recipient software is now forced to
check for <thread/> to distinguish the <rtt/>. Requires me to make
"Keeping Real-Time Text Synchronized" algorithm more complex.
- Note that this is already a legitimate option already in XEP-0301
anyway, but I feel it shouldn't be made REQUIRED

I think this is a minor sender-specific concern, and can be safely
changed in the future with no compatibility impact (since the spec
requires all recipients to get the new starting seq value anyway), the
0.6 will continue to advocate randomization, but discussion is welcome
from upcoming 0.6 reviewers.  (I'm planning to send 0.6 to Peter

Mark Rejhon

More information about the Standards mailing list