Re: iSCSI : Review Feedback on iSCSI Rev 06

[Stephen Bailey <steph@cs.uchicago.edu>]

Santosh,

> 3) Why does the new draft limit the size of text commands and nop commands to
> 4096 bytes ? What is the rationale behind the magic number selection of 4096 
> ? 

The reason for a limit like this (I won't argue that we've done it
quite right here, in fact, I may argue against it a little bit below),
is for to allow the receiving endpoints to have only extremely modest,
tightly bounded resources for handling this non-nominal (or, at least,
non-performance) traffic.

DataPDULength is way too large a limit.  I'm still optimistic that the
maximum DataPDULength limit will be relaxed back towards 4G, even
though I know that y'all have decided against it and everybody out
there thinks I'm on dust (you'll see...).

The limit that makes slightly more sense from an engineering
standpoint, but makes no sense whatsoever from a standards standpoint,
is FirstBurstSize.  In a hardware implementation, DataPDULength is a
property associated with the hardware data handling path.  The data
arriving in DataPDULength units is destined for buffers which are
known to have already been allocated and supplied from the upper
level.  The resource cost for these buffers is a direct function of
the application, as opposed to iSCSI overhead.

The Login[Response], Text and Ping PDUs, and probably (but not
definitely) unsolicited data, flow through a path where the buffers
are iSCSI implementation overhead.

iSCSI must provide a mechanism for reducing this resource overhead to
an arbitrary, manageable size.  The alternative is to require an iSCSI
implementation to allocate a gratuitously large quantity of memory to
handle occurences which a) may rarely (probably never) happen b)
don't provide the implementation anything at all worthwhile in return
for that memory.

Because this is a non-performance path, having this parameter being
negotiable is also a waste of effort.

The iSCSI negotiation protocol should be (it mostly already is)
designed to tightly bound the worst-case (largest) text payload in a
Text or Login[Response].  To do this we must:
  1) determine the maximum text payload size which contains all
    `fixed' length keys 
  2) create an iterator protocol for arbitrary, or even just large
     text messages.  This includes X-* parameters---an X-* exchange
     must be structured to work within the max text PDU limits.  In
     addition the X-* parameter definitions must create their own
     iterator if necessary---iSCSI only needs to handle iSCSI
     specified keys.

Looking over the present set of text keys, the security exchanges
already have tight size bounds, and clearly aren't going to be the
limiting factor in the maximal text payload.  That leaves the
operation parameters.  Most of the operational PDUs also have a small
maximum fixed size.  The exceptions are:
  InitiatorName
  InitiatorAlias
  TargetName
  TargetAddress
  TargetAlias

We can probably put a modest bound on each of these keys individually
(e.g. 512 bytes), which means that the maximum text payload size
within a Login exchange is tightly bounded and 4K seems adequate.

The problem comes with SendTargets=.  That is why I proposed an
iterator protocol for SendTargets= instead of having the target
information gush back from the target uncontrolled.  Simply bounding
the maximum text payload and allowing and arbitrary sequence of text
payloads to be sent in response to a single request doesn't cut it.
We need to be able to bound the total amount of data returned from
each particular request.

SendTargets= actually has two problems.  1) an arbitrary number of
targets per endpoint, 2) an arbitrary number of addresses per target.
Given the second problem, unfortunately, it's not adequate to merely
have a target iterator, since the data for each target may be
arbitrarily long.  Therefore, here's another proposal which might be
close to the mark:

  Initiator keys:
    SendTargetStart=
       Send first PDU of target list information
       If already in the midst of a target list exchange, restart at
         the beginning
    SendTargetMore=
       Send next PDU of target list information
    SendTargetEnd=
       Terminate a target list exchange

  Target Keys:
    TargetName=name
       one per target
    TargetAddress=address
       one or more per target
    TargetAlias=alias
       one per target (may be empty)
    TargetMore=
       more target information remaining within the present target

A target list exchange always terminates with a Text PDU with final=1.
In the case that the exchange is ended by a SendTargetEnd=, the
target's Text PDU with final=1 would have no payload.

We would specify at most one target list request outstanding per
session.  Personally, I'd like to be even more restrictive and say
that target list exchanges are only allowed on single connection
sessions where a TargetName was not specified at login.  However, Mark
Bakke seemed to think that rather than a session with no TargetName,
it should be a session with TargetName=iSCSI.  Either way is fine with
me, assuming that we do not want to allow a regular, operational login
with TargetName=iSCSI (e.g. for boot, or simple initiators).  I happen
to think that operational login with TargetName=iSCSI is useful.  The
fact is, many boxes, even big ones, will have only a single target,
but many LUNs.  This corresponds to present storage boxes (as opposed
to bridges).

Steph