Subject: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion:

From: [email-masked]
Date: Tue, 4 Jan 2011 13:21:02 +0800

Hi,

By our equipment's performance analysis, we(internal) find that SUBSCRIBE 
method always occupy a lot of resource, especially for some long duration 
Event Packages. (Considering the traffic model, some Event Packages, have 
larger call rate and longer duration than INVITE method.) 

Supposing the SUBSCRIBE's dialog&event resource consuming is similar to 
INVITE's dialog&session(signalling level) resource consuming, one Event 
Package's would need more resource consuming than the session usage. 

Considering some Event Package's event occurence probability is very low 
in the subscription's relative long duration lifecycle, we can make a new 
type of subscription which would tear down the dialog after the 
SUBSCRIBE(and the first NOTIFY), while send the subsequent notification 
out-of-dialog.

I'd like to hear Adam and other RFC3265 experts' view points.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Jan 2011 13:44:52 +0100

Hi Gao, 

>By our equipment's performance analysis, we(internal) find that SUBSCRIBE method always occupy a lot of resource, especially for some long duration Event Packages. (Considering the traffic 
>model, some Event Packages, have larger call rate and longer duration than INVITE method.) 
>	
>Supposing the SUBSCRIBE's dialog&event resource consuming is similar to INVITE's dialog&session(signalling level) resource consuming, one Event Package's would need more resource consuming than 
>the session usage. 
>	
>Considering some Event Package's event occurence probability is very low in the subscription's relative long duration lifecycle, we can make a new type of subscription which would tear down the 
>dialog after the SUBSCRIBE(and the first NOTIFY), while send the subsequent notification out-of-dialog. 
>	

I'm neither, but I have some questions for clarifications:

1. I assume the SUB sender would still need store some data, in order to match the out-of-dialog NOT to the previous SUB dialog?

2. If 1 is true, for how long would the SUB sender keep this data, and be prepared to receive the out-of-dialog NOT? I guess the subscription timers don't apply in this case, or?

3. Would the out-of-dialog NOT be routed using a Contact/GRUU, rather than the AOR, of the SUB sender, to ensure it reaches the SUB sender?

Regards,

Christer

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 4 Jan 2011 10:53:41 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]

we can make a new type of subscription which would tear down the dialog after the SUBSCRIBE(and the first NOTIFY), while send the subsequent notification out-of-dialog.
________________________________________

I do not see that much saving could be obtained using the new method.  The notifier would still need to maintain knowledge of the pseudo-subscription, as it needs to know that it must send NOTIFYs.  The subscriber would still need to maintain knowledge of the pseudo-subscription, as it needs to be able to interpret the received NOTIFYs, and it needs to refresh the pseudo-subscription.

The only savings that I can identify are that if the intermediate elements maintain state regarding subscription dialogs.  The simple solution to such overhead is for the intermediate elements *to not maintain state regarding subscription dialogs*, either by being proper proxies (and thus not maintaining state regarding *any* dialog), or by not Record-Routing themselves during the creation of subscription dialogs (and thus not needing to retain state regarding subscription dialogs).

In either method, the notifier would need to know a URI that routes directly to the subscriber.  In a subscription with no Record-Routes, it would of necessity be the Contact URI in the SUBSCRIBE.  In the new method, it could be defined in another way, but the SUBSCRIBE Contact URI seems to be sufficient.  In either method, the best solution seems to be for the subscriber to have a GRUU to use as its Contact URI.

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 4 Jan 2011 17:09:18 +0100

Agreed. The key here is to understanding what dialog state needs to be maintained, and the proposal as currently described does not seem to change that. It merely changes formal dialog state into something that does the same thing but is not formally defined.

Of course we could remove all state altogether, but that surely is PUBLISH.

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Worley, Dale R (Dale)
> Sent: Tuesday, January 04, 2011 3:54 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [sipcore] About SUBSCRIBE method's performance 
> and Out-of-Dialog notification suggestion:
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of [email-masked] [[email-masked]]
> 
> we can make a new type of subscription which would tear down 
> the dialog after the SUBSCRIBE(and the first NOTIFY), while 
> send the subsequent notification out-of-dialog.
> I do not see that much saving could be obtained using the new 
> method.  The notifier would still need to maintain knowledge 
> of the pseudo-subscription, as it needs to know that it must 
> send NOTIFYs.  The subscriber would still need to maintain 
> knowledge of the pseudo-subscription, as it needs to be able 
> to interpret the received NOTIFYs, and it needs to refresh 
> the pseudo-subscription.
> 
> The only savings that I can identify are that if the 
> intermediate elements maintain state regarding subscription 
> dialogs.  The simple solution to such overhead is for the 
> intermediate elements *to not maintain state regarding 
> subscription dialogs*, either by being proper proxies (and 
> thus not maintaining state regarding *any* dialog), or by not 
> Record-Routing themselves during the creation of subscription 
> dialogs (and thus not needing to retain state regarding 
> subscription dialogs).
> 
> In either method, the notifier would need to know a URI that 
> routes directly to the subscriber.  In a subscription with no 
> Record-Routes, it would of necessity be the Contact URI in 
> the SUBSCRIBE.  In the new method, it could be defined in 
> another way, but the SUBSCRIBE Contact URI seems to be 
> sufficient.  In either method, the best solution seems to be 
> for the subscriber to have a GRUU to use as its Contact URI.
> 
> Dale
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 4 Jan 2011 12:13:16 -0500

________________________________________
From: DRAGE, Keith (Keith) [[email-masked]]

The key here is to understanding what dialog state needs to be maintained, and the proposal as currently described does not seem to change that.
________________________________________

I suspect that the question is dialog state maintained in intermediate elements, as many SIP systems coming from traditional telco companies implement intermediate elements as B2BUAs, and often have up to a dozen B2BUAs in what would be expected in SIP to be a single dialog.  I expect Gao will clarify the question when his day arrives.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Jan 2011 15:39:05 -0500

If this is the issue, then it just points out the obvious - that there 
are consequences to using B2BUAs rather than proxies. If it hurts, don't 
do it.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Jan 2011 21:54:18 +0100

Hi,

Stateful proxies also maintain state.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Tuesday, January 04, 2011 10:39 PM
To: [email-masked]
Subject: Re: [sipcore] About SUBSCRIBE method's performance and Out-of-Dialog notification suggestion:

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Jan 2011 16:10:49 -0500

> Stateful proxies also maintain state.

Sure. But generally *less* state.
For instance, often you could get by with just a transaction stateful proxy.

And is it really the state that is the problem? Or is it the message 
processing? There is potentially a lot more work per-message for a B2BUA 
than a proxy.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 04 Jan 2011 17:49:51 -0600

I'll echo what has already been said: the notifications need some kind 
of correlation to match the subscription. The dialog provides this. You 
might be able to shave the state down a bit, but since the correlation 
needs to be unique (in the entire universe, forever), you probably can't 
make it much smaller than it already is.

Without an explicit correlation between the subscribe and the NOTIFY, 
the only identifier you could use is the resource identifier itself. As 
Keith pointed out, we have something that behaves like this: PUBLISH. 
You can use this model, if you'd prefer; replace the subscription with 
provisioning information, and send a PUBLISH when you want to update 
state. And you need to take this with the caveat that you lose a bunch 
of functionality when you go from a subscription model to a publication 
model.

But let's back up a bit.

You talk about resource consumption as it pertains to a subscription; in 
particular, the dialog state required to keep this kind of information 
in memory. I'd like to do a back-of-the-napkin calculation to understand 
the issue. Dialogs are identified by to-tag, from-tag and call-id. On 
top of that, they must maintain a route set (including the Contacts) and 
two CSeqs (one for each direction).

I'll grab a random wire trace to get a feel for the size of this 
information.

To (with tag): ~16 bytes
 From (with tag): ~16 bytes
Call-Id: ~24 bytes
Local Contact: ~32 bytes
Remote Contact: ~32 bytes
Route Set (~74 bytes x 3 proxies): ~222 bytes
Two CSeqs: 4 bytes

That's about 346 bytes. To make the math easy, let's be sloppy and 
assume that miscellaneous overhead bumps this all the way to 512 bytes 
per dialog.

That means that, in the 8 GB of RAM that my laptop has, I could store 
state for 16 million dialogs. In the 32-GB server-class boxes that I'm 
used to dimensioning for, it would take only 5 servers to store a dialog 
for every man, woman, child, and newborn baby in the U.S. -- or 20 
servers to do the same thing for China. It would take a hair over 100 
such servers to do this for every living human being.

That's assuming we need to keep everything in actual wired RAM. If we're 
allowed to swap the data out to a pair of 2 TB hard drives (possibly 
sensible if the traffic is as low as you imply), this state -- one 
subscription for every human currently alive -- all fits on a single server.

When you're talking about network servers, memory is cheap, and hard 
drives are cheaper. Standardization and implementation is expensive. So, 
I'm a bit doubtful that it would be a good investment on anyone's part 
to come up with a simplified model for RFC3265 subscriptions.

/a

On 1/3/11 11:21 PM, [email-masked] wrote:
>
> Hi,
>
> By our equipment's performance analysis, we(internal) find that 
> SUBSCRIBE method always occupy a lot of resource, especially for some 
> long duration Event Packages. (Considering the traffic model, some 
> Event Packages, have larger call rate and longer duration than INVITE 
> method.)
>
> Supposing the SUBSCRIBE's dialog&event resource consuming is similar 
> to INVITE's dialog&session(signalling level) resource consuming, one 
> Event Package's would need more resource consuming than the session 
> usage.
>
> Considering some Event Package's event occurence probability is very 
> low in the subscription's relative long duration lifecycle, we can 
> make a new type of subscription which would tear down the dialog after 
> the SUBSCRIBE(and the first NOTIFY), while send the subsequent 
> notification out-of-dialog.
>

---

From: [email-masked]
Date: Wed, 5 Jan 2011 14:12:22 +0800

Hi Christer,

> 1. I assume the SUB sender would still need store some data, in 
> order to match the out-of-dialog NOT to the previous SUB dialog?

By my primary thinking, I'd like this feature Event Package specific, that 
is some Event Packages which have the requirement could send notification 
out-of-dialog. 

Further, I think some Event Packages might need matching mechanism, some 
migt cut it out.

But I think the matching mechanism is not the so heavy here, as the most 
memory usage is for Route Set. This heavey part could be saved while we 
use notification out-of-dialog.

> 
> 2. If 1 is true, for how long would the SUB sender keep this data, 
> and be prepared to receive the out-of-dialog NOT? I guess the 
> subscription timers don't apply in this case, or?

I think this could be defined Event Package specific too.

> 
> 3. Would the out-of-dialog NOT be routed using a Contact/GRUU, 
> rather than the AOR, of the SUB sender, to ensure it reaches the SUB 
sender?

To be honest, my proposal is row now, and I hadn't think this point.
I agree that considering a specific heavy SUBSCRIBE usage, the 
"out-of-dialog" suggestion might not save impressive resource. But 
considering general usage, I think it would be meaningful.

Thanks,

Gao

---

From: [email-masked]
Date: Wed, 5 Jan 2011 14:21:50 +0800

Dale and Paul,

> > I suspect that the question is dialog state maintained in 
> intermediate elements, as many SIP systems coming from traditional 
> telco companies implement intermediate elements as B2BUAs, and often
> have up to a dozen B2BUAs in what would be expected in SIP to be a 
> single dialog.  I expect Gao will clarify the question when his day 
arrives.

[For Dale] I think it is about both, that is intermediate elements and the 
UAC/UAS.

> do it.

[For Paul] I think it is meaningful in cases that intermediate elements 
are defined B2BUA/Stateful(by some Network Architecture) or demanded 
B2BUA/Stateful(by users/operators).

Thanks,

Gao

---

From: [email-masked]
Date: Wed, 5 Jan 2011 15:19:39 +0800

Hi Adam,

> I'll echo what has already been said: the notifications need some 
> kind of correlation to match the subscription. The dialog provides 
> this. You might be able to shave the state down a bit, but since the
> correlation needs to be unique (in the entire universe, forever), 
> you probably can't make it much smaller than it already is.
> 
> Without an explicit correlation between the subscribe and the 
> NOTIFY, the only identifier you could use is the resource identifier
> itself. As Keith pointed out, we have something that behaves like 
> this: PUBLISH. You can use this model, if you'd prefer; replace the 
> subscription with provisioning information, and send a PUBLISH when 
> you want to update state. And you need to take this with the caveat 
> that you lose a bunch of functionality when you go from a 
> subscription model to a publication model.

What I suggested is something like PUBLISH(out-of-dialog), but more. IMO, 
PUBLISH model hasn't define who(identify the subscriber) need which 
notification(identify the Event type) in PUBLISH usage. My thinking is 
about SUBSCRIBE model, with out-of-dialog notification for some specific 
Event Packages.

> But let's back up a bit.
> 
> You talk about resource consumption as it pertains to a 
> subscription; in particular, the dialog state required to keep this 
> kind of information in memory. I'd like to do a back-of-the-napkin 
> calculation to understand the issue. Dialogs are identified by to-
> tag, from-tag and call-id. On top of that, they must maintain a 
> route set (including the Contacts) and two CSeqs (one for each 
direction).
information.
> assume that miscellaneous overhead bumps this all the way to 512 
> bytes per dialog.
> 
> That means that, in the 8 GB of RAM that my laptop has, I could 
> store state for 16 million dialogs. In the 32-GB server-class boxes 
> that I'm used to dimensioning for, it would take only 5 servers to 
> store a dialog for every man, woman, child, and newborn baby in the 
> U.S. -- or 20 servers to do the same thing for China. It would take 
> a hair over 100 such servers to do this for every living human being.
> 
> That's assuming we need to keep everything in actual wired RAM. If 
> we're allowed to swap the data out to a pair of 2 TB hard drives 
> (possibly sensible if the traffic is as low as you imply), this 
> state -- one subscription for every human currently alive -- all 
> fits on a single server.
> 
> drives are cheaper. Standardization and implementation is expensive.

Yes. One of our eqiopment has the similar memory consuming statistics.

While memory is just one apsect of resource consuming. Further, t one 
equipment would have other tasks, such as call control, services and so 
on. So, the capacity of one equipment might not be so ideal.

> So, I'm a bit doubtful that it would be a good investment on 
> anyone's part to come up with a simplified model for RFC3265 
subscriptions.

In fact, doing a practical performance analysis is hard, and it would be 
implementation specific. So, I suggest to evaluate it by relative compare:

Considering one Event Packages, having the similar (call) arrival rate and 
longer holding time(some event types has much longer holding time than 
session) than session usage(INVITE), if we allow out-of-dialog 
notification, we might save resource consuming as much as(or more than) 
the whole session siganlling.

In fact, I am not going to change the RFC3265 track a lot. I'd like to 
make it optional for some specific Event Packages.

Thanks,

Gao