RE: iSCSI: RE: Target record not to span PDUs?

["Wheat, Stephen R" <stephen.r.wheat@intel.com>]

Thanks for the reply, Julian.

But your answer didn't address why we should introduce such a restriction.

I don't see an initiator processing the text commands until it has received
the entirety of the concatenated packages.  So, why would we introduce the
complexity of ensuring a key=value pair does not span a PDU boundary?  I.e.,
we already have to deal with splitting the text response across multiple
messages, why complicate the check to include partitioning the PDUs on
intra-key-value boundaries?

Furthermore, we then preclude the ability to send huge key-value responses.
Though we cannot envision such huge responses now, doesn't mean they won't
appear in the future.  I'm usually against facilitating a future feature
that may never be realized, but that is when providing for that feature
costs something.  In this case, it doesn't.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 1:40 PM
To: Wheat, Stephen R
Subject: Re: iSCSI: RE: Target record not to span PDUs?


Every single key value pair is now restricted in size anyhow (64 key, 255
value).
With the  limitation we have introduced you can't have:

xxxx=zzzz+zzzz yyy=vvvv

where + is a PDU boundary.

We never stated this explicitly.

That's all.

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 22-08-2001 19:15:20

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  iSCSI: RE: Target record not to span PDUs?



Julian,

I'm not sure the problem case as stated is syntactically correct; maybe it
has to do with my interpretation of book marks.

As stated, the sequence looks like:
  [Begin data segment]
  ...
  TargetName=I.got.chopped.4096
  TargetAddress=10.1.1.45
  [End data segment]

My understanding of bookmark is that the packet would look like:
  [Begin data segment]
  ...
  TargetName=<incomplete target name>
  [End data segment]

Where the next message would simply be concatenated to the previous text.
And would look like:
  [Begin data segment]
  <rest of target name>
  ...
  TargetAddress=10.1.1.45
  [End data segment]

So, yes the host needs to buffer the last incomplete record, awaiting the
text to be concatenated, but there is no rewind or re-parse.

What am I missing?

If I'm right in my interpretation, then it would seem that your response is
overly restrictive.  Being concerned about buffer memory is one thing, but
when we are talking about a few kilobytes, that is getting too concerned.
If an initiator was really so limited in its memory, then it would probably
only be doing one login at a time anyway.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 3:23 AM
To: ips@ece.cmu.edu
Subject: Re: Target record not to span PDUs?



Good point. I think that we can do this as we have a limit on the size of
an individual record far lower than 4096.

I'll ad the following text to 2.9.5:

   A Key=value pair must be confined to a given text response even in the
   presence of bookmark - i.e., it must start and end within one Text
   Response.

Julo

Tow Wang <Tow_Wang@adaptec.com> on 22-08-2001 05:06:44

Please respond to Tow Wang <Tow_Wang@adaptec.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "'ips@ece.cmu.edu'" <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