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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Jul 2001 00:08:05 -0400

-----Original Message-----
From: Vasilis Polychronidis [mailto:[email-masked]]
Sent: Tuesday, July 24, 2001 7:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Simple] Re: Scalability at a macro level

>Hi Jonathan and Edwin, 
>Please see my comments below: 
>BR, 
>-Vasilis 
>Edwin Aoki wrote: 
>>Jonathan, 
>>
>>I agree that by virtue of SIMPLE's design in allowing UAs to communicate 
>>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, 
>>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.
>
>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. 

Vasilis, one of the important things to understand about the SIP model is
that we specify protocols, not architectures. The current mechanism
described in the draft-ietf-simple-im-sdp-00.txt allows each side to provide
a SIP URL. This SIP URL can be anything, so long as that anything gets
routed to me. So, a valid usage case is to make use of a dedicated IM relay
service whose proxies are used soley for that purpose. Lets say, for
example, I am a customer of foo.com that provides relays for IM (for nat
traversal) at imrelay.foo.com. Lets say my client detects its behind a NAT
(see draft-rosenberg-sip-entfw-02.txt on how to do that). It would open a
TCP connection to imrelay.foo.com and send a REGISTER:

REGISTER sip:imrelay.foo.com SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Contact: sip:[email-masked]:9433;transport=tcp
Translate: sip:[email-masked]:9433;transport=tcp

(the Translate header is described in draft-rosenberg-sip-entfw-02.txt; its
the new version of the Contact cookie I have described previously). Now,
this REGISTER creates a binding between an incoming request for
sip:[email-masked] and that TCP connection I have just sent the
register over. So, when I send an INVITE to someone for an IM session, the
SDP in the INVITE looks like:

m=message 5060 sip sip:[email-masked]

Which will cause the IMs to me to be routed through this TCP connection I
have opened to the IM relay, and this relay is a proxy used only for this
purpose.

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

I don't think this is needed for presence, since presence is really control
traffic. IM can contain content, and thats really the source of the problem
for using existing proxy networks.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Vasilis Polychronidis <[email-masked]>
Date: Wed, 25 Jul 2001 22:30:02 -0700

> have opened to the IM relay, and this relay is a proxy used only for this

Jonathan thank you for the informative explanation. I wish this case was
mentioned
in the draft-ietf-simple-im-session as an example
My question is with your SDP definition which I believe is very restrictive and
does not allow for any other transport than SIP.
The session description should be flexible enough to allow different message
transport protocols.
For example I am proposing something like the following:

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.
I was wondering if you are planning to extend your ID to include this case?

BR,

-Vasilis Polychronidis

---

From: Ben Campbell <[email-masked]>
Date: Thu, 26 Jul 2001 15:01:44 -0500

Vasilis Polychronidis wrote:

[snip]

> The session description should be flexible enough to allow different 

The sdp draft was intended to define the sdp for IM over SIP. That is 
the purpose of the protocol field in the m-line. If others wish to 
define sdp for IM over other protocols, they are welcome to do so with a 
different protocol field value.

>     sip/udp and sip/tcp should not be used to transport messages over 
> SIP proxies
> (signaling)

The c-line is somewhat problematic, in that we want to user a rich URL 
form of addressing, not simply a fqdn or address. The port to be used 
and the transport protocol is also fully described by the URL.

Thanks!

Ben.

---

From: Vasilis Polychronidis <[email-masked]>
Date: Thu, 26 Jul 2001 13:25:02 -0700

Ben thank you for your prompt and informative answer.

BR,

-Vasilis Polychronidis

Ben Campbell wrote:

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