SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: ISID issue summary





    David,

    An excellent summary of the issues.

    A couple of things I want to point out about the "text key" proposal, however.
    a) The proposal sounds to me like iSCSI will have "optional SCSI Port names". Only when the key is used is the SCSI port named and when the key is not used, there is no such name. That's probably an acceptable situation as far as SAM-2 is concerned, but it certainly is odd.
    b) The proposal would require at least as much coordination above the "session manager" level as managing ISIDs, though admittedly, it need not be implemented in all cases.
    c) I'm concerned how to describe the model when names are optional, so as to avoid the parallel nexus problem. Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName.

    Jim Hafner

    Sent by: owner-ips@ece.cmu.edu

    To: ips@ece.cmu.edu
    cc:
    Subject: iSCSI: ISID issue summary



    For those who haven't been following the long intricate
    email discussion between Jim Hafner and myself, let me
    try to explain the issue.

    SCSI architecture (SAM2) is based on an intuition that SCSI
    ports are fixed (e.g., physical) things that have names.  So
    far, the existence of the names has been an intellectual
    curiosity as they haven't mattered to any visible SCSI
    functionality.  Single port Initiators predominate in
    both Parallel SCSI and Fibre Channel (e.g., a dual ported
    Fibre Channel HBA is usually treated as two SCSI Initiators,
    not a single dual-ported one).

    Jim tells us that T10 is about to define persistent reserve
    functionality that depends on the identity of the SCSI Initiator
    Port - in particular that under some circumstances, persistent
    reservations will be associated with the Initiator Port independent
    of the Target Port.  Persistent reservations are currently bound
    to the Initiator Port and Target Port (as well as the LU they
    affect).  For the rest of this message, I'm going to assume
    that we want to support this functionality.  Assuming this and
    that I got the description in this paragraph right ...

    ... I need to take a slight detour into pragmatics.  Those
    who configure storage networks rapidly discover the value
    of consistency and matching configurations.  Multi-path I/O
    configurations tend to want to see access to the same set of LUs
    consistently across a set of interfaces (i.e., Ports).  Between
    suitable configuration and the aggressive setup of connections
    to all possible targets, all the required connections come into
    existence as part of the boot process.  Applying
    this experience to the new persistent reservation functionality,
    one would expect persistent reservations that are bound only to
    an Initiator Port to be independent of the Target Port, in that
    the reservation should span connections to all of the relevant
    Target Ports and those connections should come into existence
    as part of the boot process.

    Turning to iSCSI, the situation gets complicated by the
    interaction of two factors:
    - Parallel sessions are permitted down to the interface
    level (e.g., more than one iSCSI session may exist
    that uses IP addresses A and B to connect iSCSI Initiator
    I to iSCSI Target T).
    - SCSI disallows parallel nexii (i.e., more than one session
    between the same two SCSI Ports).
    If SCSI Ports are mapped to hardware entities such as network
    interfaces in iSCSI, the opportunity for parallel sessions
    between the same pair of network interfaces vanishes.  In order
    to avoid that outcome, iSCSI Initiator Ports have to be
    mapped to software entities. To date, the ISID has been
    used to identify those software entities, and the only rule
    on their allocation is:

        ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
        Group (SCSI target port), then can be only one session with a given
        ISID (identifying a SCSI initiator port).  See 3.12.8.

    In order to get the expected outcome of the new functionality
    being defined by T10, the same ISID has to be used to establish
    all the connections that the persistent reservation is supposed
    to span.  Unfortunately, that's above and beyond what iSCSI
    requires - the relevant text about doing this in -08 is:

           The "ISID rule" does not preclude
           the use of the same ISID from the same iSCSI Initiator with
           different Target Portal Groups on the same iSCSI target or
           on other iSCSI targets

    "does not preclude" is rather weak language for something that's
    essential to making a piece of SCSI functionality work.  If an
    iSCSI implementation uses a different ISID for every session
    (which is also not precluded by the current text), then persistent
    reservations will never span Targets or Target Ports for that
    implementation despite T10's best efforts and intentions.  IMHO,
    allowing that outcome is *wrong* (and this is the source of the
    difference of opinion between Jim and myself).

    The correction to this involves what Jim has called "conservative
    reuse" of ISIDs.  This is something like for each ISID that an
    implementation uses, a connection with that ISID is made to
    every possible Target Portal Group of every possible Target.  I
    suspect a longer explanation than this will be needed, including
    a discussion of the desirability of avoiding a situation in which
    the same ISID is used by two iSCSI implementations that are part
    of the same Initiator and set up sessions concurrently.

    IMHO, if we want to support persistent reservations at this stage
    that span target ports, we need to replace the "does not preclude"
    language with a REQUIREMENT for conservative reuse to avoid a
    situation in which SCSI functionality that works consistently with
    other transports works inconsistently with iSCSI (i.e., doesn't
    work with iSCSI implementations that don't do conservative reuse).

    Stepping back from the assumption that support for port-spanning
    persistent reservations is required, I observe that the conservative
    reuse rule impacts all implementations, even those that will never
    use such persistent reservations because ISID is a mandatory part
    of the iSCSI protocol.  If a text key were used instead, only those
    Initiators that want to support this functionality on which T10
    is "crossing a few t's and dotting a few i's" are affected (the
    text key is optional).  The text key would be subject to a
    conservative reuse rule similar to the one that would be needed
    for ISIDs, and once T10 finishes the i's and t's, we can precisely
    reference the SCSI features (persistent reservation expansion)
    that require use of this text key.

    In addition, text keys have much better alternatives for dealing
    with conflicts than ISIDs - if a text key conflicts, it is possible
    to continue  the negotiation with a different text key, whereas
    ISID conflict is fatal to one of the two sessions involved.
    As Jim has previously observed, changing the text key (e.g.,
    generate a large random number in response to a conflict),
    results in a situation that can be dealt with by software that
    uses persistent reservations, although this departure from
    conservative reuse should only occur as a consequence of some
    sort of configuration mistake or bug.  At the tail end of this
    reasoning chain is the observation that use of this text key
    leaves the ISID without value/purpose, and hence would call
    for its removal (or perhaps designation as a reserved field).

    Putting on my WG chair hat for a moment, I can accept either
    alternative outlined above:
    - Add conservative reuse to the ISID rule.
    - Use a text key for iSCSI port identification.
    But I'm not comfortable with the current situation in which iSCSI
    implementations are permitted to break T10-defined SCSI features
    that will work as expected in other SCSI transports.

    I hope this now makes sense to more people than just Jim and I,
    and I apologize for the length of this message, as this is a
    somewhat subtle issue.

    Comments?
    --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: Wed Oct 10 11:17:30 2001
7177 messages in chronological order