[tcpm] More TCP options

Hello there,

AFAICS there is clearly a need for more options space in TCP (especially in a 
way to extend option negotiation). Even though current needs may be satisfied 
with workarounds, it is clear that a more generic approach will be needed.

I suggest that we find a backwards compatible solution that would allow TCP to 
become extensible again.

I dare to propose one such approach:

Add one (final) TCP option that would be negotiated during the initial 
handshake. This option will eventually initiate a kind of TCPv2 communication 
that may one day in the future become the de-facto standard.

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?).

The initial option negotiation problem will be solved by:
* Permitting cookies to do their job as there will be no extra options in the 
SYNACK segment.
* Allowing extra options to be negotiated by data segments. (A modification to 
existing TCP semantics).

After a successful "extended header" negotiation, all TCP segments should 
contain an option that indicates the size of the included extend header. This 
may be 0 for no such options. Having this in mind it will be possible to 
allow more options to be negotiated using data segments (most probably the 
first segment). A way for reliably performing such a handshake is also 
required.

I believe that we should have in mind what we would like to have in 10 years 
from now (and not tomorrow) and that something like the above will be an 
absolute requirement. Providing such a common infrastructure to TCP will 
allow most TCP implementations to become compatible in (lets say) N years 
from now and be able to "survive" for M (M>>N) years more, without loosing 
backward compatibility.

Nonsense ? Already discussed ? 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm