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

From: Mark Allman <[email-masked]>
Date: Tue, 01 Jan 2013 21:53:50 -0500

I am confused.

> Not sure about everyone else, but the way I interpreted (and meant)
> the 1s bit was to say "a new value, such as 1s, as opposed to a
> complex adaptive mechanism". It wasn't about the exact value of 1s per
> se. 

You say "a new value, such as 1s".  My point is 1s is NOT a new value.
It is the standardized value.  Before proposing some new value, it'd at
least be handy if folks understood the current value.

> About lowering the initial RTO further: I, for one, hadn't thought of
> that, and am not fully aware of all the pro's and con's. But yeah, it
> might be worth considering? 

Well, if you're not suggesting lowering the initial RTO then what are
you suggesting?  I have no idea what you are saying here.  The initial
RTO is the RTO that is used before an RTT sample is taken.  So, just
what are you suggesting here?

allman

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 2 Jan 2013 05:25:14 +0000

On Tuesday, January 01, 2013 6:54 PM, [email-masked] <mailto:[email-masked]> wrote:

>> complex adaptive mechanism". It wasn't about the exact value of 1s
>> per se.
> 

I am suggesting:
1st SYN contains data.
Retransmit that SYN without data after 100mS.
Make the next retransmit timer 1 second with the normal power of 2 backoff after that. All SYN retransmits without data.
Do the same for the SYN/ACK.
No cookies.
The initial 100mS SYN retransmit timer MAY be lengthened by application knowledge of conditions. For example, satellite or wireless.

-- 
Jakob Heitz.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 1 Jan 2013 23:32:16 -0800

Hi Jakob,

On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz <[email-masked]>wrote:

> Make the next retransmit timer 1 second with the normal power of 2 backoff
> after that. All SYN retransmits without data.
> The initial 100mS SYN retransmit timer MAY be lengthened by application
> knowledge of conditions. For example, satellite or wireless.

I think you consider 1 second SYN RTO is fine. But, you want to accelerate
the first retransmission.
This seems to be a bit inconsistent design to me.
Well, it might be useful if the SYNs are discarded because of accidental
packet drops or because of data payload.
But, I'm still wondering how practical these situations are.

Thanks,
--
Yoshifumi

---

From: Michael Welzl <[email-masked]>
Date: Wed, 2 Jan 2013 08:52:32 +0100

> least be handy if folks understood the current value.

Sorry for that. I had missed the change to 1s, and so, when someone said "shorter value, such as 1s", I said "yeah, something like that".

> what are you suggesting here?

Sorry again for the confusion. I called it a SYN-ACK timer, but of course that's the initial RTO. So yes, the idea was to lower that - but I'd first have to look into the arguments that went into the 3s => 1s step which I had missed.

Cheers,
Michael

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 2 Jan 2013 08:53:27 +0000

The reason for the accelerated first retransmission:
The SYN with data may get dropped for 2 reasons.
1. Middleboxes that consider it abnormal.
2. SYN flood protection at the server.

I expect SYN flood protection to be much more aggressive towards SYN packets with data.
In the majority of cases, the SYN with data should get through just fine. When it doesn't, the accelerated retransmission without the data will recover.

Cheers,
Jakob.

On Jan 1, 2013, at 11:32 PM, "Yoshifumi Nishida" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz <[email-masked]<mailto:[email-masked]>> wrote:

I am suggesting:
1st SYN contains data.

I think you consider 1 second SYN RTO is fine. But, you want to accelerate the first retransmission.
This seems to be a bit inconsistent design to me.
Well, it might be useful if the SYNs are discarded because of accidental packet drops or because of data payload.
But, I'm still wondering how practical these situations are.　

Thanks,
--
Yoshifumi

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 2 Jan 2013 10:35:35 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jakob Heitz
> Sent: Wednesday, January 02, 2013 9:53 AM
> To: Yoshifumi Nishida
> Cc: Joe Touch; tcpm ([email-masked]); Marco Mellia; Michael 
> Welzl; [email-masked]
> Subject: Re: [tcpm] About the SYN/ACK-timer
> 

If there is such a middlebox, the best solution is to try to learn that and cache it, on order to avoid the use of SYN data at all. This is mostly orthogonal to the retransmission timer. Except for one detail: The smaller the gap between the two transmissions, the higher is the risk of reordering, i. e., that such heuristics break because the RTO is *too* small. Thus, accelerated first retranmission can indeed have drawbacks with middleboxes... And, with an initial RTO of 1s, the only penalty is the 1s timeout for the first connection. After that, the sender would hopefully not use SYN data any more.

So, what remains is the 1s RTO for the first connection to that destination. An initial timeout below one second to an unknown destination comes along with quite some risk of spuriour retransmission on narrow-band links. It might not be a too good idea because of that.

> 2. SYN flood protection at the server.

I might miss something fundamental, but if a server is in SYN flood protection mode, would it not be a good idea if the client backs off a bit? Using a 100ms timer is quite the opposite of that.

In summary, it is not clear to me what actual problem we discuss here.

For what it is worth, as already mentioned multiple times: There is a TCPM working group item draft-ietf-tcpm-fastopen, which has quite some related text, including the initial RTO.

Michael

> In the majority of cases, the SYN with data should get 
> through just fine. When it doesn't, the accelerated 
> retransmission without the data will recover.
> 
> Cheers,
> Jakob.
> 
> On Jan 1, 2013, at 11:32 PM, "Yoshifumi Nishida" 
> <[email-masked]> wrote:
> 
> 
> 
> 	Hi Jakob,
> 	
> 	
> 	On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz 
> <[email-masked]> wrote:
> 	
> 
> 		On Tuesday, January 01, 2013 6:54 PM, 
> [email-masked] <mailto:[email-masked]>  
> <mailto:[email-masked]> wrote:
> 		
> 		> I am confused.
> 		>
> 		> It is the standardized value.  Before 
> proposing some new
> 		> value, it'd at
> 		Make the next retransmit timer 1 second with 
> the normal power of 2 backoff after that. All SYN retransmits 
> without data.
> 		The initial 100mS SYN retransmit timer MAY be 
> lengthened by application knowledge of conditions. For 
> example, satellite or wireless.
> 
> 
> 	I think you consider 1 second SYN RTO is fine. But, you 
> want to accelerate the first retransmission. 
> 	Well, it might be useful if the SYNs are discarded 
> because of accidental packet drops or because of data payload.

---

From: Marco Mellia <[email-masked]>
Date: Wed, 02 Jan 2013 14:30:29 +0100

FYI, here are some old slides on the topic
http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf
and here you can find how to play with the initial RTO on MS Windows
http://support.microsoft.com/kb/170359/en-us
and more tweaks are here
http://technet.microsoft.com/en-us/library/cc739819(v=ws.10).aspx

Honestly, 1s as initial RTO seems a good and safe choice. Going below 1s 
as default value seems really not a good idea, especially considering 
that from the user perspective, little is gained.

The "SYN with data" looks like a very complicated stuff, that in most of 
the cases would allow to gain 10ms or so (i.e., one RTT), with a lot of 
problems that will arise with incompatible middleboxes, incompatible 
implementation, etc.etc. To me it seems not worth.
Consider this my 2c tip.
Ciao
M

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

-- 
Ciao,                    /\/\/\rco

+-----------------------------------+
| Marco Mellia - Assistant Professor|
| Skypeid: mgmellia                 |
| Tel: +39-011-090-4173             |
| Cel: +39-331-6714789              |   /"\  .. . . . . . . . . . . . .
| Politecnico di Torino             |   \ /  . ASCII Ribbon Campaign  .
| Corso Duca degli Abruzzi 24       |    X   .- NO HTML/RTF in e-mail .
| Torino - 10129 - Italy            |   / \  .- NO Word docs in e-mail.
| http://www.telematica.polito.it   |        .. . . . . . . . . . . . .
+-----------------------------------+
The box said "Requires Windows 95 or Better." So I installed Linux.

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 2 Jan 2013 18:57:17 +0000

On Wednesday, January 02, 2013 1:36 AM, Scharf, Michael (Michael) <> wrote:

>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Jakob Heitz Sent: Wednesday, January 02, 2013 9:53 AM
>> To: Yoshifumi Nishida
>> Cc: Joe Touch; tcpm ([email-masked]); Marco Mellia; Michael Welzl;
>> [email-masked] Subject: Re: [tcpm] About the SYN/ACK-timer
>> 
> If there is such a middlebox, the best solution is to try to
> learn that and cache it, on order to avoid the use of SYN
> data at all.

Of course it is, but there is no need to standardize that.

> This is mostly orthogonal to the retransmission
> timer. Except for one detail: The smaller the gap between the
> two transmissions, the higher is the risk of reordering, i.
> e., that such heuristics break because the RTO is *too*
> small. Thus, accelerated first retranmission can indeed have
> drawbacks with middleboxes...

no.
It will pass the lone SYN (misordered, arrives first)
Then it will drop the SYN with data.
No harm done.

> And, with an initial RTO of 1s,
> the only penalty is the 1s timeout for the first connection.
> After that, the sender would hopefully not use SYN data any more.
> 
> So, what remains is the 1s RTO for the first connection to
> that destination. An initial timeout below one second to an
> unknown destination comes along with quite some risk of
> spuriour retransmission on narrow-band links. It might not be
> a too good idea because of that.
> 
> I might miss something fundamental, but if a server is in SYN
> flood protection mode, would it not be a good idea if the
> client backs off a bit?

During SYN flood protection, I'm assuming the server will
aggressively drop SYN with data, but accept SYN without data
more readily.
Therefore, retransmit the SYN without data, then back off
as normal.

> Using a 100ms timer is quite the
> opposite of that.
> 
> For what it is worth, as already mentioned multiple times:
> There is a TCPM working group item draft-ietf-tcpm-fastopen,
> which has quite some related text, including the initial RTO.

I'm aware of it.
I don't like the cookie idea.
It was a great initial idea, but got complicated
and incomplete in a hurry.

I am not proposing an initial RTO of 100mS.
I am proposing a single retransmission of the SYN without data
at 100mS. There is a difference.

>> 		> least be handy if folks understood the current value. 		>
>> 		without data. Do the same for the SYN/ACK.
>> 		No cookies.

-- 
Jakob Heitz. x25475. 510-566-2901

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 2 Jan 2013 11:45:46 -0800

> aggressively drop SYN with data, but accept SYN without data
When syn-cookie is activated in Linux, upon receiving SYN-data the
server sends SYN-ACK acking only the initial/SYN sequence (i.e., it
drops the data part only). Upon receiving the SYN-ACK, the client will
retransmit the data in the final ACK of the handshake. The proposed
shorter SYN-retransmit w/o data in TFO does not help assuming no
network drops.

HTH

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 2 Jan 2013 20:35:17 +0000

> shorter SYN-retransmit w/o data in TFO does not help assuming no

I am assuming an upgraded stack once SYN with data becomes
a common thing to do.

However, you confirm that the scheme will work with
current code too.

-- 
Jakob Heitz.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 3 Jan 2013 00:28:07 +0100

> > If there is such a middlebox, the best solution is to try to learn 
> > that and cache it, on order to avoid the use of SYN data at all.
> 
> > This is mostly orthogonal to the retransmission timer. 
> Except for one 
> > detail: The smaller the gap between the two transmissions, 
> the higher 
> > is the risk of reordering, i.
> small. Thus, 
> > accelerated first retranmission can indeed have drawbacks with 
> > middleboxes...
> 
> no.
> It will pass the lone SYN (misordered, arrives first) Then it 
> will drop the SYN with data.
> No harm done.

Well, right for that case.

But if there is *no* middlebox (hopefully the default in the Internet), and if there is reordering, the sender sees that the SYN w/o data got through first (I guess that the SYN with data will have to be dropped). Therefore, the sender has to wrongly assume that there is a malicious middlebox. As a result, it will probably needlessly disable the use of SYN data for that path. If so, there is harm.

The whole point here is that this risk is probably higher for a gap of 100ms, compared to 1s.

> > So, what remains is the 1s RTO for the first connection to that 
> > destination. An initial timeout below one second to an unknown 
> > destination comes along with quite some risk of spuriour 
> > retransmission on narrow-band links. It might not be a too 
> good idea 
> > because of that.
> > 
> > I might miss something fundamental, but if a server is in SYN flood 
> > protection mode, would it not be a good idea if the client 
> backs off a 
> > bit?
> 
> Therefore, retransmit the SYN without data, then back off as normal.

Sure, it makes sense to drop SYN with data first.

But my concern is the overall increase of the server load that this early retransmission causes. For instance, consider a server that is flooded by SYNs and, as a result, the processing of a SYN may require some additional time, possibly resulting in an overall RTT larger than 100ms. If you then retransmit the SYN after 100ms, the load on the overloaded server is further increased, possibly by factor two, because every SYN is basically sent twice, and the server thus has to process twice the number of SYNs. That is independent of what exactly is done with SYN data.

Actually, in such a case it really matters why a server enters SYN flood protection, where the actual processing/resource bottlenecks are, etc. Maybe these are non-issues in practice. But it seems to require at least some careful thinking.

Michael

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 2 Jan 2013 23:59:37 +0000

On Wednesday, January 02, 2013 3:28 PM, Scharf, Michael (Michael) <> wrote:

>>> This is mostly orthogonal to the retransmission timer. Except for
>>> one detail: The smaller the gap between the two transmissions, the
>>> higher is the risk of reordering, i. e., that such heuristics break
>>> because the RTO is *too* small. Thus, accelerated first
>>> retranmission can indeed have drawbacks with middleboxes...
>> 
>> no.
> But if there is *no* middlebox (hopefully the default in the
> Internet), and if there is reordering, the sender sees that
> the SYN w/o data got through first (I guess that the SYN with
> data will have to be dropped). Therefore, the sender has to
> wrongly assume that there is a malicious middlebox. As a
> result, it will probably needlessly disable the use of SYN
> data for that path.

That would be old code.
Even then, it still works.

> If so, there is harm.
>>> retransmission on narrow-band links. It might not be a too good
>>> idea because of that. 
>>> 
>>> protection mode, would it not be a good idea if the client backs
>>> off a bit?
>> 
> But my concern is the overall increase of the server load
> that this early retransmission causes. For instance, consider
> a server that is flooded by SYNs and, as a result, the
> processing of a SYN may require some additional time,
> possibly resulting in an overall RTT larger than 100ms. If
> you then retransmit the SYN after 100ms, the load on the
> overloaded server is further increased, possibly by factor
> two, because every SYN is basically sent twice, and the
> server thus has to process twice the number of SYNs. That is
> independent of what exactly is done with SYN data.

Processing a duplicate SYN is even less work
than processing a new SYN.
This really is no drama.
The prolific use of multiple TCP connections
by browsers over several years has not dented the internet,
much less melted it down.

> 
> Actually, in such a case it really matters why a server
> enters SYN flood protection, where the actual
> processing/resource bottlenecks are, etc. Maybe these are
> non-issues in practice. But it seems to require at least some careful
> thinking. 
> 
> Michael

-- 
Jakob Heitz.