Re: [tsvwg] New Internet Draft: Congestion Signaling (CSIG)
Nandita Dukkipati <[email protected]> Fri, 9 Feb 2024 22:53:17 -0800
| Newsgroups | gmane.ietf.irtf.iccrg,gmane.ietf.ippm,gmane.ietf.tsvwg |
|---|---|
| Message-ID | <CAB_+Fg5McYXt=M5MNkuxHrKrXQgZMS6PLRoVeUKiSUe5Qb7LjA@mail.gmail.com> |
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 <[email protected]> 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 <[email protected]> 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= > [email protected]> 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 [email protected] https://mailman.irtf.org/mailman/listinfo/iccrg