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

[Jakob Heitz <[e-mail]>]

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

>> -----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.

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.
> 
>> 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?

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.
> 
> 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.

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.

> 
> 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



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