Re: iSCSI: Unsolicited data PDU retry

[Bill Studenmund <wrstuden@wasabisystems.com>]

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