RE: iSCSI: Login negotiation space

[pat_thaler@agilent.com]

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