[ippm] Is loopback/direct export amplification worse than linear?

Martin Duke <martin.h.duke@gmail.com> Mon, 16 November 2020 05:45 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBE13A138B for <ippm@ietfa.amsl.com>; Sun, 15 Nov 2020 21:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIjD2IVfmUfk for <ippm@ietfa.amsl.com>; Sun, 15 Nov 2020 21:45:09 -0800 (PST)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 8A3923A138A for <ippm@ietf.org>; Sun, 15 Nov 2020 21:45:09 -0800 (PST)
Received: by mail-il1-x129.google.com with SMTP id n5so14028104ile.7 for <ippm@ietf.org>; Sun, 15 Nov 2020 21:45:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wDMKxS6bIL8QHOPhFpydhjjZzg6hlAxxCZTgi0p+Q9I=; b=lsdyVtSTN6JxQy5fPcoKGzpZ/j4nzfvE5vFUeiZYu69hyb6wopRZ1w1dNIRdpHkO97 j/tHQbGp2FAUglr78TE158VLO3yhxDl4U6hHw8vIin+GTKf2i+qhUY+5J5jD0Q1l1CtZ L8C+mBY8/bGDuMqOz91fxLPHYjLO+/NCSbhZhB4clal4o0WXN93dZ7m9Q7pBw5bBzVp8 Ya0ooYw1NaYDNba8p/BuVc3w2tj6DD4wXKLIUy2vxLHb62jc17N8syXgcqkYz32zOHos dmjj8I5W3S8yYUHttIi6jhyyuBA72cCwNmf7p6OOsNYj75EPTX9c2c9W9jtVF5kNPEv/ DxKQ==
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=wDMKxS6bIL8QHOPhFpydhjjZzg6hlAxxCZTgi0p+Q9I=; b=DcTuTGK1WaApqrtKayte4Y54wt121pj6wCd34JX72L+H/BshPFl0LbAf9y9yS3oLwI NrcS941UYf4xvCriRdDjA+8YpKwsB69+Z0kYvOVzLm5SNalBj1AF3e8X2sz+dVBDKNMu /c6enVicAwmAiJnnToogkwQpuHwIzrx/KmEwjCto+qfA/DE0y6+U3LS/i4juNdW7+mLc Wb/e0cuyHoRZk6Sq36hzhPVUEWDckl99ebTk3HkBPHcYzoGjLu5Wrop0duHjTApdR+PV G1NUrsabE74rIijJVspPNagNUXiRYSMBX1n8MCYaeUsrEJdvdYVVMV2pgn23KEU0nYB6 WjCQ==
X-Gm-Message-State: AOAM5305udnbbwEkuvO6q3W31h8crvF3LijEVoVgDhxrKOtWuWaNOSJz 9OsGK7Hz8JerRJyJ43aacsCEfiIg4ReaKaZ+HuP17Jh8ulw=
X-Google-Smtp-Source: ABdhPJyuZB3+jSv9heUhJvuB7xFRFa7DEVJsQKr5vD5JtD9TwCWiE+Ettb8TsuuJgbIgwaps2XUn/ZJN7LH8tpfanYY=
X-Received: by 2002:a05:6e02:1151:: with SMTP id o17mr7154115ill.303.1605505508314; Sun, 15 Nov 2020 21:45:08 -0800 (PST)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Sun, 15 Nov 2020 21:45:04 -0800
Message-ID: <CAM4esxQiaRoCb9-7eBMy4yoCv28=St2XN-8AF7DwPiC2HU_Fzw@mail.gmail.com>
To: IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000082146105b432e10c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/PyfokOEsBBCTtRdNYG-Vr-674Nw>
Subject: [ippm] Is loopback/direct export amplification worse than linear?
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 05:45:14 -0000

I recognize that the loopback and direct export drafts discuss potential
amplification results, as a path of length N will generate N packets for
each IOAM packet -- a linear relationship. As these are discussed in the
draft with proposed mitigation, in an editorial sense the job is done.
Whether giving people this kind of foot gun is a good idea is a separate
question, but reasonable people can disagree.

However, if I understand correctly, certain pathological combinations of
IOAM namespaces could result in amplification far worse than linear.

1) Loopback loops
Imagine there is an IOAM namespace that covers the path from Hop A to Hop
D. There is a separate namespace entirely contained in A-D, from hop B from
hop C. Both namespaces enable loopback.
                           A
--------------------------------------------------------D

 B-------------------------------C

So a user packet is traveling from A to D. There will be (D-A) loopback
packets headed towards A. The (D - C) loopback packets that generated
between C and D will travel through the encapsulating node at C and then
trigger further loopbacks to C. Thus the total number of packets generated
by the single user packet is
(D - A) + (D - C)(C - B)
and obviousy there could be several of these smaller namespaces, or nested
namespaces, that aggravate the amplification further.

2) Direct Export
Direct Export potentially has even worse properties. Suppose namespace A,
N_A hops across, direct exports to a node that is reachable across
namespace B. Namespace B, N_B hops across, direct exports to a node
reachable across namespace A.

Thus a single user packet sent over namespace A will generate N_A packets
that traverse Namespace B. This will, in turn, generate N_A * N_B packets
that traverse namespace A, which in turn triggers N_A ^ 2 * N_B packets,
and so on.

In fact, if the namespaces direct export with probability exactly,1/N_A and
1/N_B, the same level of traffic will ping-pong infinitely. Any more than
that, and the traffic will steadily increase to infinity. If the
probability is 1, the growth is exponential.

****************

This analysis, if correct, raises three questions that I can think of:
- Are these corner cases plausible?
- If so, and they occurred, would the namespace administrators necessarily
be aware of each other? If not, I'm concerned that this is unsafe to deploy.
- Do phenomena like this indicate that the design is brittle and putting in
some "considerations" doesn't really mitigate the dangers here?

Martin