Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft

hiren panchasara <hiren@strugglingcoder.info> Thu, 18 April 2019 17:53 UTC

Return-Path: <hiren@strugglingcoder.info>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE6312038C; Thu, 18 Apr 2019 10:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usBY_oNTkEPq; Thu, 18 Apr 2019 10:53:18 -0700 (PDT)
Received: from mail.strugglingcoder.info (unknown [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 67DAB12015E; Thu, 18 Apr 2019 10:53:18 -0700 (PDT)
Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id ED95117BF9; Thu, 18 Apr 2019 10:53:17 -0700 (PDT)
Date: Thu, 18 Apr 2019 10:53:17 -0700
From: hiren panchasara <hiren@strugglingcoder.info>
To: Neal Cardwell <ncardwell@google.com>
Cc: draft-ietf-tcpm-rack@ietf.org, Matt Olson <maolson@microsoft.com>, "tcpm@ietf.org" <tcpm@ietf.org>, Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>, Yuchung Cheng <ycheng@google.com>, Nandita Dukkipati <nanditad@google.com>, Priyaranjan Jha <priyarjha@google.com>
Message-ID: <20190418175317.GE45038@strugglingcoder.info>
References: <BL0PR2101MB104347EF7FC7CD5C86DF08B7C3250@BL0PR2101MB1043.namprd21.prod.outlook.com> <20190417181344.GM31257@strugglingcoder.info> <BYAPR21MB12568E60F973DB41C4905D8EBC250@BYAPR21MB1256.namprd21.prod.outlook.com> <20190417192202.GN31257@strugglingcoder.info> <CADVnQym8cSACWmbbOSugb-QRcxpuaYTVKGPD=XX5i0AQH8m-JQ@mail.gmail.com> <20190417211521.GA45038@strugglingcoder.info> <CADVnQymm3TpoySoiej2j8GP0=TAJBQ=o+tJYRod5VYVvhQjsNg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="Ns7jmDPpOpCD+GE/"
Content-Disposition: inline
In-Reply-To: <CADVnQymm3TpoySoiej2j8GP0=TAJBQ=o+tJYRod5VYVvhQjsNg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/eeR03oRFFpFh37Q00rEf2FXmn_Q>
Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 18 Apr 2019 17:53:20 -0000

On 04/18/19 at 09:18P, Neal Cardwell wrote:
> On Wed, Apr 17, 2019 at 5:15 PM hiren panchasara
> <hiren@strugglingcoder.info> wrote:
> > I'll keep this to the point I thought got missed.
> >
> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-04.txt
> >
> > Is where we can see `Scheduling a loss probe` getting changed.
> > Specifically, following condition has been removed from -04:
> >
> >    3.  The connection is either limited by congestion window (the data
> >        in flight matches or exceeds the cwnd) or application-limited
> >        (there is no unsent data that the receiver window allows to be
> >        sent).
> >
> > And afaict, Linux code still has this condition in. If you can provide
> > some rationale behind this change, it'd be great.
> 
> We removed the code for that condition from Linux around 2017-12-13,
> in this commit (GPLv2 patch in this link):
>   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/net/ipv4/tcp_output.c?id=b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd
> 
> The commit description explains the rationale for removing that
> condition, but here is a paraphrased description of the rationale for
> removing that code and that condition in the draft:
[skip]

Thanks a lot. This makes sense.
Apologies for misreading the code.

Cheers,
Hiren