|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Some proposed vendor-specific (X-) keysKen, 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:ksandars@eurologic.com] Sent: Friday, June 07, 2002 10:54 AM To: pat_thaler@agilent.com; ni1d@arrl.net; bmastors@allocity.com Cc: ips@ece.cmu.edu 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, 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
Home Last updated: Mon Jun 10 19:18:47 2002 10646 messages in chronological order |