RE: iSCSI: Login negotiation space

[pat_thaler@agilent.com]

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