Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys

From: [email-masked]
Date: Thu, 6 Jun 2002 17:31:09 -0600

Paul,

I agree. This would also create a testing nightmare for initiator
developers. If the initiator has adapts itself for n targets then 
it has n different personalities that all need to be tested.

We have interoperability testing to help us find and fix
spec ambiguities that cause interoperability problems. 

The way to build market for iSCSI is to have interoperability - 
not to have cases wher Brand_x Target doesn't work with Brand_y 
Initiator because Brand_y doesn't have the tweak profile for 
Brand_x.

Regards,
Pat

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Thursday, June 06, 2002 1:06 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys

>>>>> "Bob" == Bob Mastors <[email-masked]> writes:

 Bob> I like it.  Otherwise the user has to configure the initiator
 Bob> with the target type and the target with the initiator type.  It
 Bob> is unlikely that this problem will disappear for a long time if
 Bob> ever.  As the threads on the C bit has shown there will be lots
 Bob> of ways to implement the spec and probably no device will
 Bob> correctly support all possibilities.  I am already putting "if
 Bob> (vendor)" code in my implementation. Maybe in a few years I will
 Bob> not need it. But until then it would be nice if I could
 Bob> dynamically determine vendor information for iscsi so the user
 Bob> does not have to configure it. 

Oh boy, now I'm well and truly frightened.

I read your message as saying that there isn't going to be
interoperability for several years.  Sorather than create a serious
incentive for implementers to fix their defects, we should implement a
way to have them report which collection of defects they implement so
we can invoke workaround collection #42.  Of course, the larger the
collection of crocks we work around, the larger the number of bugs in
implementations that everyone else will have to work around.

In the words of a well known American, "Just Say NO".

     paul

---

From: Ken Sandars <[email-masked]>
Date: Fri, 7 Jun 2002 17:53:56 +0000

Hi Pat, Paul, Bob,

There is no disputing the fact that identifying brokeness and fixing it is 
the right way to go. 

Now while it's nice to lend our mental muscles to the task of identifying 
these problems, it's pretty difficult to compel other vendors to fix 
something which is broken wrt to the spec, when it works with some other 
products in the marketplace.

The unfortunate reality is that certain problems have been long identified 
(over half a year in some cases), and remain unfixed.
 
Our approach is to implement the spec. As we encounter problems we fix our 
broken bits and notify the partner of the issue - in most cases this has 
worked well and they have fixed their problems too. However, we are compelled 
to put work-arounds in our system in order to interoperate with those who 
have have fielded systems which remain broken.

At this stage, unless the intiator is known, we turn all the work-arounds on. 
This has an impact on performance. We'd like to avoid this. 

We want to see iSCSI run at the speed of a thousand startled gazelles. We 
want to see all iSCSI offerings interoperate. We don't want to see the 
management of these things as a nightmare.

I think the use of the proposed keys will only assist implementers by 
providing additonal information - which can be used or ignored.

Oh, and we won't send them from our target if the initiator doesn't send 
them, as there may be some initiator which doesn't handle the X- keys!

(I have further comments inline):

> it has n different personalities that all need to be tested.

As Bob Mastors said, it's already in there, so it's being done. And testers 
are meant to have nightmares! It's their job ;-)

> spec ambiguities that cause interoperability problems.

Yep - we find them, and they ignore them, so this doesn't get us over the 
finish line.

> Initiator because Brand_y doesn't have the tweak profile for

As I noted above, we interoperate, but at the cost of performance.

> Oh boy, now I'm well and truly frightened.

Welcome to my nightmare!

> interoperability for several years.  

I'm a lot more optimistic than that - these problems should be gone within a 
year of the draft becoming a standard. In the meantime, we DO interoperate, 
just in a hobbled mode for unknown initiators.

> Sorather than create a serious
> incentive for implementers to fix their defects, 

Can you suggest what this incentive might be?

> we should implement a

Sounds messy to me. It comes down to this: we work by default in a mode to 
achieve maximum interoperability, albeit at the expense of some 
performance/reliability features. If an initiator lets our target know what 
it is, and we recognise its lack of the known quirks, we remove the 
work-arounds.

Our tester's nightmares, our developer's pain to identify and create 
work-arounds, and at no cost to the standards track. And it's all optional.

> In the words of a well known American, "Just Say NO".

OK - but think carefully before following the advice of famous Americans - 
didn't some other well known American spell tomato with an 'e'?  ;-)

>      paul

Cheers,
Ken

-- 
Ken Sandars
Eurologic Systems Ltd
[email-masked]