Re: Multiple connections & design complexity

[psarkar@almaden.ibm.com]

The complexity does not arise simply from the additional fields (which I
agree are not onerous)
but from the way the additional fields will be interpreted (mistakenly or
otherwise) and the potential
interoperability hassles different interpretations will cause.

Prasenjit


   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose


csapuntz@cisco.com@ece.cmu.edu on 08/08/2000 06:05:19 AM

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:   csapuntz@cisco.com
Subject:  Multiple connections & design complexity




There has been significant comment that using multiple connections
per session adds significantly to complexity of the design.
This message is an attempt to describe the complexity exactly.
I hope that you'll agree with me that the complexity is not onerous.

There are two ways in which multiple connections are used in iSCSI:

1) Multiple simultaneous TCP connections for bandwidth

2) Multiple TCP connections for fault tolerance/recovery
     (i.e. when one TCP connection in a session dies,
         another one starts up)

The features in iSCSI that come out of #1:
Command Reference Number
Expected Command Reference Number (not strictly necessary if the window
never
    shrinks)
Max Command Reference Number
Session ID

The features in iSCSI that come out of #2:
Status Reference Number
Expected Status Reference Number
Session ID
Recovery bit in opcode field
Connection IDs for TCP connections

And the following iSCSI opcode has been suggested by some for recovery:
Terminate TCP connection

-Costa