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

[Tom Herbert <[e-mail]>]

On Sun, Feb 18, 2024 at 9:14 AM Jai Kumar <[e-mail]> wrote:
>
> Hello Tom,
>
> As a major switch vendor provider, I can with confidence say that your statement is not correct.
> Quote:
> “ we insert more information into L2 that makes it a variable length header which actually makes processing *harder*, not easier especially for legacy devices that don't support CSIG.”
>
> Layer 3 parsing is much more complex specifically when packet traverses thru multiple tunnel domains where packet need to be encap’ed or decap’ed. Not only the parsing gets impacted, transit nodes need to worry about checksum and/or encrypted, auth packet as well.

Jai,

Those cases do not affect Layer 3 parsing at intermediate nodes.
Packets are forwarded based on the addresses in the outer network
layers in the presence of tunnels. If the argument is that updating
the IPv4 header checksum is too much trouble then use IPv6 or just
make your network one big Ethernet domain and switch on Ethernet E2E.
In the latter case you may as well make the return path go over L2 to
make the protocol symmetric in both directions; that solves the
multiple upper layer protocols problem and you wouldn't even need to
take the proposal to IETF at all  :-).

>
> HW implement is one of the challenges IOAM is facing and that’s why it has such a sparse (or no) support from switch vendors.

I'll let the IOAM and Segment Routing advocates respond to that.

Tom

>
> Keeping CSIG in layer 2 or 2.5 (like MPLS) simplifies complexity of hw implementation by multitude.
>
> Best,
> -Jai
>
>
> > On Feb 18, 2024, at 8:49 AM, Tom Herbert <[e-mail]> wrote:
> >
> > On Sat, Feb 17, 2024 at 11:17 AM Matt Mathis
> > <[e-mail]> wrote:
> >>
> >
> > Hi Matt,
> >
> >> I think the L2/L4 split is brilliant.
> >
> > As opposed to the L1-L7 split being brilliant? :-)
> >
> >> Putting the forward instrumentation as low as possible in the stack permits easy processing in HW w/o parsing any L3.
> >
> > A switch is already doing IP routing which requires parsing of L3. If
> > we insert more information into L2 that makes it a variable length
> > header which actually makes processing *harder*, not easier,
> > especially for legacy devices that don't support CSIG. If this is done
> > in a Hop-by-Hop Option, then all the protocols a router looks at are
> > at fixed offsets and fixed length (Ethernet header could be at offset
> > 0, IPv6 header is at offset 14, and the CSIG information is at offset
> > 54)-- that's the best case scenario for Hw router processing.
> >
> >> Putting the replies in L4 only requires a handful of implementations to cover all possible paths,
> >
> > I'm not sure "a handful of implementations" could cover all possible
> > paths. The draft only talks about TCP and QUIC, but that is hardly a
> > complete set of protocols-- there's RTP, GTP, ROCEE, and various
> > tunneling protocols to name a few. On the other hand, if this
> > information is in the Network layer then there are at most two
> > protocols that need to be extended: IPv4 and IPv6. This also true at
> > the link layer, this proposal would need to extend Ethernet, Mobile,
> > and tunnels. The fundamental premise of a network layer protocol is
> > that it works with *any* transport layer above it, and *any* link
> > layer protocol below it (that to me is the brilliant thing :-) ).
> >
> >> and piggybacks on existing solutions to session layer issues, such as authentication and authorization.
> >
> > But that only considers the return path of the signals, not the
> > forward path so it could only solve half the problem. If the forward
> > path is in L2 then we can't leverage Internet protocols for
> > authentication (maybe there's ways to do this at L2 but then we have
> > to consider every L2 protocol and regardless the the path
> > characteristics are very different in both directions of
> > communications and the protocols aren't even under the same SDO). If
> > we use L3 in both directions then we can leverage all of the IETF
> > protocols. For instance, if E2E authentication is required, then it's
> > just a matter of using AH in both directions (note the presence of AH
> > in packet doesn't affect router processing).
> >
> >>
> >> 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.
> >
> > There have been a *lot* of discussions and work in IETF on how to
> > optimize router processing for network to host signaling like this
> > draft is proposing.  Please look at IOAM, the work being done in 6man
> > to make Hop-by-Hop Options viable, and work done in tunneling
> > protocols that are intended to be processed in HW.
> >
> > Tom
> >
> >>
> >>> On Sat, Feb 10, 2024 at 7:42 AM Tom Herbert <tom=[e-mail]> wrote:
> >>>
> >>> On Fri, Feb 9, 2024 at 10:53 PM Nandita Dukkipati <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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=[e-mail]> wrote:
> >>>>>>>
> >>>>>>> Hi IPPM folks,
> >>>>>>>
> >>>>>>> I am pleased to announce the publication of a new internet draft, Congestion Signaling (CSIG): https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ravi-ippm-csig/&source=gmail-imap&ust=1708879744000000&usg=AOvVaw2NqlnBohcTmRfPfCpkG028
> >>>>>>>
> >>>>>>> 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
> >>> [e-mail]
> >>> https://www.google.com/url?q=https://mailman.irtf.org/mailman/listinfo/iccrg&source=gmail-imap&ust=1708879744000000&usg=AOvVaw1WMuz9B16Iot8u2lJtzb-U
> >>
> >>
> >>
> >> --
> >> Thanks,
> >> --MM--
> >> Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.
>
> --
> This electronic communication and the information and any files transmitted
> with it, or attached to it, are confidential and are intended solely for
> the use of the individual or entity to whom it is addressed and may contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are
> not the intended recipient or the person responsible for delivering the
> e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.