Subject: RE: iSCSI:Can each do there own thing?

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 30 May 2002 13:16:34 -0600

Bill Studenmund wrote:
 <snip>
> However, I would also like to point out that 5 is almost
> equivalent to allowing an unlimited PDU size (or a PDU size up to
> the buffer size at the end of 4.1) during negotiation. The only
> difference is that the receiver can pace the arrival of the
> data by sending blank PDUs with 5 but it is not clear to me
> that that makes much implementation difference when one must be
> able to buffer the whole negotiation.

I agree that with 5 you do have to be able to buffer the whole negotiation
payload. But that size only has to be 16k if you don't do the long-key
cryptographic techniques, and 64k if you do.

If an extended negotiation payload weighs in at over 64k, I think it's
fair to indicate an error (if you're the target) and close the connection.

If you aren't doing long-key crypto negotiation (kerberos and SPKM AFAIK),
it would be fine to stop after 16k.

Thoughts?

<PAT> So one could deal with this by making the max PDU data size during 
login negotiations 16k increasing to 64k when support for long-key cryptographic
techniques is indicated, not add the C bit and not allow key-value pairs 
to be split. During full-feature phase negotiation, one would either need to
not negotiate for longer sets of key-value pairs than fit in the maxPDURcvDataSize
or one would still need the C bit.

Regards,
Pat

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 30 May 2002 12:59:39 -0700 (PDT)

> or one would still need the C bit.

That option would work for login, but I think we'd still need the C bit
around for FFP negotiations for all the reasons the WG previously
considered when coming up with the multi-PDU support in Text messages.

While we could make the login PDU size larger for login, I'd say stick
with the C bit technique. I think we need it for FFP, so we might as well
use it for login.

Take care,

Bill