SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI-Asynch event code



    Santosh,
    
    	If there were only one connection per session I would agree, but I
    think you are overlooking the multiple connection case.
    
    	If an initiator has say 10 connections in a session and the target
    requests a logout of one of them what motivation does the initiator
    have to reopen that connection in a timely manner? And as I mentioned,
    the initiator may be unable to connect to the target for many reasons.
    The spec doesn't mandate an initiator re-login in a connection and any
    target design that assumes it will is a bad one.
    
    	- Rod
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Santosh Rao
    Sent: Wednesday, June 12, 2002 5:47 PM
    To: pat_thaler@agilent.com
    Cc: ni1d@arrl.net; Julian_Satran@il.ibm.com; ips@ece.cmu.edu
    Subject: Re: iSCSI-Asynch event code
    
    
    
    I don't see a need to allow key re-negotiation during FFP. The only
    key
    that is really required to be used in FFP is SendTargets.
    
    The keys that are permitted during FFP are :
    
    - SendTargets
    - TargetAlias
    - InitiatorAlias
    - TargetAddress
    - MaxRecvDataPDUSize (or whatever its latest name is)
    - Vendor Specific keys
    
    Of the above, the only real negotiation involves the MaxRecvPDUSize. I
    don't see any use of attempting to modify/negotiate/communicate the
    remaining keys during FFP (with the exception of SendTargets).
    
    I see no problem in forbidding key re-negotiation during FFP and
    handling PMTU changes by dropping the connection and allowing it to be
    re-established.
    
    There needs to be a conscious effort to simplify this login
    negotiation
    process and bound the complexity that's being heaped upon it. If we
    don't make the attempt to keep it simple, we are going to be bitten by
    a
    bunch of bugs in this area due to its complexity.
    
    This is one such area where we can choose not to increase the
    complexity
    of login negotiation.
    
    There have been some concerns raised about the initiator not logging
    back in upon a target driven logout. Such an initiator driver is a
    poor
    design. As long as an upper layer in the O.S. has an open pending on
    some LUN of that target port, it is the duty of the initiator driver
    to
    attempt to keep the I-T nexus established, and if there's a transient
    glitch in the I-T nexus, the initiator must attempt to re-login.
    
    An initiator that does not do this gets what it deserves. There's no
    need to add complexity to the spec in an attempt to deal with poor
    initiator implementations. The target need not care if the initiator
    does not log back, in this case.
    
    - Santosh
    
    
    
    pat_thaler@agilent.com wrote:
    >
    > Paul and Santosh,
    >
    > If this isn't needed, then I don't see why FFP negotiation is needed
    at all (other than to support discovery with SendTargets but that
    isn't really a negotiation). The initiator could also close and reopen
    the connection to change PDU size. If we support renegotiation of some
    keys during FFP for the initiator, then we should do it for the target
    as well. Otherwise we shouldn't support renegotiation at all.
    >
    > Pat
    >
    > -----Original Message-----
    > From: Paul Koning [mailto:ni1d@arrl.net]
    > Sent: Wednesday, June 12, 2002 1:54 PM
    > To: santoshr@cup.hp.com
    > Cc: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
    > Subject: Re: iSCSI-Asynch event code
    >
    > Excerpt of message (sent 12 June 2002) by Santosh Rao:
    > >
    > > Why is this needed ? The target can just send an async event to
    drop the
    > > connection or request a connection logout, and the connection can
    be
    > > re-established allowing for new negotiation.
    > >
    > > I don't see the point of making this change so late in the game.
    There
    > > exist mechanisms such as target driven connection logout/drop
    which can
    > > be used to achieve the same effect.
    >
    > I agree.
    >
    >     paul
    
    --
    The world is so fast that there are days when the person who says
    it can't be done is interrupted by the person who is doing it.
    	~ Anon
    
    


Home

Last updated: Thu Jun 13 14:18:44 2002
10759 messages in chronological order