Subject: [tcpm] More TCP options

From: Stefanos Harhalakis <[email-masked]>
Date: Wed, 16 Jul 2008 20:46:24 +0300

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Adam Langley" <[email-masked]>
Date: Wed, 16 Jul 2008 10:52:44 -0700

> Nonsense ? Already discussed ?

I believe that the current thinking around this issue is given in
   http://tools.ietf.org/html/draft-eddy-tcp-loo-04

If you've not already carefully read that, you should, to save
reiterating discussions. Also, there's an archive of the tcpm list
online:

http://www.ietf.org/mail-archive/web/tcpm/current/maillist.html

Cheers,

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Adam Langley" <[email-masked]>
Date: Wed, 16 Jul 2008 11:34:20 -0700

On Wed, Jul 16, 2008 at 11:09 AM, Stefanos Harhalakis <[email-masked]> wrote:
> Please excuse my ignorance. After (carefully) reading the draft I see that it
> already describes everything I proposed and addresses the concerns too. I'll
> try to be more carefull in the future.

No apologies needed! Although no one is scheduled to give a
presentation of long options at the next IETF meeting[1], I expect
there will be some discussion. If you have a use case for long options
you might want to tell the list about it. Currently I don't believe
there's a really compelling one.

Cheers

[1] http://www.ietf.org/meetings/72/

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 16 Jul 2008 14:41:46 -0400

Stefanos Harhalakis wrote:

> 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:
> 
> 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.

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Wed, 16 Jul 2008 14:39:32 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Adam Langley
>Sent: Wednesday, July 16, 2008 2:34 PM
>

There's plenty of meeting time left, based on the current agenda
requests:
http://www.ietf.org/proceedings/08jul/agenda/tcpm.txt

If someone wants to give a presentation to spur some face-to-face
discussion, there seems to be enough mailing list discussion from
different people to warrant it.  Are there any volunteers?
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 16 Jul 2008 14:17:04 -0700

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