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

Scott Brim <> Tue, 22 March 2011 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 108CB28C0EC for <>; Tue, 22 Mar 2011 06:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.579
X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZbIa1jCkolKc for <>; Tue, 22 Mar 2011 06:39:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D0953A6844 for <>; Tue, 22 Mar 2011 06:39:55 -0700 (PDT)
Received: by iyi12 with SMTP id 12so8750590iyi.31 for <>; Tue, 22 Mar 2011 06:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p+XVbr8Y+3UUuq3Q0lmwd6dTUtzE5HEzSccaw1UCyhg=; b=knu+EOHhNqYkYEkfUt32rAB1ZBoHmA9Sz3boWkm2yd6XGcm5E0zDx6ef5aCpl7SXXP NvbSbQAq21RiDXOlCFi2yVxf7DIgwDG/P+OtRlWhVJBUlmHrlAxgTG8zQBZu6PqRoHq2 cwM3mq09ftjhv3lRvfZ9x08iYA1eIIfEdAp1s=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ace/QTtmbrP3WqhNQjm1MB/PyVqnnbZh34vMDa1BAtECsw/s5BEkKLXsteQHmaSQys lTbAXgzArw7/IrgNM58e8OvBA/nlf5CKzOTLhm4nrEh8ple5VGIwWtk89+d1oXfBfp2k XuZk1zkt2Gyi4vrzMUGGzqypruaJ/yc1+fMAc=
Received: by with SMTP id l4mr9232354ict.13.1300801285606; Tue, 22 Mar 2011 06:41:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 22 Mar 2011 06:41:05 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Scott Brim <>
Date: Tue, 22 Mar 2011 09:41:05 -0400
Message-ID: <>
To: Pete Resnick <>
Content-Type: text/plain; charset=ISO-8859-1
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: Tue, 22 Mar 2011 13:39:56 -0000

Pete: Yes, amusing.  I want to digress on one thing you said ...

On Mon, Mar 21, 2011 at 23:48, Pete Resnick <> wrote:
> There are two obvious drivers of this evolution: First and foremost is the
> continuing lack of end-to-end connectivity in the network. This is due to
> the presence of NATs and assorted firewall nonsense that makes non-tunneled
> applications harder and harder to deploy. But the second driving force is
> the more insidious one: economics. The economics of the Internet are
> currently being driven by big players consolidating the network, pushing as
> much as they can into servers so that they can control both the data and the
> user experience for applications on the Internet. This of course is not in
> the interest of end users, except insofar as the "big players" are end users
> with large economic interests. The more centralized the data becomes, the
> more dependent users are on the "big players", the less innovation in
> applications can take place, and the less stable the Internet is as a whole.

I think the causality is turned around several times in these sentences.

First, NATs did not force people into client-server mode.  If people
had had a strong desire for end-to-end transparency, we would have
more of it.  NATs started appearing and they didn't cut off anything
people saw as vital.  Some apps (e.g. FTP and Skype) adapted.  It is
now hard to preserve peer-to-peer, and get away from client-server,
partly because of NATs but mainly because the vast majority of people
find client-server to be convenient.  They like services.  If there
was more demand for transparency you would see more of it.

Second, yes economics, and yes the big boys are pushing to control
more, but that doesn't mean it is not in the interest of end users.
They like services.

So yes, architecturally we must fight to preserve peer-to-peer, but we
are not doing so because zillions of end users want us to; we are
doing so because we know better than they do what's good for them (and
the Internet).

Finally I don't see how having data centralized, or data flows between
fewer src/dst pairs, lowers stability of the Internet.