Re: [tcpm] TCP Long Options

Wesley Eddy wrote:
> 
> I guess the real problem was that the TCPM group didn't ever get
> consensus that working on any long options mechanism was important,
> so it never got done as a WG item, and it couldn't be done as an
> independent submission RFC because TCP is a core protocol.  Thus,
> 4 years later, it is still not done, and I still get email every
> few months from people that stumble upon the draft and want to use
> it to enable some other experimental modification that requires a
> really long option or two.  I think this is what happened with Adam.
> He was working on another project, ran across the previous version
> of the TCP Long Options draft, and discovered it was what he had been
> reinventing.
> 
> In my personal opinion, it's a good idea to have some way to do
> long options (any way, not necessarily even this draft) that's
> at least published Experimental (off by default), simply because
> different groups of people keep thinking they need long options.  I
> think that's the point that the WG didn't have consensus on in the
> past, and may or may not still lack.
> 

The functionality sought with TCP "long options" are already provided
with SCTP. The only valid reason cited for not using SCTP for these
type of new applications is lack of support from middle-boxes.

Any TCP enhancement that does not preserve transparency to existing
software and hardware will face all of the problems of SCTP, and
probably with fewer benefits.

In addition to the middle-box issue that is always cited, there is
a special issue with changing the syntax of TCP options that is in
the hosts themselves - any form of header/data separation done in
existing software or hardware could be broken. This is especially
true for LRO/LSO (Large Receive/Send Offload).

I strongly suspect that any encoding that provided more option space
would prove inherently incompatible with one or more existing middle
boxes, host stacks and/or NICs. If such a feature merely provides
SOCK_STREAM service between two enhancement-aware endpoints, then
why not simply map SOCK_STREAM to SCTP at both ends and leave TCP
alone?

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