Re: iSCSI: keys/parameter dependence

["Julian Satran" <Julian_Satran@il.ibm.com>]

I have one comment regarding to batching.

Batching is not related to the C-bit. C-bit is meant to simplify spanning over PDU boundaries.
Batching can be done with the previous structure as well - there is a lot you can do with an 8k block!

Julo

"Robert D. Russell" <rdr@io.iol.unh.edu> Sent by: owner-ips@ece.cmu.edu 06/04/2002 09:46 AM Please respond to "Robert D. Russell"

To:        Martins Krikis <mkrikis@yahoo.com>         cc:        ips@ece.cmu.edu         Subject:        Re: iSCSI: keys/parameter dependence

Martins:

Comments below on all your e-mails in this one reply.

> As to "running and tested",
> I don't think many people have encountered split
> PDUs in operational stage or FFP Text negotiations
> yet.

Agreed.


> Those, who prefer the "batch-processing" approach
> fought for the C-bit, so I would say that it was
> introduced in order to allow it.

I missed that point earlier.


> Regarding ordering, however, it had never been
> defined, and I would hate to see it introduced.

It was defined before draft 8, but was taken out when that
draft came in.  Unfortunately, I did not take it out of
my memory.  I agree that it should not be reintroduced.


> In my opinion, it is best to treat all operational
> parameters as independent and negotiate them as
> such.

Agreed.


> Just before the commit
> (i.e., turning on the T or F bit), one can do an
> all-encompassing consistency check and reset
> the negotiations if the values violate the laws
> imposed on them, or offer some more keys to solve
> any such problems, if this is still possible.


What you are saying seems to imply that C=0 does NOT
require the receiver to reply to keys received up to that point
-- it could send another empty PDU, or more likely, it could send
new offers of its own.  I agree that there is nothing in the draft
that says when replies to keys should be sent, only that they
MUST be sent (sometime).

For example, consider a login negotiation of operational parameters
in which the initiator sends a login pdu containing key=value offers
and the C bit 0.  The target responds with a login response pdu
containing key=value offers of its own (offering different keys)
but no replies to any of the offers it received in the login.
The initiator can then reply to the target's new offers, or it
can decide not to reply, and instead send additional new offers
or even an empty pdu, (C bit 0 in both alternatives).  And now
the target could do as it did before, not replying to any offers
but either sending back new offers or sending back an empty login
response pdu (again C bit 0 in both alternatives).  This could go
on indefinitely.

It would seem that the initiator might try to force replies by
setting T=1 to force an end-of-stage transition.  However, the target
can refuse to make the transition and can reply with T=0 and still
no replies to the keys it was offered.

This is admittedly a rather far-out example, because presumably both
initiator and target want to end the negotiations as soon as possible.
My point only is that I do not see anything in the draft that says
when the replies to keys have to be sent, only several references
that there MUST be a reply to every key offered (eventually).

Thoughts, comments?


> I could even imagine negotiations
> succeeding but laws
> (e.g. FirstBurstSize <= MaxBurstSize) not being
> broken when sending data... OK, the last thing
> might technically be forbidden at the moment
> but it is not that unreasonable. It would be
> something like
> FirstBursSize = min(FirstBurstSize, MaxBurstSize)
> done after the negotiation end, and then you can
> forget about dependencies. I think it is way
> easier than worrying about key ordering every
> time something is sent or received.

The dependency can be accounted for when generating the reply.
For example,

reply.FirstBurstSize = min(offer.FirstBurstSize, reply.MaxBurstSize)

That way nothing is broken when sending data.


> And how many instances of TargetName and TargetAddress
> can the SendTargets command provoke from the other
> side? I think it can easily overflow the 8192 bytes.

Yes it can, but there was already a mechanism in place to deal
with this.  In fact, this brings up an interesting point.
Presumably the C bit has to be used with replies sent to
SendTargets (or any other offer that might generate a long reply),
since the C bit is in the Text Response PDU used to send these replies.

Refering to sections 9.10.2 and 9.10.4:  If the target generating a
long reply has more text to send than will fit in one PDU, then it
should indicate this by setting C = 1.  Setting C = 1 also forces F=0,
and this in turn forces the Target Transfer Tag to be something
other than 0xffffffff.  When there is no more text to send,
the target sets C = 0 and F = 1 and TTT=0xffffffff in the last
text response pdu it sends to the initiator.  There is no
situation in which C = 1 and F = 1 can occur (since this is
explicitly stated in 9.10.2 as being an error), nor is there a
situation in which C = 0 and F = 0 should occur (because C = 0
means "I'm done sending stuff" and F = 0 means "I'm not done sending
stuff").

Is this the way you interpret the merging of the C bit with the
long text reply mechanism?  If there is a consensus on this,
perhaps the wording in the draft in section 9.10.4 should include
the (required) settings of the C bit whenever it mentions the
corresponding settings of the F bit and TTT field.


> > -- FirstBurstSize and MaxBurstSize are dependent
> > because of the
> > requirement in section 11.15: "FirstBurstSize MUST
> > NOT exceed
> > MaxBurstSize."  See my e-mail response to Mike for
> > details
> > on that dependence.
>
> I saw it. I consider it unbelievably ugly to have to
> look at the values in order to figure out ordering
> requirements. I prefer ignoring ordering completely
> and check for overall consistency before commit.

You are correct, the values can be figured out without
resorting to an ordering -- my mistake.


> Nowhere does it say anything about the order.

Agreed.


> So, are you really proposing a requirement that
> we must look at the values in order to figure out in
> which order to send keys? That is so UGLY, it is
> hard to believe that this is happening.

Please forget I even suggested it.


> > The existence of a dependency between OFMarker and
> > OFMarkInt, and between
> > IFMarker and IFMarkInt, is implied by the statements
> > in section A.3.2:
> > "When the interval is unacceptable the responder
> > answers with
> > "Reject".  Reject is resetting the marker function
> > in the spcified
> > direction (Output or Input) to No."
>
> No it isn't. IMO, it is resetting the marker interval
> to its previous value, which is likely the default
> value. I believe it's perfectly legal to negotiate
> the marker interval but to not turn on marker use,
> or to turn on the use but stay with current (default)
> values for the interval. If one side can't  tolerate
> the other's  Reject (i.e., can't live with the
> default value), it is welcome to bail and try next
> time w/o markers. BTW, we could use 0 here as a
> special value, meaning that markers are not in use,
> then we wouldn't need the boolean keys for
> markers.
>
> > This last sentence should probably be reworded to
> > say:
> > "A response value of "Reject" to an OFMarkInt
> > (IFMarkInt) key resets the
> > corresponding OFMarker (IFMarker) key value to
> > "No"."
>
> No, thank you. I would prefer if Reject meant the
> same as with the other keys, i.e., negotiation
> failed for this key, let's stick with the old
> value, or bail if we must.

Either the sentence needs to be reworded so it is proper English
or it should be taken out of the draft.  I take it you are advocating
its removal?

Bob Russell