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

Ted Lemon <mellon@fugue.com> Wed, 19 July 2017 07:22 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CC43D131467 for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 00:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j9vlFzLk_5Jo for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 00:22:57 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FD912EE45 for <dnsop@ietf.org>; Wed, 19 Jul 2017 00:22:57 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id s70so14155300pfs.0 for <dnsop@ietf.org>; Wed, 19 Jul 2017 00:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JGgud/jU9fgcM9PyCyx+kPOKmIDFLu+/C+Mz/4ckVEU=; b=H1t41Q4/Ek5CAVELu/u5DdRZkxx/YUkg0x+sbxjaASULahX8bOn5TGfCx841lxEwPt val/rn6uo2iI2yv6DipdeXfrjTMpcilUXUoX9bt8SQpTkUaFVTdhC6ag6PU20tFCyoZh lML1be9O4QkZYzdFlicYeSAlYafJgCA6iT6+PfiuVRURn4kGfJlgOqIlrBhZySPjTjPk llKO+kB6t2x+2wGUYTOauCMlhUCEREJepr5zaibGplJv7FtafXHz4Dz9wzEHc7e/g5LC uDpLUNZczy0Y+orxNAZyo/pAN5EsAnI9ncVWruyYJFtslURvwOpdXE8XIzLqWytZTRPN QZSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JGgud/jU9fgcM9PyCyx+kPOKmIDFLu+/C+Mz/4ckVEU=; b=Id39E/jNSDXsnYtik/ytiD+4M8HYsoV2NNFYjhywyxDfEdSFeL9C4rh9dZCnV2SuKT 234Wkw+cZhhjUSVS3SDWlgH917J/9G8nX3CO+xbh0o5UsSvnwQJWBEKu2IR1g/wPC5If 41G5kldW4catmdTdy+TQH7TaGuB0fz7SgL1JmrlPD0Nfer8ENF3ZHkSFnnHUr/QAa7D/ Lz/rgR/0C5y0bfWXY7bObI0LnlNns1R/h3WHZA2V7eNnjuHvXwEiGHrGNu4c1qo3TrGD d5cU8RjjzRzNtAANwZueQ0Ss5uW2fxjSJPMkLC/xGof1/N/zvgCtubs63Lf971G2CHdD ZULg==
X-Gm-Message-State: AIVw112d9kCrLUD2C56641/cVWGM0DEiBmRHK9IXFW6ojyV2VtcZGyl2 dQcjfk3dUf0VHMpFfFYBFTDVqa9lg4eSE9I=
X-Received: by with SMTP id x68mr1667911pfi.176.1500448976462; Wed, 19 Jul 2017 00:22:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jul 2017 00:22:16 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 19 Jul 2017 09:22:16 +0200
Message-ID: <CAPt1N1nSPqyf=7z6uDhDfv7SbmbvhW_ObUc3090AA4OGvScZug@mail.gmail.com>
To: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a1137741e3f02840554a68009"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IWcghhEoDoDJu6PQjw_W5JPP0rI>
Subject: [DNSOP] Ordering requirement in draft-dnsop-session-signal
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 07:22:59 -0000

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.