Subject: [Simple] Re: Scalability at a macro level

From: [email-masked] (Edwin Aoki)
Date: Tue, 24 Jul 2001 11:28:19 -0700

Jonathan,

I agree that by virtue of SIMPLE's design in allowing UAs to communicate
directly with each other that SIMPLE can scale from a processing load
standpoint,
but I'd also be interested in seeing some analysis of SIMPLE, or, in fact, SIP
itself in terms of the bandwidth overhead that the protocol adds on top of the
actual message data.  Even though an individual's bandwidth requirement may
be relatively small, eventually, all of that bandwidth gets aggregated at an
ISP.
If there are a hundred simultaneous clients receiving bandwidth from a given ISP

(or, in AOL, Earthlink, or MS's case, millions) which are routinely sending and
receiving presence notifications and messages in a real-time basis to/from each
of their presentities/watchers, eventually that adds up to a lot of data which
flows
out of the ISP - in many cases many times greater than the existing proprietary
messaging protocols in use today.

Have any of the other SIP-based media WGs looked at this issue?

-Edwin

>
> I haven't seen any published documents. However, the scalability is
> potentially huge, because simple can push the PA function for presence back
> to the clients. Similarly, instant messages can be handled end-to-end when
> set up as a session (see draft-ietf-simple-im-session) which also results in
> excellent scalability.
>
> -Jonathan R.
>

---

From: Vasilis Polychronidis <[email-masked]>
Date: Tue, 24 Jul 2001 16:13:38 -0700

Hi Jonathan and Edwin,
Please see my comments below:

BR,

-Vasilis

Edwin Aoki wrote:

> directly with each other

Only in the peer to peer mode. Peer to peer is not working very well in the current
NAT environment.

> that SIMPLE can scale from a processing load
> standpoint,

This is a valid concern but I am more concerned when messages transverse SIP proxies
(VoIP signaling infrastructure)
The aggregate effect of a successful IM service will severely hinder the call
control signaling (e.g.. call originations and
call terminations).
That is the reason I was proposing for separation of IM traffic from IM signaling
traffic.
Unfortunately the current drafts they barely mention such possibility.

> out of the ISP

Very true. Separating Presence events from signaling (SIP proxies) is an idea that
should be
seriously considered in this case (i am not referring to Peer to Peer model).
Maybe deploying a separate SIP infrastructure (SIP proxies) just for Presence events
decoupling
it from call control signaling?

> - in many cases many times greater than the existing proprietary

Here is a quote from a previous E-mail that I posted in the list. The
draft-ietf-simple-im-session
did not address any of the issues raised in this E-mail:
I think there was consensus that we would move forward with:

JR>  1. defining MESSAGE as a sessionless page mechanism

I would prefer if this becomes a separate ID (Notification/paging service based on
SIP).
Notifications/Pages should be described in a more generic framework. (the same way
SIP
Events
are more general than the presence service).
In any rate I do not have any strong feelings about this.
On another issue I am always hesitant of using signaling infrastructure (SIP
proxies) for
transporting user messaging.
The signaling infrastructure (SIP proxies) has completely different requirements
(QOS,
reliability, availability, etc.) than
your messaging or your transport (RTP, etc.) infrastructure.
IMO mixing signaling data (session initiation) with application data is not a very
good idea.

You do not want the SIP proxies to start dropping INVITE messages (VoIP call set up)

because your signaling infrastructure is congested from user notification/pages.
SMS which is a huge commercial success was a technical nightmare for the operators
for
exactly
the above mentioned reason (mixing signaling in this case SS7 with messaging data).
I hope we will learn from examples like this and will not repeat similar technical
mistakes.

JR>  2. allow for INVITE/BYE to establish an IM session

This is an excellent idea.
I will list some of the most important (IMO) benefits of doing this (Jonathan
mentioned
many of them in previous e-mails):
1. Unification of Multimedia sessions (VoIP, Video with the Instant Messaging
Service).
Control all sessions (IM, Voice, Multimedia) in a unified method using the same
signaling
protocol.
2. forking actually works
3. you can actually clean up state in end systems which are
automata (like an IM conference server, which you cannot build without this!)
This is a huge benefit. Multiparty chat sessions is very natural (easy) with SIP.
4. you can avoid sending 5meg MP3 "IMs" over proxies
This is very important. Separate signaling from transport. Follow similar
architecture as
VoIP.
Actually by introducing the concept of a chat (IM) server you can solve the NAT
issues
associated with IM
4. you can reuse alot of the sip tools we have constructed for
sessions - transfers, multiparty conferencing, etc.
Again you unify the user experience. User is presented with the same
features/options
regardless
the session (IM, Voice, etc.)

JR>  I think we still have a bit more thinking to do on exactly how the
JR>  IM-as-a-session will work. I had proposed including a SIP URL in the SDP,
JR>  which will work in many cases, but there are still some record-routing
JR>  issues, like the one Robert points out. I don't think those details were yet
JR>  ironed out, though.

The session description should be flexible enough to allow different message
transport
protocols as well as
peer to peer and client-server (IM server or chat Server) communication models:

c = IN IP4 FQDN or IP Address
m = message <port> <protocol> [ "/" MP integer] <IM-identifier>

where:
FQDN or IP Address = the address/identifier of expected data source or data relay or

data sink
port = port number
protocol = udp | tcp | http | rtp | sip/udp | sip/tcp
    sip/udp and sip/tcp should not be used to transport messages over SIP proxies
(signaling)
IM-identifier = im:user@domain (CPIM IM identifier)
MP stands for message profile
for example MP 0 may mean CPIM
MP 1 may represent some type of XML type message
etc.
The beauty of this format is that is extensible.
Also this approach allow us to separate the signaling addressing from the transport
addressing

>
> >
> > -Jonathan R.
> >
>
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple