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

[[e-mail]]

Hi,

It seems that we haven't reached an agreement for this topic. I'd like to 
put together a discussion text for this issue, including:

1. Typical traffic model for SUBSCRIBE and Notification and Performance 
analysis;
2. Out-of-Dialog Notifaction optional solutions;
3. Interworking and compatibility. 

Would this topic welcome in the coming IETF meeting in Czech?

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :([phone]
 e_mail : [e-mail]
===================================
----- 转发人 高扬140197/user/zte_ltd 时间 2011-01-12 16:56 -----

高扬140197/user/zte_ltd
2011-01-05 15:19

收件人
Adam Roach <[e-mail]>
抄送
[e-mail]
主题
Re: About SUBSCRIBE method's performance and Out-of-Dialog notification 
suggestion:






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).
> 
> 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.

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


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