RE: Adding LUN as a field within the command structure.

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

Paul,

As iSCSI advocates thousands of LUNs per session, then search for the LUN
over a range multiplied by the number of outstanding tags unique for all
LUNS as well.  If TCP is in hardware, how is innovation helping?  RTT uses
just the Tag.  What a mnemonic.  RTT should mean Round Trip Time in an IETF
specification.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> VonStamwitz, Paul
> Sent: Thursday, August 10, 2000 6:52 PM
> To: 'Douglas Otis'
> Cc: Ips
> Subject: RE: Adding LUN as a field within the command structure.
>
>
>
> Doug wrote:
> > I vote no.
>
> > If you are making hardware to process TCP, this hardware is
> able to handle
> > more than a few connections.  There will *always* be a port
> sort operation
> > to find the connection and associated state information.  It is not more
> > effective to require an additional sort to locate LUN as a
> second tier of
> > state information.
>
> There is another second tier of state information (or is it
> tertiary?) that
> would require sorting, and that is the tag.
>
> > The ability of the client to index the entire volume of
> > devices possible is remote and will be a larger constraint.
>
> If you map a group of LUNs to a connection, then the indexing is for that
> group only and not the entire volume.
>
> The feedback we received is that a connection/LUN is desirable, but making
> it a requirement is too restrictive.
>
> -Paul
>