Re: [tcpm] TCP tuning
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tcpm] TCP tuning



On Wed, Feb 3, 2010 at 10:39 AM, Biswas, Anumita
<Anumita.Biswas at netapp.com> wrote:
>
>
>> -----Original Message-----
>> From: Jerry Chu [mailto:hkchu at google.com]
>> Sent: Wednesday, February 03, 2010 10:21 AM
>> To: Michael Welzl
>> Cc: tcpm at ietf.org WG
>> Subject: Re: [tcpm] TCP tuning
>>
>>
>> Michael,
>>
>> On Wed, Feb 3, 2010 at 6:42 AM, Michael Welzl
>> <michawe at ifi.uio.no> wrote:
>> > Hi all,
>> >
>> > (sorry if this is a bit off topic, as the mentioned presentation is
>> > mainly about using a larger initial window)
>> >
>> > In the context of the discussion that Jerry brought up on parameter
>> > tuning, one question that was raised was the initial RTO during the
>> > SYN - SYN/ACK exchange. I understand that we can't
>> recommend to resend
>> > SYN's more aggressively because this might cause a server to be
>> > overloaded with SYN's, but why do we have to wait extremely
>> long until
>> > we resend SYN/ACKs?
>> >
>> > Back then, when I asked, I got no answer. Both Jerry and I
>> pointed to
>> > our measurement results which show that the effect is nonneglible.
>>
>> Actually Mark Allman, Vern Paxon and I have been working on
>> revising RFC2988 to reduce the initial RTO from 3secs to
>> 1sec. Will submit the proposal soon!
>>
> This implies that this proposal brings the intial RTO value to be equal to the minimum RTO value of 1 second. Is this true?

Correct.

>
> I am going by RFC 2988, section 2, 2.4. It explicitly states this:
>
> " (2.4) Whenever RTO is computed, if it is less than 1 second then the
>         RTO SHOULD be rounded up to 1 second.
>
>         Traditionally, TCP implementations use coarse grain clocks to
>         measure the RTT and trigger the RTO, which imposes a large
>         minimum value on the RTO.  Research suggests that a large
>         minimum RTO is needed to keep TCP conservative and avoid
>         spurious retransmissions [AP99].  Therefore, this
>         specification requires a large minimum RTO as a conservative
>         approach, while at the same time acknowledging that at some
>         future point, research may show that a smaller minimum RTO is
>         acceptable or superior."
>
> Is it time to reconsider a smaller minimum RTO as well?

Yes this is the 3rd item on my todo list
(see http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf) but is not
nearly as important as the first two IMO.

Jerry

>
>
>
>
>
>
>> Best,
>>
>> Jerry
>>
>> >
>> > So I'll use this chance to ask again  :-)
>> >
>> > Cheers,
>> > Michael
>> >
>> >
>> > On Feb 3, 2010, at 3:28 PM, Lars Eggert wrote:
>> >
>> >> Hi,
>> >>
>> >> Jerry Chu has recently started the discussion on whether
>> we need to
>> >> think about tweaking TCP for the "modern Internet." Just
>> came across
>> >> another presentation from (AFAICT) another corner of Google that
>> >> makes similar arguments.
>> >>
>> >> FYI:
>> >>
>> http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Chang
>> >> ing_TCP_Slow_Start.pdf
>> >>
>> >> This topic seems to be gaining momentum, and the WG should
>> take some
>> >> time considering if there is work here for it.
>> >>
>> >> Lars_______________________________________________
>> >> tcpm mailing list
>> >> tcpm at ietf.org
>> >> https://www.ietf.org/mailman/listinfo/tcpm
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm at ietf.org
>> > https://www.ietf.org/mailman/listinfo/tcpm
>> >
>> _______________________________________________
>> tcpm mailing list
>> tcpm at ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.