Re: iSCSI : Review Feedback on iSCSI Rev 06

[Santosh Rao <santoshr@cup.hp.com>]

Stephen Bailey wrote:
> 
> 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...).

Steph,

I agree that an upper limit is required on the text/login/nop commands.
What I was pointing out was that this upper limit needs to be lower than
DataPDULength, failing which fragmentation can occur.

If it is felt that explicitly defined keys that constitute such limits
is over-kill due to these PDUs not being in performance path, that's
fine. All we then need is to say :

non-scsi command PDUs commands MUST be limited to a size of :
min(4096, DataPDULength).

This ensures that no fragmentation occurs when DataPDULength is < 4K.

Regarding the separate problem that arises from an unbound response to a
command PDU [such as a SendTargets], the iterator proposal results in
more "wire traffic" during target discovery than the use of a single
text command and target controlling the data returned. Multiple sets of
data from the target can then be re-assembled into a single host buffer.

This is the way the FC-GS-2/FC-GS-3 GID_FT command operates and it
allows for a faster target discovery than the iterative use of other
FC-GS-2/GS-3 name server queries such as GA_NXT (GAN).

However, both methods could be specified by the draft with
implementations choosing either an iterator based scheme or a bulk
response scheme.

Regards,
Santosh



> 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
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard