RE: iSCSI: keys/parameter dependence

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

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

pat_thaler@agilent.com 06/05/2002 09:41 PM Please respond to pat_thaler

To:        Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu         cc:        ips@ece.cmu.edu, mkrikis@yahoo.com, owner-ips@ece.cmu.edu         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: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

"Robert D. Russell" <rdr@io.iol.unh.edu> Sent by: owner-ips@ece.cmu.edu 06/04/2002 09:46 AM Please respond to "Robert D. Russell"

To:        Martins Krikis <mkrikis@yahoo.com>        cc:        ips@ece.cmu.edu        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