Subject: RE: middleboxes and Re: [tcpm] TCPx2

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 10 May 2006 14:14:48 -0700

Mark Allman wrote:
>> In summary, this seems like a fine experiment, but so would a simpler
>> mod that just extended the option space.
> 
> I am going to pop up a level here.  This is some can I
> opened, isn't it?
> Migrating from TCP to SCTP, using options echoed in RSTs as
> part of a handshake, riding TCP on UDP, ..., man... I thought
> my hack was sleazy---you guys have really outdone yourselves! :-)
> 
> In any case, about the above....  The way I look at it is this....
> 
>   + If the crystal ball says that for the forseeable future we're just
>     going to add functionality to TCP (e.g., UTO or portnames or
>     quick-start or a new authentication scheme or whatever) then maybe
>     we just bite the bullet and extend the option space with some hack
>     (and, all the proposals are) and leave the rest of the
> header alone.
> 
>   + If, on the other hand, the crystal ball says that in addition to
>     *extensions* we're likely to need to augment the standard stuff
>     (more port space, more sequence space, more reserved
> bits, even more
>     window space, etc.) the we should either:
> 
>     (1) bite the bullet and say we have outgrown TCP and either:
> 
>       (1a) go about deprecating it in favor of SCTP/DCCP, or
>       (1b) start the process of coming up with a next-generation
>            byte-stream transport that includes more space and all the
>            features a modern transport should have (whatever
> those are)
> 
>       or
> 
>     (2) decide that TCP is still a reasonable (if not optimal)
>         general-purpose protocol and enact one hack to give
> it a bigger
>         header such that it can accommodate today's networks
> and future
>         expansion more readily.
> 

To me the critical issue is maintaining critical compatability
and interoperability. If you are going to lose those, then it
is no longer a minor modification. Further, it won't matter how
useful it is, it won't get deployed anytime soon. And I don't 
think that calling it "TCPx2" or whatever will make it get
required support anytime sooner.

That suggests that any "minor" enhancement should

a) be totally compatbile with current standards, and merely 
   define an extra option that will be properly understood
   as "an option I don't understand but can ignore" by all
   current stacks or network elements.

b) not use much of the remaining option space.

c) enable a much larger exchange of connection setup information,
   when a basic connection is established using the simple
   option described in a and b.

For example, this new option could say something as simple
as "if we both agree to use the 'extended connection' feature
then the first TCP segment we each send will be a special
TCP segment that does not contain ULP payload but rather
special option negotiations. (That's first TCP segment as
sent, obviously the message should document its length
in the first two bytes and the receiver should rely upon
that length rather than on the actual segmentation).

If both sides do not speak the enhanced version then they
simply go straight to the ULP payloads without enhancements.
As far as any existing network element is concerned everything
looks like a standard TCP connection, albeit one with some
new-fangled option that is irrelevant to the network element.

That would allow a very large option space, but restrict it
to options that make sense *after* a nominal connection is
established. But that could include redirecting within a
host a virtual host, jumpstarting the window sizes, etc.

An enhanced INETD, or equivalent, could even launch the
daemon instance *after* doing the special-options exchange.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 10 May 2006 21:57:42 -0400

Caitlin Bestler spake unto us the following wisdom:
[snip...]
> new-fangled option that is irrelevant to the network element.

As long as we're on the "but NATs really do suck!" bandwagon ... this
isn't really true.  Try inserting some random goop between byte 0 and
the first data of an HTTP exchange, and see how many middle boxes you
break -- I bet it will be a nontrivial number.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 May 2006 23:05:17 -0400

> required support anytime sooner.

I read the above as indicating that you do not believe that TCPx2
"maintains critical compatibility and interoperability".  Is that a
correct interpretation?  If so, I'd like to hear the logic behind the
statement, because from my seat compatibility and interoperability are
maintained with the fallback to RFC793 TCP sketched in the i-d.  (The
clear case when that would break is when a stack supported TCPx2 and not
TCPx1.  But, since *it's (basically) the same protocol* it would seem
stupid to go to x2 and not continue to grok x1.)

>    option described in a and b.

So, it's fine if you are in favor of arbitrary extension via options.
As I have sketched previously, I don't think that is the right path,
personally.  But, we can differ.

I will note that while I am practical enough to understand that
middleboxes need to be dealt with, I am sure glad that the IETF does not
take the position that only transports 6 and 17 are blessed to initiate
connections (e.g., DCCP) (e.g., SCTP).  I think it is fundamentally
wrong to constrain our engineering in that way.  I do not mean to
disparage RFCs 791 and 793, but they were not handed down from a deity
and I do not think we are duty-bound to use them for eternity. 

allman