|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Negotiation clarifications still neededJulian, I generally agree with the intent of the wording. A couple of comments - - I assume you meant "text-value of a received key-name" by "key text" (the only occurrence of "key text" is here). I suggest we use the definitions on pages 68 & 69. [ This is somewhat unrelated. But with the advent of formal terminology now, I'd actually recommend that we replace all "key=value" usages in the text with "key-name=text-value".] - IMHO (if my above assumption is true), the proposed rule is overly constraining. o The originator would only have to refrain from originating new keys if a partial *key-name* is received. IOW, doesn't have to wait for the entire text-value to arrive (though it may). o The "no incomplete key text" should not imply that the responder is also forbidden from responding to other (complete) text-value offers that it had already received. As a pathological case, if every PDU begins from the middle of one text-value and concludes in the middle of the next text-value, the responder should not be required to sit out until all the proposals are received in full (though it may). Here's a strawman with some wordsmithing. Key=value pairs may span PDU boundaries. A responder having a received partial key-name or not received the following "=" in a PDU MUST refrain from originating any new key=value negotiations until it had received the key-name in full and the following "=" . In this case, the receiving entity can only assume the role of a responder for this key. This way one avoids having both negotiating entities assuming the originator role in a negotiation. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" <Julian_Satran@il.ibm.com> To: <pat_thaler@agilent.com> Cc: <ips@ece.cmu.edu>; <mkrikis@yahoo.com> Sent: Friday, May 24, 2002 10:26 PM Subject: RE: iSCSI: Negotiation clarifications still needed > Pat your proposed 2b may be what we are looking for - i.e. a responder may > not originate a key if it has an incomplete key text. > > The text we may want to add to section 4.2 is: > > Key=value pairs may span PDU boundaries. A responder having a received > partial key text MUST refrain from originating any new key=value > negotiations until it has no incomplete key text. This way one avoids > having both negotiating entities assuming the originator role in a > negotiation. > > > Julo > > > > > pat_thaler@agilent.com > 05/25/2002 12:16 AM > Please respond to pat_thaler > > > To: mkrikis@yahoo.com, Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Negotiation clarifications still needed > > > > Martins, > > Comments referenced by the same items Martins used. > > 1. Julian sent an email saying he would put the text > I proposed in (though the text you quoted is not the > whole text). > > 2. I think that the principle we have been using on > text negotiation was that each key negotion is a > separate item. Your proposal would be counter to that > and I don't think it would be an improvement. The > target should be allowed to respond to any complete > key-value pair it has received. When a key-value > pair is straddling the PDU bondary, then it shouldn't > respond to that key until the complete key-value pair > has been received. > > There is one potential corner case issue that should > to be covered. Targets can initiate keys. If key-value > pairs didn't straddle PDU boundaries, then ensuring > that there is a clear originator for each offered key > is easy. You can originate any key that you haven't > received an offer of from your partner. But now keys > can straddle PDUs. If the text between the last separater > and the end of the PDU is Ma, then you don't know what > key your partner has started to offer. If the partner > was starting to offer MaxBurstSize and you offer it in > the next PDU of the exchange, both sides may think they > are originator. > > I suggest one of the following > a) don't allow keys to straddle PDU boundaries. > b) don't allow originating a key when the last login > PDU ended in a partial key. > c) don't allow offering a key where the start of the key > matches a partial key at the end of the last login > PDU. > > 3. Yes, we noticed a little while ago that losing a > packet at the end of negotiation could hang things up > though the concern is mainly for a full feature phase > negotiation. Looking at 6.8, any timeout during > negotiation causes the login and its TCP connection to > be terminated. The whole negotiation process (see the > point about origninators in 2) depends upon a one-by-one > exchange of PDUs. PDU loss has to terminate it. > > Therefore, the target commits to the end of login > as described for T5 target. It has sent the final > login response with a status of zero. Moves to S5. > If the login response doesn't get to the initiator, > then either the initiator will close the connection > due to the timeout. Since the target is in S4, loss > of the transport connection will cause it to go to > S8 and R1 of the cleanup state machine. It presumably > will not take the M2 transition because the intiator > isn't going to do cleanup for a connection it thinks > wasn't in full feature phase. It will take M1 due to > timeout - not elegant but good enough. > > The concern was Full Feature Phase negotation. Until > negotiation ends, it can be reset and no values change. > When the target sends the last Text Response PDU, then > it thinks negotiation has ended and it applies the > new values. If that PDU doesn't reach the initiatior, > then it terminates the entire negotiation and continues > to use the old values. The two ends are using different > values. > > We decided to not raise this as an issue because it is > such a corner case - we are operating over a reliable > connection so PDUs shouldn't be lost (unless the whole > path goes down in which case it doesn't matter). Also, > there are few values exchanged during full feature so > it isn't worthwhile to add complexity. > > Regards, > Pat > > > -----Original Message----- > From: Martins Krikis [mailto:mkrikis@yahoo.com] > Sent: Friday, May 24, 2002 12:39 PM > To: Julian Satran > Cc: ips@ece.cmu.edu > Subject: iSCSI: Negotiation clarifications still needed > > > The previous thread went on too long, but since it > has now quieted down, I'll conjecture that the > following are the aspects that still need to be > addressed. > > 1. Not everybody seemed to have noticed that it is > NOT legal to send the same key again, if it > has once been negotiated (including negotiations > that end with a reserved value (Reject, > Irrelevant or NotUnderstood). > > I think it would benefit the draft to add the > sentence that Pat proposed to paragraph 5 or page > 72 in 12-92: "Sending the key again would be a > re-negotiation". That I think would make it crystal > clear. > > 2. When the key=value pairs that Originator is > sending are broken across multiple PDUs, it > is not clear whether the Responder may start > responding to the keys as soon as it receives > them or whether it should send blank PDUs back > (as in the example on page 164 of 12-92) until > it gets a PDU, the data part of which ends in > a NUL byte (thus signaling that there are no > broken key=value pairs at the end of it). > > I am proposing that the draft should make it explicit > that only blank PDUs are to be sent. This allows > decoupling of key=value generation from > their encapsulation in PDUs (i.e., the generating > logic need not worry about whether a key=value > pair will fit and go out in this PDU or has to > be retained to go out in the next). I can explain > in detail why this is important (it has to do > with teh possibility of receiving the "just-about > outgoing" keys) but I'm keeping this "brief". > > Furthermore, it is my feeling that instead of > checking the last bytes of a PDU for NUL, it > would be better if the end-of-data was marked by > a flag in the header. This way encapsulation will > be simpler---just put as much data in the PDU as > fits there and raise the flag if it isn't all, > instead of checking whether it ends in a NUL and > possibly shortening data to make it not end like > that. > > 3. There is an opinion that on page 73 of 12-92, > the phrase that says "or the responder may > select an admissible value" is in contradiction > to the very next sentence. There is also an > opinion that this phrase is entirely unnecessary > and detrimental to achieving broad > interoperability (I call it "cutting slack to > misbehaving or incompatible originators"). > > I don't have a suggestion since I consider the > "feature" that this phrase allows of little > importance to a properly built iSCSI node. > > 4. This is new. When doing Text Request/Response > negotiations (i.e., in FFP), it seems > that the Initiator commits to the new values > when it receives a response from the Target with > the F bit set. It is unclear when the Target should > commit. Should it switch to using the new values > as soon as it sends its response with the F-bit > set, or should it do so only when it knows that > the Initiator received its response? > > Commiting right away is simpler and since responses > with F-bits set have TTT=0xffffffff and thus > may not be reset, sounds plausible. If the > values have importance on the next reception, > it may also be important to commit timely. However, > what if the Initiator doesn't get this response? > Target now has committed, Initiator hasn't. Committing > later puts the burden on Initiator to send something > effectively telling "I've received your final > response". Otherwise the Target will time out and > not commit. This response can get lost too. > > Basically, it is beginning to look a bit like > (what was it called?) "distributed consensus problem"? > I think it goes like this: > > Two generals that are on oposite sides of the > enemy want to synchronize their attack, and > start sending messengers through with messages > like > "attack at dawn->", > "<-ok, attack at dawn", > "I know you know we attack at dawn->", > "<-, I know you know I know we attack at dawn", > etc., etc., ... > But at no point can they commit yet... > > Is anybody else worried about this? > Anyway, so when should a target commit? Page 83 > of 12-92 is the relevant reference. > > Thanks, > > Martins Krikis > > Disclaimer: these opinions are my own and may > not be those of my employer. > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > >
Home Last updated: Tue May 28 16:18:41 2002 10353 messages in chronological order |