Discussion:
Shortest TCP session?
(too old to reply)
glen herrmannsfeldt
2013-01-19 19:33:37 UTC
Permalink
Someone in another newsgroup is trying to get especially high TCP
connection setup/teardown rates, which reminded me that I forgot
how short a TCP connection can be?

Can you add data to the SYN, SYN+ACK, and ACK packets
of the three-way handshake?

Can you add FIN on the last (and first) data packet?

That is, does:

1) SYN+data+FIN
2) SYN+ACK+data+FIN
3) ACK

work?

Usually, I would choose UDP in this case, but some might
like TCP better.

-- glen
Jorgen Grahn
2013-01-19 21:34:14 UTC
Permalink
Post by glen herrmannsfeldt
Someone in another newsgroup
Who, and which one?
Post by glen herrmannsfeldt
is trying to get especially high TCP
connection setup/teardown rates, which reminded me that I forgot
how short a TCP connection can be?
Can you add data to the SYN, SYN+ACK, and ACK packets
of the three-way handshake?
Can you add FIN on the last (and first) data packet?
1) SYN+data+FIN
2) SYN+ACK+data+FIN
3) ACK
work?
Rick Jones will most likely answer, but until then:

I asked here in 2005 or 2006. IIRC, the answer was close to "maybe in
theory, but in practice this is broken in OSes, or disabled to avoid
attacks." This also ties into the T/TCP protocol, and why it was
flawed and abandoned.
Post by glen herrmannsfeldt
Usually, I would choose UDP in this case, but some might
like TCP better.
I'd try to avoid designing protocols with short-lived connections
in the first place!

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
glen herrmannsfeldt
2013-01-19 23:10:26 UTC
Permalink
Post by Jorgen Grahn
Post by glen herrmannsfeldt
Someone in another newsgroup
Who, and which one?
comp.arch.fpga
Post by Jorgen Grahn
Post by glen herrmannsfeldt
is trying to get especially high TCP
connection setup/teardown rates, which reminded me that I forgot
how short a TCP connection can be?
Can you add data to the SYN, SYN+ACK, and ACK packets
of the three-way handshake?
Can you add FIN on the last (and first) data packet?
1) SYN+data+FIN
2) SYN+ACK+data+FIN
3) ACK
work?
I asked here in 2005 or 2006. IIRC, the answer was close to "maybe in
theory, but in practice this is broken in OSes, or disabled to avoid
attacks." This also ties into the T/TCP protocol, and why it was
flawed and abandoned.
Yes, the OP didn't explain the details. If he is building both
ends, then he can make them any way he wants, including ignoring
attacks. He wants 1000000 connections per second over gigabit.
Post by Jorgen Grahn
Post by glen herrmannsfeldt
Usually, I would choose UDP in this case, but some might
like TCP better.
I'd try to avoid designing protocols with short-lived connections
in the first place!
It does seem that the trend is to keep the connection open and reuse
it when possible. But UDP is much easier to do in an FPGA than TCP.

As I understand it, the receiver isn't supposed to get the data until
after the ACK, in which case it wouldn't (usually) have data to return.
(That is where a UDP server could respond based on a UDP request.)

After that post, I got out my Comer, and was looking through the state
machine diagram, but I couldn't decide if it should work or not.
It might be that it isn't the full state machine.

Probably it should be two separate questions.

First about data on the SYN and SYN+ACK, and second on
putting FIN on the SYN and SYN+ACK.

-- glen
Jorgen Grahn
2013-01-20 06:56:56 UTC
Permalink
On Sat, 2013-01-19, glen herrmannsfeldt wrote:
...
Post by glen herrmannsfeldt
After that post, I got out my Comer, and was looking through the state
machine diagram, but I couldn't decide if it should work or not.
It might be that it isn't the full state machine.
Also look at T/TCP. It can be seen as an attempt to answer the
question "what's the smallest modification to TCP we can do to make
very short request--response sessions?"

http://en.wikipedia.org/wiki/T/TCP

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
r***@gmail.com
2014-03-10 19:26:04 UTC
Permalink
I believe these statements to be true, mostly from reading RFC 791:

1) You may put data in the SYN and SYN+ACK segments, but it doesn't make any sense since the TCP connection isn't established yet.

2) You may put data in the ACK segment which acknowledges the SYN+ACK.

3) I'm not sure if the ACK acknowledging the SYN+ACK can carry the FIN flag, but I can't find any prohibition for it.

4) The TCP state diagram in RFC 791 makes it look like you can't have a FIN flag in the ACK segment that acknowledges a FIN segment. I believe this is because the diagram is documented as being incomplete.

So I believe that the shortest (in segments, not bytes or time) TCP connection is as follows:

Client <-> Server
-> SYN
<- ACK, SYN
-> ACK, data, FIN
<- ACK, data, FIN
-> ACK
Post by glen herrmannsfeldt
Post by Jorgen Grahn
Post by glen herrmannsfeldt
Can you add data to the SYN, SYN+ACK, and ACK packets
of the three-way handshake?
Can you add FIN on the last (and first) data packet?
1) SYN+data+FIN
2) SYN+ACK+data+FIN
3) ACK
work?
I asked here in 2005 or 2006. IIRC, the answer was close to "maybe in
theory, but in practice this is broken in OSes, or disabled to avoid
attacks." This also ties into the T/TCP protocol, and why it was
flawed and abandoned.
Post by glen herrmannsfeldt
Usually, I would choose UDP in this case, but some might
like TCP better.
I'd try to avoid designing protocols with short-lived connections
in the first place!
It does seem that the trend is to keep the connection open and reuse
it when possible. But UDP is much easier to do in an FPGA than TCP.
As I understand it, the receiver isn't supposed to get the data until
after the ACK, in which case it wouldn't (usually) have data to return.
(That is where a UDP server could respond based on a UDP request.)
After that post, I got out my Comer, and was looking through the state
machine diagram, but I couldn't decide if it should work or not.
It might be that it isn't the full state machine.
Probably it should be two separate questions.
First about data on the SYN and SYN+ACK, and second on
putting FIN on the SYN and SYN+ACK.
-- glen
glen herrmannsfeldt
2014-03-10 21:55:00 UTC
Permalink
Post by r***@gmail.com
1) You may put data in the SYN and SYN+ACK segments, but it
doesn't make any sense since the TCP connection isn't
established yet.
In a non-interactive session, I might already know what I want to ask.
Post by r***@gmail.com
2) You may put data in the ACK segment which acknowledges the SYN+ACK.
3) I'm not sure if the ACK acknowledging the SYN+ACK can carry
the FIN flag, but I can't find any prohibition for it.
4) The TCP state diagram in RFC 791 makes it look like you can't have
a FIN flag in the ACK segment that acknowledges a FIN segment.
I believe this is because the diagram is documented as
being incomplete.
So I believe that the shortest (in segments, not bytes or time)
Client <-> Server
-> SYN
<- ACK, SYN
-> ACK, data, FIN
<- ACK, data, FIN
-> ACK
It is possible that some sessions will have a data length of zero, in
at least one direction. I time server can always return the time,
without any incoming data. (Which it seems could be on the syn-ack.)


(snip)
Post by r***@gmail.com
Post by glen herrmannsfeldt
Post by glen herrmannsfeldt
Can you add data to the SYN, SYN+ACK, and ACK packets
of the three-way handshake?
Can you add FIN on the last (and first) data packet?
1) SYN+data+FIN
2) SYN+ACK+data+FIN
3) ACK
work?
(snip, I also wrote)
Post by r***@gmail.com
Post by glen herrmannsfeldt
Probably it should be two separate questions.
First about data on the SYN and SYN+ACK, and second on
putting FIN on the SYN and SYN+ACK.
Note that was over a year ago!

-- glen

Loading...