RE: A Transport Protocol Without ACK (resend)

["HAAGENS,RANDY (HP-Roseville,ex1)" <randy_haagens@hp.com>]

Robert,

The reason we proposed immediate write data for iSCSI was as an optimization
for short writes over "long" networks.  As network diameter increases,
minimizing round-trip signalling delays becomes important.  Sending write
data immediately following the command eliminates the need for an RTT from
the target, and thus eliminates a round-trip delay.

If immediate data threatens to overflow the target's cache, the target may,
on an emergency basis, discard the data; and, when ready, request data again
using the RTT protocol.  This behavior should be minimized, however, as it
will tend to congest the network.

Note the use of SCSI-layer flow control (RTT mechanism).  I agree with those
that say a controller must manage its cache, regardless of the size of the
cache.  This is most apparent when one considers multiple hosts sharing a
storage controller.  In order to allocate performance between the hosts, the
controller must ensure that a write burst from a single host cannot fill its
cache.  RTT provides a means for doing this that still allows other commands
(read commands, for example) from the same host to proceed.

However, reserving a few MB of cache for each host, to accommodate immediate
writes, seems to me reasonable.  The command windowing mechanism (another
flow control mechanism) will prevent the overrunning of these immediate
write buffers, assuming that the controller has reserved space in proportion
to the largest immediate buffer allowed (which is negotiated) x the maximum
number of commands.

Upon writing this, it occurs to me that it may be useful to add an
XOF/XON-like mechanism for temporarily disallowing immediate write data.
This would give the controller another tool for cache management.  When its
cache became congested, the controller could signal one or more of the
requesting hosts to stop sending immediate write data with commands; later,
another message could allow immediate writes to resume.  These messages
would need to make it to the iSCSI layer in the hosts, as they will affect
how the host does DMA chain construction.

R

Randy Haagens
Director, Networked Storage Architecture
Storage Organization
Hewlett-Packard Co.
tel. +1 916 785 4578
e-mail: Randy_Haagens@hp.com


-----Original Message-----
From: Robert Snively [mailto:rsnively@Brocade.COM]
Sent: Thursday, September 21, 2000 2:16 PM
To: 'ips@ece.cmu.edu'
Subject: FW: A Transport Protocol Without ACK (resend)




-----Original Message-----
From: Robert Snively 
Sent: Thursday, September 21, 2000 8:35 AM
To: 'Douglas Otis'; Jim McGrath; 'Randall Stewart'
Cc: 'Y P Cheng'; 'Ips@Ece. Cmu. Edu'
Subject: RE: A Transport Protocol Without ACK


A minor correction:

>  
>  If you examine FCP documentation, you will find that you can 
>  send data with
>  the command as an option.  You can also send the response at 
>  the end of data
>  as an option.  Every vital feature used to justify tossing 
>  FCP structures
>  become moot.  

While this is true in FCP, the function has been made "obsolete"
in FCP-2 because there is no identifiable benefit to it and because
it complicates retry.  I believe the same would be true of any
reasonable iSCSI implementation.  A reasonable iSCSI implementation
is defined as one that has essentially zero additional overhead in 
managing two transfer units as opposed to managing one transfer unit.

Randy Haagens (E-mail).vcf