Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Congestion Signaling (CSIG)
Tom Herbert <tom@herbertland.com> Mon, 19 February 2024 17:54 UTC
Return-Path: <tom@herbertland.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 3217CC14CF12 for <ippm@ietfa.amsl.com>; Mon, 19 Feb 2024 09:54:12 -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_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=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 pWV_h1z47N05 for <ippm@ietfa.amsl.com>; Mon, 19 Feb 2024 09:54:07 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 D6A2DC14CE4A for <ippm@ietf.org>; Mon, 19 Feb 2024 09:54:07 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5611e54a92dso6310891a12.2 for <ippm@ietf.org>; Mon, 19 Feb 2024 09:54:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1708365246; x=1708970046; darn=ietf.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=Z2BVNuyYRXdXV/IEC63PLyKYlFVBlixaeKdIVDF0yPw=; b=grGh2fVjAgGPV8lVzEp6bObJG/U1PIWsz6myiZPuyfydQv0vvUlojVeCLvhybHFqHs liCdHMub+rbFqihqw143C2EouMjMlAbP8BDKmKecUPG2MJuQ/CtQf5V613U4H7qxAJc1 P9lpaFzx1vjQQX8QIgeqcNPEMNp8GMJO/Z6nafj7JHmeL2F+TyKnRocB73BPWoGZ4UlC zZG5z7OAXwPLMRnK+mIPAxvZ/gOUc2y2wS2DyXi3sYedUXVWO4KYwJgZ1IgH/BVFP2V5 eTdLS7X5h4sH8w64rNSmiw33Rb/6PxhZ6tB2k9WzbP18Ems8UDuNxh1psjFzd7WHZyor wH3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708365246; x=1708970046; 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=Z2BVNuyYRXdXV/IEC63PLyKYlFVBlixaeKdIVDF0yPw=; b=EHm3bWLykNTLNNeWtcenmgzILpolkz216YFFWJfvpQ/Y0Q8tfXtwImC3jOtXmBuljn gCNSjuh3PahI4M7NBMzx4iNO/hriljSDfxRKNunt5xnS7qHYhFilyoHu7tVzk/3XNT1q dH3Ot+kceJTDhw6PdQ0RGtpoElgduU7UK/TuyMwWpsMWe0EbOdlYp4pKp7f7VH8Zp2/4 /ujBOXyW9O8An0lNu/gv65PLcyfyRuwMFuxCpzb674ctrFNaqY3hfTD9UbrjkzAvz9aa pqOnskPmCWSLtcYyHrxVXKZOrJKq2BOWOjnGaSXmTdw5DEePu6M0a6d++1Y2RsPZHrk9 UvLA==
X-Forwarded-Encrypted: i=1; AJvYcCU1EsXq9rBGfQUDRuxRdDBE5ywL0tcEYSxJ9cVYR86rTpc/qvN+uEPvIHm2cqwLv6UP0s4Uy4atx1rWFwo7
X-Gm-Message-State: AOJu0YxsAoWNSx5/7jE1QeSba2lSfEAbVwlph5PDOO/MwLJgEsLsSh7+ nhMTAA+5Yzn7PusYGNjE1VGL1ZMIg5Sw55ao/hGX/aHDS+yJ9gwsbVaYME+8RiuaXlpmOGv17af VgavlzHwojStEIIPkv+TaYa+hETREX4WebDaw
X-Google-Smtp-Source: AGHT+IFWofvCgcjkPWzuIT/qUf2UgkXXeRJcF4+FD0St+kWP195npXpD8tITnBoploKtRmZY4M/YQA1StTkZk9T8qcA=
X-Received: by 2002:aa7:dcc4:0:b0:564:ad00:fbab with SMTP id w4-20020aa7dcc4000000b00564ad00fbabmr676190edu.37.1708365245971; Mon, 19 Feb 2024 09:54:05 -0800 (PST)
MIME-Version: 1.0
References: <CAF0+TDD+44TAHf7y05GzmCgbau66ey7AU2RaVroim_Tukf=7nQ@mail.gmail.com> <CALx6S35V8xyDBkN0m8kDEcNk0N734Fqq0Ne8ZJ284ZnSSUwV9w@mail.gmail.com> <CALx6S35XNyBe5=gh7JpaCKEkiXaEwPGHrDZe=E-EPkiF5mUCLA@mail.gmail.com> <CAB_+Fg5McYXt=M5MNkuxHrKrXQgZMS6PLRoVeUKiSUe5Qb7LjA@mail.gmail.com> <CALx6S35OHyhWjmkV2jiOqO-sB9Csugx0umB_yF_ann9rB8Tgbw@mail.gmail.com> <CAEsRLK9_bHrhyvFqCz3do=Ax3mKZor4EtqXY2chdfL7fzi1UMw@mail.gmail.com> <500388A6-50D3-4535-84CB-E6EF454960DD@gmx.de>
In-Reply-To: <500388A6-50D3-4535-84CB-E6EF454960DD@gmx.de>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 19 Feb 2024 09:53:54 -0800
Message-ID: <CALx6S37gOatLC_DZiM4M=e8qrzyE9y1D1i+UqOYXatd7Y6Nauw@mail.gmail.com>
To: Sebastian Moeller <moeller0=40gmx.de@dmarc.ietf.org>
Cc: Matt Mathis <mattmathis@measurementlab.net>, Nandita Dukkipati <nanditad@google.com>, Abhiram Ravi <abhiramr@google.com>, IETF IPPM WG <ippm@ietf.org>, tsvwg <tsvwg@ietf.org>, ccwg@ietf.org, iccrg@irtf.org, 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/ippm/QAUC1kk_lJO4AsC8ixz2Y56mdEY>
X-Mailman-Approved-At: Mon, 19 Feb 2024 10:05:56 -0800
Subject: Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Congestion Signaling (CSIG)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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, 19 Feb 2024 17:54:12 -0000
On Sun, Feb 18, 2024 at 11:34 PM Sebastian Moeller <moeller0=40gmx.de@dmarc.ietf.org> wrote: > > Hi Matt, > > > On 17. Feb 2024, at 20:17, Matt Mathis <mattmathis@measurementlab.net> wrote: > > > > I think the L2/L4 split is brilliant. > > [SM] Respectfully, the brilliance depends very much on the goal/gamer plan. Is this purely aimed at data center traffic this looks like a sweet solution that is 'organically' confined to the domain with appropriately capable L2 elements? Or is the end-game here an (overdue) improvement of end-to-end loads/congestion information? In the former case L2/L4 seems a decent solution, in the latter case less so (not that getting a common L3 solution would be guaranteed or easy). > > > > Putting the forward instrumentation as low as possible in the stack permits easy processing in HW w/o parsing any L3. > > [SM] Sweet, but that really means that this solution is unlikely to survive over a full internet path. > > > Putting the replies in L4 only requires a handful of implementations to cover all possible paths, > > [SM] Mmmh, that might be but partly because the L2 solution noticeably restricts the set of possible paths, no? > > > and piggybacks on existing solutions to session layer issues, such as authentication and authorization. > > [SM] What is the threat model here? I would guess an attacker that knows the full path might just as well probe the congestion level and an attacker that does not know the path might not be able to do much with the congestion information? (Any attacker that can modify the congestion information might as well drop the packet directly). > > > > > I would consider mentioning but then temporarily excluding alternet placements: either as a shim at the top of L2, sort of like VLAN tags, or within an L3 option. Both of these have their own challenges, but might be extremely valuable in some environments. > > [SM] Some environments, like the internet? I know that the I in IETF is not a strict limiter of scope, but still it would be nice if drafts would have a viable path of being implemented over the internet... That said, well possible that the current state does not merit use-over-the-internet yet and so maybe starting with an L2/L4 solution might be considered a safety back-stop? Sebastian, There's no reason to believe that Congestion Signaling isn't of interest to use on an internet (lower case 'i' is explicit here). This is almost certainly beneficial for 6G for instance which is an internet composed for various link layer technologies. Neither is this the only protocol of this nature there are and will be others-- from an IETF POV I believe we want a extensible protocol solution that benefits multiple use cases and works in different environments. Tom > > Regards > Sebastian > > > > > On Sat, Feb 10, 2024 at 7:42 AM Tom Herbert <tom=40herbertland.com@dmarc.ietf.org> wrote: > > On Fri, Feb 9, 2024 at 10:53 PM Nandita Dukkipati <nanditad@google.com> wrote: > > > > > > Hi Tom, > > > > > > We updated the draft, correcting some nit errata, and to not let the draft expire. It's not discussed in any other mailing lists. > > > > Thanks Nandita. > > > > I still have fundamental concerns about the protocol layering in this > > draft, please see my previous comments on that. The draft defines a > > protocol for end-to-end network to host signaling and IMO, such a > > protocol belongs in the network layer but the draft puts the protocol > > in L2 and L4 and seems to avoid L3 without explanation. IOAM defines a > > very similar method of signaling and RFC9486 is a good model for > > network layer protocol that provides network to host signaling. > > > > Tom > > > > > > > > Nandita > > > > > > On Thu, Feb 8, 2024 at 3:53 PM Tom Herbert <tom@herbertland.com> wrote: > > >> > > >> 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 > > > > _______________________________________________ > > iccrg mailing list > > iccrg@irtf.org > > https://mailman.irtf.org/mailman/listinfo/iccrg > > > > > > -- > > Thanks, > > --MM-- > > Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. >
- [ippm] New Internet Draft: Congestion Signaling (… Abhiram Ravi
- Re: [ippm] [tsvwg] New Internet Draft: Congestion… Tom Herbert
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Huangyihong (Rachel)
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Vidhi Goel
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Ruediger.Geib
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [CCWG] [iccrg] New Internet Dr… Abhiram Ravi
- Re: [ippm] New Internet Draft: Congestion Signali… Tal Mizrahi
- Re: [ippm] [tsvwg] New Internet Draft: Congestion… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Ingemar Johansson S
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Ingemar Johansson S
- Re: [ippm] [tsvwg] New Internet Draft: Congestion… Nandita Dukkipati
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Shihang(Vincent)
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Neal Cardwell
- Re: [ippm] [tsvwg] New Internet Draft: Congestion… Tom Herbert
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Matt Mathis
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Jai Kumar
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Abhiram Ravi
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [CCWG] [iccrg] [tsvwg] New Internet Dr… Hesham ElBakoury
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Rodney W. Grimes
- Re: [ippm] [tsvwg] [CCWG] [iccrg] New Internet Dr… Gorry Fairhurst
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Jai Kumar
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Ingemar Johansson S
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Greg Mirsky
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Jai Kumar
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Jai Kumar
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Jai Kumar
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Christian Huitema
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Jai Kumar
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Jai Kumar
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [iccrg] [tsvwg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Tom Herbert
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Ruediger.Geib
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Sebastian Moeller
- Re: [ippm] [CCWG] [tsvwg] [iccrg] New Internet Dr… Zaheduzzaman Sarker (Nokia)
- Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Co… Gorry Fairhurst