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



    
    We could live with this too.  The SHOULD is strong enough to dissuade any
    initiator to issue more than one but MUST is good too.  The important thing
    is not to have this as a hidden assumption for other things so that if we
    feel (now or in the future that we want to remove the restriction we can do
    so).
    
    Julo
    
    Black_David@emc.com on 05-09-2001 23:04:46
    
    Please respond to Black_David@emc.com
    
    To:   mbakke@cisco.com, Julian Satran/Haifa/IBM@IBMIL
    cc:   ips@ece.cmu.edu
    Subject:  RE: iSCSI - bookmarks change
    
    
    
    > 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.
    
    I think Mark's original suggestion of turning the SHOULD into
    a MUST (only one outstanding Text Command on a connection) is
    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.
    
    
    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
    ---------------------------------------------------
    
    
    
    


Home

Last updated: Thu Sep 06 15:17:04 2001
6384 messages in chronological order