Subject: [tsv-area] Cool idea from Bryan Ford's "Meta-SYN"

From: Matt Mathis <[email-masked]>
Date: Thu, 20 Nov 2008 15:56:52 -0500 (EST)

In Bryan Ford's presentation on "Breaking up the Transport Logjam" he 
mentioned the idea of a Meta-SYN packet, that encapsulates several different 
types of SYN packets (or other protocol initialization messages).

This restarted a conversation that goes back at least as far as RFC1263, the 
near impossibility of negotiating new features or protocols on connection 
establishment.  However this time I had a new idea......

Define Meta-SYN to be a shim layer for connection establishment, which carries 
multiple distinct initialization packets (SYN-packets) for different protocols 
or TCP versions (e.g. the "jumbo" TCP described in 1263, or SCTP).  The first 
initialization packet within the Meta-SYN would be the fallback, a standard 
TCP SYN.  The remaining initialization packets (probably, but not necessarily 
just one) would be preferred alternate protocols or versions.  The Meta-SYN 
would be identified by its own IP protocol type.

The Meta-SYN would be followed by a 2nd packet, which is the same standard TCP 
SYN that it first encapsulated.  If the receiving host supports meta-SYN (and 
the middleboxs delivered it), then it chooses it's preferred transport from 
the choices in the meta-SYN.  If it's first choice is not TCP, then it creates 
something that looks like a TCP PCB to catch the following TCP-SYN.  This PCB 
would be somehow marked as a dummy, and would start in what is essentially 
TIME_WAIT (to be discarded after 2*MSL).

If the Meta-SYN fails for some reason, the following regular TCP SYN packet 
does it's normal thing.  If the packets get reordered, and TCP-SYN arrives 
before the Meta-SYN, then the presence of the TCP connection has to inhibit 
processing the Meta-SYN.

That is the whole thing.... really K.I.S.S.   No packed bits, nothing.

The biggest protocol downside is the overhead of the extra packet.  There are 
also huge API complexities, since a single open_by_name() has to build 
multiple initialization packets for different protocols or TCP versions and 
then bundle them in the Meta-SYN.  A successful open also has to indicate what 
it opened, since the application might care (e.g. TCP vs SCTP).  It also has 
to tear down all the connections it did not use.

Give that this can be used to negotiate between standard TCP and a huge span 
of alternates, including things as "simple" a larger TCP option space or as 
complicated as substituting SCTP, this seems like it might be worth the 
effort.

Although the presentation was in TSVAREA, this conversation belongs in TSVWG. 
Please reply there.

Thanks,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Nov 2008 09:18:36 -0800

Matt Mathis wrote:
> mentioned the idea of a Meta-SYN packet, that encapsulates several
> different types of SYN packets (or other protocol initialization messages).
> 
> This restarted a conversation that goes back at least as far as RFC1263,
> the near impossibility of negotiating new features or protocols on
> connection establishment.  However this time I had a new idea......
> 
> Define Meta-SYN to be a shim layer for connection establishment, which
> carries multiple distinct initialization packets (SYN-packets) for
> different protocols or TCP versions (e.g. the "jumbo" TCP described in
> 1263, or SCTP).  The first initialization packet within the Meta-SYN
> would be the fallback, a standard TCP SYN.  The remaining initialization
> packets (probably, but not necessarily just one) would be preferred
> alternate protocols or versions.  The Meta-SYN would be identified by
> its own IP protocol type.
...
> That is the whole thing.... really K.I.S.S.   No packed bits, nothing.

It would be simpler to just issue a SYN for each client-side available
protocol. No packed packets that way.

However, what you really want is a connection establishment
establishment protocol. You send a CEEP-SYN, and the SYN-ACK you get
back (TCP, STCP, etc.) determines which protocol you end up running.

It won't traverse NATs any better than a Meta-SYN until they're extended
to interpret it. Ditto for end hosts that don't understand them. But
then all of these solutions suffer from that issue, AFAICT.

JOe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Nov 2008 18:30:54 +0100

On 25 nov 2008, at 18:18, Joe Touch wrote:

> what you really want is a connection establishment

> then all of these solutions suffer from that issue, AFAICT.

Well, you could achieve this goal by sending a garden variety TCP SYN  
with an option that includes all the alternative transports supported  
and a priority. If there is a match with a higher priority than TCP,  
the TCP session is abandoned (or maybe kept around for a bit in case  
it's needed later) and a session is set up using the negotiated  
transport. You could even skip one or two initial packets if the TCP  
SYNs provided enough information to do this.

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Nov 2008 09:34:24 -0800

PS - in the spirit of avoiding multiple messages, we found a way of
integrating Google, DNS, and SYNs all in one, using a string-based loose
source route we call "DataRouter" (this was about 5 years ago):

http://www.isi.edu/touch/pubs/iwan2003/

The idea is that you send a TCP SYN with the following string, which is
delivered to your default DNS:

default_DNS_IP, http://www.google.com/search?q=joe+touch

which replaces the front with google's DNS, and thus goes there:

google_DNS, http://www.google.com/search?q=joe+touch

which replaces the front with the google server address, and thus goes
there:

http://10.0.0.1/search?q=joe+touch

which replaces the entire string with the first hit (always tries 'I
feel lucky'), and sends it to google's default DNS:

google_default_DNS_IP, http://www.isi.edu/touch

which sends it to ISI's DNS:

ISI_DNS_IP, http://www.isi.edu/touch

which replaces the front with ISI's server's IP addr:

http://128.9.0.160/touch

which then is sent directly to ISI's webserver, which sends a SYN-ACK
with the string "/touch" in it - or just starts sending the response.

This whole thing can occur inside the CEEP-SYN below if you also want to
delay which transport protocol is used, FWIW.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Nov 2008 09:36:50 -0800

Iljitsch van Beijnum wrote:
> and a priority. If there is a match with a higher priority than TCP, the
> TCP session is abandoned (or maybe kept around for a bit in case it's
> needed later) and a session is set up using the negotiated transport.
> You could even skip one or two initial packets if the TCP SYNs provided
> enough information to do this.

That's true, and has the benefit that it would (should) be ignored if
not needed. The trouble with this and other schemes is that the header
also needs all the options you would have sent with each SYN.

Alternately, the server can call you back with the right protocol. Oh
yeah - that won't work with NATs - ;_0

Joe

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 25 Nov 2008 09:40:48 -0800

Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Matt Mathis wrote:

One way to solve that is to always start the exchange with a TCP SYN
and TCP SYN-ACK.

The TCP SYN would include an option that indicated the willingness
to establish non TCP "connections" (or enhanced TCP connections)
instead.

The TCP SYN-ACK would include an option that indicated acceptance
of a specific connection strategy (assuming it accepted the connection).
Then in an alternate-connection-strategy specific manner, the alternate
connection setup would complete.

The alternate setup ends up being slightly longer than if it had been
used directly, but still more efficient than trying multiple setups
in parallel. The TCP SYN / SYN-ACK exchange establishes reachability,
and that information can be used by the alternate connection setup.

-- 
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.html