Re: Read data chunk size and segmentation negotiation

[julian_satran@il.ibm.com]

Mike,

I can commiserate with you about broken implementations and we might just
work towards having
compliance authority (like FC has) but the requirements you are talking
about are clearly implied by the data header structure.
Each data header has a Buffer Offset (the initial is 0). Why would we have
one if the implied input would have been a single chunk?  In any case I
will see if we can fit a statement in the introductory part.

Julo

Mark Burton <markb@ordern.com> on 23/11/2000 20:14:38

Please respond to Mark Burton <markb@ordern.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: Read data chunk size and segmentation negotiation





From: julian_satran@il.ibm.com
Subject: Re: Read data chunk size and segmentation negotiation
Date: Thu, 23 Nov 2000 15:56:40 +0200

> Interesting questions - but why?
>
> Why should the initiator care about the chunks (it has already reserved
the
> memory when issuing the read) and about how many - the target is going to
> tell him when it is over by the Status or Response.
>
> Could you elaborate?
>

I understand from your response that it is an (implicit) requirement
that all initiators must always accept a data response of any length
up to the expected data transfer length. This is logical because it is
the initiator that specifies the expected data transfer length.

I just wonder if there is (or will be) any situation that would
require the size of the data responses to be limited by the initiator
whilst still allowing for a larger data transfer length. If no such
situation can ever occur then the negotiation is not required.

However, I would still prefer that the implicit requirement that an
initiator must be capable of accepting all of the read data in one
response to be stated explicitly.

Furthermore, unless I am mistaken, the draft standard does not
explicitly state that initiators must be able to accept read data that
has been segmented into multiple responses (as opposed to a single
data response). I would also prefer that this requirement is stated
explicitly. As background to this, I am aware of an initiator
implementation that cannot accept segmented read data. Whether it was
done deliberately or by accident I don't know.

I just feel that the the more loose ends that are nailed down, the
greater the chance that the resulting end products will be
interoperable.

Regards,

Mark

----------------

>
> Folks,
>
> Given the definition of the SCSI Data Response format in Section 2.8
> and the example in Appendix B of draft-ietf-ips-iscsi-01.txt it
> appears necessary for the initiator and the target to agree on the
> maximum amount of data that can be sent in a single SCSI Data
> response.
>
> Another issue is that either the initiator should be required to
> accept multiple data responses containing the content for a single
> read or it should have some means of informing the target that it will
> not accept multiple data responses per read i.e. the read data must
> not be segmented.
>
> I guess additional login keys could be added to negotiate these
> constraints.
>
> Regards,
>
> Mark
>
>
>
>
>
>