IETF Logo Mail Archive

Re: [tcpm] new version of 2988bis

"Per Hurtig (work)" <per.hurtig@kau.se> Wed, 29 December 2010 10:11 UTC

Return-Path: <per.hurtig@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210E43A68D3 for <tcpm@core3.amsl.com>; Wed, 29 Dec 2010 02:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7m8d3PnNeey for <tcpm@core3.amsl.com>; Wed, 29 Dec 2010 02:11:52 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 004F23A68BC for <tcpm@ietf.org>; Wed, 29 Dec 2010 02:11:51 -0800 (PST)
Received: by fxm9 with SMTP id 9so9786496fxm.31 for <tcpm@ietf.org>; Wed, 29 Dec 2010 02:13:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=DwKxMO1Ca69E3ER1l5mbXT8/wGxdI0R3/4DQ5KUWOPc=; b=mrsgHSHqBX7uEdege/97SkBxi3TJR9sxPuDSnJ6UEVPbIbOD6ZWUSjfz/MzR2Vlu3X 1Hy+VGpb25K6l7FsiFNNHHCAaov0X3S0VYKQmW0QEuNbCkXYf3lOP+lj76//US12/ADr 9htyiCwLmb92DSZP1yDCFW7OvMqQLJnNglW60=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=X/Ywe+/xcph8G9HZyTyL3lJLJdgLpRFPCJFlTDdETWG3yih4s1/lNbGus4T6CoQpjn xpFMtfjNmzdQRMYhQbRNXCWdV+2C8W5AbTmJUT+BCrPGo7x7hkN4CWQtuSPjtVD957U6 phKHsX6uyGUoO6k/Tp2YjuTRQ+L4s7xpt6fls=
MIME-Version: 1.0
Received: by 10.223.85.203 with SMTP id p11mr150350fal.108.1293617636778; Wed, 29 Dec 2010 02:13:56 -0800 (PST)
Sender: per.hurtig@gmail.com
Received: by 10.223.97.14 with HTTP; Wed, 29 Dec 2010 02:13:56 -0800 (PST)
In-Reply-To: <AANLkTinrS5fOt-HXfM7o4uLDCMzM4S5n_GDJa25Ho-XT@mail.gmail.com>
References: <20101207033356.439642715136@lawyers.icir.org> <AANLkTimTJSGMOuay10krCjJbu6pPnoGFuirz_Q3_tk0F@mail.gmail.com> <AANLkTinrS5fOt-HXfM7o4uLDCMzM4S5n_GDJa25Ho-XT@mail.gmail.com>
Date: Wed, 29 Dec 2010 11:13:56 +0100
X-Google-Sender-Auth: RJY5aS53Ex0f8Eavnmv6ut-u18Q
Message-ID: <AANLkTik7bOPiQhttTNCsSaS=jqDWpMebUWohaoFhuYoy@mail.gmail.com>
From: "Per Hurtig (work)" <per.hurtig@kau.se>
To: Jerry Chu <hkchu@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] new version of 2988bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Dec 2010 10:11:53 -0000

Hi,

we have not yet experimented with slow links, but we will. Maybe there
will be an
increased amount of unnecessary RTOs due to serialization delay, but
that will also
depend on:

* the RTOmin -- if set to 1s it will surely protect a subset of the
slow connections,
* and # of RTT samples per window -- if more than one sample, the RTT
variation could
  compensate for the serialization delay

Regards,

Per



On Tue, Dec 28, 2010 at 23:21, Jerry Chu <hkchu@google.com> wrote:
> Hi,
> Have you tried your proposed change on slow links (e.g., 56Kbps dialup)?
> Your proposal assumes RTTs for pkts in a burst are statistically independent
> of each other's existence. This may be true for fast links but not for
> slower links
> when the serialization delay dominates the round trip time for transmitting
> a
> packet. E.g., when you have a micro burst of n packets, the RTT for the m'th
> packet will include the serialization delay of itself and all the preceding
> packets.
> Your proposed change may cause a lot of spurious RTOs for later packets in a
> burst, including the ones in a large IW.
> The current paragraph in RFC2988 of restarting the RTO timer afresh upon
> each
> ack, although more conservative, limits the additive effect of serialization
> delay
> to the RTT to at most 2 packets (due to delayed acks).
> Best,
> Jerry
> On Wed, Dec 22, 2010 at 1:16 AM, Per Hurtig (work) <per.hurtig@kau.se>
> wrote:
>>
>> Hi all,
>>
>> we have submitted an I-D that summarizes an alternate way to restart
>> the TCP/SCTP RTO timer:
>>
>> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt
>>
>> The difference between this approach and RFC2988(bis)'s approach is
>> the way outstanding segments are
>> considered. We're happy to receive any comments on the draft.
>>
>>
>> Regards, Per H
>>
>>
>>
>>
>> On Tue, Dec 7, 2010 at 04:33, Mark Allman <mallman@icir.org> wrote:
>> >
>> > Folks-
>> >
>> > We posted a new version of the 2988bis I-D today.  It is:
>> >
>> >  draft-paxson-tcpm-rfc2988bis-01.txt
>> >
>> > The big change is a new set of empirical results that pertain to
>> > dropping the initial RTO from 3sec to 1sec is now given (along with the
>> > previous results from Google) in the appendix.  Generally speaking,
>> > these results show it is pretty safe to drop the initial RTO.
>> >
>> > Have a look.  I believe the authors are pretty happy with this document
>> > at this point.
>> >
>> > allman
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>
>

v2.23.0 | Report a Bug | By Email