Subject: RE: [Simple] WG Last Call : draft-ietf-simple-data-req-02.txt

From: [email-masked]
Date: Fri, 25 Apr 2003 10:26:09 +0300

Inline.

 > -----Original Message-----
 > From: ext Thanos Diacakis [mailto:[email-masked]]
 > Sent: 25 April, 2003 01:58
 > To: Jonathan Rosenberg
 > Cc: [email-masked]
 > Subject: Re: [Simple] WG Last Call : 
 > draft-ietf-simple-data-req-02.txt
 > 
 > 
 > Thoughts inline.
 > 
 > Jonathan Rosenberg wrote:
 > > > 5.2 Additional requirement: "It should be possible for 
 > the user to
 > specify a
 > > > limitation on the rate of notifications sent to a 
 > particular user"
 > >
 > > While I agree with this as a goal, its something we really 
 > dont know how
 > > to do right now. Work on rate limiting is just beginning, 
 > and its really
 > > not clear how it will work. Rate limiting fundamentally 
 > means some kind
 > > of information loss, so that specifying a rate limit alone is not
 > > sufficient. You will also need to specify what information 
 > is discarded.
 > > Since the authorization stuff is extensible by design, I 
 > would rather
 > > handle this later, and not in the initial specifications.
 > 
 > Can you elaborate a bit on the information loss part?  I can 
 > see a scenario
 > where I have a piece of information (a tuple) that changes 
 > with an average
 > period of x, say, seconds.  Wouldn't it be pretty easy to 
 > specify a rate
 > limitation (i.e. a lengthier period of y seconds) which would work as
 > follows:  if there is a change in the tuple a notification 
 > is sent, but only
 > if the last notification was sent at least y seconds ago.  If the
 > notification was sent less than y seconds ago, the next 
 > notification will
 > wait until the time is such that the notifications will be y 
 > seconds apart.
 > If an additional tuple is received before such time, the resulting
 > notification would replace the one that was queued.
                      ^^^^^^^
It is the "replace" here that creates the loss of data. You lose the state previously in the queue when it gets replaced. It can be a state transition, or in case of "stateless" data (e.g., geoloc), the information itself.

Please take a look at:
http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs-01.txt

This draft tries to capture the rate limiting problem and present some requirements for a solution.

Cheers,
Aki

[snip]
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Apr 2003 08:44:50 -0400

inline.

[email-masked] wrote:
> Inline.
> 
>> -----Original Message----- From: ext Thanos Diacakis
>> [mailto:[email-masked]] Sent: 25 April, 2003 01:58 
>> To: Jonathan Rosenberg Cc: [email-masked] Subject: Re: [Simple] WG
>> Last Call : draft-ietf-simple-data-req-02.txt
>> 
>> 
>> Thoughts inline.
>> 
>> the user to specify a
>> Can you elaborate a bit on the information loss part?  I can see a
>> scenario where I have a piece of information (a tuple) that changes
>>  with an average period of x, say, seconds.  Wouldn't it be pretty
>> easy to specify a rate limitation (i.e. a lengthier period of y
>> seconds) which would work as follows:  if there is a change in the
>> tuple a notification is sent, but only if the last notification was
>> sent at least y seconds ago.  If the notification was sent less
>> than y seconds ago, the next notification will wait until the time
>> is such that the notifications will be y seconds apart. If an
>> additional tuple is received before such time, the resulting 
> ^^^^^^^ It is the "replace" here that creates the loss of data. You
> lose the state previously in the queue when it gets replaced. It can
> be a state transition, or in case of "stateless" data (e.g., geoloc),
> the information itself.

Right. Other options are to aggregate, which makes more sense for some 
types of data, or to discard other pieces of presence state.

> some requirements for a solution.

And my point is that these need to be aligned. But, the above is just 
getting started, whereas we are now in wglc in these requirements. I 
would rather address rate limiting as a problem on the presentity side 
once the requirements are more settled and the problem better understood 
overall.

> .
> 
> 
>>>> >
>>>> > 5.3.  Additional requirement: "It should be possible for the user to
> 
> specify
> 
>>>> > that a particular tuple be added, removed or modified from the
> 
> notifications
> 
>>>> > depending on the values of other tuples.".
>>
>>>
>>> Can you motivate the need for that? I am trying to keep the initial set
>>> minimal.
> 
> 
> I was thinking of something along those lines: If my location tuple shows
> "home" then add my home phone tuple to the presence doc, whereas if I'm at
> work add my email tuple.  Or if I am available by IM, stop publishing my SMS
> tuple.

OK, this is reasonable, I will add the requirement.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Thanos Diacakis" <[email-masked]>
Date: Fri, 25 Apr 2003 10:40:03 -0600

Aki Niemi wrote:

> It is the "replace" here that creates the loss of data. You lose the state
previously in the queue when it gets replaced. It can be a state transition,
or in case of "stateless" data (e.g., geoloc), the information itself.

Replace would only create a loss of data if the presence document contained
a partial notification and not the full presence document for that
presentity.  Obviously, if partial notifications are utilized, some kind of
merging would be required, but I think the requirement is still valid as is,
given that we're only specifying how to set and get the policy, not the
mechanism through which it is enforced.

Perhaps a way to get around this is to state the requirement in data-req-02
in a generic way and reference to the event-throttling draft for specifics.

Thanos
---
Thanos Diacakis
Openwave Systems
[email-masked]
+1-303 385 6705