No Subject

[Dave Nagle <bassoon@yogi.ece.cmu.edu>]

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