iSCSI: unsolicited data

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

I don't recall the earlier discussion being conclusive on this topic,
so let me attempt to make a couple of suggestions on this.

Last para in Section 2.2.5 (page 33) in rev09 mandates unsolicited
data ordering with the following wording.  
 
  "iSCSI initiators and targets MUST also enforce some ordering rules to
   achieve deadlock-free operation. Unsolicited data MUST be sent on
   every connection in the same order in which commands were sent. A
   target receiving data out of order SHOULD terminate the session."

I have a couple of suggestions to reword -

- The reference to a deadlock is true only for an implementation 
  overcommitting the unsolicited data buffers.  So, I would suggest 
  dropping this reasoning. 

- The "MUST enforce"  wording should also add that "targets MAY 
  however see unexpected unsolicited data (UUD), following data 
  digest errors on expected unsolicited data."

- Finally, the "SHOULD terminate the session", IMHO, is too strong.
  This wording will imply that a session is vulnerable to a single 
  digest error regardless of recovery level.  [ I however disfavor 
  attaching more assorted semantics to recovery levels (than the 
  current easily understood "level = setof(recovery classes)"
  formulation). ]  As you mentioned on this discussion earlier, a 
  UUD is a protocol error (or may be not, if it is the effect of 
  a prior digest failure).  

  We can choose to Reject ("protocol error") the UUD and discard the 
  data.  The only problem with this approach is: following a digest
  error on unsolicited data for one task, all the following unsolicited
  data in flight would have to be discarded.  One option is to imply
  that the target update the "expected unsolicited data"  so the 
  unsolicited data following in the pipe can be processed normally.
  So, I guess it would be saying: "the target MAY Reject the UUD".
    
Comments?
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com