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

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.

On Jan 1, 2013, at 7:33 AM, "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> wrote:

> 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: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
>> Behalf Of Jakob Heitz
>> Sent: Monday, December 31, 2012 8:24 PM
>> To: Michael Welzl; tcpm (tcpm@ietf.org)
>> 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" 
>> <michawe@ifi.uio.no> 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 <touch@isi.edu> wrote:
>>> 
>>>> 
>>>> 
>>>> On Dec 30, 2012, at 11:23 AM, Jakob Heitz 
>> <jakob.heitz@ericsson.com> wrote:
>>>> 
>>>>> On Dec 30, 2012, at 10:46 AM, "Joe Touch" <touch@isi.edu> 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
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm