Re: Target record not to span PDUs?

[Tow Wang <Tow_Wang@adaptec.com>]

Stephen and all:

Hello. Let me explain myself further, as I do care about this issue. As I
interpret the appendix E, the amount of data (bytes) generated in response to
"SendTargets" can be arbitrarily long, and thus may require an unpredictable
number of text command/text response exchanges until all target records have
been delivered to the initiator.

I don't think it is a good idea to have to buffer all the data segments of
these text responses (until seeing a final bit) before parsing the target
records and freeing the buffers. I was not confusing between the concepts of
"having to buffer all TCP frames until all bytes of a single PDU have been
received"
and
"having to buffer and hold all PDU's sent in response to SendTargets"
The former is a given due to the nature of networking, but the latter is bad,
and likely unfeasible, if one has limited buffering memory. It is more
memory-efficient (and slightly improves performance) to FULLY process each
INDIVIDUAL PDU that has been delivered to the recipient, so one can release the
buffering resources and prepare to process the following PDUs coming in.

Also, in this situation the target is much better informed about the sizes,
starting points and end points of the target records. While the target writes
each record into the "contiguous memory" buffer alluded to, it must keep track
of the offset for the amount of space already used in the buffer (as it
certainly is not infinite in size!). That will give an immediate indication of
whether a record will fit within the a PDU, or should be shipped in the
following PDU.

Tow


"Wheat, Stephen R" wrote:

> Julian,
>
> Not to be pedantic, but, again, the arbitrary decision to avoid the
> concatenation adds burden to the target side and restricts the future
> capability of key=values that exceed the max text PDU length.
>
> Again, the host side will need to buffer the input until it has all arrived
> anyway.  Is there a stronger technical reason for this other than the
> avoidance of concatenation?
>
> The approach you propose adds processing burden to every action on a target
> side to put a key=action into a PDU.  I envision the target side having
> contiguous memory to formulate the entire text response, and it then sends
> this in sequential PDUs.  Having to search for where a key=value pair spans
> the PDU boundary is work.
>
> Furthermore, being able to span PDUs facilitates a simpler specification.
>
> Maybe Tow can explain the burden of concatenation.  If Tow really doesn't
> care, can we go back to allowing the records to span PDUs?
>
> Does anyone else care about this?
>
> Stephen
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 2:01 PM
> To: ips@ece.cmu.edu
> Subject: RE: Target record not to span PDUs?
>
> Bob,
>
> The record in question is a key=value pair. What Tow was asking is a about
> a way to avoid having to "concatenate
> strings" from two Text responses that carry the SendTargets answers one
> after another and we have stated that
> explicitly now.
>
> Julo
>
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 22-08-2001 19:00:18
>
> Please respond to Robert Snively <rsnively@Brocade.COM>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
> cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> Subject:  RE: Target record not to span PDUs?
>
> It sounds like there may be some confusion between "physical
> data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
> (the messaging unit for iSCSI).  I cannot see where Tom's
> problem arises, since Protocol Data Units are very well
> behaved and should not have the problems he is discussing.
> You cannot complete Protocol Data Unit processing until you
> know you have all of them and that useful information does not
> span them.  The assembly of protocol data units into useful
> complete messages should be done at a layer below that where
> you interpret the contiguous bytes of data in the context of
> the complete messages.  I think as a general rule that any
> iSCSI action should be able to span PDUs, including the
> Target Record.
>
> Bob
>
> > -----Original Message-----
> > From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> > Sent: Tuesday, August 21, 2001 7:07 PM
> > To: 'Julian Satran'
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Target record not to span PDUs?
> >
> >
> > Julian (and all):
> >
> > Hello. This is regarding draft 07; could we require that
> > target records NOT span across
> > PDU's if a text response for SendTargets is very long? Upon
> > reading appendix E, it seems
> > that a response (of 4096 bytes in length) could end with:
> >
> > [Begin data segment]
> > ...
> > TargetName=I.got.chopped.4096
> > TargetAddress=10.1.1.45
> > [End data segment]
> >
> > In the above case, one could not determine whether the
> > address is IP V4 or V6. Even if it
> > had had enough space to put in the whole address, port and
> > group tag, one cannot parse and
> > process the record until inspecting the data segment of the
> > next text response PDU, and
> > this would involve cumulative buffering, back-parsing, etc. I
> > think the above complexity
> > could be avoided, as I can't imagine any single record
> > exceeding 4096 bytes in length.
> >
> > Tow Wang
> >
> >