Subject: Re: [ldapext] VLV: a particular target entry

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 03 Oct 2002 12:49:26 -0600

Help me understand the stability problem further. If the cookie
mechanism is used, a server knows the last view that the client has. If
a client asks for a new view (by offset) that overlaps or adjoins the
last view, the server should be able to provide contiguous results--even
when updates are happening.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/01/02 09:09AM >>>
At 07:21 AM 2002-10-01, David Boreham wrote:
>> Do you not see that VLV is broken without selection by DN.
>> That is, the VLV scroll up/down mechanism fails in the
>> general case, e.g. when content is unstable.
>
>Highly unstable content isn't within the scope of this
>protocol.

Note that I did not say "highly unstable".  I said "unstable".
That is, one entry add/modification/delete is sufficient
to cause this protocol to fail.

>Directories typically don't have highly unstable content.

But directories typically do change.  And any change is
sufficient to cause failure in this protocol.

>Kurt: do you have a counterexample ? e.g. something
>you tried to implement with the current protocol but failed 
>to get to work ? Tell us about it.

Based upon my operational experience with implementing similar
controls, it is obvious to me that the current protocol fails
where contain is not stable.  In particular, were DIT
modification causes the positioning of entries in the list to
shift.

Kurt

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 03 Oct 2002 12:05:30 -0700

>when updates are happening.

First, note that the present cookie is optionally provided by
the server and optionally returned by the server.  It's purpose
has been described to allow the server to make optimize processing
of related requests.  It, however, hasn't been described as a
mechanism which the protocol relies on to address content
instability.

If servers were REQUIRED to provide a cookie and clients
were REQUIRED used the cookie in subsequent related requests, then
the cookie could be used to address the stability problem.

I would refer to this as a "state-full" approach.

However, the authors have stated that VLV could be implemented
in a "state-less" fashion.  No cookies.

Either VLV is
        stateful - some state is needed.
        stateless - no state is needed.

Which is it?

---

From: "David Boreham" <[email-masked]>
Date: Thu, 3 Oct 2002 13:20:52 -0700

> cookie so that the client's views could be known to the server. Novell
> is the one that requested it, and it wasn't to solve any performance

I guess I saw it as a performance issue in that the Novell server
could serve non-cookied requests, it would just be slow to do so.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 03 Oct 2002 14:31:05 -0600

nope, it was to do with multiple concurrent duplicate VLVs from a single
client on the same connection. I tried poking around the archives so I
could quote myself, but there are a bunch of zero-byte archives that I
fear hold the messages.

Jim

>>> "David Boreham" <[email-masked]> 10/03/02 02:20PM >>>

---

From: "David Boreham" <[email-masked]>
Date: Thu, 3 Oct 2002 13:37:31 -0700

> could quote myself, but there are a bunch of zero-byte archives that I

I have a pretty clear memory of the discussion.
My memory says that it was related to the Novell 
server implementing only approximate indexing into the lists.
Without the cookie, the database engine would need to
create a new cursor (or whatever equivalent thing it uses)
for every request. With the cookie it keeps cursors live
for each client context.

The Netscape/Sun servers are able to serve multiple
concurrent clients without the cookie (because they maintain
an exact index into the list---all state to serve the request
unambiguously is carried in the request without needing 
the context carried over from operation to operation).

Perhaps I've been smoking something in the meantime...

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 03 Oct 2002 14:40:53 -0600

Yes, the cookie/cursor association is how we maintain state, and can
therefore perform page up/down sucessfully.

Jim

>>> "David Boreham" <[email-masked]> 10/03/02 02:37PM >>>

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 03 Oct 2002 14:47:54 -0600

>>>> "Kurt D. Zeilenga" <[email-masked]> 10/03/02 02:35PM >>>
>At 01:13 PM 2002-10-03, Jim Sermersheim wrote:
>>The original purpose of the cookie was to provide a way for a server
to
>>associate a list with a client/connection. The problem was that a
client
>>could be maintaining two VLV lists on the same connection, using the
>>same search criteria. In order for the server to perform certain
>>operations (like consistent page up/down) it was neccessary to add
the
>>cookie so that the client's views could be known to the server.
>
>Then the document should be clarified that the cookie is
>used to maintain state between related operations and that
>in the absence of a cookie, the server is to assume the
>operation is for an unrelated list.

I agree (unless the server implementation is to work against a more
static list).

>Note, even if the server only supported one list at a time, the
>request needs to state whether it is related to previous VLV
>operations or is unrelated.

yes

>>Novell is the one that requested it, and it wasn't to solve any
performance
>>issues.
>
>Okay, but this isn't what the I-D says nor what the author has said
>on this list in <[email-masked]>.
>
>  Cookies are optional because they're a performance optimization
>  required only by a subset of implementations. 

It was added a long time ago. We should have added the intent into the
doc (we probably left it out in order to leave its use unlimited).

>>The reason it was added as an optional component was to not cause
>>backward compatability problems with implementations that existed
before
>>its introduction.
>
>If a server doesn't return a cookie, what is the client to
>make of this?  Is it to assume that the server only supports
>one VLV list?  Is it to assume that each subsequent requests
>will be treated as related?  or treated as unrelated?

Since some implementations use more static (pre-canned) result sets,
the client can't really assume anything. Even if we required the cookie,
we can't cause all implementations to use it to ensure continuity or
quality. I think it's sufficient to have the mechanism available, state
its intended use, and allow clients to assume that all servers will
return contiguous results, regardless of how they achieve that.

>>This should all be captured in the archives.
>
>It needs to be captured in the I-D.

I agree. This is an easy fix.

Jim

>Jim
>
>>>> "Kurt D. Zeilenga" <[email-masked]> 10/03/02 01:05PM >>>

---

From: "David Boreham" <[email-masked]>
Date: Thu, 3 Oct 2002 14:04:13 -0700

> The client may or may not run into a stability problem, depending on the
> server implementation. I believe iPlanet implements VLVs by using a
> pre-canned result set (at least that's one implementation). With that

It doesn't do this. It maintains an always-correct list of the results
for any VLV searches specified in advance (indexed). Otherwise it computes
the result set by brute force for each operation, or punts saying the
request is too hard to resolve.

> I don't know how they handle changes to the canned result set, or
> changes to the users access control.

It is possible for the client to miss entries or jump into
some unfamiliar part of the list, if the list is highly dynamic
concurrent with the client paging. I'm not convinced that it
is possible (or even desirable) to try to invent a browsing
mechanism which handles highly dynamic content, even with a 
context cookie.

Does anyone have an application which needs this ?
I've seen countless VLV applications developed and
deployed and have never had this come up as a problem.

We're talking address book lists here folks. If you want
to do a scroll view onto a dynamic SQL result set, cool,
but is this the place to be defining the protocol for that application ?

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 03 Oct 2002 16:10:16 -0600

If every entry in the client's current view has vanished, you would just
attempt a re-position based on their current requested offset. They
would end up in a place that may or may not be confusing.

In my mind, for this particular issue, there doesn't need to be any
change to the VLV protocol. Only clarifications and further notes to
implementers.

Jim

>>> "David Boreham" <[email-masked]> 10/03/02 03:54PM >>>
Discussion point: what if the complete list were to change between
two VLV requests from a client ? How does a cookie help us to
render something unconfusing to the client ?

If, as I hope, it's clear that this is a hopeless exercise, then
let's think about a continuum of progressively less and less
major change to the list between consecutive requests...

Where on this continuum would we decide that there was
sufficiently little change to make it possible to use cookies
or whatever other protocol devices to ensure that the user
isn't 'confused' by the list change ?