RE: iSCSI: Negotiation clarifications still needed

[pat_thaler@agilent.com]

Julian,

 

The problem is that the text you propose says "incomplete key text" and

everywhere else the key is just called "key" so one isn't sure whether

"key text" means key or the whole key-value pair. Therefore, "key text"

should probably be "key".

 

> 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.
>
One could add after the second sentence "It may send key-value responses

and declarations."

 

Also, I think there could be a clearer tie between the 4.2 text on

declarations and the keys in 11. I suggest adding before:

"Keys marked as "declarative" may appear also in the SecurityNegotiation
stage while all other keys described in this chapter are operational
keys."

 

the sentence:

"Keys which are subject to declaration rather than negotiation are marked declarative."

 

This ignores sendTargets which is an odd kind of declaration. It isn't a negotiation but it causes

the target to respond with declaritive keys and it is FFPO. Ideally one would use different labels to

indicate that a key was subject to declaration and that it could be sent in SecurityNegotiation stage.

 

Regards,

Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, May 28, 2002 12:34 PM
To: Mallikarjun C.
Cc: ips@ece.cmu.edu; mkrikis@yahoo.com; pat_thaler@agilent.com
Subject: Re: iSCSI: Negotiation clarifications still needed

Mallikarjun, 

Thhe current text and your proposed text say basically the same think. If 
you feel that originating does not convey the meaning of originator I will 
rephrase it. 

I will not consider 
key-name and text-value as they would require a long re-reading of the 
text. 

Julo

"Mallikarjun C." <cbm@rose.hp.com> 05/28/2002 10:02 PM Please respond to "Mallikarjun C."

To:        <pat_thaler@agilent.com>, Julian Satran/Haifa/IBM@IBMIL         cc:        <ips@ece.cmu.edu>, <mkrikis@yahoo.com>         Subject:        Re: iSCSI: Negotiation clarifications still needed

Julian,

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
>
>
>