Re: [tsvwg] FW: New Version Notification for draft-white-tsvwg-l4sops-00.txt

Jonathan Morton <> Tue, 04 August 2020 04:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 057583A07EC for <>; Mon, 3 Aug 2020 21:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.051
X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YvaHqYGA_sCP for <>; Mon, 3 Aug 2020 21:05:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 813E63A07D7 for <>; Mon, 3 Aug 2020 21:05:12 -0700 (PDT)
Received: by with SMTP id d2so15979361lfj.1 for <>; Mon, 03 Aug 2020 21:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=to:cc:from:subject:in-reply-to:references:content-transfer-encoding :date:message-id:mime-version; bh=7FZy+p1Hbrlire6qfDFsq9wWXxfgHpSNyHaZ++Zvhak=; b=j7TpLuzUEvHdGprsmQLZ/6antOWNdWXr4OO/3WtdrrPCUPBPF0mpzN7IY+CDD0vDQE JTe2bveBD6NdHigqWeO4Lr+uUGn3d1SZ8gY1CHe3QujCQM1D/XS+JR6fa2nW0hZRlzxH /hzfNc0TFtp5FmLbrLoc8lF2K0nMvxkKnzTotdm5yN0jgGI1AnEVJqma1tEzPeNvRq2A VQE14nMIK1/kgKhiq3TZnryoAK/F7RARQGrWYH7+8XawRJr5lupcjtsLAcwhl9Df8Ksm z4inUGbZnbP6FkjXlSNrH+jKWCC5K5U8caLoNh7kwwWGeK5LwIrGKzMDOaS9c5NzCyyU 3nyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:to:cc:from:subject:in-reply-to:references :content-transfer-encoding:date:message-id:mime-version; bh=7FZy+p1Hbrlire6qfDFsq9wWXxfgHpSNyHaZ++Zvhak=; b=OzRLlOaHRilvoM0tsERaaLHVJYnHFVfZYQJQ/BOI+0T9At4TuPu3WjHYgwa9qwyef6 QQkJCtD45x/YsEF1nb8fgL1IjXRn6Acq602I+cA87kQjEjCiTj6koWLT9HB7tao9Ucg9 z8UawIpoywoESiCiHPExRpf6C8e8WefX60XfwlDua5Tqsa+qXFAje+MCKDrrXa6AP790 xaImG4jmH3pRCaRCUdpZrSTHRGFFEmgYQr7JAYgRH6U4bjOzp5Wl6qxYP4AlvO3GeuJg wOh2L0p9Exc9BkZC32HuRO44ZqEI0VV1OSw66zQ6a3bkx0w54jBb5+tWVb0eIeTGIQAr imIA==
X-Gm-Message-State: AOAM530scbvxm+j30vJOT5SUr4x5Kvzss3ZhUMlKrwKx4JUtUH7MQo4G kigpGrl09K0BZBwG+Yn5+JM=
X-Google-Smtp-Source: ABdhPJyvqKZFYkwMIVXj4BxU1QYGTqhhwV9hI/dSHmtHkoYNaz5W7NpY9ZNqGxWuKwweJYDu/OrjEA==
X-Received: by 2002:a19:c206:: with SMTP id l6mr9922106lfc.152.1596513910580; Mon, 03 Aug 2020 21:05:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id l1sm4728661ljg.134.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2020 21:05:09 -0700 (PDT)
X-Priority: 3
From: Jonathan Morton <>
In-Reply-To: <>
References: <> <> <> <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Date: Tue, 4 Aug 2020 04:05:08 +0000
Message-ID: <>
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tsvwg] FW: New Version Notification for draft-white-tsvwg-l4sops-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Aug 2020 04:05:14 -0000

> [SM] This description ignores the birthday paradox issue that Pete Heist demonstrated. A misbehaving L4S will cause less havok there but it is not without side-effects on stochastic flow queueing systems, we might as well acknowledge that, no?
> [GW] IIRC that issue can occur in fq_codel, but is much less likely in Cobalt (due to set-associative hashing).  Is that correct?

The set-associative hash (presently in Cake, not actually part of COBALT) does significantly push back the onset of flows colliding in the same queue.  It does not 100% eliminate the possibility, so you still have to manage the risk (product of likelihood and consequence) appropriately.  Two flows with mutually compatible congestion responses colliding is a mild enough consequence, but that is not nearly so clear for when the responses are incompatible, especially when it is the newcomer that is dominant.

What no fancy hashing algorithm can compensate for is when the distinction between flows is hidden by a tunnel encapsulation.  Since the L4S team has been adamant in other conversations that tunnels are a common feature on the internet, and I believe we should expect a mixture of conventional and high-fidelity flows within these tunnels, that should definitely factor into your analysis.