Subject: RE: iSCSI: Login negotiation space

From: [email-masked]
Date: Wed, 3 Jul 2002 12:09:20 -0600

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:[email-masked]]
Sent: Wednesday, July 03, 2002 8:34 AM
To: [email-masked]
Cc: [email-masked]
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

---

From: Martins Krikis <[email-masked]>
Date: Wed, 3 Jul 2002 14:04:48 -0700 (PDT)

I believe I'm with Pat. Requiring 10 times more
free space to be available than the real minimum
needed is an overkill. Coming down to 2K or 4K
sounds very reasonable.

What I don't understand, however, is why was a
minimum mandated (with a MUST) and not just
encouraged (with a SHOULD) in the first place?
I.e., what's wrong with an implementation that
does its best as long as it can and answers with "Out
of resources" when the data amount that needs to
be stored gets excessive? Alternatively, would
it be considered compliant to support the mandated
minimum (whatever it ends up to be) on at least
one login, but reserve the right to answer with
"Out of resources" on the _simultaneous_ other
logins, if they send too much data?

Thanks,

  Martins Krikis, Intel Corp.

  Disclaimer: these opinions are mine and may
              not be Intel's.

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com