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

Leslie Daigle <leslie@thinkingcat.com> Tue, 22 March 2011 20:09 UTC

Return-Path: <leslie@thinkingcat.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 37C7D28C17A for <apps-discuss@core3.amsl.com>; Tue, 22 Mar 2011 13:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id MDRmZZfI3czX for <apps-discuss@core3.amsl.com>; Tue, 22 Mar 2011 13:09:12 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net []) by core3.amsl.com (Postfix) with ESMTP id 3924328C176 for <apps-discuss@ietf.org>; Tue, 22 Mar 2011 13:09:12 -0700 (PDT)
Received: from cashmere.local ([::ffff:]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 22 Mar 2011 16:10:44 -0400 id 00018054.4D890244.00006CEB
Message-ID: <4D89023C.4090307@thinkingcat.com>
Date: Tue, 22 Mar 2011 16:10:36 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Thunderbird (Macintosh/20070728)
MIME-Version: 1.0
To: Apps Discuss <apps-discuss@ietf.org>
References: <4D87612E.3090900@dcrocker.net> <4D881C04.2080406@qualcomm.com>
In-Reply-To: <4D881C04.2080406@qualcomm.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [apps-discuss] IETF-port-80 technical plenary Re: IETF technical plenary: the end of application protocols
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2011 20:09:14 -0000

So, this is the IETF-port-80 tech plenary?  Can't wait for hosts2-ns in 
Quebec City ;-)

IMO, the approach outlined in the plenary plan makes (and, ultimately, 
would entrench) an unwarranted distinction between clients and servers 
as devices on the Internet.  Clients do IMAP to get mail, but SMTP is an 
Application protocol for inter-server mail transfer.  The Internet has 
actually flourished _because_ any client could be a server.  In that 
vein -- not all transaction models are supported in HTTP, so overlaying 
all applications could be expensive and ineffective.

So, while I don't doubt there will be more of this type of HTTP-embedded 
application work,  IMO it should not be conflated with the totality of 
Internet application/infrastructure standardization.

In general, the IETF has done application _transport_ protocols (HTTP, 
and XMPP for that matter), and infrastructure (naming -- URLs, URNs 
etc).    This is particularly evident in the split of HTML off to the 
W3C - which made sense, because the expertise required was different, 
the focus much more on the end-user requirements than the network 
realities.  (And, HTTP remains at the IETF because its revisions benefit 
from the IETF's much broader understanding and expertise of transport 
issues is the most important aspect to bring to bear on it).  So, making 
this a call to action around the IETF's application standardization 
activity seems a little incomplete.

If this rises to the level of the IAB's attention, I'd like to think the 
IAB would manage to have that broader perspective -- not necessarily of 
application protocols or their structure, but the fact that the Internet 
of the future is going to be a very diverse place (still) and is not 
just about clients and servers as we commonly conceive them (notebooks, 
desktops, etc).

In November, I had the opportunity to participate in some discussions 
about the shape of the future Internet, in terms of devices:  i.e., 
handhelds and other untethered devices.  The current and ongoing 
constraints of those devices make for an interesting landscape for the 
Internet of the future.  Ted alluded to some of them in his remarks in 
this thread.  I wrote up some of my perspective on the landscape, in 
terms of untethered devices and the implications of/for RFCs 1122/1123, 
here:  http://isoc.org/wp/ietfjournal/?p=2185#more-2185  .  I think 
those documents represent pretty sound "first principles", and concluded 

"Diversity and openness remain critical in Internet deployment, in order 
to continue to foster innovation. 1122/23 stress the importance of 
recognizing that individual networks would be set up and operated 
according to local design choices. The open Internetwork application 
framework is what has permitted the creation of novel applications 
without requiring permission from network operators or device 
manufacturers for deployment. The World Wide Web was one such idea that 
took hold like wildfire. Time and again, users and usage of Internet 
have laid the groundwork for the Internet’s evolution, not some master 
control. It’s important to retain the ability to support that kind of 
innovation and open experience, as provided for in the hosts 
requirements in 1122/23. In that light, the notion of an open standard 
“split node” model, with individual users establishing and controlling 
preferences for policies, would allow more growth and innovation than, 
for instance, “one size fits all” policy assumptions implemented as 
network operator private controls.

In the end, then, it’s clear the future Internet will support many users 
and uses based on untethered devices, and thus feature hosts that exceed 
the expectations of 1122/23. But the framework in those documents is 
sound: provide a set of requirements for interoperation at the transport 
and application levels, and unfettered innovation will follow. Time will 
tell whether the requirements of hosts are updated to accommodate the 
practical realities of power and bandwidth constraints understood with 
untethered devices, or whether the “host” will become some tethered 
server supporting multiple roaming devices, for example. The only wrong 
choice is no choice at all."

which seems applicable here.


Pete Resnick wrote:
> On 3/21/11 9:31 AM, Dave CROCKER wrote:
>> Folks,
>> I just saw the announcement for the Technical Plenary presentation.
> I sent this to the IAB a few weeks ago. We haven't had much conversation 
> (they responded, but the firehose of stuff before the IETF meeting kept 
> me from replying until recently), but I thought you all would be amused.
> -------- Original Message --------
> Message-ID: <4D76B361.2050704@qualcomm.com>
> Date: Tue, 8 Mar 2011 16:53:21 -0600
> From: Pete Resnick <presnick@qualcomm.com>
> To: <iab@iab.org>
> Subject: IAB Technical Session
> CC: "'The IESG'" <iesg@ietf.org>
> [Feel free to forward this as you see fit.]
> Dear IAB,
> You will probably find it unsurprising that I find the abstract of the 
> technical session at the IAB plenary to be completely unadulterated 
> rubbish. It is by no means the "advancement in the design of web 
> browsers" nor the "widespread availability and growing sophistication of 
> JavaScript interpreters in browsers" that has changed the architecture 
> of applications. Quite the contrary, it is the forcing of a particular 
> application paradigm, that of requiring all applications to be 
> client-server based with all intelligence based in the server, that has 
> in turn forced Javascript sophistication to increase to accommodate 
> complex application logic inside the browser. (Indeed, it is this force 
> that has led to HyBi, the abomination whereby browser-based 
> applications, instead of being able to simply open a TCP connection, are 
> forced to go through an HTTP tunnel to the web server in order to get 
> any kind of network connectivity.) Protocols like POP and IMAP are not 
> being subsumed into these systems. Rather, the semantics of these 
> protocols are being dumbed down, eliminating functionality, in order to 
> allow them to fit into the new constrained environment.
> 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.
> This is not a state of affairs in which we need to "identify areas where 
> the standardization is unlikely to be relevant in the future, and focus 
> our efforts on those areas where our application designs will remain 
> impactful." Rather, we need to do what we can with tools we are 
> currently developing (the deployment of IPv6, the use of MPTCP and other 
> protocols which allow us to route around the damage to the end-to-end 
> model) to combat this model and have the Internet remain a distributed 
> end-to-end network.
> Back to La Mancha. I've been noticing these windmills....
> pr


      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle