Adding LUN as a field within the command structure.

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

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.  The ability of the client to index the entire volume of
devices possible is remote and will be a larger constraint.

The point of aggregation, gateway, which mandates this replicated operation
by means of inclusion of LUN indicates the inability to scale this design
due to this architectural bottle neck.  The data path from the target to the
point of aggregation is not guaranteed and, as this is an encapsulation,
even error handling is not benefited by TCP as there can still be delivery
errors.  Is the desire to create such a constriction due to a lack of
ability to map drives across IPs and ports?  What rational justifies
aggregation into something that does not scale and is not reliable?

This design does not provide a clean separation between protocol layers as
desired.

Doug