|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Login negotiation spaceJulian,
There is a separate
number for cases where very long authentication items are supported and I
haven't asked to change that number.
Remember the text
is:
Any iSCSI target or initiator MUST support receiving at least 16384 bytes of key=value data in a negotiation sequence except when indicating support for very long authentication items by offering or selecting authentication methods such as public key certificates in which case they MUST support receiving at least 64 kilobytes of key=value data. Changing the 16384
number on the first line to 4096 will have no effect on the 64 kilobytes
limit on the last line and implementations desiring to support very long
authentication items are covered.
4k works fine for
the required CHAP authentication and there is no reason to require 16k.
Controlling memory by delaying negotiation with some parties as memory fills is
an unnecessary complication which can result in deadlocks.
If one does what you
suggest and throttles keys "as you have unprocessed keys exceeding the mount of
memory you want to keep aside", then you may get to that point but find that
none of the keys you have are processable - the C bit is set and you need to get
some more packets before you can process.
One could throttle
just some logins when one has enough memory left to complete some but not all of
the negotiations, but there is a risk of deadlock. A simple example: Target
X decides to stall negotiation from Initiator B until negotiation from
Initiator A completes freeing buffer. Initiator A has stalled negotiation
with Target X until negotiation with Target Y completes freeing buffer. Target Y
has stalled negotiation with Initiator A until negotiation with Initiator B
completes. Initiator B has stalled negotiation with Target Y until negotiation
with Target X completes. They are all stalled until one or more of the logins
times out.
It is much safer and
simpler to set the required memory size to a reasonable limit for the mandatory
negotiation items plus some comfortable room for expansion.
Regards,
Pat
-----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:36 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, 4k is absurd. We have the security guys asking for 64k certificates! And the PDUlength default is 8k! Besides you can control the total memory consumed by throttling login as soon as you have unprocessed keys exceeding the mount of memory you want to keep aside (you control the login progress by delaying requests/responses). Julo
Julian, A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. It is n * 16k where n is the number of simultaneous logins the implementation supports - it adds up. The system vendors we work with want to use the memory to do useful work and demand that driver sizes be kept small -- they want the memory available to do "real" work. If 2k doesn't leave enough headroom, then we could live with somewhat more like 4k. If future features added to iSCSI require more space, the drivers that support that can allocate more memory. It is an internal parameter that can be changed when the need arises. There is no future interoperability need to make the buffer oversized in current implementations. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 02, 2002 12:10 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login negotiation space Pat, A factor of 10 over what is needed today is what I would call a conservative design. Limiting the support to 2k would be extremely unwise. And 16 is a tiny amount of memory - of no concern to software implementation and to most hardware implementations. Julo
Julian, 4.1 contains a requirement that initiators and targets support receiving at least 16384 bytes of key=value data (when not supporting very long authentication items). This is overkill and is making drivers larger than they need to be. My calculations are that Security negotiation using the CHAP method (including the Any-stage keys) takes less than 1600 bytes. Operational negotiation requires 1276 bytes (also including the Any-stage keys). All the operational plus security keys are 1911 bytes. Therefore an implementation could hold all the necessary keys in 2 Kbytes. And, the implementation doesn't need to keep the security keys after the security negotiation is done so it could clear some of that out to make room for future keys or vendor specific keys. 16 K bytes is about 10 times the necessary storage in that case. The number of negotiation bytes that a device is required to support should be reduced substantially - preferably to 2048 bytes. Regards, Pat The numbers: 43 AuthMethod CHAP keys 264 Name (no defined size limit - using 255) 11 Algorithm 11 Identifier 264 Challenge 42 Response (for MD5) _____ 635 Chap negotiation length 892 Any-stage keys ---- 1527 Operational negotiation keys 24 HeaderDigest 24 DataDigest 49 MaxConnections 270 TargetName* or InitiatorName* 271 TargetAlias* or InitiatorAlias* 273 TargetAddress* 55 TargetPortalGroupTag* 15 InitialR2T 19 BidiInitialR2T 18 ImmediateData 34 MaxRecvDataSegmentLength 24 MaxBurstLength 26 FirstBurstLength 24 DefaultTime2Wait 26 DefaultTime2Retain 25 MaxOutstandingR2T 18 DataPDUInOrder 24 DataSequenceInOrder 24 ErrorRecoveryLevel 23 SessionType* ------ 892 Any-stage keys 384 Not Any-stage ------ 1276 Operational keys
Home Last updated: Wed Jul 03 12:19:18 2002 11096 messages in chronological order |