IETF Logo Mail Archive

Re: [tcpm] new version of 2988bis

Yuchung Cheng <ycheng@google.com> Tue, 04 January 2011 00:54 UTC

Return-Path: <ycheng@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 899AB3A67E3 for <tcpm@core3.amsl.com>; Mon, 3 Jan 2011 16:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.059
X-Spam-Level:
X-Spam-Status: No, score=-104.059 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 xMNpzyNyoT-T for <tcpm@core3.amsl.com>; Mon, 3 Jan 2011 16:54:43 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A97523A67E1 for <tcpm@ietf.org>; Mon, 3 Jan 2011 16:54:43 -0800 (PST)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p040uoJm027308 for <tcpm@ietf.org>; Mon, 3 Jan 2011 16:56:50 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294102610; bh=jMEo/y8uU4+39CocaGLbjjV1fGQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=xTbOi6IM4B4Wn8eBt1GBjB+kgr1eBJIb1bpaIhBwOhu6rwbdFBShCgNkCt17vzNuC QpAa8lo0u3ZWj5H8w4BgA==
Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by wpaz5.hot.corp.google.com with ESMTP id p040umV3009380 for <tcpm@ietf.org>; Mon, 3 Jan 2011 16:56:49 -0800
Received: by qwe5 with SMTP id 5so17247005qwe.40 for <tcpm@ietf.org>; Mon, 03 Jan 2011 16:56:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=BI77fQXf26FD1zhmxdnrc003RKvNzjGGOmvnTJ3wcWo=; b=jpJDPDgMOOW97U8ZaBxhIcyl9C45aUe39KOdngNFF3pp1HCCOXyDZdg7KaTsFt7fl2 okFDjF/Cddh5u+VlvM/Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=EfnaXMPBMuQc0KPlDQ8R851Vt8t8Tdy3PDfHkmvipt0/hvk9HnsVRzHmEhyOXZNB88 bLqiGuMHxabtXnaCKvEg==
Received: by 10.224.28.210 with SMTP id n18mr19860648qac.191.1294102608660; Mon, 03 Jan 2011 16:56:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.59.65 with HTTP; Mon, 3 Jan 2011 16:56:27 -0800 (PST)
In-Reply-To: <AANLkTimTJSGMOuay10krCjJbu6pPnoGFuirz_Q3_tk0F@mail.gmail.com>
References: <20101207033356.439642715136@lawyers.icir.org> <AANLkTimTJSGMOuay10krCjJbu6pPnoGFuirz_Q3_tk0F@mail.gmail.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 03 Jan 2011 16:56:27 -0800
Message-ID: <AANLkTind7iG+GVU3LRWiUkMwG3cxeh-MgDZpd3=r2V+w@mail.gmail.com>
To: "Per Hurtig (work)" <per.hurtig@kau.se>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
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, 04 Jan 2011 00:54:46 -0000

Hi Per,

The author in [LS00] has a follow-up paper claiming this problem turns
out to be a feature. It might be worthwhile to address this part in
the proposal.

"The peak-hopper: a new end-to-end retransmission timer for reliable
unicast transport"
http://www.ieee-infocom.org/2004/Papers/52_3.PDF

Section II, subsection B. The implicit RTO offset:

In previous work, we had identified this as a “bug” [LS00],
but our analysis in this study has convinced us that this is
actually a feature. This “responsive safety margin”
compensates for the problems explained in the following two
sub-sections, and especially for the sluggish response to delay
spikes often avoids spurious timeouts. It is important to note,
though, that this safety margin does not exist for highly
interactive applications where often only a single packet is in
flight.


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