Subject: FW: [Sipping] Update to event throttles

From: "Brok, Jacco (Jacco)" <[email-masked]>
Date: Mon, 14 Mar 2005 15:57:57 +0100

I believe this issue gets some attention in my I-D:
http://www.ietf.org/internet-drafts/draft-brok-simple-regulate-publish-00.txt

In my opinion, throttling alone is not good enough to solve the bandwidth problem when publishing presence. The I-D suggests a mechanism that can be used in parallel with PUBLISH to provide a User Agent Client with a way to learn what to publish, with what rate etc. 

Jacco Brok

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Paul Kyzivat
Sent: maandag 14 maart 2005 0:41
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Update to event throttles

During the discussion at the meeting it struck me that perhaps what is 
needed is a bandwidth sensitive filter specification. The basic throttle 
mechanism doesn't necessarily reduce bandwidth, while the basic filter 
mechanism isn't time or size sensitive. A richer filter mechanism could 
have more flexibility.

	Paul

[email-masked] wrote:
> Jonathan,
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of ext Jonathan Rosenberg
>>Sent: 11 March, 2005 11:39
>>To: Niemi Aki (Nokia-NRC/Helsinki)
>>Cc: SIPPING WG
>>Subject: Re: [Sipping] Update to event throttles
>>
>>
>>I'm inclined to say that I don't find this a terribly 
>>pressing problem. 
>>We don't have any real networks for whom subscribers are being 
>>overwhelmed with notifications, for which this would be the 
>>ideal way to 
>>deal with it (compared to compression or filters, both of 
>>which reduce 
>>the amount of data).
>>
> 
> 
> The overall problem of bandwidth consumption is extremely pressing.
> 
> We have been talking to many mobile operators (GPRS, EDGE, WCDMA) about deploying SIP-based presence in their current networks, and it turns out many of them are saying it is impossible. The reason they are giving is that presence would generate too much data transmitted over the air, that it would make the service commercially viable. You might blame the operators' business models, too expensive radio technology, etc. but the situation is what it is.
> 
> So, we have to pursue the reduction of traffic on several fronts:
> - Compression (SigComp, GZIP for the payloads)
> - Filtering
> - Partial notifications
> - Throttling
> 
> Each of these are useful components and help in different ways. Throttling may not be the most effective of the methods, but it is definitely the simplest, and useful in certain circumstances. 
> 
> If someone does not need throttling, they don't need to implement it.
> 
> So far people seem to have argued either that
> - the problem does not exist: I have just argued that it does
> - the problem scope is too narrow: Well, the particular component to address the overall problem field happens to be simple, and there are no known requirements beyond that
> - the problem can be solved in a different way: Yes, but the ways speculated have been complementary, not better than what is specified in the draft.
> 
> Regards,
> 	Markus
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Wed, 16 Mar 2005 10:46:59 -0600

Paul wrote:

> I'm really wondering what happens when somebody on a cellphone has a 
> buddylist with a 100 people in it, and they are all doing stuff that 
> changes there presence regularly. 

A simple, not complete,  solution is to aggregate the presnce info (as
suggested), and send them on demand from the client, i.e Pull, so the PS
doesn't push them to the phone. Then you also control in the client how
often and when can a subscriber pull this info ( is the phone in a session
already,  too busy for this operation, etc..)
In the mean time the PS is always updated with the most recent information
presence model. It just stores it there.

So the phone is not always updated with the most recent data but only when
it requests update. Not the exact intended behavior of presence but one way
to control what would be described as a largely unpredictable situation.

Rgds/gf

Ericsson Canada