Re: multiple TCP connections

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

Steve,

Between the router and an intelligent switch, the packets are encapsulated
to allow load balancing and multi-paths.  The internal address of the packet
does not change for this encapsulation that responds to failure at 10 second
intervals typically.  This would be true for any protocol other than iSCSI.

The major problem with the charter of IPS are assumptions aimed at providing
an OEM specification to a specific product providing a bridge between
Fibre-Channel and 1 Gbit Ethernet to exclude these reliability practices.
As most high-end disk drives can only handle about 150 operations per
second, the throughput on the drive interface is largely dependent on the
size of these transactions.  In most SAN environments, the half-duplex data
rate at the drive is less that 10 MB/sec. (Still possible within Fast
Ethernet rates which provide up to 25 MB/sec. full duplex)  Improvements to
the operations per second figure require increases in power to the square of
the improvement.  With co-location sites running into the tens of
mega-watts, a reduction in operations per second could have a significant
power benefit together with the use of Ethernet switches at providing the
actual reliable switching fabric rather than Fibre-Channel or Parallel SCSI.

Second, because of the IPS direction being aimed at the Fibre-Channel
bridge, security issues that result in this approach have been over-looked
together with the reliability issue mentioned.  Rather than mapping a
process to a port nexus, process IDs are buried somewhere within the TCP
stream.  The overhead of the Fibre-Channel bridge (iSCSI) approach will
overwhelm legacy equipment with this buried critical data and preclude
third-party verification.  The iSCSI headers are free-form and non-aligned.
The redundant data-handling resulting from this simplistic approach will
ensure protocols using an aligned structure will well out perform the iSCSI
standard and ensure a short life for this iSCSI product.  The iSCSI
architecture is based on Fibre-Channel and not that offered by an IP
networked device.

Doug

Julo wrote:

>There is no standard way of doing link agregation. That's the main reason
>for having
>the session (+reliability).

Being ignorant of networking practices, it seems to me that link aggregation
is more appropriately solved as a routing problem than as part of the
application protocol. IP supports multiple links per end-point. If an
end-point has two links, then it must have at least two routes to it. From
there it's just a question of getting the routing to load-balance between
the routes.

What am I missing? Is it that the currently-available TCP/IP implementations
and routers don't do load-balancing on links, due to  problems introduced by
out-of-order arrival?



I also don't understand the point about reliability. A multi-homed host
already has hardware redundancy, and even if today's commercially-available
routers and TCP/IP stacks don't do load balancing they surely understand how
to use a different route in the event of link failure.

Is the claim of reliability based on just having multiple links, or is it
based on using the command reference numbers to recover a failed TCP
session?


Is there work going on elsewhere in the IETF with respect to link
aggregation?

Thanks.

Regards,
-Steve

Steve Byan <stephen.byan@quantum.com>