RE: iSCSI: Iteration for SendTargets

["Douglas Otis" <dotis@sanlight.net>]

Mark,

In the SCTP version of iSCSI (see draft-otis-record-delivery-01.txt) session
iteration was implemented.  My thinking was that this handling may happen
within "stack" space as this information is not to be stored until
successful completion.  With that in mind, keeping a lid on the amount of
memory consumed allows for reasonable limits to be placed on the routines.
I thought iteration was a good idea.

With respect to default devices, as the Target may provide a different
"default" Targets dependent on the Initiator name, depending on the wisdom
of the Target, there may not be a need to further process the Target list.
If a simple Target provides the same "default" to all Initiators, then a
need to further resolve to a Target is then required.  If the Target already
knows the privilege of the Initiator as well as the shared password, it
should also be able to properly select the correct "default" Target.  One
wonders how a generic server would make this selection without human
intervention otherwise.  If the "default" Target responds with a different
name and alias, the Initiator could choose to select this Target on
subsequent Logins.

Doug

> At the interim meeting we had discussed the fact that a
> SendTargets response can become rather large, given storage
> arrays with 10s of ports, and gateways that can represent
> many targets.
>
> Consider a single target on a 32-port storage array.  This
> target can easily be expected to have a 40-character iSCSI
> name, 40-character alias, and 32 DNS-named addresses, with
> each DNS name being 30 characters long.  Including the text
> key names, equals signs, null characters, and values, the
> response for this target would take:
>
>        12+40+32*(15+30)+13+40 = 1545 bytes
>
> Given a limitation of 4096 bytes on text responses, the fact
> that multiple targets can be returned in a response, and
> that the iSCSI name, alias, and DNS-named addresses in
> the response do not need to be as well-behaved as those in the
> example, it's easy to envision normal SendTargets responses of
> over 4k.
>
> There are different ways to handle this:
>
> 1. Restrict SendTargets commands and responses to the
>    canonical target sessions, and handle them in software.
>    Remove the text response limit for canonical target sessions,
>    since they are not done in hardware anyway.
>
> 2. Add an iterator capability to SendTargets.  Steph brought
>    this up during the interim meeting.  This will work well if
>    #1 can't be done.
>
> There may be others, but these are the two I've thought about.
>
> The argument for #1 is that SendTargets is really a software
> function, and nobody is likely to actually implement it in
> hardware.  It would use normal socket calls, so the length of
> the response would not be much of an issue for the initiator.
> The same would be true of a target if it used a normal TCP
> stack for canonical sessions; however, there may be implementations
> that do not plan to do this (speak up if this is a problem).
>
> If the argument for #1 does not hold, it would be necessary
> to implement some sort of iterator.  Steph has already posted
> on this topic.  An iterator would be easy enough to do for
> SendTargets, and we could put it in, but I want to make sure
> that #1 is exhausted first.
>
> Please let me know what you think.
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>