Re: multiple TCP connections

[julian_satran@il.ibm.com]

Lyndon,

Several of us looked through it.
Very good job.  And in many respects close to what we need. But not close
enough.
We recognize that your objectives where quite different from ours - ours
are simpler
as far as functions goes (e.g., we don't demand out of order processing
only
out of order DMA not to have data pile up in adapters) but far more
stringent
performance requirements.

Nevertheless we will continue watching what you do both for ideas and
guidance,
to influence it where we can and perhaps use sctp or some light weight
version as it gets widespread.

Regards,
Julo

Please respond to "Lyndon Ong" <long@nortelnetworks.com>

To:   Steve Byan <steve_byan@hotmail.com>, ips@ece.cmu.edu
cc:   stephen.byan@quantum.com (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: multiple TCP connections




We recently completed work on a transport protocol with multi-homing
support, plus support for multiple information streams within one
session.  If this might be of interest (it was built for transport of
signaling and control messaging) folks can find it at
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-13.txt .  It
was recently approved as a Proposed Standard and is on the RFC editor's
queue.

Cheers,

L. Ong
Nortel Networks

At 05:48 PM 7/31/2000 -0400, Steve Byan wrote:
>I don't understand the motivation for creating the concept of a session
>consisting of multiple TCP connections in the iSCSI draft.
>
>If the motiviation is a desire to share the load over multiple physical
>paths, IIRC IP already provides this in the form of multihoming. I
>suspect there is some current activity in this area, although I'm not
>network-literate enough to point to any such work.
>
>If the motiviation is to work around performance flaws in the
>implementation of multihoming in some TCP/IP stacks, then I suggest that
>it would be better to fix the implementations.
>
>If the motiviation is to work around a fundamental performance flaw in
>IP multihoming, then I suggest that IP should be fixed, or that some
>other generic solution be engineered.
>
>If the motiviation is to make it easier to implement TCP/IP hardware
>acceleration by pushing the aggregation of multiple paths up into the
>application protocol, then I suggest that a general solution should be
>engineered (one that can be applied to multiple protocols), rather than
>creating a special hack for iSCSI.
>
>Is there a rationale for multiple TCP connections that I have missed?
>
>If not, which is the claimed rationale?
>
>Thanks.
>
>Regards,
>-Steve
>
>Steve Byan <stephen.byan@quantum.com>
>Design Engineer
>Quantum Corp.
>MS 1-3/E23
>333 South Street
>Shrewsbury MA 01545
>(508) 770-3414
>________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel.
+1 408 495 5072
Fax. +1 408 495 1699