Re: [tcpm] A proposal for two-party adaptive initial congestion window

Mark Allman <mallman@icir.org> Tue, 07 December 2010 03:23 UTC

Return-Path: <mallman@icir.org>
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 669D028C0F5 for <tcpm@core3.amsl.com>; Mon, 6 Dec 2010 19:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.32
X-Spam-Level:
X-Spam-Status: No, score=-106.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 AYYeGZaTcwQC for <tcpm@core3.amsl.com>; Mon, 6 Dec 2010 19:23:39 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 1215928C0F6 for <tcpm@ietf.org>; Mon, 6 Dec 2010 19:23:29 -0800 (PST)
Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oB73OQMK016454; Mon, 6 Dec 2010 19:24:27 -0800 (PST)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BED2C2714F13; Mon, 6 Dec 2010 22:24:26 -0500 (EST)
To: Andrew Yourtchenko <ayourtch@cisco.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <Pine.GSO.4.64.1012032352260.17630@sweet-brew-7.cisco.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Tom Sawyer
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma43242-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 06 Dec 2010 22:24:26 -0500
Sender: mallman@icir.org
Message-Id: <20101207032426.BED2C2714F13@lawyers.icir.org>
Cc: tcpm@ietf.org, ananth@cisco.com
Subject: Re: [tcpm] A proposal for two-party adaptive initial congestion window
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
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, 07 Dec 2010 03:23:41 -0000

> https://datatracker.ietf.org/doc/draft-yourtchenko-two-party-initial-window/

I read through this.  I think its overkill and likely doesn't solve any
sort of real problem.  It at least doesn't offer any argument that it
does.  The basic idea is that we take the sender IW adaption scheme that
has been sketched on the list and augment it with receiver information.
So, then, several things:

  - The basic premise of the sender adaption scheme is to setup a
    tolerance for problems caused by the IW burst.  My sketch said 5%.
    I.e., an IW works if at least 95% of the IWs are sent without loss.
    (It could be 2% and still IW=10 would work according to the Google
    data.  As a data point.)  Given this, *at most* including receiver
    side information is only of assistance in a low percentage of the
    cases because that is the failure rate of the sender-side scheme.

  - The two party scheme supposes that the receiver has insight that
    would be helpful on picking an initial window.  That may or may not
    be the case.  We have no idea where the issues with larger IWs might
    crop up (sender, receiver or middle).  But, given that the issues
    are not likely to all be at the receiver this further chops down the
    cases where this two-party adaption could possibly have any impact.

  - If the receiver knows a peer sending a larger initial burst is going
    to cause problems then that receiver can advertise a smaller
    window.  It has a control that can be applied already.

  - Trying to tightly engineer the IW is pretty meaningless because even
    if you get the receiver to help the sender in choosing a proper
    value the sender is going to then double the cwnd and probably blow
    it in the next RTT if the path is really ratty.  We need something
    *reasonable* as an initial setting, not optimal.

  - I don't find the simulations in the document to be particularly
    insightful.  The efficacy of the mechanism is based on how often
    there are persistent problems that (a) will fall within the sender's
    tolerance for problems and (b) are at the receiver such that the
    receiver can alert the sender of the issues.  To figure that out
    would require an empirical study not a series of simulations.

And, a nit:

  - Your sketch of Quick Start is wrong.  If the entire path does not
    approve of a given rate then the sender falls back to the standard
    IW and *does not* "use the full proposed bandwidth".

FWIW.

allman