Subject: RE: iSCSI: need for new data SNACK code?

From: Dave Sheehy <[email-masked]>
Date: Thu, 11 Jul 2002 17:29:23 PDT

> > 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.

The only promise the target has made to the initiator is that it will not
send a segment larger than MaxRecvDataSegmentLength. It is free to segment
to any size <= to that and to change that size, for its own purposes, at
any point in time w/o notifying the initiator. I don't think the spec says
anything about requiring the target to use a constant segment size. 
Therefore, the described behavior is perfectly legal and not a bug as you 
seem to believe.

Dave

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 11 Jul 2002 19:10:35 -0700

Dave,

I am glad that others are chiming in as well, :-)

>It is free to segment
> any point in time w/o notifying the initiator.

That is correct for the general case, but not for the specific data SNACK
case under discussion - the spec requires the retransmitted PDUs to be 
"exact replicas" barring certain header fields, in the absence of a negotiated 
max PDU size change.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]