SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI - bookmarks change



    David-
    
    Thanks; that was the kind of response I was hoping for.
    A few more comments below.
    
    Black_David@emc.com wrote:
    > 
    > > If we simply have to have a way for a special implementation
    > > to do multiple outstanding text commands, we could say:
    > >
    > >    An initiator SHOULD have only one outstanding command on
    > >    a connection at any given time.
    > >
    > >    A target receiving a text command while another text command
    > >    is in progress on the same connection MAY reject either or
    > >    both commands.
    > >
    > > Standard implementations would then have only one outstanding
    > > command at a time; vendor-specific implementations could have
    > > multiples if they wish (providing that both initiator and target
    > > support them).
    > 
    > Sorry to butt in on this, but ...
    > 
    > That sort of compromise leads to interoperability problems.
    > Either support for multiple outstanding commands is REQUIRED,
    > or there is REQUIRED behavior when an implementation does
    > this *and the Target detects it* (it's possible to overlap
    > commands in a fashion that the target won't detect), or
    > support for overlapping commands is negotiated on login
    > leading to one of the previous two possibilities.
    > 
    > The quoted text is in invitation to mismatched assumptions
    > between Initiator and Target and resulting interoperability
    > difficulties - the truly dangerous piece of Mark's text is
    > the unpredictable ability to reject a new command
    > based on existence of an old one, as it's entirely plausible
    > to create a situation in which no forward progress is possible.
    
    The text I sent would be dangerous; that was part of the point
    of sending it.  If we wanted to keep the SHOULD, we would also
    have to add the "MAY reject" stuff to cover the target side.
    To really make this work, everyone either has to support multiple
    outstanding commands or not.
    
    > I think Mark's original suggestion of turning the SHOULD into
    > a MUST (only one outstanding Text Command on a connection) is
    
    This is what I would prefer as well.
    
    > the better course of action, possibly with an additional sentence
    > requiring Task Abort to work on Text commands (i.e., to abort
    > a text command that's using bookmarks, fire a Task Abort at
    > it, after that succeeds, the next Text command will also).
    > A target that receives a text command in the presence of an
    > outstanding one then rejects the second as a protocol error.
    
    I'm not so sure about the task abort for bookmarks; wouldn't
    it be simpler to assume the task abort on receipt of the next
    text command?  I think that's what Julian had intended.  If
    a command is sent, and a response (with B=1) is received, and
    another command is sent, the target would silently discard any
    leftover context from the first command, and perform the second.
    
    There is another error case, however.  If a text command is
    sent, and a response has not yet been received at all, and
    the initiator wants to send a different command, we would need
    to decide what to do.  Your method using task abort above would
    work well in this situation, and we should specify what
    happens.
    
    --
    Mark
    
    > 
    > Thanks,
    > --David
    > ---------------------------------------------------
    > David L. Black, Senior Technologist
    > EMC Corporation, 42 South St., Hopkinton, MA  01748
    > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    > black_david@emc.com       Mobile: +1 (978) 394-7754
    > ---------------------------------------------------
    
    -- 
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    


Home

Last updated: Thu Sep 06 02:17:20 2001
6363 messages in chronological order