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

From: Adam Roach <[email-masked]>
Date: Wed, 10 Mar 2004 20:27:10 -0600

Regarding Eric's comments about whether this document
needs to be RFCed, I'm somewhat ambivalent. I could
see it being useful either way.

On the other topic under discussion -- whether the
subscriber should be allowed to specify a specific
algorithm to employ when multiple states are queued --
I think that such complication is not justified by
the practical applications.

Of key importance is the fact that most event
packages will have a single obvious mechanism that
is appropriate.

In many cases, the kind of combining that a notifier
can perform is limited by the specific way it has
been implemented. Forcing it to support suboptimal
combining cases that likely don't even make sense
for the event package is just a waste of code, and
may force unnecessary architectural concessions.

/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

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Mar 2004 20:35:17 -0600

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Mar 2004 20:44:32 -0600

Alex Audu [mailto:[email-masked]] wrote:

> ...[I]f you are doing something like presence-based routing,
> you don't want to route based on stale information.

Don't throttle, then.

/a

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 11 Mar 2004 11:17:45 -0500

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