Retiring IETF veteran warns: Stop adding so many damn protocols

A retiring veteran of the Internet Engineering Task Force (IETF) has left the organization with a departing piece of advice: stop creating so many protocols. Ross Callon was one of just 21 engineers who attended the first IETF meeting in San Diego in 1986 and has missed only a handful of the 95 subsequent meetings it has held …

[ecofeco]

Bloat

Bloat has become a huge problem in the IT industry in every field and it has very real consequences.

We're already seeing some of them.

[Mike Shepherd]

Re: Bloat

I agree that bloat (protocols and software) is a problem, but it's useful to ask why is the wheel so often re-invented?

Hardly anyone insists on writing their own strtok(), printf() etc. They know that the standard libraries are reliable. As for other software, it's typically ill-considered, confusing or badly-documented, so the right course often is to re-invent it. The result may be no better, but it's something you can understand and maintain.

Writing good library code is hard, as is designing a protocol to suit many purposes.

[Paul Crawford]

Re: Bloat

You would like to think that standard libraries are known, fixed and tested. Not when it comes to the IoT world where the mbed implementation of gmtime() is broken! And not fixed in over two years!

Says a lot about how well they develop and test IoT stuff, eh?

https://developer.mbed.org/questions/75856/Who-will-fix-the-mbed-system-gmtime-func/

https://github.com/ARMmbed/mbed-os/issues/1098

[Mike 16]

Re: Hardly anyone insists on writing their own strtok(),...

Actually, I created "my own" strtok(), although I admit you said "hardly anyone". Also, I created it because, back at that time, there were no freely usable implementations of the C standard library, and a few of us decided to fix that. And (almost) finally, I did it for "completeness", not because I or anyone I knew would be so barking mad as to _use_ strtok(), other than as a "reductio ad absurdum" to illustrate that _real_ character manipulation uses (pointer,count,position) structures, and doesn't poke holes in existing strings that someone else might be looking at.

And (really) finally, when I wrote a test suite (for all the functions in <string.h>) and ran it against all five commercial libraries I had access to, _none_ passed. Yeah, I verified that the failures were real, not just bugs in my test suite. I think of this every time someone opines how there are so many high quality fully tested libraries out there for pretty much every purpose. I have trouble believing that the clowns who have had bugs in memcmp() or memcpy() can somehow write a flawless network stack.

[Alan Johnson]

Re: Bloat - exceptions to every rule

"Hardly anyone insists on writing their own strtok(), printf()"

Hardly anyone insists on writing their own for no good reason but there often are good reasons. Printf is a large function, on embedded systems with limited memory this can be an issue and a cut down version with limited capabilities can help. Printf implementations often use dynamic (heap) memory which can be a major problem and printf implementations are not always thread safe, strtok() is rarely (never?) thread safe and you may not have strtok_r() available. Writing your own standard library functions may seem daft, and done for its own sake it is but there are often good reasons that make it essential.

[Flywheel]

Re: Bloat

"very real consequences"

In government circles they're called "jobs" *sigh*

[one crazy media]

Re: Bloat

IT folks have no clue about most of these protocols considering, most are happy with using Active Directory and MS proprietary crap.

Try talking to an IT person about protocol spec and you are going to get a glazed look in their eyes.

[DWRandolph]

and the very obligatory https://xkcd.com/927/

But there is always someone who thinks the little shiny they just built is sooooo muuuch betttteeer then anything else that sheer common sense dictates everyone re-architect to use it right away!

[Anonymous Coward]

Posting obligatory xkcd is a form of bloat.

[Dan 55]

Posting obligatory xkcd is a form of bloat.

Perhaps we could come up with a new lightweight caching protocol to fix that, like xkcd://927 ?

[Mike Lewis]

as well as the obligatory "The wonderful thing about standards is that there are so many of them to choose from" attributed to Grace Hopper, Andrew Tanenbaum, Patricia Seybold and Ken Olsen.

"The wonderful thing about sources of one quote about standards..."

[Anonymous Coward]

He's right...

Everyone agrees that community efforts are a good thing, but we all still want to do things "our" way. Because "our" way is best. Although they can be the best option for you, that does not automatically make them a viable candidate to become an official standard for everyone.

I think xkcd shows a good example of this ;)

[James Marten]

We're already there

Take a look at either /etc/services or /etc/protocols on a typical Unix system. How many of the ports/protocols listed there (a) have you ever heard of, or (b) will ever be seen on a typical LAN or over the Internet?

[Anonymous Coward]

Re: We're already there

Well.... >90% of /etc/services have been there for 20+ years, and are totally obsolete.

[Anonymous Coward]

He is right

Just go into the NVO3 group to see what he is talking about. 3 invented unnecessary transport protocols with no use cases and sole rationale "we need more evil bits in the header". No agreement for 5 years. No consensus. Complete and utter clusterf***... Or the L2VPN group which despite reasonably good management by its chairs still managed to degenerate into an Alcatel Featuritis. Or the remaining MPLS zombie meetings.

Or...

When he started to attend IETF it was attended by engineers. It is now attended by Dumb and Dumber standard droids from one well known Chinese vendor and by product managers from Microsoft and Vmware and which will never allow consensus if this means their "internal" resource in their own company being reduced.

Anon. For obvious reasons.

[Destroy All Monsters]

Re: He is right

WE NEED TO BUILD A WALL!

It's the same in the language area, really.

How many manhours and lives are currently burnt on the utterly unsecure and unmanageable WOMBAT and square wheel that is Node.js? We will be carrying the technical debt with us for decades.

Well, we do get flashy mobile-enabled websites with colorful hexagons (these are à la mode for some reason) which will be torn down tomorrow...

[Yes Me]

Re: He is right

He's right, up to a point (and I've known him personally since 1993). But he's wrong too: you can't stop people inventing new ideas; everything is binary, and binary trees are rather like fractals; so we can't stop this constant invention, we have to try and control it and manage it. Just Say No is not really an option. (And you should see how much crud is in fact laughed out of the IETF every year.)

[bazza]

Re: He is right

"He's right, up to a point (and I've known him personally since 1993). But he's wrong too: you can't stop people inventing new ideas;"

Well, we kinda do stop people inventing pointless new protocols and stuff, but only through ensuring they don't profit from them. For example, some IoT startup wanabe creates a whole load of proprietary stuff, and they're highly unlikely to develop into the next Apple or Google. In fact the problem we have is that there is Apple and Google, they have created their walled gardens, and no one else can get a piece of the action.

From the article:

"While diversity in approaches is inevitable and valuable, too many options damages interoperability," Callon observed according to a write-up of the talk in the IETF's most recent newsletter. "We have to be a little concerned about creating too many options because some vendors implement some, while some vendors implement others, and suddenly we don't have interoperability."

He's underdone it there; we should be gravely concerned about the decline of inter-operability. We have a lot of low level standards that work (http, ip, etc), but compatibility with those is not enough to ensure level competition between clouds and online service providers. A lot of new stuff has been built in recent years with the deliberate intent of walling in customers. Part of the problem is that no service of a brand new type can be inter-operable; it is inevitably in a class of 1. However as soon as someone else starts up a similar service there is zero value to the original provider to be inter-operable. And government is too lacking in technical understanding to see that these walled gardens are going to cost the consumer a lot of money. It's practically a license to gouge the market. Look at the "Apple Tax" you have to keep paying if you want to retain access to all that music you've bought in iTunes...

The industry has long since learned that bring a new service type to market 1st is key; quality doesn't really matter up to a point, but being first does. Lock those users in.

[Warm Braw]

Re: He is right

The IETF is just a place where people get together to try and get some traction for ideas they feel have technical (or, more latterly, marketing) merit. It's not really a surprise that if you let a thousand flowers bloom some will turn out to be persistent weeds. I think the problem is more that the supposed oversight body, the IAB, rather lost its bottle after the IPv6 debacle and hasn't really been able to fulfil its role of "constant gardener" ever since.

[AskOllie.com]

RFC1925

This was immortalised a bit over 20 years ago in RFC1925 - The Twelve Networking Truths

(12) In protocol design, perfection has been reached not when there

is nothing left to add, but when there is nothing left to take

away.

[Doctor Syntax]

Re: RFC1925

Which was written by Ross Callon himself.

I also like no 5:

It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

Pick your own examples.

[Steve Knox]

Yeah but no but yeah but

Ok, I agree with him in principle, but this:

"You can take an Internet Protocol (IP) packet and encapsulate it in an IP header. There are four options just for that: IPv4 in IPv4, IPv4 in IPv6, IPv6 in IPv4, and IPv6 in IPv6. Given all those options, it's hard to get one of them implemented and deployed everywhere."

is wrong on several counts.

First off, IPv4 and IPv6 are not different standards; they are different versions (editions if you will) of the IP standard.

Second, these four options are just the Cartesian product of the two versions. Want to make any list exponentially larger? Throw in a Cartesian product.

Third, each of these four options have clear uses, as defined by the capabilities of the host network and the desired capabilities of the virtual network.

There are a lot of unnecessary duplicate or overlapping standards out there. But the options for encapsulation of IP traffic over different versions of the standard don't deserve to be lumped in with them.

[Anonymous Coward]

Re: Yeah but no but yeah but

There wouldn't be *any* IP encapsulation options if IPv6 replaced IPv4 back in the 90s as intended. But IPv6 itself has some design flaws. One might call it... bloated.

[Fred Goldstein]

Re: Yeah but no but yeah but

Bloated is too nice a word. IPv6 was just a flat-out mistake, a political reaction by k1dd13z at IETF who could not accept a working, cleaner approach, TUBA, when it was approved as the new IP. TUBA was a profile of OSI CLNP and just the mere taint of OSI, even though it was the part of OSI that worked (came from DEC, not the CCITT), was enough to drive them as apoplectic as a Republican facing Obamacare. So the B-team was set out to write what became IPv6.

TUBA, of course, was originally proposed by Ross Callon.

[Notas Badoff]

Pride

Quick, how many languages were announced in each of the last five years? With "major industry backing" aka Google, Microsoft, Apple, Mozilla, AlsDeli, etc. (oEck, madly inadequate list)

This has been going on forever and the reasons why have always been more social than technical, prestige than practicality. Back in 60s Texaco Oil had their own programming language, TexTran. Because they needed a Texas-sized language?

I have to wonder if this all couldn't be summarized as "I'm going to win this campaign because my orcs have _six arms_ with blades for fingernails and eyes that shoot out porcupine quills! And they smell so bad everyone closer than 20 meters is incapacitated! And Gygax helped so I'll get the respect I deserve!"

[Anonymous Coward]

Done by Design

There is an assumption here that this isn't been done by design. You only have to look at how Google implemented their Privacy Checkup Software Tool.

The layout of Dialog boxes, Text off screen, Toggle switches, Confirmation Dialogs - to realise this is all by design, to make interoperability difficult/prevent something been achieved, in this case, turn off Google's snooping. This simple example shows how its become industrialised within Google, and applied to all aspects of their engineering.

[Anonymous Coward]

Just seeing the photo, I first thought "oh no, who has now committed terrible letter bomb acts, and been arrested". Luckily, it wan't anything like that.

[Anonymous Coward]

Hmmmm....

With every protocol & format having multiple stamps of standards compliance these days, I guess we have to raise our standards for standards. "Standard" is no longer enough. One must sift through the hype and bullshit to figure out what everyone will do in reality.

[one crazy media]

100% Correct

Most of them are not implemented or used by anyone. IT people don't have a clue about these protocols anyway.

IETF need to stop inventing useless protocols and concentrate making the existing protocols more robust and secure.

[energystar]

Every new Protocol...

Introduces stress to the Standard. Also to every already existent Protocol. The Standard was developed for a very specific Family of Protocols, and every new one -up to a certain point- BASTARDIZES, the former aims of the Standard.

[Daniel 18]

And then there are the marketing reasons

... when companies introduce more protocols in order to keep their users locked in a private walled garden, and force other companies to pay for access... and maybe cripple the protocols implemented by competitors, in the marketplace... and to provide ammunition for IP lawsuits.

[Fred Goldstein]

Ross has a good point, but it's endemic to the IETF way of doing business, and to the TCP/IP suite in general. It's all about specialized little protocols rather than looking for a general model. John Day recognized this over 20 years ago and began work on what became RINA, Recursive InterNetworking Architecture. It uses only two protocols and recurses them as many times as needed, no more no less, with many adjustable parameters for scope and requirements. Check out the IRATI and ICT-PRISTINE projects and the Pouzin Society sites:

http://www.pouzinsociety.org/

http://irati.eu/learn-rina-vs-the-current-internet-architecture/

It shrinks the complexity and code base requirement by orders of magnitude. And it's actually easier to adopt than IPv6, since it can support unmodified IP applications (as well as native ones using its single application protocol), or run inside an IP backbone if necessary.