Subject: Re: [NSIS] QoS NSLP Issues 20 and 17 - sequence numbers, etc

From: Martin Stiemerling <[email-masked]>
Date: Wed, 03 Aug 2005 18:46:45 +0200

Hi Andrew,

| Some thoughts related mainly to issue 20 (RSN wrap around) and partly to
| issue 17 (failure and restart handling).
|
| At IETF62, when I brought up the issue of sequence number handling, Dave
| Oran said "do what the routing people do". I'm not sure it's quite so
| obvious.  :-)
|
| As I understand it, the main point that Dave was getting at with his
| comment, was a suggestion to use a linear sequence number space rather
| than a circular one. Auxiliary questions relate to what happens when
| RSNs reach their maximum possible value, what happens when nodes
| restart, etc.

I have a question about the node restart case. If a node restarts,
a new full D-Mode exchange (plus probably C-MODE etc) would been
started between these two nodes. Couldn't this knowledge been used to be
at least aware of a new start of the RSN value?

|
| The idea of a circular sequence space would need to be discounted
| immediately if the ARPANET sequence bug scenario could be applied [see
| footnote]. As far as I can tell, this does not appear to be the case.
| The ARPANET sequence bug issue principally stems from the fact that a
| router can receive the same piece of routing information from multiple
| different sources (i.e. its neighbouring routers), and these all come
| from the same sequence space. In the case of the QoS NSLP the sequence
| numbers are peer-to-peer (with the peer identified by the SII), so this
| issue does not apply.
|
| If we were to use a circular sequence space, then wrapping would likely
| be done as described in RFC1982. Even then, wrapping isn't going to be
| very common - assuming the RSN is incremented once every 30s then a
| 32-bit RSN would give us about 4000 years.
|
| Like TCP, SCTP uses a circular sequence space (as per RFC1982). DCCP
| also wraps sequence numbers, but uses an asymmetric window with losses
| assumed to be more common than reordering.
|
| This leaves the question of what to do when the 'sending' node restarts.
| If the new sequence number is 'bigger' than the old one, then things
| would simply proceed. If it is 'smaller' then a method of
| resynchronizing would be required. One method might be for the receiving
| node to send an error message back informing the sender of the current
| sequence number. However, this would also be sent in the event of
| reordered messages. A better method might be to use an epoch identifier.
|
| OSPF uses a linear sequence space. When the sequence number reaches the
| maximum value then the Link State Advertisement instance must first be
| deleted, and then it restarts LSA flooding with the initial sequence
| number. This would be a problem for the QoS NSLP since RSNs are
| peer-to-peer (within the context of a session), but sessions are
| end-to-end. However, you could possibly propagate an error back to the
| QNI.
|
| When a router restarts it can learn the value of the LS sequence number
| from seeing its own LSAs sent back to it. The nearest equivalent for the
| QoS NSLP would probably be for the receiver to send an error back giving
| the current sequence number so that the sender can reschronize. Another
| alternative is to add an epoch number to the RSN that is incremented on
| each reboot (effectively extending the sequence space).
|
| I haven't currently got a strong preference either way.
|
| The principle of the linear sequence space is "reaching the maximum
| never happens, so we don't need to worry about it too much". However, it
| seems to me that we still have to say something about what happens.  It
| shouldn't get totally wedged because you can always just leave the soft
| state to expire. Is that good enough? You may be able to pass an error
| back along the path to allow something better.
|
| Using a circular sequence space requires the definition of the wrapping
| rules.

I'm fine with a circular sequence space and the fact that wrapping rules
are needed. However, if people think that 32 bits are too small and
will result in wrapping happening to often, I wouldn't mind to go
to 64 bit. My believe is, that 32 bits and wrapping rules are good.

|
| If I had to go for one or the other, I'd probably currently pick a
| circular sequence space on the principle that we can just reference
| RFC1982.
|
| In either case, the use of an epoch number to identify node restarts
| seems like a good idea. As to whether this should be in GIMPS or the
| NSLP (NTLP issue #43), I'd probably go with the NSLP using a common
| object used by multiple NSLPs. If your internal software architecture is
| suitable, you can just have one epoch number for all the NSLPs you have,
| or you can have a different one for each.
|
| Note: Currently the NAT/FW draft just says 'wrap' and nothing more than
| that. So, some of the same thinking may need to be done there.

The MSN handling is somewhat different in the NATFW NSLP case compared
to QoS in the sense of restarts. (the wrapping problem is the same).
The MSNs are generated by the NI , maintained by it, and have
only a significance within a single sessions. If now a node in between
reboots, there is no harm out of the MSNs, since they are used end-to-end.
If the NI reboots, it is very likely that the session used afterwards by
the NI has a different session ID and thus the MSN value out of the old
session does not matter.

  Martin

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "McDonald, Andrew" <[email-masked]>
Date: Thu, 4 Aug 2005 16:36:15 +0100

>at least aware of a new start of the RSN value?
I'm not sure that this event necessarily indicates a node restart. 
Depending on how the various timers (NSLP state timer, routing state 
timeout, MA timeout) are configured, I would have thought that it would 
be possible for a full D-mode exchange to occur without actually having 
a node restart.

Andrew