[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI: keys/parameter dependence
I wonder what I said to warrant such a long answer.
I just pointed out that the C bit should not be viewed as related (directly) to batching.
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.
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 05, 2002 8:56 PM
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.
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.
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 04, 2002 10:19 AM
To: Robert D. Russell
Cc: email@example.com; Martins Krikis; firstname.lastname@example.org
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!
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
> 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
> 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
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).
> 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.
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
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.
> 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
> > 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
Last updated: Thu Jun 06 18:18:38 2002
10557 messages in chronological order