Subject: RE: [tcpm] TCPx2

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 8 May 2006 11:27:53 -0700

Mark Allman wrote:
> Hi folks!
> 
> I jotted out an i-d on an idea that has been rolling around
> my head for a while.  I submitted it, but until it pops out
> in the archive you can slurp a copy here:
> http://www.icir.org/mallman/draft-allman-tcpx2-hack-00.txt.
> The general idea of this hack is to increase TCP's header
> size once to deal with these field-foo-is-not-big-enough
> issues rather than trying to design a solution for each of these.
> 
> (As the document says, this is not a proposal for a TCPng.)
> 
> So, crack open an adult beverage, take a look and let me know
> what you think ... or, at least enjoy the read! :)
> 
> allman

In any sort of "let's really fix TCP" discussion I think
the starting point should be SCTP. There are some very fine
features in SCTP, (just as the 4-way handshake, multistreaming
and multihoming) and one very big limitation -- lazy middleboxes
that should be working at L3 are all too often L4-aware and
thereby fail to properly support SCTP.

We can be purists and say that the middleboxes should be
updated to conform to the specs. In that case, why don't
we just come up with a profile of SCTP that's optimized
for SOCK_STREAM? It's much easier than defining a new
transport protocol.

Or we can start with the assumption that any new solution
MUST be transparent to existing middleboxes. That suggests
that the way to get more space for connection setup and
other data is to somehow get both sides to agree that the
first N bytes of the data stream aren't for the application
but carry this additional data.

Is something that would be a new transport protocol even
properly belong under the label "Modifications"?

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

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 May 2006 14:38:34 -0400

Christian:
> Increase size fields is definitely a good reason for looking at TCPx2.
> [...]
> But there are other reasons as well, e.g.:

Caitlyn:
> the starting point should be SCTP. 

Allow me to call attention to this bit from the draft:

    This document is not about specifying a "TCPng".  The functionality
    (or lack thereof) of TCP is not changed.  The intention is to simply
    give TCP some possibly breathing room.  The proposal is for
    pragmatic evolution, rather than principled engineering.

This draft is not about adding functionality.  I believe everyone in
the transport community has their own vision of what a TCPng looks
like.  If you do, please write it down and take it from there.  This
proposal is a (probably cracked out) wondering about whether simply
bumping the size and leaving the functionality is a reasonable path.  

(And, pragmatically, this leaves more option space and more reserved
bits in the header for people to tinker with.)

allman

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 May 2006 08:00:45 +0300 (EEST)

> bumping the size and leaving the functionality is a reasonable path.

I guess the most important point we'd have to figure out at some point 
(not necessarily here, as this group isn't even chartered to do TCPx2) 
is, "is TCPx2 [or some similar "bigger is better" proposal] useful 
enough on its own to be worth doing?"

I.e., if there's going to be significant deployment pain 
(implementation should be rather straightforward), maybe addressing 
some other TCP shortcomings would also be called for.  Or maybe not, 
it depends on your perspective and how well you think other protocols 
like SCTP or DCCP address your scenarios.

I think we learned from the IPv6 experience that while Bigger is 
Better, many folks would actually have wanted to get a feature upgrade 
(e.g., identifier/locator split) as well...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings