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

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Mon, 10 Jun 2002 14:10:00 -0600

Ken,

The incentive is that, in my experience, when products interoperate out of the chute (because the spec is clear) the market grows quickly. When interoperability is a nightmare built in by testing and tweaks, then markets grow slowly.

Ambiguities need to be fixed. A number that have been raised recently have been fixed. If there are ones you feel haven't been addressed, I would like to see them fixed. That is what we should do rather than planning on building in work arounds.

Regards,
Pat

-----Original Message-----
From: Ken Sandars [mailto:[email-masked]]
Sent: Friday, June 07, 2002 10:54 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys

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, [email-masked] 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:[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.

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
[email-masked]

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 15:19:25 -0700 (PDT)

On Mon, 10 Jun 2002, THALER,PAT (A-Roseville,ex1) wrote:

> Ken,
>
> The incentive is that, in my experience, when products interoperate
> out of the chute (because the spec is clear) the market grows quickly.
> When interoperability is a nightmare built in by testing and tweaks,
> then markets grow slowly.
>
> Ambiguities need to be fixed. A number that have been raised recently
> have been fixed. If there are ones you feel haven't been addressed, I
> would like to see them fixed. That is what we should do rather than
> planning on building in work arounds.

I agree that if folks know of ambiguities, we should fix them. PLEASE
bring them up. NOW. :-)

I also agree that we shouldn't ship a spec with what we know to be holes
in it. In fact, that's why my EMails have been quite, shall we say,
vigorous. _I_ want iSCSI to be the best spec it can.

The question to me, though, is two-fold. 1) as my other note indicates, I
think these keys have value on their own (I don't plan on using them for
bug adaptability, just info).

2) (and this is the bigger question) What do we do about bugs we find
*after* we get to RFC stage?

Yes, we fix them in the next version. But how quickly are we going to get
that version out?

Are we going to crank RFCs out as fast as Julian can make I-D drafts now?
I doubt it. If we were, then I think saying, "Update to the next version,"
is a reasonable approach.

I expect iSCSI 2 (or 1.1) will be on the order of a year or more out from
iSCSI. What does everyone else think?

What do we do in the mean time? And shouldn't we think about that now?

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Mon, 10 Jun 2002 20:28:22 -0400

Excerpt of message (sent 10 June 2002) by Bill Studenmund:
>... 2) (and this is the bigger question) What do we do about bugs we find

If the spec is as good as it should be, that's a fine time frame.  But
if significant interop issues are found soon after RFC, then 1.1 will
have to happen a whole lot sooner.
    
    paul

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 17:51:57 -0700 (PDT)

> have to happen a whole lot sooner.

What happens if we're somewhere inbetween? Or what if we find an issue
where 80% of the implementations all chose the same way?

I'm trying to scope out the shades of gray we might run into.

Take care,

Bill

---

From: David Robinson <[email-masked]>
Date: Mon, 10 Jun 2002 21:50:50 -0500

> I'm trying to scope out the shades of gray we might run into.

As a reminder about the IETF standards process, RFC2026. The IPS
working group is driving towards "Proposed Standard" which
by definition: "Implementors should treat Proposed Standards as
immature specifications." The next step is "Draft Standard"
where there is expectation that changes will be made between
Proposed and Draft.  "A Draft Standard is normally considered
to be a final specification..."

To move from Proposed to Draft is where two independant implementations
are required and where the "80%" implementation problems are caught
and fixed.

The RFC we are driving towards is just the first step in a long
path, there will be plenty of opportunities to fix "bugs" that
are found we real implementations are built. Thus vendor specific
keys are not needed, what we have today is not going to be
the "Internet Standard."

	-David

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 11 Jun 2002 11:20:09 -0700 (PDT)

> keys are not needed, what we have today is not going to be

So what do we tell our customers? Our paying, cranky customers? That they
are part of the great iSCSI experiment? Or worse yet, what are you going
to tell your sales folks when a big sale doesn't go because of some
interop quirk? Try again in 6 months when the equipment has already been
bought? :-)

I'm not saying we shouldn't work (hard) to fix all the problems we can.

I'm saying that a policy of, "You loose," to the customers who run into an
interop problem is impolite. :-|

Take care,

Bill

---

From: Santosh Rao <[email-masked]>
Date: Tue, 11 Jun 2002 12:02:49 -0700

I don't see why this thread is going forever. There are other scsi
transports that deal with these types of issues without having to define
scsi transport protocol keys to indicate vendor_id, product_id and
product_rev. You can do one of the following :

a) Parse out the DNS name of the target device from the exchanged
TargetName key, if you're an initiator. Similarly, parse out the DNS
name of the initiator from the exchanged InitiatorName key, if you're a
target. Use the DNS name as an indication of which device you're
speaking to and add your device specific tweaks based on this.

If the InitiatorName or TargetName is in EUI-64 format, you can obtain
the vendor_id information from the upper 3 bytes of the EUI-64 name.

b) Send INQUIRY to LUN 0 to determine the vendor_id, product_id and
product_revisison_level of the device. Use this data to perform any
device specific tweaks in your software/firmware.

c) Provide out-of-band static configuration mechanisms in your initiator
or target to assign a vendor specific identity to 1 or more initiators
or targets. This allows the target configuration personnel to configure
the device appropriately for the initiators it is speaking to. 

I don't see any need to be defining iscsi login keys to duplicate the
vendor_id, product_id information. 

- Santosh

-- 
The world is so fast that there are days when the person who says 
it can't be done is interrupted by the person who is doing it.
	~ Anon

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 11 Jun 2002 12:49:49 -0700 (PDT)

> speaking to and add your device specific tweaks based on this.

That we can do. But that means that the system adminsitrator or a "smart
agent" has to correlate the info. And, if a device moves, it has to get
involved again to reconfigure.

It could be that this won't be a problem, but it could also be a hassle.

> the vendor_id information from the upper 3 bytes of the EUI-64 name.

That only gets you one of the three keys. :-) The product and revisions
are the ones that are more important if we are bug-compensating. :-)

> device specific tweaks in your software/firmware.

That assumes that the iscsi device is the same as the scsi device. In the
case of an iscsi->FC or iscsi->Parallel SCSI gateway, that's not going to
be the case.

> the device appropriately for the initiators it is speaking to.

That, like the first option above, involves correlating a lot of info, and
keeping it up to date. Sounds like turning a protocol mess into a
management mess.

> vendor_id, product_id information.

Well, that's your opinion. Some of us feel that what you describe above is
a hassle we'd rather spare our customers. Especially since happy customers
spend more. :-)

Take care,

Bill

---

From: Santosh Rao <[email-masked]>
Date: Tue, 11 Jun 2002 12:02:49 -0700

- Santosh

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 17:51:57 -0700 (PDT)

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Mon, 10 Jun 2002 20:28:22 -0400

paul

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 11 Jun 2002 12:49:49 -0700 (PDT)

Take care,

Bill

---

From: David Robinson <[email-masked]>
Date: Mon, 10 Jun 2002 21:50:50 -0500

-David

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 15:19:25 -0700 (PDT)

Take care,

Bill

---

From: David Robinson <[email-masked]>
Date: Mon, 10 Jun 2002 21:50:50 -0500

-David