iSCSI: Iteration for SendTargets

[Mark Bakke <mbakke@cisco.com>]

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