RE: Urgent as Framing Hint?

[julian_satran@il.ibm.com]

Doug - you are (again) quoting snippets out-of-context and misrepresenting
the discussions in IPS.
The main reason SCTP is not yet considered is maturity. Nobody is going to
"bet-its-bussiness" on it
for the next 2 years and there where no compelling reasons to go for this
route (for a while).  TCP is simple and good and IPS has no mandate and no
intentions to ask for changes.   However many of us don't see TCP as dead
as Latin and
are convinced that new applications and network technology will "induce"
changes (even if slow like in any mature area).

Julo

"Douglas Otis" <dotis@sanlight.net> on 29/11/2000 03:00:57

Please respond to "Douglas Otis" <dotis@sanlight.net>

To:   David.Eckhardt@cs.cmu.edu, end2end-interest@ISI.EDU
cc:
Subject:  RE: Urgent as Framing Hint?




Dave,

The desired goal for SAN transport is the ability to transfer data
immediately and directly between the network and application.  With SAN or
VI, ordered delivery is not typically required and to keep buffers lean,
latency low, and memory utilization at minimum, an adapter moves
application
data directly between application space and network encapsulation.  In the
case of iSCSI, the encapsulation is a persistent TCP connection passing SAN
blocks contained within iSCSI structures.  As TCP does not allow content of
the stream to be processed prior to receipt of all intervening segments,
this is seen as a competitive weakness if compared to Fibre-Channel.  The
obvious solution to this inherent TCP restriction would be use of SCTP, but
for marketing reasons, most within the IPS workgroup have instead elected
to
modify TCP.  UDP does not provide flow control and this group wishes to
leverage off of the market acceptance of TCP.

The modifications range from the use of RDMA TCP option, Urgent Pointers
marking Protocol Data Units, a Push flag doing the same, and now a shim
(recommended segment alignment but with a PDU ID and non-standard CRC-32
for
frame discovery.)  The ultimate impact on TCP is rather sizeable as the
normal API for TCP does not allow data to be transferred from iSCSI
structures prior to completed sequences and status being returned to the
application.  The question will ultimately end with how do you allow out of
sequence delivery of application data using TCP and, in addition, how do
you
frame the encapsulation protocol and still call this protocol TCP.

The RDMA option size interferes with SACK, Urgent Pointer fails beyond 64k
offsets.  In RAID, each stripe is typically 64k so a single row update will
overwhelm this pointer.  The shim, rather than saying segment alignment is
required, an unworkable method of frame discovery is provided as an
alternative.  Those wishing to use a standard TCP stack will be at a
competitive disadvantage as a result.  Noting market forces to cause
vendors
to comply with whatever modification employed within a dominate TCP SAN
transport, SAN intends to transform TCP stacks into a datagram protocol
providing out of sequence delivery and segment alignment.  But that IS SCTP
you might suggest.  Yes, but this group wishes to use TCP!  TCP modified to
work like SCTP.

My answer is use SCTP.  My voice is but one; I have framed the question and
provided an 'unacceptable' answer.  Is there a better answer to this
problem?  The article I posted earlier is a good example of TCP
modification
efforts.  My apologies if my input is seen to taint this endeavor.  I could
be wrong and this group is most likely to set me straight.

Doug

> I think you might get higher-quality answers from this forum
> if you first briefly summarized why UDP is wrong for your
> application.
>
> Dave Eckhardt
>