RE: summary of iSCSI meeting 22 June 2000

[julian_satran@il.ibm.com]

I agree with Mike. In a decently layered approach as you add new
applications at the upper layers it is to be expected that lower layers
will also adjust to better cope with new demands.

However in the current scheme of things a message oriented approach has the
distinct advantage that messages can be processed out of order while in a
stream approach a packet loss can affect the whole stack.
A clever TCP option (like the RDMA option forwarded by Costa) can help by
enabling TCP segments to be processed independently (it will not help if IP
fragments are lost and this should be avoided anyhow - I mean IP
fragmentation!).

And again Mike is right - iSCSI packets numbered across connections go a
long way to enable recovery as you will see in the draft I sending for
designer-review today.

Regards,
Julo

Michael Krause <krause@cup.hp.com> on 27/06/2000 17:20:49

Please respond to Michael Krause <krause@cup.hp.com>

To:   JoeBre@exabyte.com, Kalman Meth/Haifa/IBM@IBMIL, ips@ece.cmu.edu,
      scsi-tcp@external.cisco.com
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: summary of iSCSI meeting 22 June 2000




At 10:51 AM 6/22/00 -0600, JoeBre@exabyte.com wrote:

>Comments inline
>
> > ...
> >
> > Further discussion of what happens when TCP packets get lost,
> > especially if
> >  they contain an iSCSI header.
> > How well can iSCSI compete with FC if we are so dependent on
> > TCP, with its
> > dropped packets.
>
>All error handling for dropped packets should exist below the SCSI layer.
>If SCSI would be required to be involved in error handling for dropped
>packets, it would be disastrous for SCSI Stream Devices (ex: tape backup
>session). This is due to the fact that SCSI Stream Devices have stateful
>behavior.

iSCSI can compete quite well with TCP especially if the TCP implementation
uses SACK for selective retransmissions.  The fact that TCP does all of the
reliability for packets (not transactions which are different) is a benefit
available to any layered architecture approach - TCP can take on and solve
a class of problems without impacting iSCSI architecture / device designs.

Note: iSCSI should be responsible for its level of transaction
recovery.   For example, all transactions should be numbered with iSCSI
implementing a SACK scheme.  This would allow iSCSI to recover transactions
that may have been lost due to a failure within the fabric, e.g. a session
which is striping across multiple TCP connections may loose a TCP
connection and should recover.

> > In the LAN, TCP packets are not generally lost and we should  be
> comparable
> > to FC.  Over WAN, can have packet loss and resulting
> complications,  but that is no
> > longer competing with FC (which doesn't exist at all in the WAN).
>
>The people working on the FC-BB specification would probably refute the
>statement that FC does not exist at all in the WAN.

The general Internet has packet loss in the 1-in-100 range today - it is
getting better as higher bandwidth backbones are used to accommodate the
increased workload (most packet drops are due to congestion).  For a dark
fiber solution which is properly provisioned, one can insure that
congestion is a rare event and thus the packet loss will be very
low.  There are many dark fiber providers in the world delivering solutions
today so one can deploy a system (many companies are doing just this)
without major problems.  It should be noted that many companies and
backbone providers will be moving to OC192 and deploying DWDM with the
ability to deliver Tbps over the next couple of years.  So, perhaps the
congestion problem will really go away and one will be left with the much
harder problems to worry about.

Mike
 - att1.htm