SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: ISCSI: CmdSN in non-leading login



    
    Perhaps our notes passed in the night, but that is what I attempted to say
    in my last note, your comments are correct.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>@ece.cmu.edu on
    05/13/2002 12:05:53 PM
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    Bill Studenmund <wrstuden@wasabisystems.com>, Julian
           Satran/Haifa/IBM@IBMIL
    cc:    John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu, "Mark S. Edwards"
           <marke@muttsnuts.com>, owner-ips@ece.cmu.edu
    Subject:    RE: ISCSI: CmdSN in non-leading login
    
    
    
    John,
    
    I don't understand your point. An outstanding immediate command doesn't
    affect the progress of ExpCmdSN or MaxCmdSN. In the situation you describe,
    the target would act on the non-immediate commands 1000 and 1001 when it
    got them. It would then increase MaxCmdSN as it empties those non-immediate
    commands from its queue.
    
    The login immediate command with CmdSN would be processed when it arrives
    regardless of the current non-immediate command's CmdSN. Any immediate
    command can arrive with a CmdSN lower than ExpCmdSN or higher than
    MaxCmdSN. The use of CmdSN in immediate commands is to allow the immediate
    command to have a relationship to the non-immediate commands - e.g. CLEAR
    TASK SET.
    
    Pat
    
    -----Original Message-----
    From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
    Sent: Monday, May 13, 2002 10:57 AM
    To: Julian Satran
    Cc: John Hufferd; ips@ece.cmu.edu; Mark S. Edwards;
    owner-ips@ece.cmu.edu
    Subject: Re: ISCSI: CmdSN in non-leading login
    
    
    On Sun, 12 May 2002, Julian Satran wrote:
    
    > John,
    >
    > My only point was that there is enough information in the section to
    > describe correct behavior.
    
    > And immediate commands do not create any blockage regardless of their
    > CmdSN.
    
    Don't they though? Say I have a queue depth of 2, and I start a secondary
    login with a CmdSN of 1000. I can then send other immediate commands at
    1000, and a non-immediate command at 1000. I can then also send a
    non-immeidate command at 1001. But can I send a command at 1002 before the
    login has finished? If we increase the queue depth, there will still be
    some other command number that would overflow it.
    
    Say the login takes a while. Won't the login pin the queue at 1002 until
    it's done? Now let the login take a while, it requires talking to say a
    low kerberos server or doing a DH computation. If we really pay attention
    to CmdSN, then the slow login process can effectively take the device
    off-line while it completes, since we can't enqueue new commands.
    
    Worse yet, say the secondary connection is NOT from our initiator, but
    from an imposter. All the rogue has to do is get the TSIH right & guess a
    CmdSN, and stall at trying to add another connection. Say do leading
    negotiation, but just never send any security negotiations. The queue will
    eventually become pinned until the target times out. Nice little DOS
    attack; all you have to do is get the TSIH right & guess a CmdSN. You
    don't have to do any security negotiation.  :-)
    
    I'd like to suggest that we just ignore CmdSN on non-leading sessions,
    beyond the fact that a well-behaved initiator should pick a CmdSN in its
    current command window. We certainly shouldn't pay attention to it before
    security negotiations have completed. :-) Oh also no commands should be
    sent over the new connection with a CmdSN lower than the one used in the
    new connection.
    
    Take care,
    
    Bill
    
    
    
    
    


Home

Last updated: Tue May 14 01:18:32 2002
10113 messages in chronological order