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

[Tom Herbert <[e-mail]>]

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://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.