Subject: RE: [Sipping] WGLC for draft-ietf-sipping-event-throttle-reqs-00. txt

From: Milinski Alexander <[email-masked]>
Date: Thu, 11 Mar 2004 17:27:40 +0100

Eric, 
here I don't disagree, that's why I put in "at least for presence", but: I believe the draft is very ambiguous in that respect, in particular due to the existence of one single example only.
Alexander

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Thursday, March 11, 2004 5:18 PM
To: Milinski Alexander
Cc: Sipping (E-mail)
Subject: RE: [Sipping] WGLC for draft-ietf-sipping-event-throttle-reqs-00. txt

Beating my dead horse:

IT DOES NOT MAKE SENSE TO DICTATE THE QUEUING/DROP/MUX ALGORITHM.  The Algorithm will be, by its nature, event package-specific.

One service might use LIOTO.  One service might use FIFO.  One service might use composite state.  One service might really use LIFO (can't think of it, but it may be out there).

Saying LIOTO should be one of the algorithms misses the point -- the point is one CANNOT, a priori, define the algorithms outside the context of a PARTICULAR INSTANCE of an event package.

> -----Original Message-----
> From: Milinski Alexander [mailto:[email-masked]]
> Sent: Thursday, March 11, 2004 8:39 AM
> To: 'Adam Roach'; Eric Burger; [email-masked]; 'Niemi Aki
> (Nokia-M/Espoo)'
> Cc: Sipping (E-mail)
> Subject: RE: [Sipping] WGLC for
> draft-ietf-sipping-event-throttle-reqs-00. txt
> 
> 
> Hi Aki, Adam, Eric, Alex, all,
> similar to previous comments, I have a concern that buffering 
> out-of-date notifications results in a "past-tense service" 
> rather than in a presence service, and I do not believe this 
> is desirable. It will require enhanced complexity on the 
> subscriber side to handle out-of-date notifications. Otherwise 
> it means to delay up-to-date notifications, which is even 
> less desirable. That's why I support "single-element LIFO 
> (or, as Paul put it, LIOTO)" at least for presence.
> Probably the draft can be cleaned up in this respect.
> 
> To add more detail:
> Only one example is given. I remember Dean had reviewed the 
> text earlier on the mailing list, and I believe the examples 
> he gave were much more illustrative.
> In the example given, Lisa receives "all the buffered 
> notifications". It seems that this can be all notifications 
> or none, depending on the notifier, correct? I think this 
> should be made more clear.
> 
> Additional comment:
> On REQ6: I agree with the principle, but I think it is that 
> obvious that it should not only be placed as a requirement 
> but as a general principle somewhere else in the document. A 
> limit given by the subscriber is a limit and should not be 
> confused with a performance requirement towards the notifier.
> 
> Regards,
> Alexander
> 
> P.S. there is also a typo in 4.2: wathcing --> watching.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Adam Roach
> Sent: Thursday, March 11, 2004 3:35 AM
> To: Eric Burger; [email-masked]
> Cc: Sipping (E-mail)
> Subject: RE: [Sipping] WGLC for 
> draft-ietf-sipping-event-throttle-reqs-00. txt
> 
> 
> Eric:
> 
> While I agree with your overall point, I have to take
> contention with one of your examples.
> 
> Eric Burger [mailto:[email-masked]] wrote:
> 
> > Consider the event package, "Where have I been?"
> > 
> > A sensible algorithm is FIFO, as it would give the path of my 
> > location.
> 
> As would single-element LIFO (or, as Paul put it, LIOTO). I think
> you've confused a "where have I been" event package with a (flawed)
> attempt to construct "where have I been" out of potentially
> lossy stream of "where am I" information gathered over a period of
> time.
> 
> A state representing "where have I been?" would necessarily include
> the path you're talking about.
> 
> As long as people have the misconception that they can throttle
> without losing information, people are going to continue to think
> that FIFO is somehow sensible.
> 
> /a
> 
> _______________________________________________
> 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: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Fri, 12 Mar 2004 15:25:23 +0200

ext Milinski Alexander wrote:
> Eric, here I don't disagree, that's why I put in "at least for
> presence", but: I believe the draft is very ambiguous in that
> respect, in particular due to the existence of one single example
> only. Alexander

I can agree to that, and I will strengthen the draft on this by adding 
better examples. I also agree with what Eric is saying below. This has 
been my point in this work all along. For example, LIOTO only works for 
event packages that always carry full state notifications. It severely 
breaks partial-notify, watcher-info and any other package that has 
partial state defined.

I would also add, that the event throttling work merely brings out an 
issue that actually already exists. How do current un-throttled 
notifiers implement their output buffer? Each event package has rate 
limitation recommendations - what happens today if presence state 
changes more often than the notifier is allowed to generate 
notifications? This is not specified, but the assumption is that "the 
right thing happens", i.e., if this was a full state notification, LIOTO 
might be appropriate; for partial state, merging the buffered states is 
the only reasonable option.

Cheers,
Aki

> -----Original Message----- From: Eric Burger
> [mailto:[email-masked]] Sent: Thursday, March 11, 2004 5:18 PM
>  To: Milinski Alexander Cc: Sipping (E-mail) Subject: RE: [Sipping]
> WGLC for draft-ietf-sipping-event-throttle-reqs-00. txt
> 
> 
> Beating my dead horse:
> 
> IT DOES NOT MAKE SENSE TO DICTATE THE QUEUING/DROP/MUX ALGORITHM.
> The Algorithm will be, by its nature, event package-specific.
> 
> One service might use LIOTO.  One service might use FIFO.  One
> service might use composite state.  One service might really use LIFO
> (can't think of it, but it may be out there).
> 
> Saying LIOTO should be one of the algorithms misses the point -- the
> point is one CANNOT, a priori, define the algorithms outside the
> context of a PARTICULAR INSTANCE of an event package.
> 
> 
> 
>> -----Original Message----- From: Milinski Alexander
>> [mailto:[email-masked]] Sent: Thursday, March 11,
>> 2004 8:39 AM To: 'Adam Roach'; Eric Burger; [email-masked];
>> 'Niemi Aki (Nokia-M/Espoo)' Cc: Sipping (E-mail) Subject: RE:
>> [Sipping] WGLC for draft-ietf-sipping-event-throttle-reqs-00. txt
>> 
>> 
>> Hi Aki, Adam, Eric, Alex, all, similar to previous comments, I have
>> a concern that buffering out-of-date notifications results in a
>> "past-tense service" rather than in a presence service, and I do
>> not believe this is desirable. It will require enhanced complexity
>> on the subscriber side to handle out-of-date notifications.
>> Otherwise it means to delay up-to-date notifications, which is even
>>  less desirable. That's why I support "single-element LIFO (or, as
>> Paul put it, LIOTO)" at least for presence. Probably the draft can
>> be cleaned up in this respect.
>> 
>> To add more detail: Only one example is given. I remember Dean had
>> reviewed the text earlier on the mailing list, and I believe the
>> examples he gave were much more illustrative. In the example given,
>> Lisa receives "all the buffered notifications". It seems that this
>> can be all notifications or none, depending on the notifier,
>> correct? I think this should be made more clear.
>> 
>> Additional comment: On REQ6: I agree with the principle, but I
>> think it is that obvious that it should not only be placed as a
>> requirement but as a general principle somewhere else in the
>> document. A limit given by the subscriber is a limit and should not
>> be confused with a performance requirement towards the notifier.
>> 
>> Regards, Alexander
>> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Adam Roach Sent:
>> Thursday, March 11, 2004 3:35 AM To: Eric Burger;
>> [email-masked] Cc: Sipping (E-mail) Subject: RE: [Sipping]
>> WGLC for draft-ietf-sipping-event-throttle-reqs-00. txt
>> 
>> 
>> Eric:
>> 
>> While I agree with your overall point, I have to take contention
>> with one of your examples.
>> 
>>  attempt to construct "where have I been" out of potentially lossy
>> stream of "where am I" information gathered over a period of time.
>> 
>> _______________________________________________ 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