RE: iscsi : Data ACKs already been included into draft (?)

[Michael Schoberg <michael_schoberg@cnt.com>]

Missed the reflector the first time so I'll try this one again...


I'm still in favor for moving R2T and Data-IN into the StatSN realm (remove
DataSN).  Looking at it, I wonder why there was this split to begin with.
If the initiator is able to request retransmission of any/all T->I PDUs, it
stands to reason that there should never be gaps in the Data-IN/R2T stream
(unless the target is broken).  Separating Data-IN & R2T ACKs from the
normal StatSN stream means requiring an equivalent protection mechanism be
created.  Bottom line is that will add complexity to iSCSI.

If Data-IN/R2T were moved in StatSN, there's still the problem of the
requirement of optional support.  Lightweight systems may not be able to
buffer much data to allow for long T->I message queues and the current draft
lists SNACK support as optional (for this reason?)  To support this, we may
need to have different flavors of R2T & Data-IN: one with StatSN and one
without.

I'm kind of surprised there hasn't been much discussion along this line.
There seems to be two extremes being expressed (in-favor of a Data-ACK even
if it involves writing new message engines -OR- in-favor or completely
removing Data-ACK to avoid overhead).  It seems like optionally moving
Data-IN/R2T into the StatSN queue would allow for both without adding much
complexity to the code.


: -----Original Message-----
: From: Santosh Rao [mailto:santoshr@cup.hp.com]
: Sent: Wednesday, September 26, 2001 2:21 PM
: To: ips@ece.cmu.edu
: Cc: Black_David@emc.com
: Subject: iscsi : Data ACKs already been included into draft (?)
: 
: 
: Julian & All,
: 
: It looks like the Data ACK scheme you proposed has already 
: been included
: into the Rev 7.97 draft !(?) I don't recollect the group 
: having reached
: consensus on re-inclusion of this feature, nor consensus on 
: the mechanism
: used for the data ack. Given this, why is the change already 
: present in
: the draft ?
: 
: I would like to request that any changes to the draft be 
: first posted to
: the reflector for review and only upon its acceptance on the reflector
: should it be included in the draft. Incorporating changes 
: into the draft 
: prior to their acceptance on the reflector is only going to 
: slow down the 
: stabilization of the draft further.
: 
: At this late stage in the draft, every sentence modified must 
: be subject
: to review prior to inclusion in the draft.
: 
: Thanks,
: Santosh
: 
: -- 
: #################################
: Santosh Rao
: Software Design Engineer,
: HP, Cupertino.
: email : santoshr@cup.hp.com
: Phone : 408-447-3751
: #################################
: