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

[Pete Resnick <[e-mail]>]

On 3/24/11 3:45 AM, Scott Brim wrote:
> On Wed, Mar 23, 2011 at 23:09, Peter Saint-Andre <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 3/22/11 7:41 AM, Scott Brim wrote:
>     > 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.
>

I think this is revisionist history. Let's separate out a couple of things:

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.

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 only look to what people find desirable or what they 
view as vital *now*, nothing new is ever created. Did people desire 
forms of communication other than what AT&T provided to them with POTS? 
And really, I challenge you to come up with some evidence that people 
find client-server to be convenient. I hear people complain about their 
web-app experiences all of the time. Do people actually want 
client-server, or do they simply not understand what they could have?

3. We have been spending literally years coming up with ways to work 
through server-based services (and through NATs) to provide people with 
peer-to-peer services. Indeed, several of the technologies that seem to 
be driving this discussion (WebSockets, RTCWEB, HYBI) are in response to 
a stated need for Javascript applications to talk peer-to-peer, 
bypassing the client-server model you say people desire. That seems to 
go against the position that people aren't interested in peer-to-peer 
applications. If so, we're just talking about delivery model and 
underlying protocols, not people's desires.

4. Finally, be careful about layer violations. Whatever people want, it 
is likely above layer 7. Even if we could establish that people like the 
idea of using a server-based model for their interactions (of which I am 
not convinced), that doesn't mean that the underlying network ought to 
reflect that architecture. In fact, it's probably a really bad idea. 
People liked (still like) the idea of point-to-point connections for 
their telephones. That doesn't mean that we should devote ourselves to 
moving away from packet switching. When we bump into circuit switching, 
we tunnel through it or route around it. Similar principles ought to 
apply here.

>     > 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.
>
>     Scott, I think there is a great deal of truth in what you say. The big
>     services have become big in large measure because most people seem to
>     prefer identifiable services. Perhaps it's the herd instinct or the
>     human inability to hold too many things in mind at once or the
>     simplicity of signing up for something and letting someone else handle
>     the details.
>

I think Peter is on to something. It is I think more about the herd 
instinct, if not a more hierarchical instinct. We don't seem to like 
anarchy. We like someone "in charge" to take care of things. However:

>     Whatever the reason, most people don't want to run their
>     own services -- it's much easier to visit a website, and tell people
>     that you're "on", a popular email or IM or blogging or
>     microblogging or
>     voice or video service than it is to install and maintain postfix or
>     Prosody or WordPress or laconica or Asterisk or Yate on the server
>     side
>     plus Thunderbird or Pidgin or Jitsi (etc.) on the client side (let
>     alone
>     the whole stack of OS and DNS and databases and registered domains and
>     certificates and all the rest).
>

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).

>     So yes, services are easy and popular with end users. As a result, the
>     companies that offer those services often become large and even
>     dominant
>     on the 'net. At that point some of the dynamics that Pete
>     mentioned come
>     into play, but I don't think they are the root cause.
>

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, anymore than I think it's 
user wishes that keep certain things on television. You can get people 
to watch all sorts of nonsense TV, but that doesn't (in and of itself) 
mean that they actually aspire to watch it.

> 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.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: [phone], Fax: [phone]