Re: [ippm] New Internet Draft: Congestion Signaling (CSIG)

Tal Mizrahi <> Mon, 30 October 2023 08:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48282C14CE47; Mon, 30 Oct 2023 01:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 uX4IhIXIsRc7; Mon, 30 Oct 2023 01:47:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 69EEEC14CE44; Mon, 30 Oct 2023 01:47:36 -0700 (PDT)
Received: by with SMTP id e9e14a558f8ab-3575732df7fso732705ab.0; Mon, 30 Oct 2023 01:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1698655655; x=1699260455;; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kM3kPa6MR9TyyVgXex62MylkHZbo6BuP9i5HhgAYH4E=; b=F44uDc8+TbuH6ZqidLDyojlXOQuvKidqvCwulJ+kgxBHPm23vkVwxPy+Cp4J6Y0M8a x4XqqvAuWBWgqE63bF8OMxMDUsIiSvEXgwHouL2v693tf5Ye+Q2TW+d0gGvMnGzesh5H XxDu1R0Qmry16COWOF2Wo7/Jm8TB32JBaoKvm3cRAcSngpbapaG/CB2G6NhpTNBw4X99 MuoVwFMbT2bQyT0pg5L+bf1jo4W36KRXCz1Fqaz7FU9m7ONzGPr7uU6IPcKFMfamjSWj irdluaESz2dT7K7o9xjmr/APkoYrS3Hmfrq5VjakWeXxY5JkkYEPTr2x6uiZkiW51WKA vtxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1698655655; x=1699260455; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kM3kPa6MR9TyyVgXex62MylkHZbo6BuP9i5HhgAYH4E=; b=KZe/Uwej+bTUDfVAgMHQrLa01nrYEg3UW2Ygzt6GC58BizoN9nHOlNPB7WPyu02xMl Ue7fBatsMYj46w14SKiu8C0iKp/b+kufAliUu1UHoQvkh8O3bmQGOAJ4k9ct50S/l1Ov mhllWhsIdEqzl8rCczaMdOfKWdPvm9spGx19NuTyWe8xZGXnU2oc1oHZdJnc6IuNfsN3 BZVgG/QcL1cnBU+Mhfc8c+wEpfM/0kv/q81I0C98yaodx5DIlXl2YgBZLuCrJURh3NTN r+Rr/FiPYt/9BVoYcDbf2pxOSQKCaLv8NtproLJpg6Fge/5uIUYGQUwqPJ8EnG21WOT0 ZU+Q==
X-Gm-Message-State: AOJu0YwDclkQfmqVC1nWBG6poprYmy+S2GMlXe5cyFK99TbCKAvzcS48 eiZnH3A+gLNzIQ3F581RuRkkj7kLQ2FgPkYsdtR9roxCNBMbqw==
X-Google-Smtp-Source: AGHT+IHyJqMUqMWOP/Bmv+PbvtAMvG3zgtkE377JjSCj03VQA4wimsqK1pExUb5kEvGj5TPGYsVOPKpK0Zp/bLjUTwE=
X-Received: by 2002:a5d:9ec9:0:b0:7a5:cd6b:7581 with SMTP id a9-20020a5d9ec9000000b007a5cd6b7581mr9551285ioe.2.1698655655438; Mon, 30 Oct 2023 01:47:35 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tal Mizrahi <>
Date: Mon, 30 Oct 2023 10:47:11 +0200
Message-ID: <>
To: Abhiram Ravi <>
Cc:,, Nandita Dukkipati <>,, Naoshad Mehta <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [ippm] New Internet Draft: Congestion Signaling (CSIG)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Oct 2023 08:47:40 -0000

Dear Abhiram and authors,

Thanks for posting this draft.

A few comments:
- The notion of using fixed-length end-to-end performance metrics over
data packets is interesting and under discussion in IPPM. Please have
a look at the following existing draft:
- The concept of transparently forwarding the CSIG-tag across routers
very roughly reminds me of the "uniform model" in RFC 2983, where QoS
fields are copied across tunnel encapsulating/decapsulating devices.
If we view the CSIG-tag as an extension of the IEEE 802.1Q PCP field,
then the current draft requires routers to forward the L2 QoS fields
when routing, which is a bit similar to the uniform model.
- Having said that, I would suggest you reconsider the comments from
previous reviewers about considering the CSIG-tag in the IP layer. You
may try to define an alternative encapsulation of the CSIG-tag as an
IPv6 hop-by-hop option, and see whether you lose something by using
this approach.
- Is it necessary to require that the CSIG-tag is the innermost tag? Why?
- The MACsec security-tag needs to be discussed further. Generally
speaking, everything after the security-tag is encrypted and/or
integrity-protected, so specifically the CSIG-tag can't be modified by
802.1 bridges if incorporated after the security-tag. You may consider
placing the CSIG-tag before the security-tag.
- Please note that coexistence with FGL tags (RFC 7172) and E-TAGs
(IEEE 802.1BR) should also be considered.
- Regarding CSIG Reflection, it would be useful to discuss how it
would work with RDMA.


On Sat, Sep 9, 2023 at 5:43 AM Abhiram Ravi
<> wrote:
> Hi IPPM folks,
> I am pleased to announce the publication of a new internet draft, Congestion Signaling (CSIG):
> CSIG is a new end-to-end packet header mechanism for in-band signaling that is simple, efficient, deployable, and grounded in concrete use cases of congestion control, traffic management, and network debuggability. We believe that CSIG is an important new protocol that builds on top of existing in-band network telemetry protocols.
> We encourage you to read the CSIG draft and provide your feedback and comments. We have also cc'd the TSVWG, CCWG, and ICCRG mailing lists, as we believe that this work may be of interest to their members as well.
> Thank you for your time and consideration.
> Sincerely,
> Abhiram Ravi
> On behalf of the CSIG authors
> _______________________________________________
> ippm mailing list