RE: iSCSI: Login negotiation space

["John Hufferd" <hufferd@us.ibm.com>]

Pat,
I guess I do not see a real problem here.  This is a buffering design
issue, which if done well and dynamically, does not have a problem.  It is
not clear that anything needs to change.  16k is not very large (and many
times this is divided into even smaller segments that are taken from a pool
dynamically).   And I have not seen the case where so many logins occurring
at the same time that an real issue exists.

Also, the issue of everyone stalling out, is in my opinion a matter of bad
design.

I do not believe there is an important issue here since regardless of what
size you come up with, the theory of problems occurring with a bad design
is the same.  At some point there is always a limit of resources, and the
design is what causes it to occur at one time versus another.  I do not
believe, that the fact that the 16k value is not fully used each time is an
important issue.  If the buffering is done well, there is very little
unused space during high utilization.

Also, I do not believe there is an important interlock issue.  That is
because we are talking about a large number of sessions being logged in, or
there is not a problem to begin with.  Therefore, to think that there are
many that are so tied up with the C bit handling that they never free any
space, is not a situation that I find probable.  There will always be some
logins that will be finishing up.  If the one in a billion chance occurs
that they run out of buffers in a well managed buffer pool, then "out of
resources" error is approprate.  Again, changing from 16k to a smaller
value, is not an important issue, since you can always dynamically allocate
smaller buffer segments on your way to meet a 16k need.


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


pat_thaler@agilent.com@ece.cmu.edu on 07/03/2002 11:09:20 AM

Sent by:    owner-ips@ece.cmu.edu


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