|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Delaying Login - was: RE: iSCSI: Login negotiation space
Julian,
Your comment about controlling login progress by delaying requests/responses begs the question: How long is too long?
I actually have a question about delaying login during Session Reinstatement. Say a target receives a login indicating Session Reinstatement. The target must internally abort all tasks on the session, but this may take a very long time and the implementer may not
want to complete the reinstatement login until all the tasks are aborted; again, how long is too long?
Perhaps a blurb in a new section (6.3.3?) on Timeouts on Login, or Timeouts on Session Reinstatement?
Mike
On Tue, 2002-07-02 at 12:35, Julian Satran wrote:
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
|
pat_thaler@agilent.com
07/02/2002 10:02 PM
Please respond to pat_thaler
|
To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space
|
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
|
pat_thaler@agilent.com
07/02/2002 01:56 AM
Please respond to pat_thaler
|
To: Julian Satran/Haifa/IBM@IBMIL
cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space
|
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
Michael Morrison
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key: 74C30155
|
Home
Last updated: Tue Jul 02 19:18:44 2002
11087 messages in chronological order
|