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

On Wed, Jan 2, 2013 at 10:57 AM, Jakob Heitz <jakob.heitz@ericsson.com> wrote:
> On Wednesday, January 02, 2013 1:36 AM, Scharf, Michael (Michael) <> wrote:
>
>>> -----Original Message-----
>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf
>>> Of Jakob Heitz Sent: Wednesday, January 02, 2013 9:53 AM
>>> To: Yoshifumi Nishida
>>> Cc: Joe Touch; tcpm (tcpm@ietf.org); Marco Mellia; Michael Welzl;
>>> mallman@icir.org 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.
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

> 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"
>>> <nishida@sfc.wide.ad.jp> wrote:
>>>
>>>
>>>
>>>      Hi Jakob,
>>>
>>>
>>>      On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz
>>> <jakob.heitz@ericsson.com> wrote:
>>>
>>>
>>>              On Tuesday, January 01, 2013 6:54 PM,
>>> mallman@icir.org <mailto:mallman@icir.org>
>>> <mailto:mallman@icir.org> 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
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm