IETF Logo Mail Archive

Re: [tcpm] new version of 2988bis

Jerry Chu <hkchu@google.com> Tue, 28 December 2010 22:19 UTC

Return-Path: <hkchu@google.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 6F3363A68E8 for <tcpm@core3.amsl.com>; Tue, 28 Dec 2010 14:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Level:
X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=-3.823, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 U+6wtARKmHE7 for <tcpm@core3.amsl.com>; Tue, 28 Dec 2010 14:19:14 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 175063A68E7 for <tcpm@ietf.org>; Tue, 28 Dec 2010 14:19:13 -0800 (PST)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id oBSMLHsl024261 for <tcpm@ietf.org>; Tue, 28 Dec 2010 14:21:18 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293574878; bh=jjVOFdh5+z8DtArdnksYToVLX2s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ofp0bWDD8G8lYcfXQV+XW7iM7hnU1RBNxORo1XWux1KuIjUzthbQ+58YODvSNCjmU Mwg89bv4qNgISOqMyPU+Q==
Received: from gye5 (gye5.prod.google.com [10.243.50.5]) by wpaz33.hot.corp.google.com with ESMTP id oBSMKuYr030806 for <tcpm@ietf.org>; Tue, 28 Dec 2010 14:21:16 -0800
Received: by gye5 with SMTP id 5so4891521gye.18 for <tcpm@ietf.org>; Tue, 28 Dec 2010 14:21:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+VOoX8GuGL2/gmYHHYM/3nANYY2X8dVdJTPz7jbItpI=; b=RbtkOcxmmlI/9QiFc9G9szqT9yp7Te1KrJl9bV+vbJaPY3DCt2AD5XjO8B24dGkTKb b58BgGOPsUFNWfN/Gq8A==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tnGlqH94BupakUzdTuoyX73oUTW06s1i1n4x7jfFWW1zGihcd2A94s5znA94FId9jt KYuObmX0Y2JOiTOm4MJQ==
MIME-Version: 1.0
Received: by 10.150.218.21 with SMTP id q21mr18120343ybg.177.1293574876341; Tue, 28 Dec 2010 14:21:16 -0800 (PST)
Received: by 10.151.26.9 with HTTP; Tue, 28 Dec 2010 14:21:16 -0800 (PST)
In-Reply-To: <AANLkTimTJSGMOuay10krCjJbu6pPnoGFuirz_Q3_tk0F@mail.gmail.com>
References: <20101207033356.439642715136@lawyers.icir.org> <AANLkTimTJSGMOuay10krCjJbu6pPnoGFuirz_Q3_tk0F@mail.gmail.com>
Date: Tue, 28 Dec 2010 14:21:16 -0800
Message-ID: <AANLkTinrS5fOt-HXfM7o4uLDCMzM4S5n_GDJa25Ho-XT@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: "Per Hurtig (work)" <per.hurtig@kau.se>
Content-Type: multipart/alternative; boundary="000e0cd40650fea7c504987fde36"
X-System-Of-Record: true
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: Tue, 28 Dec 2010 22:19:15 -0000

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