SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    No Subject



    Sender: plabat@cup.hp.com
    Message-ID: <396616B2.84603BDD@hp.com>
    Date: Fri, 07 Jul 2000 10:43:14 -0700
    From: Pierre Labat <pierre_labat@hp.com>
    Organization: Hewlett Packard ATM-SISL
    X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
    X-Accept-Language: en
    MIME-Version: 1.0
    To: ips@ece.cmu.edu
    Subject: Recovery from a dropped TCP connexion
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    
    Hello,
    
    In the last teleconf it has been stated that :
     -> in case of a droped TCP connexion, a command that was on the flight
          must be replayed on a new TCP connexion going through the same
          service delivery port. This, because SAM-2 requires that all that
    concern
          one command must flow through the same delivery port.
    
    But, because the recovery is done at the command level, why not
    abort this command on the target (the target will abort/cancel locally
    all the commands on the flight for the dropped TCP connexion),
    and replay the command on another link (other service delivery port).
    As the command will be totally restarted we don't need some intermediate
    
    command state that would need to be maintained per port.
    We can cleanup what was ongoing for this command on the initial port
    and restart drom scratch on the alternate port.
    
    It doesn't hurt SAM-2 because the replay of the command is a whole
    new command.
    Of course iSCSI must change the LUN in the headers to take into account
    the new service delivery port.
    
    The big advantage is that it can speed up the recovery.
    1) It is likely that if the TCP connexion dropped through a service
      delivery port, the attempt to open a new one through the same
      SDP will fail.
    
    2) Replaying the command through an alternate link is faster
      than waiting for the establishment of new TCP connexion.
    
    Regards,
    
    
    Pierre
    
    
    
    


Home

Last updated: Tue Sep 04 01:08:10 2001
6315 messages in chronological order