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

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Costa:

Ok, I have read through this draft... very interesting... but
I must be missing something...

How does it solve the framing problem?


It does offer the same broken Urgent mechanism as an option but
this will not work. Unless the VI approach uses a modified
TCP I see no method in here to not have the same issue.. I.e
what happens when a segment with the VI header is lost? Same
issue.. no difference that I can see. Did I miss something in
my read of the draft???


The other issue hanging issue on it of course is the two patents
held by giganet.



R

csapuntz@cisco.com wrote:
> 
> > 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

-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)