[DNSOP] Ordering requirement in draft-dnsop-session-signal

[Ted Lemon <[e-mail]>]

I was about to send this in a private message to Tom and Stuart on this
topic, but I think it's actually the discussion that the working group
needs to have about this, so I'm sending it here instead.   The proposal we
were discussing was whether to just drop the ordering requirement.

I think that it actually makes a lot of sense for session signaling to
impose an ordering constraint.   It's a lot less useful if you can't be
sure that a session signaling message will be applied to subsequent
messages that are sent.

It's true that we could put IDs on TLVs in messages that are session
signaling messages, and, by doing so, effectively make messages idempotent,
but to do it correctly, you still need a queue: if a subscribe message
arrives after the unsubscribe that cancels it, the result can't be that you
are subscribed.   So in practice if you get an unsubscribe for an
unrecognized ID, you have to remember that ID and then ignore the subscribe
that follows it with the same ID.

But more importantly, if a query to which a session signal was intended to
apply follows the session signal on the way out, but arrives at the
recipient (could be a client or server) before the session signal, it will
be processed differently than if it arrives after.   That doesn't make
sense.   We could say that session signaling messages do not contain state
changes, and hence this can't ever happen, but that substantially reduces
the utility of session signaling.   We could also say that if a session
signaling message applies to a message that follows it, the two messages
should be tied together somehow, which would work for my use case, but I
don't think it generalizes.

This does complicate implementation for DNS-over-QUIC, but I think that's
kind of too bad--if you are doing DNS-over-QUIC, you're going to need to be
able to queue messages.   If the queue gets really big, you have a problem
with your connection: it would be better to drop it than to try to process
messages out of order.

I mentioned at the microphone that we should also consider whether
non-session-signaling messages need to be processed in order.   I believe
the answer is that they need not be processed in order.   We should just
make that explicit, if it isn't already mentioned in the document (I didn't
think to check last time I read the document).

Finally, the question was raised whether "in order" means "in order of
receipt" or "in order of transmission."   I think the only interesting
meaning of "in order" is "in order of transmission," and we need to have a
way to signal that order: each session signaling message needs to have a
sequence number, and the sequence numbers on session signaling messages
need to be strictly monotonically increasing with wraparound.   To make
this work, QUIC encapsulateion has to encapsulate *every* message with a
sequence number: if it's not a session signaling message, the sequence
number doesn't increase, because we don't care about order in that case.

Messages that are received that have a sequence number larger than the
number of the most recently received session signaling message are queued
until that message is received, whether they are session signaling messages
or normal messages.

This is only necessary for QUIC: TCP already ensures ordered delivery.