Re: iSCSI: Unsolicited data PDU retry

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

>You're suggesting that, when
> REtransmitting a command, it is ok to send a command that indicates we're
> sending more PDUs (F-bit not set) and to then NOT send them as we're
> plugging a command hole.

Sorry, but I never said it - perhaps I was just unclear.  On the
contrary, 
I am suggesting that the command retry mechanics must be identical.

All I said was that the target is responsible for Data-Out recovery
*when*
it did receive the command earlier.  If the initiator is suspecting that 
the command never got there, it's obligated to repeat the entire command
retry sequence - including the unsolicited data, if any.
-- 
Mallikarjun 


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


Bill Studenmund wrote:
> 
> On Wed, 7 Aug 2002, Mallikarjun C. wrote:
> 
> > Bill,
> >
> > I do not quite follow what "could lead to a mess"....let me address what
> > I think is your question.
> 
> Ok.
> 
> > I did not say that target "drives the data-out sequencing" for unsolicited
> > data, only that the target drives the *error recovery* for all data-out (assuming
> > it received the command, so has the ITT context).
> 
> Ahh...
> 
> > Let me attempt to rephrase.  A digest error as an example, taken on
> > one of the unsolicited data PDUs, would have to be recovered by the
> > target sending a recovery R2T - IOW, target driving the Data-Out PDU
> > recovery is true even for unsolicited data.
> >
> > If I understand you correctly, you seem to suggest that retries may carry
> > different header flags (F-bit and no-F-bit) - it's illegal.  Take a look at 5.2.1.
> 
> Yes, you are correct that that's what the spec says about the packet.
> 
> Well, here's what I thought was the mess. You're suggesting that, when
> REtransmitting a command, it is ok to send a command that indicates we're
> sending more PDUs (F-bit not set) and to then NOT send them as we're
> plugging a command hole. That really strikes me as a protocol violation.
> It may not be by the letter of the protocol, but it just seems wrong. I
> mean I doubt we be happy with an implementation that did that on the
> initial transmission, so why do it on the retransmission?
> 
> Think about what's going to happen to this command (assuming I understand
> you right). Either we are really plugging a hole or we aren't. If we
> aren't, the target will drop the repeat and the unsolicited data on the
> floor.
> 
> But if we really are plugging a hole, we send this one command and then we
> have to wait until the target times out and requests error recovery R2Ts.
> i.e. because of that one error, we now have to wait both the initiator and
> the target timeout period before things start to get fixed. Also, having a
> perceived error state on the initiator's side need the target to perceive
> an error to fully recover seems cumbersome.
> 
> If that's really considered the best thing to do, well, it will work. It
> just seems sub-optimal.
> 
> Take care,
> 
> Bill