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

["Scharf, Michael (Michael)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Jakob Heitz
> Sent: Wednesday, January 02, 2013 9:53 AM
> To: Yoshifumi Nishida
> Cc: Joe Touch; tcpm ([e-mail]); Marco Mellia; Michael 
> Welzl; [e-mail]
> Subject: Re: [tcpm] About the SYN/ACK-timer
> 
> The reason for the accelerated first retransmission:
> The SYN with data may get dropped for 2 reasons.
> 1. Middleboxes that consider it abnormal.

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

 
> 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" 
> <[e-mail]> wrote:
> 
> 
> 
> 	Hi Jakob,
> 	
> 	
> 	On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz 
> <[e-mail]> wrote:
> 	
> 
> 		On Tuesday, January 01, 2013 6:54 PM, 
> [e-mail] <mailto:[e-mail]>  
> <mailto:[e-mail]> wrote:
> 		
> 		> 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
> 		
> 		
> 		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.
> 
> 
> 	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
> 
>