Re: Unsolicited data PDU retry

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

Tony,

In addition to what Julian said, let me add one more comment.

Initiator is not expected to initiate any Data-Out recovery on its own -
without being requested so via a recovery R2T by the target.  The unsolicited
data PDU retry is not advised.  This follows from the design goal (e)
in section 5.1.2 (top of page 80 in rev15) - only one side drives error
recovery for a given class of PDUs, and target does it for Data-Out.

Hope that clarifies.
--
Mallikarjun

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

----- Original Message ----- 
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <tonyb@cybernetics.com>
Cc: <ips@ece.cmu.edu>; <owner-ips@ece.cmu.edu>
Sent: Wednesday, August 07, 2002 9:56 AM
Subject: Re: Unsolicited data PDU retry


> Tony,
> 
> Not all the recovery details are made explicit in text.
> The code is a bit more complete but it is also not exhaustive.
> It is meant to model recovery for interoperability.
> 
> As for the data our assumption has been that target will drop data for 
> non-instantiated tasks (not a known ITT).
> As for duplicates ignoring duplicates is implied by the window rules in 2.
> 
> Julo
> 
> 
> 
> 
> "Tony Battersby" <tonyb@cybernetics.com>
> Sent by: owner-ips@ece.cmu.edu
> 08/06/2002 09:22 PM
> Please respond to tonyb
> 
>  
>         To:     <ips@ece.cmu.edu>
>         cc: 
>         Subject:        Unsolicited data PDU retry
> 
>  
> 
> In section 5.2.1 Usage of Retry (draft 15), it is specified that 
> initiators
> can resend commands that have not been acknowledged for a timeout period.
> Does this retry include re-sending unsolicited data PDU's?  The target is
> supposed to ignore non-immediate commands with duplicate CmdSN's or 
> CmdSN's
> outside the expected range, which takes care of immediate data, but I 
> don't
> see anywhere where it is specified that the target should ignore duplicate
> or unexpected unsolicited data PDUs.  Or, is the target supposed to hold 
> on
> to unsolicited data PDU's for a command that it does not know about (e.g.
> because the command PDU was discarded due to a digest error) and then 
> later
> re-associate the unsolicited data PDU's with the correct command when the
> command PDU is re-sent by the initiator?
> 
> The last paragraph of section 2.4.2.2 gives some rules for the ordering of
> unsolicited data for different commands, which may also be related.
> 
> Thanks,
> Anthony J. Battersby
> Cybernetics
> 
> 
>