Re: iSCSI:Can each do there own thing?

[Martins Krikis <mkrikis@yahoo.com>]

This isn't a very interesting reply, but the next mail is a 
a very important read, IMHO. Please read that one carefully,
a compromise is included there.

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

Yes, in particular, I think sending is harder to implement w/o the
guarantee of only empty PDUs coming back.

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

I don't think that there is a requirement to answer all received keys
as soon as possible. They may not all fit, so this is not even possible
in general. And split PDUs may be unavoidable, too. 

What we need added to the draft is some restrictions that would make it
impossible for both sides to feel like they originated a key. Currently,
if one side sends part of the key, it may feel well entitled to consider
that key as sent, but the other side is not mandated to consider this
partially received key as received, so it may send it too---with disastrous
results for the negotiation.

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

Yes, and for this reason it cannot simply do what many consider the
simplest aproach---create all the key=value pairs that would be nice
to process in one batch, and pass them down to the encapsulation layer
without worrying how many will fit in the first PDU.

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

By forbidding origination on split PDUs we avoid the possibility of
both sides feeling like originators. It is a step in the right direction.
In order to deal with interruptability, we need to forbid sending
anything until the other side hasn't finished. (For better definitions
please see the next mail from me.)

> > Now the rules we have now in the current draft level 12-94,  some seem to
> > say, are workable.  

Well, there is not enough of those rules, hence the above mentioned
possibility of both sides feeling like originators for the same key.
But there is work in progress here, so 12-95 may have the missing rule(s).

> > But if someone sends empty PDUs, etc., that seems to
> > work too, and some folks (at least 2) think that is a good idea.

Guarantee of receiving only empty PDUs is more important than ability
to send them (that already exists).

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

Without guarantees of empty PDUs there is more work at sending even for
an implementation which is "empty-PDU-favoring".

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

So do I. Receiver is not the hard part, because it is easy to be
"polite towards the sender" and send only empty PDUs. And with any
scheme you have to notice that you're forbidden to do something.

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

Again, I don't think it is an error to send a belated (many PDUs later)
response to a key, as long as it is sent in the same negotiation
sequence. It is also not an error to send empty PDUs (as many times
as one wants w/o any reason whatsoever). And both these things are
fine in my eyes, so I may not be understanding the issue here...

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

True. The sender has to be aware of whether each new key=value pair
fits in the PDU completely, partially or not at all. It cannot work
on a batch of pairs and not worry about PDU boundaries.

> > 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 religiously illiterate, so I don't even know (or care to know) what
I was just accused of doing, but I'm rather sure I was doing it. In my
eyes, however, I was simply defending a simpler scheme. But in order
to try to be fair I have composed an analysis of all schemes. Read the
next mail please, this is long as it is.

> > 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 the way spec gets clarified/restricted will pretty much tell
whether the simpler batch-processing approach is possible. But with
a minor change in what is called a split-PDU there actually is a hope
for batch-processing implementations even with the scheme that seemed
to prohibit them, so there is a hope for a compromise.

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

I don't understand why lack of replies would be considered an error
under any conditions.

Take care,

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be those of my employer