Subject: Re: [Simple] draft-ietf-simple-simple-05

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 6 Nov 2010 22:34:08 +0100

2010/11/2 David Viamonte <[email-masked]>:
> If, in the end, there is an applicability environment for SIMPLE, and such
> environment is mostly operator-related, such situation will certainly
> influence the evolution of the technology. As I said in a previous mail,
> judging this might be "interesting", but this is simply what it is, probably
> not "good" or "bad". If, on the other hand, such reality is assumed and IETF
> makes an effort to ensure that SIMPLE technology is available in a broader
> perspective beyond operators-only, that'll be a good service to give, hence
> ensuring users and the Internet community in general more choices for the
> deployment of new IM / Presence-based services.
>
> Hope this is interesting, apologies for the long mail :-)

Hi David, thanks for your mail.

I agree. It's good that operators come to standard technologies and
specifications. But IMHO it's not so good the fact that those
specifications are just suitable for them (as they have been designed
mainly by operators in closed forums).

Let me compare the evolution of SIP and SIMPLE:

SIP is mainly used in Internet (by SIP providers), in telcos/operators
infrastructure, in private PBX's, in peering conexions between
carriers. Of course, with the arrival of IMS it's obvious that
operators need a xtra layer of specifications and requeriments in
order to interoperate properly (billing, roaming...).

However SIMPLE is just designed to fit well with big telcos
requeriments. So even if it's a standard technology its usage is
mainly oriented to telcos private networks, and to provide rich
services to those operators. Taking this into account, SIMPLE doesn't
fit well in a pure Internet environment. Their authors don't worry
about it (this is clear by reading this whole thread) so finally
SIMPLE will never success as "Internet protocol" and providers giving
communication rich services in Internet will never try SIMPLE.

Anyhow, I must surrender to the fact that nobody here is interested in
debating the issues I've pointed out during this thread (complexity,
inefficiency, ambiguity, limitations... of SIMPLE). It seems that the
specification is sacred as it is. I should accept it :)

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Nov 2010 02:19:50 -0500

Iñaki,

I was present from the beginning of SIMPLE.
IMO there was no undue influence of "telcos/operators" in its 
specification. As I saw it, the primary goal was that it be designed to 
be complementary to SIP - to just be another media type that could be 
negotiated. The exact form of the media protocol just evolved from the 
accumulated requirements. I'll agree that it ended up being pretty 
complex, and maybe in retrospect could have been done better. But there 
was a reason for everything in it.

I'll certainly grant that XMPP has been much more successful in 
practical deployments. I'd be perfectly fine with integrating XMPP into 
sip as the medium for IM, but this presents the problem that XMPP has 
its own session establishment mechanism and its own addressing scheme, 
and so doesn't harmonize easily with sip.

My major frustration is not ending up with one session establishment 
mechanism that can be used for all media and presence.

	Thanks,
	Paul

On 11/6/2010 5:34 PM, Iñaki Baz Castillo wrote:
> 2010/11/2 David Viamonte<[email-masked]>:

---

From: David Viamonte <[email-masked]>
Date: Tue, 09 Nov 2010 21:37:47 +0100

Hi,

good reflection. Actually, following up on historical perspective, I 
just came to notice that there has been consistent consensus that the 
basic subscription / notification mechanism may generate nontrivial 
amounts of traffic. There's been indeed IETF & SIMPLE historical 
interest and activity around optimizing such mechanism (e.g.: Resource 
Lists, SubNot Etags, Indirect Presence publication, Partial 
Notification, SIMPLE SigComp profile, ...).

My view is that once SIMPLE Presence gets deployed it will be just a 
matter of time that interdomain scalability becomes "the next" 
bottleneck or at least "area of improvement". This is more a built-in 
need of any Presence technology deployed in an open, distributed, 
multi-domain basis than something very specific to OMA Presence, 3GPP 
IMS or GSMA RCS.

At that stage, there are basically two possibilities:

a) Additional workarounds and optimizations are defined elsewhere, at 
which point IETF community may claim that those are "nonstandard 
proprietary extensions".
b) Halfway after having started work in a) other SDO's may issue a LS to 
IETF requesting to "fix" or "advise" upon appropriate usage of SIMPLE 
"plus their extensions" to mitigate scalability issues.

If neither a) nor b) are the best options (which may or may not be the 
case), my understanding is that IETF taking the lead of interdomain 
analysis and optimization is an interesting activity. Obviously, in the 
absence of a critical mass of contributors or interest, list opinion may 
be different.

Cheers,

David

On 07/11/2010 08:19, Paul Kyzivat wrote:
> specification. As I saw it, the primary goal was that it be designed 
> to be complementary to SIP - to just be another media type that could 
> be negotiated. The exact form of the media protocol just evolved from 
> the accumulated requirements. I'll agree that it ended up being pretty 
> complex, and maybe in retrospect could have been done better. But 
> there was a reason for everything in it.
>
> practical deployments. I'd be perfectly fine with integrating XMPP 
> into sip as the medium for IM, but this presents the problem that XMPP 
> has its own session establishment mechanism and its own addressing 
> scheme, and so doesn't harmonize easily with sip.
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 17:13:58 -0500

On Nov 9, 2010, at 3:37 PM, David Viamonte wrote:
> bottleneck or at least "area of improvement".

I think this time has already come, or is imminent.  We've already started to see this problem in deployments.  Even in interdomain *Enterprise* deployments. (granted these are really big Enterprises)

> This is more a built-in 

I've often wondered: does XMPP not have such interdomain scaling issues?  Or is there just not much interdomain XMPP yet?

-hadriel

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 06:22:18 +0800

On 11/10/10 6:13 AM, Hadriel Kaplan wrote:
>> My view is that once SIMPLE Presence gets deployed it will be just
>> a matter of time that interdomain scalability becomes "the next" 
> I think this time has already come, or is imminent.  We've already
> started to see this problem in deployments.  Even in interdomain
> *Enterprise* deployments. (granted these are really big Enterprises)
> 
>> This is more a built-in need of any Presence technology deployed in
>> an open, distributed, multi-domain basis than something very
>> specific to OMA Presence, 3GPP IMS or GSMA RCS.

I very much agree, which is why Avshalom and I were working on a better
problem description in the first place. In a perfect world we'd have
enough cycles to finish that work.

> I've often wondered: does XMPP not have such interdomain scaling
> issues?  

The main interdomain scaling issue we've seen is not between any two
domains but between services that host large numbers of domains, because
the XMPP specs legislate that thou shalt set up two TCP connections per
domain pair, one in each direction. If I host 10k domains and you host
10k domains and all of those domains want to talk with each other, we'll
each be servicing 2 million TCP connections. And yes we're working on
that problem, see for instance:

http://tools.ietf.org/html/draft-ietf-xmpp-dna-00

http://tools.ietf.org/html/draft-barnes-xmpp-dna-00

> Or is there just not much interdomain XMPP yet?

There is a lot of interdomain XMPP. At the jabber.org service we
typically have several thousand live server-to-server connections at any
one time. I'm sure that even larger deployments have more (e.g., Google
Talk).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/