RE: iSCSI question

[pat_thaler@agilent.com]

Hi Shahram,

There isn't any session "re-establishment" code. There is session establishment code that has to be there for one to do anything and the recovery code would have something to decide to close the session and and whether to try to start the session establishment code.

The question is how often will PDU recovery work. Look at various problems:

A) The path breaks and routing doesn't switch things to another path. The TCP connection goes down. Recovery requires session or connection recovery and iSCSI knows it can't do path recovery.

B) If there is a short lived problem in the path (noise burst, congestion drop, physical layer training, quick path change), then TCP will detect the drops and recover. The iSCSI layer won't see it.

C) If the iSCSI payload is damaged when it is not protected by CRC and the TCP checksum doesn't catch the error, then iSCSI would see a PDU loss (assuming either that digests are on or that the error caused an error in a header field that prevents processing). PDU recovery can work for this situation.

D) Another possibility is that there is a protocol state problem that has occurred at one end of the connection (could be due to an implementation bug or a soft memory error changing state information). PDU recovery wouldn't work here; depending on the exact problem it may require session recovery or connection recovery may work. However, the iSCSI initiator probably doesn't know whether it is in this case or case C so if it supports path recovery, it may try it.

The worth of PDU recovery depends partly on how often case C occurs. If 99% of the failures are A and B, 1% are C and 9% are D, then one may be better off to go straight to connection or session recovery when iSCSI detects a need to recover. It isn't worth extra code, cost, and complexity to recover faster in 1% of the cases.

Even if 5% of failure are due to C and 5% are due to D, it may not be desireable to attempt path recovery. Path recovery could recover the C failures quickly but it will delay recovery for the D failures because their resolution will wait for Path recovery to be tried and time out. It can be better to decrease the maximum delay for recovery rather than to speed some cases at the cost of delaying the slower recoveries

Regards,
Pat

-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Thursday, August 08, 2002 1:21 PM
To: 'Bill Studenmund'
Cc: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com; ips@ece.cmu.edu;
owner-ips@ece.cmu.edu
Subject: RE: iSCSI question


Hi Bill,

Thanks for your reply. Please see my comments below:

1) I doubt that the session re-establishment code is simpler than PDU recovery code.
But think what you are saying is that, you need to have the session recovery anyway, so the PDU recovery is extra code.
2) Even if that is the case, it has nothing to do with the error recovery hierarchy.
The error recovery hierarchy must show what recovery should be tried before the other ones. In other words it has to show how the recovery escalates.
3) I think it should escalate as following: PDU -> Connection -> Session


Yours,
-Shahram  

> -----Original Message-----
> From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
> Sent: Thursday, August 08, 2002 3:59 PM
> To: Shahram Davari
> Cc: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com; 
> ips@ece.cmu.edu;
> owner-ips@ece.cmu.edu
> Subject: RE: iSCSI question
> 
> 
> On Thu, 8 Aug 2002, Shahram Davari wrote:
> 
> > Pat,
> >
> 
> > Thanks. I understand your point. Although terminating a 
> session may be
> > easy, but, starting a new session requires new login, parameter
> > exchange, new connections establishment, authentication, etc. So I
> > wonder how is this any simpler than a simple PDU retransmit?
> 
> It's simpler in terms of the code in both the initiator and target.
> 
> That's how it's simpler. :-)
> 
> Take care,
> 
> Bill
>