RE: TCP limitations (was Re: ISCSI: Urgent Flag requirementviolates TCP.)

[julian_satran@il.ibm.com]

You will find this old memo interesting.
Our WG chair(s) in their infinite wisdom have decided that they should not
be kept arround in the public
document area of this working group (and the I-D don't keep them either).

Some other options have been discussed as well and will be taken to the
end2end.
(See attached file: iSCSI-RDMA-memo.txt)



"Bernard Aboba" <aboba@internaut.com> on 23/11/2000 07:29:30

Please respond to "Bernard Aboba" <aboba@internaut.com>

To:   "Randall R. Stewart" <randall@stewart.chicago.il.us>, "ronald lee"
      <ronald.c.lee@sun.com>
cc:   ips@ece.cmu.edu
Subject:  RE: TCP limitations (was Re: ISCSI: Urgent Flag
      requirementviolates  TCP.)




>>TCP option field to do the framing.

This is a bad idea since it will make it very difficult
to leverage the same silicon between iSCSI and other
accelerated TCP/IP applications.

>I believe this is clearly OUTSIDE the scope of the WG. We CANNOT
>change TCP.. period... if you desire to do this, you must take
>this to the end2end group (as Scott suggested)...

Makes you wonder what part of NO isn't understood here ;)

>Hmm, seems to me if you implement P-MTU discovery this problem would
>go away, but I do agree that if there is no P-MTU discovery you may
>have a problem with fragments....

In practice, it will be very difficult to attain the design
goals without P-MTU discovery.

>I cannot support even having this urgent method has an option. It is to
>unstable and WILL NOT work reliably...

I will check the Windows TCP/IP implementation, but I believe that you
are correct.

>Another thought, listed in your memo is
>the choice of a "magic" signature. But this may present a problem
>as well (CPU wise) since now one must scan memory looking for the
>"magic" mark (when one gets out of sync) and of course one would
>need a escape sequence in case data heading for a disk or tape had
>the magic mark...

In practice, this would be very difficult to pull of at 1 Gbps line
rates. It's worth keeping in mind that at that line rate you don't have
very many clocks, even with a 1 Ghz processor. You would need to
optimize the "magic signature" search in silicon to have a prayer
of meeting the clock budget.

>I don't know of any other viable options though..

How about a length field?

Text - character set unknown