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

[Matt Mathis <[e-mail]>]

I think the L2/L4 split is brilliant.   Putting the forward instrumentation
as low as possible in the stack permits easy processing in HW w/o parsing
any L3.    Putting the replies in L4 only requires a handful of
implementations to cover all possible paths, and piggybacks on existing
solutions to session layer issues, such as authentication and authorization.

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.

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://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
> [e-mail]
> 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.