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

Tom Herbert <tom@herbertland.com> Thu, 08 February 2024 23:53 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 8BF1FC14CF15 for <iccrg@ietfa.amsl.com>; Thu, 8 Feb 2024 15:53:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, 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=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 UJFOMpLaP7F8 for <iccrg@ietfa.amsl.com>; Thu, 8 Feb 2024 15:53:29 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 7ABD0C14CF18 for <iccrg@irtf.org>; Thu, 8 Feb 2024 15:53:29 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2d0c7e6b240so5387361fa.0 for <iccrg@irtf.org>; Thu, 08 Feb 2024 15:53:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1707436407; x=1708041207; 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=nvthn6zKTkIozezxyPnQFvqHiw89XFDE/1zU2diwlCg=; b=Ah4RnVtlWvFdpC+cgWLGwQ7W9gzgZTs6cDLVBO/GDoc/yvt9DnP+GZn+nRfxMcwcYj 4QI4GkcwYv9jgUiHjlcmTnrFzJWH0/QCrW2y/zf37vpspyeC2vKcND3N8nvyyo7EXf18 7PMAp1yRQCwaQKbNOZULcMBisj9MPwdmJn7Ut6cb3AfmoSGhg5ehIqxzdLQdtaV8muqw u6tdqeay6A0abLxn3VjALXz/O4z6pHSwboqyejvvd6lxQWO6Vz1nzoSVtT7cf6HJCove EP2YYvIwpZ0wFnitbscztpWE8S1EBnPDk7H0fgTOo3cbcQ7/Esy5UqdCPce08sYQFs0Y RdoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707436407; x=1708041207; 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=nvthn6zKTkIozezxyPnQFvqHiw89XFDE/1zU2diwlCg=; b=STVbKYDBzdAbl7YnMLwgEsAzyomx2L3Nm1YPYY+1YdTfJp6QksEARaqBAxn80N9btA TgvoafimpTPPkVw8rTFnXM7iNoa84int2lDswrptPGBpcu/pTzMAig5cwO32WuDmJH1+ JTsB/kYUzBi0KRE5+B96b0O+nd4wqkqPlyowi9MWFx7WjsDg5b/+TjNV1C8AP01SrRtQ XBDCQUMJUyIkDD2chL2v/Bv2g7ZRlFg7tb9KTkg3g63eacZ9rNnNfu59KRJ10LtRLVPS U+6oGHt1OEKaVajxnVqo8tGWPeRjpTv9QOGr/RJZYvYcFGANrFrwmAmxq6QbF8tJw4sT dffQ==
X-Gm-Message-State: AOJu0YyouO2Is4vKZgnSmR2MNIpNtdzGy+cA6wXCMDV3BieOIxzgCjRT c2sYEVmtxZ+Y0HnzorYgro4PYhsuK1BGK3R9L8FE4TL/ufBHHJoaCO4zwDeCGx1Hpj3RIxARY+z gm2ZBw1pHSwrnS0YcatbazLCwaSL7vRJCcK/s
X-Google-Smtp-Source: AGHT+IHzxRQvcdL1G4YQ8AHvB++51IHVFaixjLdKh/rRLpjxHocGpnsSXLPogW++szFU/8vNXfZF7+D/uqu01b0ACG8=
X-Received: by 2002:a05:651c:1989:b0:2d0:ab90:adbc with SMTP id bx9-20020a05651c198900b002d0ab90adbcmr75103ljb.28.1707436407029; Thu, 08 Feb 2024 15:53:27 -0800 (PST)
MIME-Version: 1.0
References: <CAF0+TDD+44TAHf7y05GzmCgbau66ey7AU2RaVroim_Tukf=7nQ@mail.gmail.com> <CALx6S35V8xyDBkN0m8kDEcNk0N734Fqq0Ne8ZJ284ZnSSUwV9w@mail.gmail.com>
In-Reply-To: <CALx6S35V8xyDBkN0m8kDEcNk0N734Fqq0Ne8ZJ284ZnSSUwV9w@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 08 Feb 2024 15:53:15 -0800
Message-ID: <CALx6S35XNyBe5=gh7JpaCKEkiXaEwPGHrDZe=E-EPkiF5mUCLA@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/WWnacHrmommKXsa7t7yB_uUPrM0>
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://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: Thu, 08 Feb 2024 23:53:33 -0000

Hi,

I noticed there is now an -01 version of the draft posted on Feb. 2.
Is this draft being discussed on some other list?

Thanks,
Tom

On Sat, Sep 9, 2023 at 9:09 AM Tom Herbert <tom@herbertland.com> wrote:
>
> 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