Subject: RE: [nfsv4] (no subject)

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 24 Aug 2005 17:18:28 -0400

> Yes, or they participate but the system's broken, etc.  You could also
> ask whether clientid (or ip address, or whatever you really want to
use)
> counts the right thing.

That's up to the implementation.  You can count IP adresses.  You can 
count requests issued by the associated addresses.  When there are 
sessions, you can count requests or ops on sessions associated with 
a given implementation.  You can give special weight to clients with 
a large ops-per-second.  What metric you choose to use to govern your 
testing is a choice you make, based on what's important to you.  Clearly

there are many bad choices and some of the good ones are better than 
others.

> If you really wanted accurate results I'd think you'd want to have
> someone actually do the hard work required to choose a representative
> sample of users and study them carefully, rather than just collecting
a
> lot of superficial data on every user out there.

If you want to do that, and then get the information for your
representative
sample where you can and follow up for those clients where you don't
(fix whatever is broken) then that would give you the accuracy/validity
that you want.

> So I'd think the important question would be whether implementation
id's
> would be useful to a person doing such a study.

I think they would be more useful than not having the information.  The
point is that how careful you want to be in sampling (or whether you
want
to sample at all) is a decision that implementers can make.  For some
people, the accuracy you want may be too expensive to achieve.  They 
would rather have a cheap set of numbers that is better than nothing 
than have ... nothing.  They may be wrong to want that, but I think 
that we are talking about providing informaion that can be used in 
numerous ways and the only use that is troublesome is not an inaccurate 
survey but the bug/workaround database.

Regarding that latter, some people have noted that to the truly kludge-
addicted that possibility already exists via the request tag.  I know
of no instance in which it has been used, though.  But if people are so
inclined, they will do this whether impids are available or not.  I
don't think that impids increase the risk very much.  I think Mike's
proposal does a lot to address the issue so as to reduce the risk.  
However, I'd like us to be as paranoid as we possibly can be while 
still being able to function.  Some possiblities:

    The server and client MUST NOT, UNDER ANY CIRCUMSTACES WHATSOEVER,
    behave differently as a result of the reciept of a particular impid
    or the absence of an impid.

    To guard against the possibility of servers or clients behaving 
    differently based on the impid of their partner, interoperabuility 
    testing should generally be done with sending of impid's disabled. 
    When impid's are sent during testing, the result should be verified 
    with the sending of impid's disabled.  Any difference in behavior
    should be noted as indicating the party (client or server) receiving
    such impid and behaving differently needs to be fixed.   

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2005 4:37 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] (no subject)

On Wed, Aug 24, 2005 at 01:23:18PM -0700, Mike Eisler wrote:
> Are you saying that a vendor might have lots of customers who chose
> not to participate in phone home?

Yes, or they participate but the system's broken, etc.  You could also
ask whether clientid (or ip address, or whatever you really want to use)
counts the right thing.  And I'd think you'd want to know which clients
actually matter.  (If a customer has 200 desktops and 1 critical
server, the fact that that the one server represents 0.5% of the NFS
clients may not be a useful statistic.)

> We could get into deep discussions as to whether the customers who do
> participate are self-selecting toward certain clients or not and
> create bias. Even if that is true, it isn't a bad thing if the
> customers who opt for the best possible vendor support also get best
> possible quality assurance.

If you really wanted accurate results I'd think you'd want to have
someone actually do the hard work required to choose a representative
sample of users and study them carefully, rather than just collecting a
lot of superficial data on every user out there.

So I'd think the important question would be whether implementation id's
would be useful to a person doing such a study.

--b.

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

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

---

From: Mike Eisler <[email-masked]>
Date: Wed, 24 Aug 2005 14:24:27 -0700 (PDT)

>     or the absence of an impid.

I've got less alarmist text that is semantically the same, but I will
add that in.

>     such impid and behaving differently needs to be fixed.   

I like that idea too.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 24 Aug 2005 17:25:53 -0400

>     The server and client MUST NOT, UNDER ANY CIRCUMSTACES WHATSOEVER,

Wow, do you think we can get that one added to 2119?

--b.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 16:32:04 -0500

> >     such impid and behaving differently needs to be fixed.   

Make it configurable.  Tell customers to scream at the implementors if
turning off IMPIDs breaks anything.

---

From: Benny Halevy <[email-masked]>
Date: Thu, 25 Aug 2005 00:45:21 +0300

comment below...

Benny

> I've got less alarmist text that is semantically the same, but I will

Maybe this is obvious but I think that this should be 
restricted to the semantics specified by NFSv4.  For 
example, there's nothing wrong with a server that will 
implement a different read-ahead algorithm based on the 
impid, right?  This should be unnoticeable to a test program 
that tests NFSv4 semantics.  It might notice different 
performance characteristics though - which should be allowed.