|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: keys/parameter dependenceJulian,
And I pointed out
that the arguments for it were related to batching (even if current
implementations of 12 don't send a multi-PDU batch) and C bit is unnecessary to
deal with PDU spanning in the absence of batches. You still didn't agree so I
explained my reasoning at greater length (though it doesn't seem to have done
any good except to get you to add "(directly)" to the statement). I don't
understand what you think justifies the addition of the C bit if it isn't
to support batching.
The C bit should be
viewed as related directly to batching.
Pat
-----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, June 06, 2002 2:12 PM To: THALER,PAT (A-Roseville,ex1) Cc: ips@ece.cmu.edu Subject: RE: iSCSI: keys/parameter dependence Pat, 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. Julo
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:Julian_Satran@il.ibm.com] Sent: Wednesday, June 05, 2002 8:56 PM To: ips@ece.cmu.edu 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
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:Julian_Satran@il.ibm.com] Sent: Tuesday, June 04, 2002 10:19 AM To: Robert D. Russell Cc: ips@ece.cmu.edu; Martins Krikis; owner-ips@ece.cmu.edu 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
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
Home Last updated: Fri Jun 07 12:18:39 2002 10573 messages in chronological order |