Re: [apps-discuss] IETF technical plenary: the end of application protocols

Dave CROCKER <> Thu, 24 March 2011 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A56F28C0D0 for <>; Thu, 24 Mar 2011 08:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rmCF+0A3jEsO for <>; Thu, 24 Mar 2011 08:46:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6DC9E28C0CE for <>; Thu, 24 Mar 2011 08:46:29 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id p2OFltFB007327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2011 08:48:03 -0700
Message-ID: <>
Date: Thu, 24 Mar 2011 16:47:38 +0100
From: Dave CROCKER <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Pete Resnick <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Thu, 24 Mar 2011 08:48:04 -0700 (PDT)
Cc: Apps Discuss <>
Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Mar 2011 15:46:30 -0000

On 3/24/2011 3:52 PM, Pete Resnick wrote:
> 1. Most people came to the Internet via the web. They never had much exposure
> to, let alone use for, other facilities provided. So they think about things
> through a web lens. NATs coming in didn't *have* to force people into
> client-server mode; it simply kept them there and kept them from seeing the
> other possibilities.

I'll suggest that NAT's are irrelevant to the choice of client/server vs. 
peer-to-peer.  I used to assume that peer-to-peer meant "direct" exchange 
between peers but it was pointed out to me that it merely refers to either being 
able to initiate an exchange.  Witness instant messaging.

That IM and such services are /mediated/ means that below the /logically/ direct 
exchange there is a relaying service.  This is the same as pretending that TCP 
is "direct" in spite of having the layer below mediate.

The appeal of client/server is simplicity.  Distributed architecture are more 
difficult to design, build, debug and operate.

Vendors prefer stovepipe solutions because it improves the vendor's control and 
it makes their life simpler.  Venders do not typically engage in open and 
distributed systems because they like them.  They engage in them due to market 

DEC, IBM and Microsoft gave up their proprietary network protocols only when it 
was clear they had no choice.  At that, vendors still try to add proprietary 
tweaks with the (sometimes valid) claimes of improved functionality, but also 
with the awareness that it buys them back some user lock-in.

> 2. Don't confuse market forces for what people actually desire. People don't
> know what they want or desire until they understand what is available. If we


> 4. Finally, be careful about layer violations. Whatever people want, it is
> likely above layer 7.

Or, rather, within it.  Layer 7 is increasingly looking as if it might have 7 

>>     Whatever the reason, most people don't want to run their
>>     own services -- it's much easier to visit a website, and tell people
> People do seem fully capable to grasp "Here is my phone number, you can reach me
> here" and do at least that particular kind of peer-to-peer communication. There
> is no reason that IM or email or blogging *have* to be a service; it's a remnant
> of being pre-disposed to client-server models (including, BTW, DNS).

This is almost certainly not correct.  There are operational details required 
for these things to be useful.  Someone has to do that work.  It takes effort 
and skill.

An indicator of market maturation is that end users can, do and even must 
offload much of that effort and skill to others called experts and/or providers.

The critical questions are

      1) Do they have a reasonable choice of who they can offload to?

      2) Can the user switch to a new service easily?
         (vs. lock-in)

      3) Is there reasonable interoperability among the providers?

      4) Is there reasonable interoperability among the users.
         (reachability and data exchange.)

> Chicken/egg. There's great incentive for those large entities to maintain the
> model that is making them money. I'm not convinced it's user wishes that keep
> things the way they are,


>> I hope we can have a real discussion in Prague, without too much grandstanding.
> It's going to be difficult. I can say for myself that I've been pushing for a
> deeper discussion (and getting it in many places), but the "death of application
> protocols predicted" tone of the abstract was a bit of grandstanding itself,
> IMO. Not too conducive to rational conversation.


It is also discouraging to see narrow concerns being, instead, interpreted as 
broad rejections.


   Dave Crocker
   Brandenburg InternetWorking