SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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