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

[Nandita Dukkipati <[e-mail]>]

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.

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
>