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

["Julian Satran" <Julian_Satran@il.ibm.com>]

Michael,

I went through a 1 and 2 tier counting scheme a year ago.
The short answer is that a one tier has severe head of queue impact and a 2
tier with a continuously running and a separate one for data (roughly what
I think Santosh suggested a day or two ago) needs to carry 2 counters in
many input PDU's and is very messy to handle with it recovery.

If you want to do more about it write a draft.

Regards,
Julo




                                                                                                   
                    Michael Schoberg                                                               
                    <michael_schober       To:     "IPS Reflector (E-mail)" <ips@ece.cmu.edu>      
                    g@cnt.com>             cc:                                                     
                    Sent by:               Subject:     RE: iscsi : Data ACKs already been         
                    owner-ips@ece.cm        included into draft (?)                                
                    u.edu                                                                          
                                                                                                   
                                                                                                   
                    27-09-01 00:03                                                                 
                    Please respond                                                                 
                    to Michael                                                                     
                    Schoberg                                                                       
                                                                                                   
                                                                                                   



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
: #################################
: