RE: Urgent as Framing Hint?

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

Julo,

Fanfare to change TCP started at the pre-BOF meeting at 3Com and has
diminished little since.  As you still wish to include the urgent pointer
record marking scheme within the iSCSI proposal, intent to modify TCP is
clear and John Hufferd underscored this effort with his statements.  The
proposal description of how TCP is to behave was indicated to be incorrect
and yet you persist in maintaining an incorrect TCP behavioral statement.
As this urgent pointer scheme is problematic, your intent to continue
employing this scheme despite short-comings indicates a determined effort in
seeing TCP transform into a datagram protocol to support a desire for out of
sequence processing.  At your initial presentation within IEFT, you
indicated your desires in this area.  If I misrepresented statements, then I
wish to hear a clarification that does not sound like equivocations.

The iSCSI proposal (pg 13):

   "Unfortunately, when relying solely on the "message length in the
   iSCSI message" scheme to delineate iSCSI messages, a missing TCP
   segment that contains an iSCSI message header (with the message
   length) makes it impossible to find message boundaries in subsequent
   TCP segments. The missing TCP segment must be received before any
   following segments can be processed.

   The iSCSI protocol uses the urgent bit in the TCP header to delineate
   iSCSI messages. The first byte, and only the first byte, of every
   iSCSI PDU SHOULD be marked "urgent" if the receiving party has
   indicated its readiness to accept PDUs marked with the Urgent Bit &
   Pointer.  The result is that there will be a TCP segment with a valid
   TCP pointer (urgent flag set) pointing to the first byte of an iSCSI
   message in the TCP segment."

Perhaps you would take time to explain how the last sentence "The result is
that there WILL be a TCP segment with a valid TCP pointer (urgent flag set)
pointing to the FIRST byte of an iSCSI message IN the TCP segment." is not
mandating change to TCP.  Also can you explain how this requirement is
useful to standard TCP implementations.  It is clear you are set to
radically change TCP to allow out of sequence processing to achieve the goal
of direct and immediate data placement between the network adapter and
application space using iSCSI encapsulation.  As your endeavor venture far
from TCP, I see little basis to site TCP as stable and supported when you
then insist on making such changes.  I see much greater advantage in keeping
TCP stable and allowing innovations to occur within a younger protocol that
has explicit design goals which conform very closely to those sought for
SAN.  The transport and the API of SCTP supports the type of adapter desired
without alteration.  It is disingenuous to insist that you wish to use
standard TCP and then go about making protocol requirements that are not
possible nor useful with standard TCP.  I must say I question your sincerity
when you say that you are not envisioning changes.  If I have misunderstood
intent or taken statements out of content again my apologies.

Doug

> I am not envisioning any changes for iSCSI or at least not for the near
> future.
> There are things that bother many of us and with regards to several
> protocols in which the TCP has
> to do something to ease the end-node loads at high speed and I
> suppose they
> will be accepted in a
> reasonable time-frame (I don't know yet what they are though nor what the
> time-frame will be).
> The changes will be I assume tiny and will be deployed gradually over
> several years and with luck and good design will not
> break too many things.
>
> SCTP is dazzling but it is too young for us to know what it's weaknesses
> are.   I have no clue how light or heavy its
> implementation is or where to find a silicon producer willing to use it in
> a widely deployed are like storage interconnects
> (I guess you are not better off than me). People that wanted it badly for
> SS7 on IP have not the same type of requirements as storage producers.
>
> Julo
>
> "Randall R. Stewart" <randall@stewart.chicago.il.us> on
> 29/11/2000 18:18:00
>
> Please respond to "Randall R. Stewart" <randall@stewart.chicago.il.us>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   Douglas Otis <dotis@sanlight.net>, David.Eckhardt@cs.cmu.edu,
>       end2end-interest@ISI.EDU, ips@ece.cmu.edu
> Subject:  Re: Urgent as Framing Hint?
>
>
>
>
> julian_satran@il.ibm.com wrote:
> >
> > 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
> Julian:
>
> I do have one question for you, your statement above
>
> "are convinced that new applications and network technology will
> "induce"
>  changes"
>
> implies to me that you want TCP to change. This in and of itself is
> not necessarily a bad thing... but, if you make substantial changes
> to TCP for say iSCSI do you not run in to the same maturity/deployment
> issues of these "new changed TCP" that you hit with SCTP. You have
> the same question then, are you willing to "bet your business" on
> rolling out new and so far undefined changes to TCP?
>
> Defining any extensions or changes to TCP will, I would think take
> at least 6 months to 1 year. Then you have the adoption period
> to deploy said changes into all of your O/S vendors etc.. .the very
> issues you have with SCTP will then arise with the "new improved" TCP.
>
> ... just food for thought...
>
> R
>
> --
> Randall R. Stewart
> randall@stewart.chicago.il.us or rrs@cisco.com
> 815-342-5222 (cell) 815-477-2127 (work)
>
>
>
>