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

Tom Herbert <tom@herbertland.com> Sat, 09 September 2023 16:10 UTC

Return-Path: <tom@herbertland.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 6956CC1524B2 for <iccrg@ietfa.amsl.com>; Sat, 9 Sep 2023 09:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.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 aopKShxuRw-2 for <iccrg@ietfa.amsl.com>; Sat, 9 Sep 2023 09:10:18 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 D028EC1524BC for <iccrg@irtf.org>; Sat, 9 Sep 2023 09:10:06 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-5774b3de210so186436a12.0 for <iccrg@irtf.org>; Sat, 09 Sep 2023 09:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1694275806; x=1694880606; darn=irtf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AS42q9hQPu2HU7MAaP4lO/SHEalvuYFPgNEyXukWgbQ=; b=FYfGFC2ytyA0jukYpUflWlIE4AqkGyy7XWqHAhPEiYJ/Ecbu8yyRshTpsadZmkm2TY qekRAmC3rOxGhY2kg/Hela3Vxr3uvEe1rdb5Qs71fbgvkrTqvvucMVmfw0i5NX3+cXSj GpNlmFVQXQMomV20Ciyih4I2taHaMUm+HCK0Q9TRhRWKVLtyiOC/DXfkGC3J9kMiKfs4 X/lVqWQQ4cdHzjwuWJlvi2FOqpCr7bCwOMKHXVawpmujmcX+yjQUzK7DSRXHp/YNPHJ3 WuSon2hSDQ/WvMvw8jA17E5on7hZUocezVKzv9Y1Mg87xz5eISgytddv9QZLuKWLkIgp Vfqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694275806; x=1694880606; h=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=AS42q9hQPu2HU7MAaP4lO/SHEalvuYFPgNEyXukWgbQ=; b=Opl6PWDq8ngwppG1U3HNehxJ6p1vHGC7DfG6qGG2/1iXwGpJcxVKnfunzrISVzF+U+ zI2GMEVUnkh6CqurOi4DF+xZhrtPoJ0mIZJTOMciNlLG4Y1Y3Sf72rf7m1OxeD5kSA31 vJV/NqKakq2FTBItq5xjjVGp2+HY0fbdp4vIVLqtaXgBdkzIa3dP5jyDtNwOio7a3U/u n4MgsmDGGhtvm6LNpnA3u2315jKf7Gs81qybbiNL2B6AkgpI0L2eC9ycDYM7IQwOhioE 7Gqp9J+LaikpdwSczvQyrtxvNwyj4WhbqZTo9Iof71Kl6k9KXzttaxAqeGgzxvFvr/CU leWw==
X-Gm-Message-State: AOJu0Yw8tUwInONXh8TfriJCWqWN0R4YuWsdIiQGtzV4hg/WVTLAyuN5 4GqZEaFP424GZvcp28lWF80xaZ4zbYOAT3bQqnRDQw==
X-Google-Smtp-Source: AGHT+IG4MCNLzzOLqL/L2CbuSMTLpRmdFSbouBoHF2yBK1Q92NCAxaPh00ahXdvVvr/MM6UuvrlRA/bSc0Awk7xvkwI=
X-Received: by 2002:a05:6a20:3c93:b0:118:e70:6f7d with SMTP id b19-20020a056a203c9300b001180e706f7dmr6526396pzj.10.1694275806019; Sat, 09 Sep 2023 09:10:06 -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: Tom Herbert <tom@herbertland.com>
Date: Sat, 09 Sep 2023 09:09:53 -0700
Message-ID: <CALx6S35V8xyDBkN0m8kDEcNk0N734Fqq0Ne8ZJ284ZnSSUwV9w@mail.gmail.com>
To: Abhiram Ravi <abhiramr=40google.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>, tsvwg <tsvwg@ietf.org>, ccwg@ietf.org, iccrg@irtf.org, Nandita Dukkipati <nanditad@google.com>, Naoshad Mehta <naoshad@google.com>, Jai Kumar <jai.kumar@broadcom.com>
Content-Type: multipart/alternative; boundary="00000000000091d5560604ef534a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/kNLc2_D70EANtfnSaYVh4zyhUjQ>
Subject: Re: [iccrg] [tsvwg] 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://www.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://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Sep 2023 16:10:22 -0000

Hi, thanks for draft!

The first thing that stands out to me is the carrier of the new packet
headers. In the forward path it would be in L2 and in reflection it would
be L4. As the draft describes, this would entail having to support the
protocol in multiple L2 and multiple L4 protocols-- that's going to be a
pretty big lift! Also, L2 is not really an end-to-end protocol (would
legacy switches in the path also forward the header)l?).

The signaling being described in the draft is network layer information,
and hence IMO should be conveyed in network layer headers. That's is L3
which conveniently is the average of L2+L4 :-)

IMO, the proper carrier of the signal data is Hop-by-Hop Options. This is
end-to-end and allows modification of data in-flight. The typical concern
with Hop-by-Hop Options is high drop rates on the Internet, however in this
case the protocol is explicitly confined to a limited domain so I don't see
that as a blocking issue for this use case.

The information being carried seems very similar to that of IOAM (IOAM uses
Hop-by-Hop Options and supports reflection). I suppose the differences are
that this protocol is meant to be consumed by the transport Layer and the
data is a condensed summary of path characteristics. IOAM seems pretty
extensible, so maybe it could be adapted to carry the signals of this draft?

A related proposal might be FAST draft-herbert-fast. Where the CSIG is
network to host signaling, FAST is host to network signaling for the
purposes of requesting network services. These might be complementary and
options for both may be in the same packet. FAST also uses reflection, so
we might be able to leverage some common implementation at a destination.

Tom

On Fri, Sep 8, 2023, 7:43 PM 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
>