On Fri, Jul 27, 2012 at 1:58 PM, Gunnar Hellström <[email protected]> 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
