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

From: "John Hufferd" <[email-masked]>
Date: Sat, 8 Jun 2002 00:01:15 -0700

This thread is wasting bandwidth on this reflector.  Items of non direct
impact on the draft, should be taken to another venue.  I suggest the SNIA
IP Storage Technical Working Group.

It was quite a while ago when we decided that the iSCSI Spec did not want
to have profiles.  If profiles, or any agreement on X-,  is an
implementation issue which, again, is approprate for SNIA.  Please take the
issue there.

I encourage you all to control your selves and focus on fixing only broken
items, we need to reach closure on the spec.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

---

From: [email-masked]
Date: Mon, 10 Jun 2002 14:00:37 -0600

Bill,

It is the place of MIBs and CIM objects to cover items like this. For
diagnostic problems, these are more useful because they are available to
management systems as well as at the two ends of the link. 

Generally, building a duplicate capability to exchange management objects in
protocols adds cost without benefit.

Regards,
Pat

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Friday, June 07, 2002 10:27 AM
To: Robert Snively
Cc: 'Ken Sandars'; Ips Reflector (E-mail)
Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys

On Fri, 7 Jun 2002, Robert Snively wrote:

> The management component already has standard mechanisms
> for determining such information, including MIBs and CIM
> objects.  The operational components already have standard
> mechanisms for determining such information, including
> SCSI INQUIRY commands.  I cannot see how this additional
> (non-standard) mechanism for capturing this information is
> going to help iSCSI achieve its goals.

Question about the operational components being able to determine this
info. iSCSI is, in terms from SAM-2, a Service Delivery Subsystem (SDS).
While many implementations act as scsi servers (disks & tapes, etc.),
that's not part of the spec.

So I'm confused how an SDS answers a SCSI INQUIRY. I thought that was the
domain of the device(s) at the other end of the connection, not the domain
of the connection itself.

Take care,

Bill

---

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.

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

Ken,

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,

 

Welcome to my nightmare!

Cheers,
Ken

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

---

From: [email-masked]
Date: Mon, 10 Jun 2002 14:27:31 -0600

Luben,

An IETF standard is suppose to produce interoperability. Therefore, when
there is a MAY in the standard, it should be because each side can choose
either option and they will interoperate independent of which they choose.
For example:

"iSCSI targets and initiators MUST support at least one TCP connection
and MAY support several connections in a session."
A device that supports only one connection per session will interoperate
(over one connection) to a device that supports multiple connections.

Pat

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Friday, June 07, 2002 4:18 PM
To: Bill Studenmund
Cc: Robert Snively; 'Ken Sandars'; Ips Reflector (E-mail)
Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys

Bill Studenmund wrote:
> 
> 
> That comment reflects a very nice ideal. My concern is that I'm not sure
> we're there. What about Luben's comments that there are existing
> interoperability problems among compliant systems? AS I understand him,
> compliant *iSCSI* systems. ??

I haven't checked for those lately, (especially in the login procedure),
but any time you see ``MAY'' or ``may'' in the draft and a target
and initiator arrive at different outcomes _just_ by taking one
or the other route, you have ``compliant-non-interoperability''
(as you coined the term).
 
> My technical writing skills aren't up
> to the task to do anything different, and I expect someone will make some
> $$ off of an intro book.

There are books that talk about iSCSI now.

I bet that just one month after iSCSI becomes a standard,
you'll see 10 books on iSCSI, 5 for Unix/Linux (2 of them
with CDs + implementations) and 5 for Windoze.

I can think of at least one Linux Guru who's known to
write books like that (for a month's time) and who might
be considering this.
 
> But the problem (as a number of recent threads have shown :-) is that
> people who are looking at the spec for the first time don't necessarily
> come to understand the spec the same way that the longer-term WG members
> do. The longer-term members see the written spec as a clear reflection of
> their idea of the spec, so they don't see the problems. They've been to
> plug-fests, and so they have a lot of commonality in their mental ideas of
> what the spec is. When a choice comes up, they naturally choose the same
> way as the other longer-term members, and they don't always see that
> they've made a choice.

This basically is the old conundrum: 
How does one express one's ideas in the most unambiguous way?

We don't know of a better way than formalism (i.e. mathematics).

This is the reason I've been asking to be more formal
in the draft. And I'm not just whining, as I've made it clear
that I can volunteer time.

This is why 4.1 and 1. exist in their current form.
This is also why I've been trying to get the CRC algorithm
in 11.1 become more formal, which would make it more clear
and straightforward to implement. And this is why I'd like
to see someone draw the decision graphs for the login/text
stage/negotiations for the T and I -- then any problems
will be evident. And this is why Robert of UNH started the
variables' dependency charts.
 
> So what do we do?

The rest of us (certainly me) cannot do anything. I can just wait.
(I can only correct spelling mistakes and missed periods,
and such, like this one )

It would be interesing to see the development of iSCSI
and the reaction of the rest of the industry and (closer to my heart)
the Linux community once iSCSI becomes a standard.

-- 
Luben