Re: iSCSI: keys/parameter dependence

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

Almost everything is correct - except the mechanism for Very-Long-responses - (TTT).
This is different than the spanning mechanism (C- bit) in the sense that has in theory no bounds (it was devised mainly for SendTargets but can be used by any mechanism that has to send a lot of data - not negotiations).

Julo

Martins Krikis <mkrikis@yahoo.com> Sent by: owner-ips@ece.cmu.edu 06/04/2002 10:24 PM Please respond to Martins Krikis

To:        ips@ece.cmu.edu, rdr@io.iol.unh.edu         cc:                 Subject:        Re: iSCSI: keys/parameter dependence

Robert,

I'm cutting text out to keep it shorter...

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

Yes. The other side cannot be forced to send anything.

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

Yes, there is the possibility that one or both sides don't want
to commit the negotiation and keep ping-ponging empty PDUs. Thus,
implementations will likely be counting such request-response rounds
and have some threshold value for how many times this can go on...

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

except that reply.MaxBurstSize may have to be substituted by
current.MaxBurstSize or offer.MaxBurstSize or something like that...
i.e., there can be chicken-and-egg problems, I think. I prefer
negotiating each key individually, according to its type, allowed
values, desired values, who may send it at the concrete stage
of the negotiations, etc. I am not fond of the idea that it may
be necessary to look at the (current or future) values of other keys
in addition to what already has to be done for each key.

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

Yes, it should. There was just an example of "long responses" in 9.10.4,
but some people understood it to mean that empty PDUs going in the
other direction are mandatory. For SendTargets there isn't much
else the initiator can send anyways (?). Well, the empty PDUs
of 9.10.4 weren't mandated yet when the discussions for C-bit
started, but that's basically what the C-bit mandates. Would
be nice to add it to the example of 9.10.4, too.

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

Yes.

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

C = 0 yes, but F and TTT only if initiator set F and if the
target is ready to commit. It may still be missing values
from initiator, or just taking a break (:-)) for a couple 
request-response rounds.

> 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), 

Yes.

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

This can occur. C=0 just means "I'm done with this "set of keys" ("batch"),
now I'm willing to listen what you may have to say". It does not imply
F=1, as the target may not be ready to commit yet. In fact, initiator
need not have set F yet, so in fact target may be forbidden to set it.

> Is this the way you interpret the merging of the C bit with the
> long text reply mechanism?  

C-bit now IS the "long login/text request/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.

Perhaps something can be added, especially to the example there.

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

Oops. My mistake. I hadn't even read the sentence about "Reject"
that is in the draft currently. I have no objections to English
there, but I don't like that Reject is "resetting the marker function
to no", since that certainly introduces a dependency, and I understand
that it is legal to treat the other Rejects as "stick to the old value".,
I would like this Reject to allow the same interpretation, i.e., not
require to touch any other keys immediately. Using 0 as a special value 
for intervals also has a drawback---it can be a value "out of range", 
to be returned. Suggestions?

Martins Krikis, Intel Corp.

Disclaimer: my opinions, not necessarily Intel's.