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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Fri Jul 27 20:41:29 UTC 2012

On 2012-07-27 20:41, Mark Rejhon wrote:
> On Fri, Jul 27, 2012 at 1:58 PM, Gunnar Hellström
> <gunnar.hellstrom at omnitor.se> wrote:
>>> 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)
>> <GH>I suggest a random start seq with 30 bits  for each session..
> [Comment & Edit Made]
> Why specify exactly 30 bits?   It's not rigid like TCP/IP.  I'm trying
> to provide only the bare minimum integrity check through seq,
> (lower-layer features in a higher-layer), and only because it is
> necessary to do so for a variety of reasons.  At least one XSF member
> did make the criticism about this aspect, and I'd rather not
> 'over-strengthen' integrity checks far beyond what's "reasonably"
> needed.
> Even 30 bits still provides more than 23 years of incrementing room.
> And 29-bits has more than 30 years of incrementing room.  Randomizing
> to a value in the range of 1 million, is still sufficient, for
> practical purposes, eliminate the occasional chance collisions that
> occurs with using the same value (e.g. 0).
> I already say "Senders MAY limit the size of the new starting seq
> value, to keep <rtt/> compact while allowing plenty of incrementing
> room without overflow." which already provides the umbrella for this.
> It's generic enough, and suggests exactly the same thing.
> I have made a minor change, for now:
> c/MAY/SHOULD/ -- I've upgraded it to SHOULD.
> Thanks,
> Mark Rejhon
<GH>Using 30 bits for the random value (allowing also leading zeros) 
gives equal room for the random start value as for the minimum room for 
count up before wrap.

This is not critical. Any fixed rule that provides a guaranteed session 
of 10 years or more would be fine.

But do you need unique seq start number? Then it is not sufficient to 
take a random number. Then you really need to use an algoritm that makes 
sure it is unique.


More information about the Standards mailing list