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.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
