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

[Tom Herbert <[e-mail]>]

On Thu, Jan 15, 2026, 5:24 AM Antoine FRESSANCOURT <antoine.fressancourt=
[e-mail]> wrote:

> Hello Tom,
>
> I see the work you are referring to in UEC, but what are you referring to
> in OCP's realm? I see several network related projects on OCP's site, but I
> admit I am ignorant of protocol work done in OCP.
>

Hi Antoine,

Take a look at ESUN in OCP. They are developing a new network layer header
for use in scale-up networks. The perceived problem is that IP is too much
overhead. It's really the IP header plus UDP header since convention is
that new transport protocols are encapsulated in UDP. There is a four byte
header proposed that would be used instead of 28 or 48 bytes for IP v4/v6.

Tom


> Best regards,
>
> Antoine
>
> -----Original Message-----
> From: Tom Herbert <tom=[e-mail]>
> Sent: Wednesday, January 14, 2026 10:51 PM
> To: Miles Fidelman <[e-mail]>
> Cc: Bob Hinden <[e-mail]>; IETF-Discussion <[e-mail]>
> Subject: Re: Is IETF is being shunned for new protocol development?
>
> On Wed, Jan 14, 2026 at 1:43 PM Miles Fidelman <
> [e-mail]> wrote:
> >
> >
> > It strikes me that the three most noticeable digressions from IETF are
> the IEEE 802 standards, W3C, and WHATWG.
>
> Hi MIles,
>
> Take a look at UEC and OCP. They are proposing new L3-L4 protocols that
> are not interoperable with IETF protocols.
>
> Tom
>
> >
> > IEEE is understandable, given their long-standing involvement as a
> standards body in the electrical engineering space.  W3C, not as clear why
> it exists.  And WHATWG is kind of a mystery - why isn't W3C isn't the
> standards body for HTML.
> >
> > Miles
> >
> >
> > ________________________________
> > From: Tom Herbert <tom=[e-mail]>
> > Sent: Wednesday, January 14, 2026 4:32 PM
> > To: Bob Hinden <[e-mail]>
> > Cc: IETF-Discussion <[e-mail]>
> > Subject: Re: Is IETF is being shunned for new protocol development?
> >
> > On Wed, Jan 14, 2026 at 1:00 PM Bob Hinden <[e-mail]> wrote:
> > >
> > > Hi,
> > >
> > > > On Jan 14, 2026, at 12:06 PM, Brian E Carpenter <
> [e-mail]> wrote:
> > > >
> > > > Tom,
> > > >
> > > > To be honest I don't think you're wrong but I don't think there is
> anything new here. Twenty years or so ago I used to keep a list of other
> SDOs in the networking arena, until it became too boring to maintain**.
> Once we get above layer 4, it's always been unclear what fits into the IETF
> remit and what doesn't. That's why the Apps area (which is called something
> else at the moment) keeps getting reorganized and renamed every few years.
> The same is true of the Transport area but less so, which is why it gets
> reorganized and renamed less often.
> > >
> > > Similar, I don’t think there is anything new here or wrong.   There
> are lots of reasons why some other networking organization gets formed, but
> I think a lot of it is about control, paid membership, IPR, etc. that
> doesn’t match how the IETF works.   These groups tend to come and go, but
> the IETF keeps going.
> >
> > Bob,
> >
> > Let me give an example that is near and dear to your heart. Congestion
> > Signalling (CSIG) is described in draft-ravi-ippm-csig-01. At each hop
> > in the path the router can place congestion information in a header.
> > Sounds just like a job for Hop-by-Hop options right? Except that they
> > aren't using HBH, they're putting the information in VLANs even though
> > VLANs aren't routable (they hack things to make it routable). CSIG is
> > well deployed and supported by at least one hardware. And if the VLAN
> > technique is used for CSIG then it's likely the same technique will be
> > used for other cases of host to network and network to host signaling.
> > IMO, Hop-by-Hop options are technically a better solution, but they're
> > being avoided for non-technical reasons.
> >
> > Tom
> >
> > >
> > > Bob
> > >
> > >
> > >
> > > >
> > > > 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
> > > > <orgs.html>
> > >
> >
>
>
>