SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: unsolicited Vs immediate; restart delay



    > There's no architected mechanism to figure out on its own!  Either it 
    > has to keep the (session, connection, task) states around for a long time, 
    > OR it can clean up the these states and trigger an unnecessary ULP 
    > recovery on the initiator which is surprised at an unexpected restart failure
    >  
    > (keep in mind that initiator may not be able to restart a login precisely 
    > after the "minimum time" specified, typically there's an aggregation 
    > of multiple O/S timer requests into one master handler).  Providing an 
    > upper limit is a cleaner, safer design for both initiator and target.
    
    I agree with Mallikarjun.
    
    This is a big problem already faced by increasingly general FCP
    configurations.  The idea that RR_TOV (the resource recovery timer,
    which is equivalent to the timer being discussed here) could be
    fixedly specified (as opposed to communicated in the protocol) only
    really works with a narrow set of assumptions about the application
    configurations.
    
    With many order of magnitude range in delays, as happens with
    `internet' protocols, we really can't specify a fixed delay.
    Furthermore, in this particular case, we can't really punt it to the
    target to select.  The target has no idea.  The sad fact is that the
    initiator may not have much of an idea either, but if we don't
    provide the knob, a target choice is guaranteed to be wrong in some
    cases.
    
    Of course, you probably remember that I'm not a fan of recovery in any
    case, so my solution would be to punt recovery altogether.  Clearly
    that's not going to happen, so the next choice is to make it work :^)
    
    Steph
    


Home

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