Subject: RE: iSCSI: keys/parameter dependence

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 6 Jun 2002 09:54:07 -0600

Julian,
 
Then we shouldn't have added the C bit at all. One doesn't need it to indicate that a key-value isn't complete and one certainly doesn't need it for security negotiation where there is already a fairly lock step process for the certificate exchange.
 
The arguments people used for adding it were that they wanted to be able to batch offers larger than a PDU without worrying about length. I agree that isn't necessary today for any of the standard keys.
 
During login one can send all the standard keys in a single 8k PDU. During FFP, the only standard negotiated key exchanged is MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread over multiple PDUs without an issue.
 
The current places where C helps are:
Implementation doesn't support 8k transmit PDU size - the negotiation default of 8 k is for the size PDU one supports receiving. An implementation might chose to only send a much shorter PDU and then its keys would not al fit in a single PDU. I find it difficult to imagine someone designing an implementation that creates a long batch of keys and then sends it in multiple short PDUs when it could send it in one PDU, so this doesn't seem like a very good reason to have the C bit.
 
Anticipation of many more or longer standard keys in the future so that they don't all fit in 8k.
 
Anticipation of more FFP negotiations so that FFP offers don't all fit in a single PDU when PDU size might be as small as 512.
 
Support for vendor specific extension keys that are more then 8 k in login or more than MaxRcvPDUDataSize in FFP.
 
Pat
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 8:56 PM
To: [email-masked]
Subject: RE: iSCSI: keys/parameter dependence

As I pointed out earlier - you can batch all your keys but some certificates in 8k! 
It was never forbidden nor mandated. 

Julo 

	[email-masked] 

06/05/2002 09:41 PM 
Please respond to pat_thaler 

        To:        Julian Satran/Haifa/IBM@IBMIL, [email-masked] 
        cc:        [email-masked], [email-masked], [email-masked] 
        Subject:        RE: iSCSI: keys/parameter dependence 

Julian, 
  
Batching is related to the C-bit. Before the C-bit, a device could prepare a batch of keys to originate 
but they had to fit within the PDU because, if the keys extended beyond a PDU, the device's partner 
might originate some of the keys it had prepared but hadn't yet sent. 
  
With the C-bit, a device can prepare a batch of keys with out regard to their size because the device 
can ensure that they can be sent in multiple PDUs if necessary without the partner having an 
opportunity to originate keys in between. 
  
The C-bit releaves the size constraint on batching offers. 
  
Regards, 
Pat 
  
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: [email-masked]; Martins Krikis; [email-masked]
Subject: Re: iSCSI: keys/parameter dependence

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" <[email-masked]> 
Sent by: [email-masked] 

06/04/2002 09:46 AM 
Please respond to "Robert D. Russell" 

       To:        Martins Krikis <[email-masked]> 
       cc:        [email-masked] 
       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

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 6 Jun 2002 12:13:20 -0700 (PDT)

On Thu, 6 Jun 2002, THALER,PAT (A-Roseville,ex1) wrote:

> Julian,
>
> Then we shouldn't have added the C bit at all. One doesn't need it to
> indicate that a key-value isn't complete and one certainly doesn't
> need it for security negotiation where there is already a fairly lock
> step process for the certificate exchange.
>
> The arguments people used for adding it were that they wanted to be
> able to batch offers larger than a PDU without worrying about length.
> I agree that isn't necessary today for any of the standard keys.

Kinda. The spec says that you can have keys & values span a PDU.  My main
concern was I took the negotiation code I was writing down the path that
split keys would lead to, and I found an UGLY mess. So I would either have
to code up a mess, or I would have to have a not-strictly-conforming
implementation. The whole thread on it was an effort to avoid that mess
and follow the spec.

> During login one can send all the standard keys in a single 8k PDU.
> During FFP, the only standard negotiated key exchanged is
> MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread
> over multiple PDUs without an issue.

> Implementation doesn't support 8k transmit PDU size - the negotiation
> default of 8 k is for the size PDU one supports receiving. An
> implementation might chose to only send a much shorter PDU and then
> its keys would not al fit in a single PDU. I find it difficult to
> imagine someone designing an implementation that creates a long batch
> of keys and then sends it in multiple short PDUs when it could send it
> in one PDU, so this doesn't seem like a very good reason to have the C
> bit.

I agree this isn't a strong reason.

> Anticipation of more FFP negotiations so that FFP offers don't all fit
> in a single PDU when PDU size might be as small as 512.
>
> Support for vendor specific extension keys that are more then 8 k in
> login or more than MaxRcvPDUDataSize in FFP.

The latter ones are good reasons. But the main reason I saw for the C bit
is that the way the spec was written, to strictly comply with it would
lead to a real mess. It certainly could be done, but where I saw things
going was (as the thread indicated) not where the majority of the WG had
seen them going. For instance Julian had a sender making a buffer and
chopping it into PDUs in mind, which wasn't simple with the spec as it
was.

Yes, there are other ways out of the mess, but the C bit is one that
required little change to current negotiations. All you have to do is
stick some buffer control code in the head of the login PDU analysis code
(I posted pseudocode based off of what I am using), and your current code
works as-is.

Take care,

Bill