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

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Mon, 30 October 2023 08:47 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571CAC14CE4A for <iccrg@ietfa.amsl.com>; Mon, 30 Oct 2023 01:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_HI=-5, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBhdu_rCZAM8 for <iccrg@ietfa.amsl.com>; Mon, 30 Oct 2023 01:47:36 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 923B8C15109E for <iccrg@irtf.org>; Mon, 30 Oct 2023 01:47:36 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-3575732df7fso732715ab.0 for <iccrg@irtf.org>; Mon, 30 Oct 2023 01:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698655655; x=1699260455; darn=irtf.org; 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=UtdsX7Ly4O0c0Tb03TwuDwSbz69aSDARBPD/j4+ETJ1c72KIaZ0aTD5yLKExA/RU9i rHeaPbcKHnBvoejBd67xDTh4MvgkU1wsKNo/mJr+LRQsIKSmSZK2YInwp0Jsb/OgTYY6 njw/Hj0e4SXMxdvWIGOekSb7XJqeiKrp9n3a1UuBGFP5tmg6Tim1KGgHeyxTYcOAbh7v GAIZ4othNY+yhjlr3IjIVyQW0fSSHawRA5Ysj2y1STY2yq4Qa7APEqZfbVjc/fGR8VAa 8eAD3GFh9OVePnYYpV8NvuY3N6c+Kd1mpffX7jcoblUAKArRDj8z4xWOXST4a+FNEYGo 7iYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=tN6LUU0zydauxxxQ0z3upzdiEdo5QlxjO6mS1rZ+aX8d00CvCbmvvNXOrYLdJ3OrzC CHrN2VF7LwKFhvlo1iWO780JvXNKXd9ZL9PtCbP7i5BI0HBev94kg1bJrs8dV+OEyJpB AA9S7LLTMRrgOaO4wMEwFMLZt2U9BmiMngscQzdomIiS1aA/w61MCiIPFs37JDML/hRP OOv6WwBrSsS/oLz3fnsvEtTr5j2zgjyYy8OtRBpx1Q2CuFnC5UWssASR9QJ7kWv8c0D0 wlmQARVYmXVfjmK6MGP2WLm78QbzVfWeFz4UH72wiIKG9mjmCGF0/2PRQF3y5N6HSbHu MiwA==
X-Gm-Message-State: AOJu0YyrhQ4LHAY20F6RYD8WHTBkMdvQ+c3i4IvJucuHerdl9kzhXQ/J M/4o2pAKgWX/pZLRnR7ndou2TkmLOHVWtcrjkd4=
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: <CAF0+TDD+44TAHf7y05GzmCgbau66ey7AU2RaVroim_Tukf=7nQ@mail.gmail.com>
In-Reply-To: <CAF0+TDD+44TAHf7y05GzmCgbau66ey7AU2RaVroim_Tukf=7nQ@mail.gmail.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Mon, 30 Oct 2023 10:47:11 +0200
Message-ID: <CABUE3X=-n-dJsPwy53qWLXnzM6WB+hf6fGiF3oA5cnWPZCiYXg@mail.gmail.com>
To: Abhiram Ravi <abhiramr=40google.com@dmarc.ietf.org>
Cc: ippm@ietf.org, tsvwg@ietf.org, Nandita Dukkipati <nanditad@google.com>, iccrg@irtf.org, Naoshad Mehta <naoshad@google.com>, ccwg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/hN6Jt5zkw_xO5JNDldlCA1Y4fv0>
Subject: Re: [iccrg] [ippm] New Internet Draft: Congestion Signaling (CSIG)
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://mailman.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://mailman.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=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:
https://datatracker.ietf.org/doc/draft-mzbc-ippm-transit-measurement-option/
- 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.

Cheers,
Tal.

On Sat, Sep 9, 2023 at 5:43 AM Abhiram Ravi
<abhiramr=40google.com@dmarc.ietf.org> wrote:
>
> Hi IPPM folks,
>
> I am pleased to announce the publication of a new internet draft, Congestion Signaling (CSIG): https://datatracker.ietf.org/doc/draft-ravi-ippm-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
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm