Re: [tcpm] More TCP options

Stefanos Harhalakis wrote:
> 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'.

This is equivalent to a required TCP option. There's no such thing; if 
the other side doesn't support the option, it will return a SYN/ACK 
(granted, without the appropriate response).

The trouble is that the only solution is to RST that connection. That 
means that the new TCP is NOT backward compatible. There's no such 
thing, as a result. You might as well pick another protocol number, at 
which point you can redefine the protocol fields however you like.

> Nonsense ? Already discussed ? 

I do think we've been around this block before; it led to Mark Allman's 
"double everything" proposal. If it's worth discussing in Dublin, it 
might be useful, but I encourage others to review the archives on this 
topic.

Joe

Re: [tcpm] More TCP options

Attachment: signature.asc