Subject: RE: iscsi : DataPDULength can differ in each direction.

From: "Ayman Ghanem" <[email-masked]>
Date: Wed, 3 Oct 2001 14:28:39 -0500

Well, the proposal says:

	Each side should be allowed to specify the DataPDULength it will be
	using and there should be no attempt to negotiate this value. Rather,
	the key is exchanged in either direction to inform the other side as to
	what sized PDUs it should expect.

So, I understand that as if the initiator sends
DataPDULength=reallyBigNumber, then it is informing the target that this is
what it will be using, but the target should not attempt to negotiate it.

-Ayman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Buck Landry
> Sent: Wednesday, October 03, 2001 2:13 PM
> To: [email-masked]
> Subject: RE: iscsi : DataPDULength can differ in each direction.
>
>
> It may add complexity, but, since DataPDULength is only a boundary on
> the maximum number of bytes transmitted in a Data PDU (not the minimum),
> "the first" *does* have a say about it.  Right?
>
> -----Original Message-----
> From: Ayman Ghanem [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2001 1:38 PM
> To: [email-masked]
> Subject: RE: iscsi : DataPDULength can differ in each direction.
>
>
> I think this will add unnecessary complexity, specially for data CRCs
> having
> to be calculated based on two different PDU sizes for Reads and Writes.
> Also, one end may choose to do data digests in software. If the other
> end
> decides to use a really large PDU length (and the first doesn't have a
> say
> about it), this could be a problem.
>
> -Ayman
>
> <snip>
>

---

From: "Buck Landry" <[email-masked]>
Date: Wed, 3 Oct 2001 14:13:07 -0500

-----Original Message-----
From: Ayman Ghanem [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 1:38 PM
To: [email-masked]
Subject: RE: iscsi : DataPDULength can differ in each direction.

-Ayman

<snip>

---

From: "Rod Harrison" <[email-masked]>
Date: Wed, 3 Oct 2001 21:37:39 +0100

Can someone give a tangible benefit to this that can outweigh the
spec and implementation churn at this late stage of the game?

	From my point of view the benefit of asymmetric PDU sizes would have
to be very large to make it worth the extra complexity in buffer
management code alone.

	- Rod

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Ayman Ghanem
Sent: Wednesday, October 03, 2001 8:29 PM
To: [email-masked]
Subject: RE: iscsi : DataPDULength can differ in each direction.

Well, the proposal says:

	Each side should be allowed to specify the DataPDULength it will be
	using and there should be no attempt to negotiate this value. Rather,
	the key is exchanged in either direction to inform the other side as
to
	what sized PDUs it should expect.

So, I understand that as if the initiator sends
DataPDULength=reallyBigNumber, then it is informing the target that
this is
what it will be using, but the target should not attempt to negotiate
it.

-Ayman

---

From: Santosh Rao <[email-masked]>
Date: Wed, 03 Oct 2001 14:45:56 -0700

Rod,

The issue came up as a result of Deva pointing out that an initiator may
not be able to function with the minimal of the 2 DataPDULengths
(initiator's & target's) in the case where the value chosen was not its
value.

In order to allow for such implementations that had issues with the
DataPDULength, I raised this question. 

The benefit of both sides being allowed different DataPDULengths is :

a) Each side can specify its max supported value which the other side
would not exceed. The sender & receiver would be able to function with
different DataPDULengths, with the guarantee that their advertised
receive pdu length will not be exceeded, thus, allowing more flexible
interoperability of implementations. (btw, the proposal should have read
: Each side is allowed to advertise its maximum receive pdu length.)

b) It may also allow 2 parties with differing PDU lengths to send larger
sized PDUs in one direction to the party that advertised a higher
receive pdu length.

However, I do admit there's a cost to making this change, given we are
so late in the draft rev and several implementations have already been
made. If this is not an issue of concern to the majority of
implementations, I am ok with the current definition, although it is
more limiting on implementations.

Thanks,
Santosh

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################