Re: iSCSI:Can each do there own thing?

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Tue, 28 May 2002, John Hufferd wrote:

> I am starting a new thread.

Ok. :-)

> I am not sure that I have gotten all the nuances of the various proposals
> here, but ...
>
> I think I read, that if you receive a spanned PDU, that some want to keep
> some state and continue processing, while other are saying that it is
> easier if only an empty PDU is returned, until the complete PDU with
> nothing spanning is received.

I think that is a fair assessment. Well, we all agree some state will be
needed, it's a matter of how much state.

> I may have this wrong, but the focus seems to be on the receiver of the
> spanned PDU, and the issues it has in keeping state etc.

For me, the focus is on both. You are right that the receiver is easy to
fix; just send empty PDUs and process at the end. The one thing we would
need to add to the spec is a sentance saying you can't nail the other side
for a negotiation error (for not answering keys) if you sent a split PDU
or they sent a split PDU.

The other messy part (not hard, just messy) is for the sender. And this
part is why I personally favor empty PDUs. The sender has to be able to
process new input packets before it has finished sending everything. i.e.
it has to be able to deal with the other side interrupting it while it is
speaking.

If we forbid the receiver from originating new keys when it has received a
split PDU, we make life easier on the sender, but it still has to be
interruptable.

> Now the rules we have now in the current draft level 12-94,  some seem to
> say, are workable.  But if someone sends empty PDUs, etc., that seems to
> work too, and some folks (at least 2) think that is a good idea.
>
> So are we at a point that says that empty PDUs are OK, and if used, you
> need to remember less stuff, but if you want to remember state, then go
> ahead, but be sure you do everything correctly?
>
> Let me ask two question then:
>
> 1. Is what I summarized correct with respect to the receiver?  If not
> please itemize, the items that are broken, so that we can work on one at a
> time.

I believe that is correct with respect to the receiver.

The one thing new I mentioned is the fact you can't claim negotiation
error when not all the keys you offered were returned *if* eithe you or
the other side sent a split PDU. i.e. if one or both sides are still
talking, you can't tell yet.

> 2. Is there an important issue with the offering side, that is not covered
> with the current spec. and will things work on the offering side if the
> Null PDU us sent from the receiver?   Again, if no, please itemize.

As above, I think it's more what has to be in the sender if the receiver
can send a non-empty PDU.

> I get the feeling, and I maybe wrong here, that the various sides are
> trying to evangelize each other, even if the other side's approach works.
> I am not a big fan of evangelizing at this point.

I'm trying to not evangelize. :-)

> I am asking for a compromise that you folks can agree with that says
> something like, "yea, you can do it that way you silly so & so, but my way
> works too perhaps better", and the spec covers both implementations.  This
> might not be possible but I am not sure we are converging.  And we need to
> within a day or so.

I think with the adjustments above (no offers when you got a split PDU and
wait until no split PDUs to determine if a lack of replies is an error)
would be sufficient. I think sending empty PDUs would be easier, but the
above would suffice.

Take care,

Bill