Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement violates TCP.)

[julian_satran@il.ibm.com]

Costa,

A shim protocol is as good as an option only if it is initially agreed upon
by the communicating parties and it is presented to all intervening
elements. An initial TCP option (as we discussed for a specific protocol)
is a good shim proposal as it can be seen (and deleted or agreed) by
intervening parties. Steve Bellovin's draft is a good way to build a shim.
(By initial TCP option I mean an option that appears only in the connection
opening exchange like the MSS, but not after that).

Regards,
Julo

csapuntz@cisco.com on 27/11/2000 20:22:30

Please respond to csapuntz@cisco.com

To:   ips@ece.cmu.edu
cc:   csapuntz@cisco.com
Subject:  Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement
      violates   TCP.)





> Question for you.. I remember reading over Costa's RDMA
> proposal and it seems to me that he proposes using TCP options.
> How does this interact with the use of SACK TCP? I know the
> WG has discussed the need for SACK (or possibly not) and I
> am just curious... will the use of a RDMA option limit you from
> using SACK?
>

I guess you were talking to Bernard, but I'll interrupt here.. :-)

My original proposal took the form of a TCP option. The RDMA option
was a large TCP option, about 12-16 bytes. Since the TCP option area
is only 40 bytes total, some were worried that the RDMA option would
crowd out/limit SACK.

Since the original proposal, Jim Williams of Giganet has shown that
a shim protocol is just as viable.  A shim protocol, unlike a TCP
option, appears in the TCP stream but under the application
protocol. Jim's VI/TCP <draft-dicecco-vitcp-01.txt> sits in a TCP
stream and encapsulates VI-style RDMAs and message.

Given that shim protocol requires no changes to the TCP in the sender,
it is currently my favorite way of doing RDMA.

-Costa