RE: summary of iSCSI meeting 22 June 2000

[Michael Krause <krause@cup.hp.com>]

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