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

100ms would imply that we send two SYNs for most inter-continental TCP connections. I am still to be convinced that there is a real benefit of that redundancy.

If so, then let's be honest and call it "FEC scheme" - not getting an ACK after 100ms is clearly not a sign of loss in the current Internet.

Also, SYNs are actually not so "cheap", imho. They typically cannot be processed in the "fast path" of a TCP stack (for in-sequence data segments w/o special flags), and middleboxes might care a lot about every single bit in SYNs... And let's not enter the discussion of byte vs. packet-based queues here...

For what it is worth, I guess that one could reduce the initial RTO below one second if an endsystem has chached RTT data to the same IP address. Maybe some stacks do this already these days? It is well-known that some stacks use own optimizations beyond RFC 6298.

Michael

> -----Original Message-----
> From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] 
> Sent: Tuesday, January 01, 2013 4:53 PM
> To: Scharf, Michael (Michael)
> Cc: Michael Welzl; tcpm (tcpm@ietf.org)
> Subject: 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
> 