RE: iSCSI: Login negotiation space

["Julian Satran" <Julian_Satran@il.ibm.com>]

Pat,

I had trouble understanding the "basics" underneath your claim that 16k is excessive.
If you are concerned about many sessions having to provide this space - the targets supporting many sessions 
 must anyhow have many resources to do so (i.e., they are high end devices) .

The vast majority of those will go for the TCP window. the little that has to go for session management will either be in some host space or will be shared with other buffers for the session. 

As for throttling - if you have the 16k from the outset of a ngegtotiation I do not see how your real dealock can occur.

I am not sure that this thread is expresses a decent level of maturity but if 16k is really of concern I suggest we get it down to one PDU i.e., 8k and conclude the thread before time runs out.

And only to add a grain of salt to all this the 16 was not arbitrarily chosen. It is based on a very simple traffic model and on the assumption that a socket consumes around 6k in idle state.

Julo

pat_thaler@agilent.com 07/03/2002 09:09 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,
 
I wouldn't object to the default PDU size being lowered, but that is not what I am suggesting.
 
There is no conflict between having a default PDU size of 8k during login and having a requirement to support at least 4096 bytes of key=value data in a negotiation sequence. PDUs don't have to be full. The situation is no worse than having a MaxRecvDataSegmentLength of 8k when MaxBurstLength is 4k or having a 4 kbyte write with an 8kb byte MaxRecvDataSegmentLength.
 
The default MaxRecvDataSegmentLength at 8k would still be useful when implementations were supporting very long authentication items. Also, a vendor might suport a larger negotiaton space for vendor specific keys. Such an implmentation could send a key like X-com.acme.HugeKeySet=yes. If the partner responds X-com.acme.HugeKeySet=yes, then it can proceed to send the hugh key set knowing that its partner supports it and therefore has allocated space for it. If it gets a no or NotUnderstood response, it doesn't send the extra keys.
 
I disagree with your statement about deadlock. It is a real issue when throttling is engaged.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, July 03, 2002 8:34 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Login negotiation space


Pat, 

4k does not make too much sense either with default PDU size of 8k. 
Are you suggesting we limit this too to a lower value? 
Your deadlock example while academically correct is not very interesting as I assume that throttling can be done at the first buffer level. 

Julo