SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Out Of Sequence due to null sequence with multiple connections.



    See comments below, marked with ++++
    
    Charles Binford
    Pirus Networks
    316.315.0382 x222
    
    
    -----Original Message-----
    From: Black_David@emc.com [mailto:Black_David@emc.com]
    Sent: Monday, April 02, 2001 2:13 PM
    To: CBinford@pirus.com; ips@ece.cmu.edu
    Subject: RE: iSCSI: Out Of Sequence due to null sequence with
    multipleconn ections.
    
    
    It still appears to me that the behavior that
    Charles wants is available by sending the task management
    function twice - once for immediate delivery and once for
    ordered delivery.  Duplication on all connections would
    not be necessary in the normal case because the ordered
    instance would naturally come behind the unordered ones.
    The timer seems to be something that ought to be taken
    up under error recovery in general (and in particular,
    we should consider letting TCP time out the connection
    rather than adding yet another recovery timer).  IMHO,
    the bottom line is that the logic to duplicate the task
    management commands at the Initiator and coordinate
    them at the Target costs implementation complexity,
    and I have not seen a convincing statement of what
    we're buying with that added complexity.
    
    It may be the case that applications don't want to be
    bothered with sending task management commands twice,
    in which case we have a coordination problem of some
    form that has to be addressed in iSCSI.
    
    +++++++++++++++
    I would state this much stronger.  Applications had better not have to know
    that it is iSCSI underneath vs. FCP or parallel SCSI else I believe we
    missed the objective (granted, some things such as target address space are
    unavoidably different, but I believe task management functions should be the
    same).  The transport needs to handle the transport issues without exposing
    quirks to the SCSI or application layer.
    
    I would be more agreeable if David was advocating the iSCSI layer was
    responsible for sending task management functions twice, once with, once
    without ordering.  This puts the handling of the iSCSI specific ordering
    issue in realm of iSCSI.  My caution to this approach is that is changes the
    behavior of the target slightly.  The SCSI target layer will see the task
    management function twice, not once.  I can't think of any scenario where
    this would matter, but I get nervous when we change behavior from the norm.
    ++++++++++++++++++ cb
    
    
    For further discussion,
    --David
    


Home

Last updated: Tue Sep 04 01:05:11 2001
6315 messages in chronological order