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

[Tom Herbert <[e-mail]>]

On Tue, Feb 20, 2024 at 1:02 PM Jai Kumar <[e-mail]> wrote:
>
> Thank you for a lively discussion.
>
> I just want to add a few more points in favor of using CSIG in L2.
>
> As we are trending towards high performance ethernet fabric for HPC and AI/ML clusters, there are innovations happening in both link layer and layer 3 headers. Amongst many some of the key requirements are
> - minimal and constant overhead (in CSIG it is a fixed 16bit TPID, where as for IOAM IPv4 packets if I recall it is a GRE header encapsulation and for v6 it is Hop by Hop option)

Please see the solution I proposed (again not IOAM). This could be
done effectively as a fixed size header consisting of 14 byte Ethernet
header, 20 byte IPv6 header, and 8 byte HBH Options containing a CSIG
option. As I mentioned, hardware can identify these headers from
fields as fixed offsets, and otherwise assume that all the fields that
need to be processed are at fixed offsets in the packet.

> - independence from layer 3 transport. So that it can work in legacy IP networks or in optimized networks where there MAY be some form of compressed headers present.

By legacy, I assume you mean IPv4? There are some approaches that
could be applied (draft-herbert-ipv4-eh or maybe a lightweight
encapsulation protocol).

Also, while independence for L3 transport might be a goal, as I
already pointed out there are at most only two L3 protocols we need to
worry about: IPv6 and IPv4. If the information is L2 then we have to
map that into the different L2 technologies-- so IMO, avoiding
dependence on L2 would be a better goal to constrain complexity of the
solution. This is also true for the upper layer >=L4. Right now the
draft is dependent on L4 or higher to reflect the signal. If we put
this information in L3, then we again only have to worry how to do
this for the two IP protocols.

> - low latency hw implementation. AI/ML clusters are latency sensitive for inference and demands <.20us switch latency.

Please look at the format I proposed. I don't offhand see anything
that would make processing any slower than putting the information in
L2. Again, everything needed could be at fixed offsets and mapping the
packet to the format for processing is a matter of comparing a few
fields in the parsing buffer (and most of those fields are probably
already checked for normal forwarding anyway).

> - decoupling of congestion signaling from transport. One such example is the Ultra Ethernet Transport proposed in UEC. Reflection for source based congestion control is in purview of transport as and when needed.

But reflecting the information doesn't decouple congestion signaling
from transport. This is the reason why the reflected signal should be
in L3.

> - fixed offset and constant header variance for v4 or v6 frames for both low latency and future proofing for any innovation happening in these layers. Note that these clusters are not L2 bridged domains and are mostly L3 routed domains.

This is where I don't understand how an L2 solution can work
end-to-end. If clusters are L3 routed domains then how does
information in an L2 header get propagated through an L3 switch?

> Though we talk about vxlan tunnels in AI/ML or HPC clusters but that is still a couple of years away. So the argument of variable layer 2 headers is a weak argument.

But in that argument you're assuming the use of the protocol is just
in high performance AI/ML or HPC clusters. We get much better utility
out of developing protocols with a variety of use cases. For instance,
I think CSIG will be very high value in 6G networks which will have
different characteristics and probably heterogeneous L2 in the path.

>
> I think the draft makes it clear that applicability of the proposal is DC focussed.
>

Sure, a lot of great protocols start with a narrow use case :-)

> Tom,
> Also, there is a discussion and presentation done before talking about the HW complexity and merits/demerits of encapsulating a v4 packet in IOAM GRE header and more. It should be present in archives.

Still haven't found it. Maybe I'm looking in the wrong archives?

Tom

>
> Best,
> -Jai
>
>
>
>
> On Tue, Feb 20, 2024 at 12:35 PM Sebastian Moeller <[e-mail]> wrote:
>>
>> Hi Tom,
>>
>>
>> > On 20. Feb 2024, at 21:26, Tom Herbert <[e-mail]> wrote:
>> >
>> > On Tue, Feb 20, 2024 at 12:09 PM Christian Huitema <[e-mail]> wrote:
>> >>
>> >>
>> >>
>> >> On 2/20/2024 9:55 AM, Sebastian Moeller wrote:
>> >>>> That's more of a statement of security and not feasibility. There's simply no security in the Internet, so we cannot trust or validate that anonymous intermediate nodes are going to write correct information. Any plain text in a packet on the Internet is subject to inspection and modification if the data isn't authenticated, and in the worst case this could be a DoS vector by writing bad information.
>> >>> [SM3] Indeed, but e.g. for TCP you would need to know a lot about the most recent packet to be able to play games, no? So either you are on path and already can drop/duplicate packets at will or you are off path but still need a recent enough veridical packet to be able cause mischief, no? (I might be insufficiently creative in attack vectors)
>> >>
>> >> I am analysis congestion control information using the framework of
>> >> "honest signals". In human communication, "honest signals" are those
>> >> that cannot be easily faked by the communicator. For example, smiling is
>> >> not really a honest signal, because it is easy to fake; blushing, on the
>> >> other hand, is hard to fake.
>> >>
>> >> When it come to Internet wide congestion control, we have pretty much
>> >> the same issue. Networks may want to fool the application for a variety
>> >> of reasons, and may start faking congestion signals. Some of these
>> >> signals are hard to fake. End to end data rate for example: slowing a
>> >> specific stream of packets is hard to fake; measuring the end to end
>> >> data rate is a pretty good indication of the state of the network. End
>> >> to end RTT is also a rather honest signal: yes, routers could put some
>> >> specific packets in a slow queue, but that requires resource.
>> >>
>> >> Packet losses almost belong in that category. They are not hard to fake,
>> >> routers could play favorites and selectively drop packets with a certain
>> >> profile. But dropping too many packets affects the "quality rating" of a
>> >> provider, so there is some pressure to not fake it. That pressure is
>> >> probably one of the reasons behind bufferbloat. The main problem with
>> >> packet loss as a signal is that losses may have other causes than
>> >> congestion.
>> >>
>> >> ECN is not really a honest signal. Setting a bit in a packet header does
>> >> not require a lot of efforts, so routers could do that to play
>> >> favorites. In fact, past bugs in some networks caused almost all packets
>> >> to be marked as CE. Using ECN is very nice when you can trust it, but
>> >> end nodes should probably do that cautiously, detecting for example a
>> >> sudden raise in ECN marks rather than reacting to an average value.
>> >>
>> >> ECN is just one bit. There is always a temptation to do a better ECN
>> >> with many more bits. For example, CE directs a sender to slow down. It
>> >> would be nice to have a corresponding "All clear" signal telling the
>> >> senders that they can speed up. L4S attempts to do that by modulating
>> >> the CE bit, so that a low frequency kinda indicates "all clear", while a
>> >> high frequency says "slow down", and give some indication of how much.
>> >> Suddenly, one bit becomes several bits, just spread over many packets.
>> >>
>> >> The idea of adding more bits in packet headers is not exactly new -- see
>> >> for example TCP QUIC Start by Sally Floyd et al., RFC 4782, January
>> >> 2007. The problem is that the more bits you add, the more you exacerbate
>> >> issues of trust, and also risks of bugs. "Many more bits" may work in a
>> >> controlled environment, but I really do not see that working on the
>> >> whole Internet.
>> >
>> > Hi Christian,
>> >
>> > Do you know what the state of ECN deployment over the Internet is?
>>
>> [SM5] Nobody knows exactly, but quite a lot of Linux servers use the LInux defaults and will use ECN if the client negotiates it. In my qdisc statistics I routinely see not only drops, but also CE marks logged (from my AQM).... so believe it or not, ECN over the internet mostly works...
>>
>>
>> > It seems to me that if someone is sending to an arbitrary host over the
>> > Internet they're already pretty much accepting "best effort" service:
>>
>> [SM5] Not sure about the US, but that is all ISPs offer to end users over here... but ECN works well even over a best effort internet access link in my personal experience.
>>
>> > long latencies and with potentially high variance, such that getting
>> > fined grained congestion information from intermediate routers, even
>> > if it's honest, probably doesn't add much to the information that we
>> > can derive from packet loss or measuring RTT with no additional
>> > mechanisms or implementation.
>>
>> [SM5] How can you come to that conclusion without ever trying?
>>
>>
>> > The situation is very different in a limited domain which could
>> > include large service provider networks.
>>
>> [SM5] Indeed, papers discussion 'better congestion signalling' often come out of those environments. But IMHO not because these methods only help in those environments, but that this is where people are willing to spend the money to test and implement potential solutions.
>>
>> Sebastian
>>
>> > In that case more information
>> > is good, it's easier to provide security so we can trust the
>> > information, and we're not restricted to just one or two bits of
>> > information to carry the information in a packet. This is also where I
>> > see host-to-network signaling being useful-- this allows applications
>> > to request QoS for their packets
>>
>> >
>> > Tom
>> >
>> >>
>> >> -- Christian Huitema
>>
>>
>
> 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.