Subject: Re: iSCSI: keys/parameter dependence

From: "Julian Satran" <[email-masked]>
Date: Wed, 5 Jun 2002 19:34:41 +0300

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 <[email-masked]>
Sent by: [email-masked]
06/04/2002 10:24 PM
Please respond to Martins Krikis

        To:     [email-masked], [email-masked]
        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.

---

From: Martins Krikis <[email-masked]>
Date: Wed, 5 Jun 2002 12:33:07 -0700 (PDT)

> used by any mechanism that has to send a lot of data

Hmm, let me verify that I'm understanding this...

Let's suppose the following scenario:

A target is planning to send a very long response
(exceeding the mandatory buffering capabilities
of the other side) to a TextRequest that contained
the SendTargets key. This is legal, 
because it is not a negotiation, right? 

Let's suppose the text it is sending
will get broken in m TextResponse PDUs. 
For any of these PDUs, if the key=value pairs fit
completely (i.e., including the terminating '\0'),
and if the target doesn't mind the possibility
that the initiator may send some data back
(for example, do a little negotiation in parallel
with hearing what SendTargets will return...),
then it need not set the C-bit. Correct?

But it is also permissible to set the C-bit, 
since the target may not consider itself as 
"being done with this set of keys". Right?

If, however, in some PDU the last key=value
pair is split (i.e., will continue in the next
PDU), then it MUST set the C-bit, because
such a PDU cannot possibly "end a set of keys".

Can anybody comment on this understanding, please?

Applying this understanding to the example in
section 9.10.4, I can conjecture that the C
bit may or may not be set; it depends on whether
<part x> contains only complete (with '\0' at the 
end) pairs or not, and possibly on target's
preferences. The PDUs travelling in the other
direction need not necessarily be empty, unless
the C-bit in the preceding PDU forces them to be.
Is this true?

Many thanks in advance,

Disclaimer: these are my own opinions and are
            not necessarily Intel's opinions.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com