RE: iSCSI: need for new data SNACK code?

[Black_David@emc.com]

Marj,

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

My concern is that we're tinkering with the behavior of the existing
Data SNACK mechanism, and if we get it wrong, the results are worse than
if we get the design of a new type of SNACK wrong.
I also think this whole area of resegmentation functionality falls into
the "not sufficient time left" category - it certainly was not analyzed
correctly when it went in.

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

Let me know what you think happens when Occam's Razor is applied to
the even simpler solution of removing resegmentation completely
(see my separate recent response to Mallikarjun).

Thanks,
--David

> -----Original Message-----
> From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> [mailto:marjorie_krueger@hp.com]
> Sent: Thursday, July 11, 2002 7:02 PM
> To: 'Black_David@emc.com'
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI: need for new data SNACK code?
> 
> 
> > > 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
>