Re: Is the invariants draft really standards track?

Kyle Rose <> Wed, 27 May 2020 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14F8B3A0EC5 for <>; Wed, 27 May 2020 08:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZRzYX750Fbj4 for <>; Wed, 27 May 2020 08:28:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 828E43A0EC8 for <>; Wed, 27 May 2020 08:28:38 -0700 (PDT)
Received: by with SMTP id d22so2946877vkf.12 for <>; Wed, 27 May 2020 08:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gBinbyMx7SjKeGcuJH9CZiq9dPLgGJVdXzBT3tVO9Ys=; b=ASO3M3TI13QM4k+i+xJKznlOvuBhdEY4gK66cPnIDir5cTGkK52iAhQ3r8Zp3Jf+vj YPAyQHsF93sL4lH57dLczDg1W5vT9obZCQoJ3U46ylpwuakZvn5CD9FbsT7P0lqA6SMD pBn/SlphbybLH9Zy3L9sVpNpwaiREhTOwwARE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gBinbyMx7SjKeGcuJH9CZiq9dPLgGJVdXzBT3tVO9Ys=; b=dJQOr0sQXeMpF4WBcTm4SmeQ9r2wNpj9wJTWWy2cmlH/YgGaQKE+5GutcPQiaTmRin wyraYF5Tm61zhj4Y9MQMz7+FWutwqCokkvT8P3PvTXebtDZPX9suBlhPnnSzfZwE26qF Xsg325m1IoZ1FkF4VbTCJSfa0/5mSqlOtUca2UW9RG+H3pHedeIwpUZ5p6/ZVMZGw0lE rkCdd5gMUmAIzZk0qRxXUNp6+UeVLJlMmCRCoxRpV3ZutMPQDWrGJIad3lOK5kgeLyDZ 4r9I1WUjulp6hNVNx5QWcucUmXRPpoUwQmyMwPgImxnCbDx6MdknJUgncHTHtqHWCtY6 K7+Q==
X-Gm-Message-State: AOAM531Im9rZhGNdq6yzsXsg6t1UDlWtXfDzcuZkgumQhUE5y7axo3Ma KRXp++V2Aq3J/nK3F9QY6rIkTv9LEEYaTkPci1ziLg==
X-Google-Smtp-Source: ABdhPJy+wgg+6gs2xml2EdQQSFSStaC44nxX/HdeIBlac0B2rACbFYk4++XVZAVl3bJedhar8F5MLd4Cput4FNf0Iw0=
X-Received: by 2002:a05:6122:4e:: with SMTP id q14mr5347887vkn.57.1590593316341; Wed, 27 May 2020 08:28:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Wed, 27 May 2020 11:28:24 -0400
Message-ID: <>
Subject: Re: Is the invariants draft really standards track?
To: Ian Swett <>
Cc: Lars Eggert <>, IETF QUIC WG <>, Martin Duke <>, Jared Mauch <>
Content-Type: multipart/alternative; boundary="0000000000009a5da205a6a2dd94"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 May 2020 15:28:40 -0000

On Wed, May 27, 2020 at 10:34 AM Ian Swett <ianswett=> wrote:

> I was agreeing with MT, but I'm happy to see some more MUSTs added if
> people feel that'd be helpful.

Coincidentally, we were just talking about this internally at Akamai
yesterday. IMO, an invariants document isn't really helpful if it isn't
normative, and for it to be normative it (or a related practices doc for
operators) really needs to spell out clear boundaries for operators with

The example that came up yesterday was around operators filtering QUIC in
the event of a DDoS: one recommendation based on some conversations going
back at least to Prague 2019 was to hash packets on 4-tuple and filter
those below a hash value chosen for a desired ingress limit instead of
doing what most operators do with UDP today, which is to cap UDP throughput
and just drop packets randomly or tail drop.

This recommendation certainly imposes some constraints on future protocol
development that motivate new invariants: for instance, it would preclude
sharding a connection across multiple source ports (not that there is
necessarily a reason to do this; it's just an example). But more
importantly, it goes beyond invariants: it's one among many practices
compatible with the current set of invariants, some reasonable and some

Operators are going to do things to QUIC traffic, so it would be good to
offer them recommendations that are compatible with broad deployability.