Re: Is IETF is being shunned for new protocol development?

[Simon Leinen <[e-mail]>]

Tom Herbert writes:
> I think the thing that's new is the emergence of very specialized
> networking in limited domains. For a long time, it was an advantage to
> use the same protocols on the Internet as in private networks. That is
> getting harder to sustain since the requirements have substantially
> diverged to the extent that there's less incentive to keep  things in
> sync. We've always known that private networks can "do whatever they
> want", but nowadays there's a lot of pressure to do that en masse.

Even in this case I think I agree with Brian in that it isn't really
new.  There were always things like Infiniband or even more exotic
protocols that were specific to high-performance computing - but now
some of these escape their niche, because suddenly there's a
multi-trillion investment opportunity...

For the Ultra Ethernet case, I just found out that Hugh Holbrook was
centrally involved in it ("Chair of the Technical Advisory Committee,
Ultra Ethernet Consortium").  He has prior experience with the IETF as
an active participant[1], including as a WG Chair (SSM); maybe "we" (I
don't have his current address :-) could ask him whether the interested
parties had considered going to the IETF and why they decided to set up
a new consortium.  Perceived urgency vs. IETF speed could certainly have
been a reason, but there could be other important drivers.

> For instance, TCP has ruled the Internet for forty years. It is a
> great protocol for generic use cases. But in the world of AI, it is
> not so great (it's variable length, doesn't use packet sequence
> numbers, SACKs are verbose). So TCP is not going to be the transport
> protocol of choice for AI networks, something else is needed-- and
> it's needed quickly. AI is moving at breakneck speeds unlike anything
> we've ever imagined. They're talking about six month design cycles for
> new hardware in the datacenter, so a process to standardize a protocol
> that takes two years is a complete mismatch for that.

> Maybe it's an unsolvable problem, but I do believe it at least merits
> discussion.

I agree.  But again, the IETF has never been an undisputed leader for
standardization in all areas.  DC/HPC/storage networking standardization
always largely happened elsewhere, if I remember correctly.

Cheers,
-- 
Simon.
[1] https://datatracker.ietf.org/person/Hugh%20Holbrook

> Tom

>> 
>> To say it another way, the IETF is the bottom of an inverted pyramid and that means a lot of pressure.
>> 
>> ** I took it down some years ago, but the final version is attached.
>> Regards/Ngā mihi
>> Brian Carpenter
>> 
>> On 15-Jan-26 08:36, Tom Herbert wrote:
>> > Hello,
>> >
>> > FYI, I would like to share a letter I sent to IAB about a concern that
>> > IETF may be losing relevance particularly in AI networking.
>> > -----
>> > Dear IAB,
>> >
>> > I would like to bring to your attention a worrisome trend that IETF is
>> > being shunned as the SDO for developing an standandardizing new >=L3
>> > protocols particularly those needed for networking in AI
>> > infrastructure which is among the hottest segments for new protocol
>> > development.
>> >
>> > A good example is the protocols being developed by the Ultra Ethernet
>> > Consortium (UEC). UEC is acting as a new SDO aimed at developing scale
>> > out networking protocols for AI and HPC infrastructure. The name is
>> > misnomer; they are actively developing a suite of L2 to L7 protocols
>> > including an elaborate transport protocol encapsulated in UDP to
>> > support Remote Memory Operations.
>> >
>> > Another example is the Open Compute Project. Back in 2024 the
>> > Congestion Signaling draft was posted to the ippm working group.
>> > https://www.ietf.org/archive/id/draft-ravi-ippm-csig-01.html. While
>> > the draft has long since expired in IETF, the protocol is well
>> > deployed at least at Google I believe and there is hardware vendor
>> > support for the protocol. Standardization of CSIG is being done in
>> > either OCP (or UEC), but notably not the IETF.
>> >
>> > When I ask people  why they're not taking protocols to IETF, they give
>> > three reasons:
>> >
>> > 1) It takes too long for IETF to do anything
>> >
>> > 2) The process allows for anyone at anytime to raise objections and
>> > either bring progress to a grinding halt or sink a protocol outright
>> >
>> > 3) IETF can be too academic and not sufficiently focused on the
>> > realities of the real world
>> >
>> > I have seen each of these problems first hand so I do sympathize with
>> > those who are purposely avoiding IETF. On the other hand, I think they
>> > are throwing the "baby out with the bathwater"  so to speak since
>> > these alternate SDOs have yet to show better results. For instance, I
>> > believe the UEC specification would be in much better shape had it
>> > followed a few basic design principles that are espoused by IETF
>> > (here's my article on the problems with UEC protocol specification
>> > https://medium.com/@tom_84912/protocol-types-and-what-was-uec-thinking-66b525765577)
>> >
>> > Please take this into consideration, as I do worry that IETF could
>> > start to be left behind in the world of protocol development. I'm not
>> > sure how the concerns can be addressed, maybe there could be something
>> > like a streamlined standardization process for non-Internet wide
>> > protocols like those being developed for AI infrastructure? Also, I
>> > believe there's only one working group for AI, maybe it would make
>> > sense to have a Working Group specifically focused on networking
>> > protocols for AI infrastructure (I would note that OCP has completely
>> > pivoted to be AI focussed and they drew 12,000 people on-site to their
>> > 2025 conference-- that is mind blowing).
>> >
>> > Thanks,
>> > Tom
>> >