RE: iSCSI: need for new data SNACK code?

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

> > I am still unclear about the need to add the new data SNACK 
> > code.  IMHO, this can only be confusing to both initiator 
> and target 
> > implementers - to have two codes that have identical semantics
> > on the wire.
> >
> > The only remaining reason that I see from David (attached below)
> > is that the new code makes the initiator aware that it must request
> > status retransmission.  IOW, you're expecting the initiator 
> > to be careful 
> > enough to use the new code, but somehow you don't expect it to be 
> > attentive enough to discard the status PDU unless it had used 
> > this new 
> > code in an *outbound* SNACK.  I completely miss this rationale.
> 
> I disagree with the "careful enough" characterization.  The new code
> provides the initiator with a more robust way to detect resegmentation
> by requiring the initiator to explicitly ask for it.  

I don't follow your thinking David - the initiator has *requested*
resegmentation via a MaxRecvDataSegmentLength text request.  The foolproof
way to "detect" that the target is resegmenting is receipt of the target's
text response.

> The initiator
> can take a simple approach of always starting with the existing
> Data SNACK code that does not resegment and only using the new code
> when the non-resegmenting SNACK doesn't work.  

You seem to be thinking that an initiator would be sending SNACKs on this
connection for the previous segment size immediately after it's requested a
MaxRecvDataSegmentLength change?  That doesn't make sense to me.  The
initiator should wait for the target's text response before continuing I/Os
on this connection.  Thereafter, both ends know that that data sent as a
result of a Data SNACK is resegmented and the initiator should send a Status
SNACK for any Status PDU's received before the Text Response that were
associated with the task that requires issuance of the Data SNACK.  Seems
pretty simple to me.

> If the target makes
> its own choice to resegment, and the initiator doesn't think the
> target resegmented, there are error scenarios that combine this with
> corrupt Data PDU headers to cause the initiator to successfully
> complete a SCSI command that has not delivered all its data
> (the resegmented PDUs caused the Data PDU count to match the ExpDataSN
> value in the response that should have been discarded, but wasn't).
> While these should be rare, their consequences can be catastrophic.

What do you mean by "if the target makes it's own choice to resegment"?
Sounds like a target bug to me.  It feels like you're making this look more
complicated than it really is.

I think this new SNACK code is the wrong thing to do - it feels like adding
a new feature with questionable value to provide a questionable "fix" for a
questionable problem, and there's not sufficient time left for scrutiny of
whether or not it presents a new set of problems.

By my assessment, your solution to this problem fails Occam's Razor - if
there are two functionally equivalent solutions to a problem, chose the
simplest solution.  Mallikarjun points out a simple solution that is
sufficient to solve the original problem without adding a new PDU type.

Regards,
Marjorie