Re: [tcpm] Tuning TCP parameters for the 21st century

[Jerry Chu <[e-mail]>]

On Thu, Jul 16, 2009 at 1:39 AM, Michael Welzl<[e-mail]> wrote:
>> > - but what about retransmitting SYN/ACKs faster?
>> > Since the other side already sent a SYN, it probably
>> > isn't overloaded
>>
>> That presumes the other side already sent a SYN and it's been received,
>> and that the SYN/ACK is what's getting lost/delayed/retransmitted.  If
>> not, that won't help.
>
> Right -
>
>
>> First find where things are going wrong empirically ;-)
>
> We've done that. See, for example, fig. 2 (a) of
> http://www.welzl.at/research/publications/networking2009.pdf
> (page 7 of the pdf)
>
> Since our goal in this paper was to document general failures
> of connection setup, we did not strictly split our results
> into the case of lost SYNs or lost SYN/ACKs in it.
> Section 3 (end of page 3 / beginning of page 4) explains
> how lost SYN/ACKs were incorporated in our measurements.
>
>
> This paper is based on data produced by a student. The
> data are more thoroughly documented in his (alas, German)
> bachelor thesis. This document is here:
> http://www.welzl.at/research/tools/syn-retransmit/benjamin_kaser_bak1.pdf
> and the most relevant information is table 2 on page 47.
> (Table 1 is similar, just for SYNs, not SYN/ACKs).
>
> If you look at it, with or without German knowledge
> you will be able to see the connection to table 1 in
> the paper, where we exchanged columns with lines and
> omitted some details - apparently just the crucial
> ones  :-(    Anyway, the listed measurements are just
> the same, and hence you can read the details in the
> paper if you're interested in how we obtained our
> data.
>
> Table 2 on page 47 of the bachelor thesis has several
> details about duplicate SYN/ACKs that we've seen,
> e.g. classified by eventually successful and unsuccessful
> connections. As a quick summary, in 3432744 connection
> attempts, we have seen 56586 duplicate SYN/ACKs in total
> (this is a cumulative number, i.e. 4 SYN/ACKs are counted
> as 3). Counting only the occurrence of duplicate SYN/ACKs,
> we saw them for 0,55% of the 3432744 connection attempts.
> In general, the difference between duplicate SYN/ACK
> occurrences and duplicate SYN occurrences is negligible
> in our measurements.
>
> As I just looked at the data again, I noticed a mistake:
> in the paper, we wrote that the problem only happens for
> around 0.5% of the connections, but this is really only
> from the SYN table, not the SYN/ACK table in the bachelor
> thesis. The SYN/ACK table covers the same measurement sets.
> Hence, in total, it seems that we also saw > 1% lost SYNs
> *or* SYN/ACKs, which exactly matches what Jerry Chu said.
>
> BTW I maintain a small website about the whole thing:
> http://www.welzl.at/research/tools/syn-retransmit/index.html

Our overall pkt retransmission rate often goes over 1%. I was
wondering if SYN/SYN-ACK pkts are less likely to be dropped
by some routers due to their smaller size so we collected traces
and computed SYN-ACK retransmissions rate on some servers.
We confirmed it to be consistent with the overall pkt drop rate,
i.e., > 1% often.

FYI,

Jerry

>
> Cheers,
> Michael
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>