Re: iSCSI: Some proposed vendor-specific (X-) keys

[Ken Sandars <ksandars@eurologic.com>]

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


On Thursday 06 June 2002 11:31 pm, pat_thaler@agilent.com wrote:
> 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.
>

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 ;-)


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

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


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

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


> Regards,
> Pat
>
> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, June 06, 2002 1:06 PM
> To: bmastors@allocity.com
> Cc: ksandars@eurologic.com; ips@ece.cmu.edu
> Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys
>
> >>>>> "Bob" == Bob Mastors <bmastors@allocity.com> 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.

Welcome to my nightmare!

>
> I read your message as saying that there isn't going to be
> 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
> 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.
>

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
ksandars@eurologic.com