Re: [tcpm] More TCP options

Stefanos Harhalakis wrote:

> 
> Upon exchanging and agreeing on this option, both sides will be able
to
> support 'long options'. I propose that long options be implemented as
> an intermediate layer between the existing TCP and the data. Imagine
> something like this:
> 
> +------------+-------------------------------------+------+
> | TCP Header | Extended TCP Header  (Long Options) | Data |
> +------------+-------------------------------------+------+
> 
> Then, middleboxes (NAT boxes) will be unaffected as long they don't
re-
> pack data (is there such a possibility?).
> 

Very definitely. See RFC 5044 on what RDMA had to do to work around
these problems.

The bottom line is that the TCP Data Stream is a stream, and no
offload NIC or middle-box is obligated to understand it as having
any other structure.

The best you can do is to create an endpoint agreement that they
will exchange certain information in the payload, and only proceed
farther if they are in agreement.

Something like that might be possible as an endpoint solution, and
still be exercised by the TCP stacks themselves.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm