Reinventing the wheel (Re: ISSUE: Meeting scheduling)

Harald Tveit Alvestrand harald at alvestrand.no
Sat Jun 28 12:07:31 CEST 2003


--On 27. juni 2003 09:53 -0700 "Hallam-Baker, Phillip" 
<pbaker at verisign.com> wrote:

> There are a lot of complaints about groups re-inventing stuff that has
> existed before. But the mechanisms for communicating are limited and tend
> to be unidirectional. There is no way to ask why people have to reinvent.

actually there is ..... you can ask them.

We even did this formally some time ago - we had a BOF in Salt Lake City (I 
think) dedicated to "why do people invent UDP-based protocols".

As I remember, it was fairly entertaining, including people who said "next 
time I'll use TCP, so I don't have to bother adding all its stuff back into 
the protocol later"......

> Take a case in point, use of UDP for short transactional messages. TCP/IP
> is fine for longstanding persistent connections. It is clumsy and
> unsatisfactory for short term connections that require perhaps one to four
> packets in each direction in a simple request/response format. It should
> not be a surprise that people keep reinventing this type of mechanism, it
> is supported by a valid engineering requirement.

Old fogey mode.......

People tend to forget things like Belsnes' old proof that if you need two 
parties to exchange data, and both ends have to know that the data has been 
successfully transferred, it is IMPOSSIBLE to do it in less than five 
packets. Just because something's an engineering requirement doesn't mean 
it's possible. (the even older fogies will no doubt correct me if I got the 
details wrong....)

And, of course, networks have been brought to their knees by UDP-based 
"simple" protocols that just didn't think about congestion. I've had to 
debug some of those situations.

(DNS works because a server doesn't care whether the client got the answer 
or not - it's the client's business. But not all "quick" protocols are 
allowed to be that careless...)

Mumble.... I sometimes wonder whether part of our structural problem is 
that neither the IETF nor any other organization in the world (AFAIK) 
really teaches protocol design as an engineering skill.

               Harald



More information about the Problem-statement mailing list