Subject: iSCSI: Iteration for SendTargets

From: Mark Bakke <[email-masked]>
Date: Mon, 14 May 2001 15:49:26 -0500

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
[email-masked]
763.398.1054

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 14 May 2001 15:16:54 -0700

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