Subject: Re: [tcpm] About the SYN/ACK-timer

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 1 Jan 2013 16:33:32 +0100

I might miss something here, but to me there are some orthogonal issues in this discussion.

Retransmission of the SYN without data is already recommended in Section 4.2.2. of draft-ietf-tcpm-fastopen-02. Also, draft-ietf-tcpm-fastopen-02 refers to RFC6298, i.e., the 1s minimum RTO.

Thus, the novelty in this thread seems to be the suggestion to use much smaller minimum or initial RTOs (100ms or 200ms), right?

I really wonder how this would work for over-buffered links ("bufferbloat"), or, e.g., satellite links? IMHO, with a SYN (or SYN/ACK) RTO of 200ms, we would send every SYN (or SYN/ACK) three times, if we happen to run over a path with an RTT of one second... On a narrowband link, this could be a lot of overhead.

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jakob Heitz
> Sent: Monday, December 31, 2012 8:24 PM
> To: Michael Welzl; tcpm ([email-masked])
> Subject: Re: [tcpm] About the SYN/ACK-timer
> 
> I have an alternative to cookies.
> 
> Send data with the SYN.
> When retransmission of the SYN is required, retransmit it 
> without the data.
> Retransmit the SYN quickly: 100 to 200 mS.
> 
> It works with Middleboxes.
> SYN flood protection works as normal, just bias it against 
> SYN with data.
> 
> Cheers,
> Jakob.
> 
> On Dec 31, 2012, at 1:44 AM, "Michael Welzl" 
> <[email-masked]> wrote:
> 
> > Hi,
> > 
> > About data-in-the-SYN: I agree with Joe that this has been 
> debated a 
> > lot already - see 
> > https://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 and the 
> > discussions surrounding it. FWIW this draft is a (IMHO, 
> good) proposal 
> > to do what you want, in the right way
> > 
> > Cheers,
> > Michael
> > 
> > 
> > On Dec 30, 2012, at 10:17 PM, Joe Touch <[email-masked]> wrote:
> > 
> >> 
> >> 
> >> On Dec 30, 2012, at 11:23 AM, Jakob Heitz 
> <[email-masked]> wrote:
> >> 
> >>> On Dec 30, 2012, at 10:46 AM, "Joe Touch" <[email-masked]> wrote:
> >>>> 
> >>>> ...if it is to have any real effect. You can send data 
> in the SYN now, but the server can't deliver it to the app 
> layer until the three-way handshake completes. And it also 
> increases the amount of state for pending connections, 
> increasing the impact of DOS attacks.
> >>>> 
> >>>> Joe
> >>> 
> >>> It could, with a change to the sockets API.
> >> 
> >> No, it cannot without a change in CTO semantics, which 
> affects the state diagram and its processing on both ends - 
> which also changes the meaning of an ack and the concept of 
> reliability. 
> >> 
> >> There is a lot required, and for the first connection to a 
> site it won't work to allow the server to act on data before 
> a connection has been established. 
> >> 
> >> This is well- trod ground. 
> >> 
> >> Joe
> >> 
> >>> Of course, the app will need to participate in SYN flood 
> protection, but that's not impossible given the right architecture.
> >>> 
> >>> --
> >>> Jakob Heitz.
> >>> 
> >> _______________________________________________
> >> tcpm mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/tcpm
> > 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 1 Jan 2013 15:52:48 +0000

It's only a SYN. There aren't lots of those. And they're really small.
How about make the first SYN retransmission at 100mS and the next one at 1.1 second?

Cheers,
Jakob.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 1 Jan 2013 17:13:19 +0100

100ms would imply that we send two SYNs for most inter-continental TCP connections. I am still to be convinced that there is a real benefit of that redundancy.

If so, then let's be honest and call it "FEC scheme" - not getting an ACK after 100ms is clearly not a sign of loss in the current Internet.

Also, SYNs are actually not so "cheap", imho. They typically cannot be processed in the "fast path" of a TCP stack (for in-sequence data segments w/o special flags), and middleboxes might care a lot about every single bit in SYNs... And let's not enter the discussion of byte vs. packet-based queues here...

For what it is worth, I guess that one could reduce the initial RTO below one second if an endsystem has chached RTT data to the same IP address. Maybe some stacks do this already these days? It is well-known that some stacks use own optimizations beyond RFC 6298.

Michael

> From: Jakob Heitz [mailto:[email-masked]] 
> Sent: Tuesday, January 01, 2013 4:53 PM
> To: Scharf, Michael (Michael)
> Cc: Michael Welzl; tcpm ([email-masked])
> On Jan 1, 2013, at 7:33 AM, "Scharf, Michael (Michael)" 
> <[email-masked]> wrote:
> 
> > Retransmission of the SYN without data is already 
> recommended in Section 4.2.2. of draft-ietf-tcpm-fastopen-02. 
> Also, draft-ietf-tcpm-fastopen-02 refers to RFC6298, i.e., 
> the 1s minimum RTO.
> > 
> > Thus, the novelty in this thread seems to be the suggestion 
> to use much smaller minimum or initial RTOs (100ms or 200ms), right?
> > 
> > I really wonder how this would work for over-buffered links 
> ("bufferbloat"), or, e.g., satellite links? IMHO, with a SYN 
> (or SYN/ACK) RTO of 200ms, we would send every SYN (or 
> SYN/ACK) three times, if we happen to run over a path with an 
> RTT of one second... On a narrowband link, this could be a 
> lot of overhead.
> > 
> > Michael
> > 
> > 
> > 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Jakob Heitz
> without the 
> >> data.
> SYN with 
> >> data.
> >> in the SYN now, but the server can't deliver it to the app layer 
> >> until the three-way handshake completes. And it also increases the 
> >> amount of state for pending connections, increasing the 
> impact of DOS 
> >> attacks.
> >>>>>> 
> >>>>>> Joe
> >>>>> 
> >> affects the state diagram and its processing on both ends - which 
> >> also changes the meaning of an ack and the concept of reliability.
> >>>> 
> >> site it won't work to allow the server to act on data before a 
> >> connection has been established.
> >>>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 1 Jan 2013 18:24:44 +0100 (CET)

On Tue, 1 Jan 2013, Scharf, Michael (Michael) wrote:

> ("bufferbloat"), or, e.g., satellite links? IMHO, with a SYN (or 
> SYN/ACK) RTO of 200ms, we would send every SYN (or SYN/ACK) three times, 
> if we happen to run over a path with an RTT of one second... On a 
> narrowband link, this could be a lot of overhead.

I believe the only way to handle all the cases is for each end to somehow 
"learn" that it's on a certain type of link (some kind of heuritics), and 
tell the other end about it.

I see no way to optimize TCP for all cases ranging from multisecond RTT 
low bw connections up to future 100GE attachement over high RTT links, to 
rate-limited/policed medium-bw links, to 3GPP HSPA networks that might be 
high-bw but that might have initial 1-2 second "stop" in the communication 
with a then-rush of packets as radio resources are done negotiating, 
without telling the other end about what kind of access it's on.

I don't know if this falls into a "minor" modification of TCP or not, but 
without this, TCP is not going to behave as well as it could for a lot of 
cases.

If we keep RTT for a certain destination and tell the other end that we're 
on a ETTH connection policed to approximately 20 megabit/s and what RTT 
we're expecting to see (ie no change in RTT over time, throttling will be 
done via dropping of packets, no significant buffering), then that other 
end can treat traffic in a whole different way compared to if we're on a 
low-bw link with a lot of buffering where RTT will change wildly over time 
depending on buffer fill.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: David Borman <[email-masked]>
Date: Wed, 2 Jan 2013 21:00:23 +0000

On Dec 30, 2012, at 12:16 PM, Jakob Heitz <[email-masked]> wrote:
...
> BTW, I think the SYN packet should include data. A simple change to the sockets API should do it.

We've been down this road before with T/TCP.  In a nut-shell, sending data in the SYN doesn't buy you anything, because, as has already been stated, the other side can't deliver it until the 3-way handshake completes. T/TCP is how you make that data immediately available.  The challenge is knowing that you can trust that the data is safe to be delivered before completing the 3-way handshake.  If you have to wait for the 3-way handshake, there's really not much savings over sending the data with the final ACK.

			-David Borman

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 2 Jan 2013 21:13:47 +0000

On Wednesday, January 02, 2013 1:00 PM, David Borman <mailto:[email-masked]> wrote:

> We've been down this road before with T/TCP.  In a nut-shell,
> sending data in the SYN doesn't buy you anything, because, as
> has already been stated, the other side can't deliver it
> until the 3-way handshake completes. T/TCP is how you make
> that data immediately available.  The challenge is knowing
> that you can trust that the data is safe to be delivered
> before completing the 3-way handshake.

This is not universally the case.

In many cases, it doesn't matter and TCP can deliver
before the 3-way handshake.

For the case where it does matter, the data can be retransmitted
with the final ACK.

Flood protection is not difficult. Just fall back to SYN only.

-- 
Jakob Heitz.

---

From: David Borman <[email-masked]>
Date: Wed, 2 Jan 2013 22:07:16 +0000

> before the 3-way handshake.

That would, of course, depend on the application, and what, if any, damage would be done by receiving replicated, forged or flood of SYN packets.

TCP was designed to provide a reliable two-way byte-stream between two endpoints.  The 3-way handshake is the first step in that reliability.  By delivering data before having gone into established state, you are short-circuting that reliability, and the application has to be prepared for that.  You can achieve the same immediacy of data delivery by using UDP instead of TCP, but UDP forces the application to do more work if there's need for more than just a simple message-response system, especially for more data than will fit into a single UDP packet.  In a sense, putting data into the SYN and SYN/ACK is creating a UDP/TCP hybrid, the initial immediacy and reliability of UDP with the byte-stream handling of TCP.

As long as the application understands the underlying service, there's no problem.

If you are going to put data into the SYN and allow it to be immediately delivered, there is no reason to not also allow a FIN to go into the SYN.  Then the whole TCP connection could be accomplished with just:

	Send: SYN-data-FIN
	Receive: SYN-ACK(of-FIN)-data-FIN
	Send: ACK(of-FIN)

It's UDP with TCP data handling.  I'm not saying it's a bad thing, let's just call it what it is.

			-David Borman