Subject: [Simple] client/server standards, was: Re: Comments on draft-ietf-simple-intradomain-federation

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Mar 2009 11:32:08 -0400

thanks for the review, Adam. One rant below, which is orthogonal from 
the rest of this really, and so I am splitting this off from responses 
to the rest of your comments:

Adam Roach wrote:
> I have been asked to do a dedicated review of 
> draft-ietf-simple-intradomain-federation, and have a number of comments.
> 
> In general: much of the explanatory text is based on some of the
> growing pains associated with a relatively new technology. For example:
> 
>   In an ideal world, clients would
>   all implement to standards and this would not happen, but in
>   practice, the vast majority of presence and IM endpoints work only
>   (or only work well) with the server from the same vendor.
> 
> While this is true for the time being, I would hope that these
> impedance mismatches fade over time as people implement
> increasingly standard functionality (in fact, section 7.1.3
> relies on this fact). Keep in mind that RFCs are permanent, while
> this problem is (hopefully) temporary.

Modified "but in practice" to "but in current practice"...

I will also say that, I don't agree with you here.

There is ample precedent for the fact that these things never reach 100% 
standards, or even close, for systems that have a 'trapezoid' kind of 
model. Systems like that include email, IM/P, telephony. Lets look at those.

Firstly, is email. I think its clear that standards like POP and IMAP 
have been 'done' a very long time. Yet a large number of clients still 
talk to their servers using proprietary protocols. These include Outlook 
(which can do pop or imap but typically is used with Microsoft's 
exchange protocol), Lotus Notes, Blackberry. Even webmail clients 
arguably use a 'proprietary' interface to talk from client to server, 
though thin client is different. All have fully standardized on the 
server-server piece - SMTP. Do you think this is going to change over 
time? I don't.

IM/P at the moment is the same. Mostly proprietary on the client/server 
links - Yahoo, AOL, Skype, etc on the consumer front - are proprietary. 
When they do federate, the server-server links are standards based, 
either SIMPLE or XMPP.

Traditional enterprise voice systems, ala legacy PBXs, are also like 
this. Indeed, for them, the phone->PBX link was never even standardized. 
The server to server links, via PRI and Q.SIG, were pretty well 
standardized.

The interesting exception here is telephony. Even for analog telephony, 
the standards for client->server communications - the FXO/FXS port - is 
standardized. This remains true for cellular as well, with the interface 
between the phone and the cell towers totally standardized.

The difference is that the telephony and cell phone markets sell the 
endpoint hardware separately from the service that endpoint receives, 
which requires rigorous standardization on that interface. The market 
model for email and IM/P is different - typically the client is software 
based on thus does not need to be purchased separately. That has driven 
the market in a different direction.

My point is that there is strong historical precedent for the 
never-standardized model on client/server links, and success in adopting 
standards there is primarily an artifact of the business model, and not 
just 'wait a bit more'. Also keep in mind nothing is 100%, and even for 
email there is certainly some fraction of the market which uses a 
standardized interface from client to server, but I suspect its in the 
minority for email these days.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Adam Roach <[email-masked]>
Date: Mon, 09 Mar 2009 12:29:30 -0500

Jonathan Rosenberg wrote:
> never-standardized model on client/server links, and success in 
> adopting standards there is primarily an artifact of the business 
> model, and not just 'wait a bit more'.

If you really believe this, then why are you playing in the IETF space 
at all any more? Work like draft-rosenberg-bliss-problem-statement and 
draft-rosenberg-sip-target-uri-delivery are predicated on these links 
being standardized.

I think you're oversimplifying the role of standards in client-server 
communications, and I think you know you're oversimplifying it -- 
otherwise you wouldn't be working on client-interface extensions.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Mar 2009 13:47:25 -0400

Adam,

My own personal feelings and personal participation is not the question 
here. The question is whether or not we agree that we will, over a long 
term, see cases where a client works only with a particular server, and 
that in turn impacts at least some of the motivation parts of this document.

-Jonathan R.

---

From: <[email-masked]>
Date: Mon, 9 Mar 2009 18:51:36 +0100

Hi Jonathan, 

You make some good points. I agree that the server-to-server or inter-domain part is the most crucial thing to standardize, the client/server interface can often be provider-specific. I would add one important aspect: it is extremely important to have a common namespace for all users, even if they access the service with different protocols. In e-mail we have it and in telephony (including VoIP) we have it too with E.164. So, a hotmail user can address a Blackberry user and a Skype(-out) user can address a Comcast VoIP user. In IM/P (or social networking) we don't really have it yet, as many proprietary systems just offer a flat namespace.  

On the other hand, not every provider or vendor has the resources to develop their own client/server protocols. There are a lot of providers who benefit from client/server standards. We can see this in with SIP in telephony and XMPP in IM/P. There are many benefits, as being able to get your equipment from multiple vendors or even using open source components, rather than having to design your own solution á la Skype or MSN or RIM, or buing exclusively from them. This is true with small players (hundreds of XMPP providers) and with big ones (many large telcos running SIP based VoIP service). But I agree there is a difference e.g. between consumer and enterprise market in that regard.

The irony with SIP at the moment is that it is often still easier to download a proprietary application than configure your standard SIP client with the service provider. For instance in Nokia devices just downloading the Gizmo client and using it is not harder than figuring out how to get the SIP settings for Gizmo service. (Plus that with the proprietary client you actually get IM/P too rather than just voice...)

Some further comments inline.

>
>There is ample precedent for the fact that these things never 
>reach 100% standards, or even close, for systems that have a 
>'trapezoid' kind of model. Systems like that include email, 
>IM/P, telephony. Lets look at those.
>
>Firstly, is email. I think its clear that standards like POP 
>and IMAP have been 'done' a very long time. Yet a large number 
>of clients still talk to their servers using proprietary 
>protocols. These include Outlook (which can do pop or imap but 
>typically is used with Microsoft's exchange protocol), Lotus 
>Notes, Blackberry. Even webmail clients arguably use a 
>'proprietary' interface to talk from client to server, though 
>thin client is different. All have fully standardized on the 
>server-server piece - SMTP. Do you think this is going to 
>change over time? I don't.
>

Based on my observation things are definitely not moving towards standardized protocols such as IMAP or POP. For instance in Nokia devices we nowadays have to support a half a dozen different "mobile" or "enterprise" e-mail clients including Microsoft and RIM and a few others. IMAP and POP are still used on the consumer side but more and more people have switched to webmail. This has partly to de with business model too: if you have a browser or your specific client, you can push ads and other stuff to the user. If they can use any POP client, its harder. With enterprise mobile mail we can also claim that the proprietary solutions are feature- and efficiency-wise better than what the IETF standards can offer. This despite of many years of LEMONADE standards.

>IM/P at the moment is the same. Mostly proprietary on the 
>client/server links - Yahoo, AOL, Skype, etc on the consumer 
>front - are proprietary. 
>When they do federate, the server-server links are standards 
>based, either SIMPLE or XMPP.
>
>Traditional enterprise voice systems, ala legacy PBXs, are 
>also like this. Indeed, for them, the phone->PBX link was 
>never even standardized. 
>The server to server links, via PRI and Q.SIG, were pretty 
>well standardized.
>

The enterprises typically purchase a solution from a single vendor (or a couple of vendors who have a tight partnership) and deploy that rather than letting every employee choose their own client, so they are mostly fine with the situation. There is however a certain desire to avoid vendor-lockin so they to some extent there is interest in standards too. 

>The interesting exception here is telephony. Even for analog 
>telephony, the standards for client->server communications - 
>the FXO/FXS port - is standardized. This remains true for 
>cellular as well, with the interface between the phone and the 
>cell towers totally standardized.
>
>The difference is that the telephony and cell phone markets 
>sell the endpoint hardware separately from the service that 
>endpoint receives, which requires rigorous standardization on 
>that interface. The market model for email and IM/P is 
>different - typically the client is software based on thus 
>does not need to be purchased separately. That has driven the 
>market in a different direction.
>

There is also one big reason why the "client/server" interface in *current* cellular telephony is rigorously standardized and highly interoperable. That's because the access/transport and the service parts are tightly integrated in such as way that they can't be separated. So, you can't connect to your "server" in Finland from a US network without going through the "server" in the US network. This means that if you want to use your phone in some other network than your own, all networks and phones have to follow the same "client/server" standard. And roaming is quite important feature in cellular telephony. This is equivalent to Ethernet or WiFi or IP itself having to be very standardized; a portable device needs to be able to work everywhere in the same way. As we move from integrated network and service to IP based paradigm and closed handheld devices to ones based on open platforms such as Linux, Symbian, etc. the need to standardize the client/server interface even for mobile telephony is less important. People can just install the client that is compatible with their service provider and use it. Having said that, I think we are still far away from that day when talking about the mainstream cellular device/telephony market. There are still many forces that make standardized client/server interfaces the preferred way to go.

>never-standardized model on client/server links, and success 
>in adopting standards there is primarily an artifact of the 
>business model, and not just 'wait a bit more'. Also keep in 
>mind nothing is 100%, and even for email there is certainly 
>some fraction of the market which uses a standardized 
>interface from client to server, but I suspect its in the 

Markus

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Mar 2009 14:01:47 -0400

Thanks for the comments, Adam. Responses below. Also note that Avshalom 
did much of the work on this update and this mail is a consolidation of 
his responses, and my own:

> this problem is (hopefully) temporary.

see response in other mail.

> 
> Section 5.2.2: The scaling problems mentioned here assume a
> very naïve design. Any product that performs this kind of task
> will cluster the routing proxy. Because the data used to process
> transactions is slow-changing hard state, such clusters can scale
> effectively infinitely.

We do not say that scaling is impossible but
thyat it is a challenge. Clustering the proxies may be one option
here (server fram is mentioned in the document) but the function
is centralized in nature and central architectuere have its own
challenges even in clusters.

> 
> Section 5.2.3: it would be useful to detail some potential
> protocols for the client/database interaction. Making "Database" a
> SIP redirect server, for example, would allow this scenario to
> work with a broad base of deployed clients.

added the following paragraph:

<t>
Subdmaining can be done via different databases. In order to provide
consistent interface to clients, a front-end of a SIP redirect proxies can
be implemented. A client would send the SIP request to one of the 
redirect proxies
and the redirect proxy will reply with the right domain after consulting
the database in whatever protocol the databases exposes.
</t>

> 
> Section 5.2.4: it would be helpful to cite the p2psip work
> as a candidate for doing this in the future.

Modified last sentence to:
"which does not exist today." -> "which is being worked on
in the P2PSIP IETF working gorup but still does not exist today."

> 
> Section 5.2.5: the caveat about the number of servers should
> probably be stronger here; this approach completely defeats any
> scaling-related partitioning.\

Added:

Indeed, if multiple servers exist for the
purposes of achieving scale, this approach can defeat the very reason
those additional servers were deployed.

> 
> Section 6.1.1: if the percentage of the community that is offline
> at any given time is large, this approach simply moves any subscription
> scaling problem up to the subscriptions on the database. While not
> a show-stopper, this is an important property of the system that
> should be explained. It should also be noted that static assignment
> to a partitioned database can be used to solve this problem (i.e.,
> you're using the approaches from section 5, but at the database
> level instead of the presence/IM server level).

Added:
<t>
Note that this approach actually moves the scaling problem of the routing
mechanism to the database, especially when the percentage of the 
community that
is offline is large.
</t>

> 
> Section 6.1.2: this has the same scaling issues as 6.1.1.

<t>
Note that this approach actually moves the scaling problem of the routing
mechanism to the database, especially when the percentage of the 
community that
is offline is large.
</t>

> 
> Section 6.1.5: This should go into more detail about what
> happens when multiple servers think they're authoritative
> for a user -- e.g., the forked SUBSCRIBE will establish
> multiple subscriptions, and the forking server will be
> forced to form a coherent (if not necessarily complete)
> state for the subscribing user...

One possible scenario where multiple servers will think that
they are serving the user would be when a subscription request
is forked and reaches to multiple servers, each of them thinks
that it serves the user.

> 
> Section 6.2: this should also talk about storing policy
> on an external server using, e.g., presence rules and
> XCAP. That way, each presence server can access the same
> policy information.

Changed the beginning of the section.

from: "In the exclusive bridging model, policy becomes more complicated."
to: "Unless policy is somehow managed in the same database and is 
accessed by
    the servers in the exclusive bridging model, policy becomes more 
complicated
    in the exclusive bridging model."

> 
> Section 7.1.1: in the third bullet, why is the request routed
> to the parent instead of to the root? Routing to the root
> would achieve the same effect, but with less traffic.

It seems to be more efficient to send directly to root
but it assumes that every parent can send directly to the root
which may not be the case.
Added to the bullet:
Note that
if the node that receives the request can send the request directly to
the root, it should do so thus reducing the traffic in the system.

> 
> Section 7.1.2.2: The advice on presence subscription rejection
> is precisely opposite from the common policy model, in which
> rights are absent unless granted; and, once granted by a rule,
> cannot be revoked. The interaction between these two diametrically
> opposed models is likely to lead to some unwanted surprises. I
> think the common policy approach is the correct one to take here.
> 
> Consider, for example, the case in which I instruct
> an off-the-shelf geoloc server to allow Robert to subscribe to
> my location information, but no one else. It interprets this
> to mean "reject subscriptions from everyone but Robert" (which is
> a reasonable implementation choice). Now, this server is used as
> a leaf in a hierarchical tree of presence servers. Suddenly, no
> one can see *any* of my presence information except for Robert!
> That's certainly not what I intended. It seems quite reasonable
> for a subscription rejection at a node other than the root simply
> be interpreted to mean "the presence information from this
> branch of the tree shall not be composed into the document, but
> other information is still allowed."

I think the example is a bit misleading; you have here a geolocation 
subscription, which is rejected if *geoloc* is not to be provided. If we 
want the geoloc server to be more like a presence server, it would 
accept the subscription but provide no geolocation information.

That aspect of this section IS compliant with common policy. What is not 
compliant, is the bit about rejection. I agree with you there that, in 
the proposed model in this document, the composition does not follow 
common policy. If the subscription is rejected at one presence server, 
it is rejected everywhere.

This can be readily fixed by changing the rule so that a presence server 
only rejects a subscription if ALL of its downstream servers reject it.

However, I wonder if that is really the right thing. The fundamental 
question is, whether the common-policy model of composition is 
appropriate in these unioned federation cases. I would think that user 
expectation is that, if Adam blocks Robert on his IBM server, but didn't 
bother to do so ALSO on his Microsoft server, Robert would be blocked.

> 
> Section 7.1.2.3: Figure 11 (and the accompanying text) implies
> a push model. This can, of course, be achieved through a pull model
> as well, such as XCAP. Such an approach requires more integrated
> client support, but eliminates the need for a portal (with the
> trade-off being deployment of an XCAP server).

True - this then becomes a variant on section 7.1.2.4. I added a 
paragraph there:

<t>
It is also possible to move the decisionmaking process into each
server. In that case, there is still a centralized policy portal and
centralized repository of the policy data. The interface between the
servers and the repository then becomes some kind of standardized
database interface.
</t>

> 
> Section 7.2: The formula given to demonstrate commutativity
> is a bit confusing. I think you actually mean something like:
> 
>  Pi(Pj(x1..xm),y1..yn) = Pj(Pi(y1..yn),x1..xm)
> 
>  for all possible inputs x1..xm and y1..yn.

I was folding in the OTHER inputs to Pi and Pj into the function itself; 
the key aspect of this, is which server gets the document first.

> 
> Section 7.2.1: This entire scheme seems less well baked than
> the rest of the document. For example, I could point to concrete
> standardized mechanisms to create all the systems described so
> far; but for 7.2.1, I'd have to do some non-standard stuff (e.g.,
> indication of a loop in a back-end subscription).

Well, this document is a framework overall. There is much in here that 
would need to be standardized to build it out in each model. Several of 
these would require agreement on database protocols and schema for 
example. This is the one case where that new standards work would be a 
SIP extension - I agree.

-Jonathan R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Mar 2009 14:52:12 -0400

The fact that someone can write a server that supports a proprietary 
protocol, and gateway sit to a standard, and can write a client which 
speaks that proprietary protocol, ought to be irrelevant to us.
We could claim that all client-proxy itneractions were out of scope, and 
we are only interested in standardizing proxy-proxy interactions.  That 
is the model or path we have chosen to go down.  Having chosen to go 
down the path where we are interested in standardized client 
interaction, it seems to follow that we care about that, and not about 
what games an implementation is capable of playing using proprietary 
protocols and gatewaying.  After all, the reason for discussing the 
client-proxy behavior is so that one vendors client can work with 
another vendors proxy.  This is in contrast to the classic pbx case 
where you had to buy the phones from the pbx vendor.

Apologies if I am misunderstanding Jonathan or Adam.
Joel

---

From: Dean Willis <[email-masked]>
Date: Mon, 9 Mar 2009 16:23:02 -0500

On Mar 9, 2009, at 10:32 AM, Jonathan Rosenberg wrote:
> endpoint hardware separately from the service that endpoint  
> receives, which requires rigorous standardization on that interface.  
> The market model for email and IM/P is different - typically the  
> client is software based on thus does not need to be purchased  
> separately. That has driven the market in a different direction.
>

The market direction here appears to be moving the other way. Rather  
than just Windows 95, we now have multiple mostly incompatible  
versions of Windows, multiple generations of Mac OS, tens of Linux  
variants, and hundreds of mobile phone "operating systems". We also  
have the emergence of the smaller-than-notebook market, including  
things like the iPod Touch, UMPC, and "netbook" computers. Dozens of  
new OS and UI approaches are appearing in these areas.

Consequently, it is no longer feasible for each "trapezoid" operator  
to offer a customized UNI application for their trapezoid for every  
device platform. It's much easier if the UNI interface is  
standardized, such that for each device platform one or a few  
competing implementations can make that device work with a broad  
selection of operators.

This of course works against operators who try to control and  
constrain the user experience such that user equipment within the  
operator's spam of control is crippled so as to only work with  
services from that operator; they're going to end up with an ugly  
swarm of mutant devices that only their marketing department can love.

--
Dean