Re: [tcpm] [EXTERNAL] Re: Hystart and delay jitter

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Thu, 25 March 2021 07:40 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
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 266773A1412 for <tcpm@ietfa.amsl.com>; Thu, 25 Mar 2021 00:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.352
X-Spam-Level:
X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.251, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 zkixRZquuub5 for <tcpm@ietfa.amsl.com>; Thu, 25 Mar 2021 00:40:30 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30040.outbound.protection.outlook.com [40.107.3.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581833A1410 for <tcpm@ietf.org>; Thu, 25 Mar 2021 00:40:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bsAk0e1bP7d5hPRQrRKIy/vnRAiv01Q5wD2YxYitGDv8yl0iq8jLRAkUpZMtB+spR3VqyVr9e0PROEHFlpvEBNp/qUKF824jzrSHkwldNUh+CDXYmjRAsgxDZROxpFFjln6DhvXU2JXcoX7WI4wT+ZJqeAgqhdEMw+aBSRYpMV7bUj6xmS1B2JHC/gY4zlxRbwj44Qf/EE/dAHOFKaxokIEmvNnlOkHJFDV7SOOkEqwCAAX1CiNDx1zy0MSMNHmWGHueLWByr5YSCmtxyvif4RxxObh8kKf6O44PtalSBES6AnL1dPd0xfYsjv/whuDHM+5SBehLAFfBW5SXrR5Gvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q1x11G7s9NKYkZoVi9PvYc6PMIkitp80fWPciZpkKY4=; b=UxntWaxcRKR3R7DIyWZUirS+pHRJS/slyoIdoFi6wbZLZIwmFlrZUCnXSYushdVrOWlzbOMA5sQWe8S9f7wEkCCcLCLQLI1yemdZj+kc6tuyCcX53p96mxFXM4QNuaIVchZejtrjJbHvRuAVKCzvAUzxGedTHTaIy1w975KJ6VErEHe6rnvfdmF4O+jKjfb0b1dca8a5KA9ciODmM1K9ZlA3pjjhBRPcKSqnWBXq7Q8n/1+BIhxkkctWBZ9YrFskwk8/pv6C9ne2IrJi1cTIq9l1SoV6+Dw3jGFxScc10akYKmOE0vB8riSkBmNICajm6/5aljiNFPzn88IFDvNfEw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q1x11G7s9NKYkZoVi9PvYc6PMIkitp80fWPciZpkKY4=; b=XbUIYa/Zob4LyUAmMfmqbHaoW4anMrCAXuwXn6uhCBVOtL/DBejMV1/RjBnQE4gfWinWBK3kiJqB0c5U2atAlAVo2+U5Vrn1XI6x97beQI2wOMk0tIDZECDLDFyY3sbSsHRw/O1TPNI4Ee4q17T8IbDsanYaZ7956VX6LB8pl5s=
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com (2603:10a6:3:6c::8) by HE1PR0701MB2300.eurprd07.prod.outlook.com (2603:10a6:3:6f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.14; Thu, 25 Mar 2021 07:40:26 +0000
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::78cb:103b:9ddd:1850]) by HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::78cb:103b:9ddd:1850%7]) with mapi id 15.20.3977.026; Thu, 25 Mar 2021 07:40:26 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Christian Huitema <huitema@huitema.net>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Praveen Balasubramanian <pravb@microsoft.com>, "ncardwell=40google.com@dmarc.ietf.org" <ncardwell@google.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [tcpm] [EXTERNAL] Re: Hystart and delay jitter
Thread-Index: AQHXHzckRlKDqyN8Ekm6oKXLRC22n6qUSSkQ
Date: Thu, 25 Mar 2021 07:40:26 +0000
Message-ID: <HE1PR0701MB2299578F0983823C380DD87FC2629@HE1PR0701MB2299.eurprd07.prod.outlook.com>
References: <376bdc9f-4774-bfc8-1736-6c94fb24953c@huitema.net> <CADVnQymN6UH+XTgdkwdX16TsDTeeTu+S-=O1nVjQFWYbpDT24Q@mail.gmail.com> <CY1PR00MB01700C2168E1B4200BE23B34B6699@CY1PR00MB0170.namprd00.prod.outlook.com> <HE1PR0701MB229938341C5A909CB5664085C2689@HE1PR0701MB2299.eurprd07.prod.outlook.com> <3E80F724-7BCA-4DD2-BBEE-9D9B9E0B02FD@ericsson.com> <A34504B4-ACD0-49D5-AA05-FA918968A0D6@ericsson.com> <501f463e-3688-ce98-2842-0bb8134c5d27@huitema.net>
In-Reply-To: <501f463e-3688-ce98-2842-0bb8134c5d27@huitema.net>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: huitema.net; dkim=none (message not signed) header.d=none;huitema.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 47139b6b-582e-459e-66d1-08d8ef6141b4
x-ms-traffictypediagnostic: HE1PR0701MB2300:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB2300AA2802E99966D43B6452C2629@HE1PR0701MB2300.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2958;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Fb+Y06ck4v79A3JDkLYneqLD2d86hEJIhBNOu0mA5udbphxaLPrEyqRhcgenQyAKYQ8sDbRins07AoWa4LTiYq4re/MFn7pWzOv66/04rW/FJsyIDnjltj85g29uLDayXPz1ZAgQU5Ps1djmGiM3QoTD8GNUJ9LC9RXWtwbVQsNO8rwuQRfDyz+5RKlGv35eDtqLHJvJylQSBO6rFEixUlHQ5W12DveRqlb/LeKqbBaXMPMTOsHErJkL4NiAPTLXHjiLbedhiU2cHZuO5nE6Ln5N7EVsoNRS4zQ+1Y7xXZoGkJGiCsr1VYnH+YfVSxVfRfEwqwJCjm0HCokgXRIK6JT+jNKeyNuCmA3xtzkMkjfOAJmSRMze0u+0vQ6iPPzjROFqzvNZJfqB4WIDTjvq82MlCPPxaLZrKouxedTBXPZIVx5ZOZ7Ang0H/LLhAiT35rC6kiXfMRMvZE0ZePw5fmLeQExYv/pkHm8zmXmpl1Ee8/3QGWCUdTtUcY1L5eoYy5QdFJCC1rEnkkRaKgLQEt0biPLwjS4q4BQFWocFy1zuD2hpRwskSRIMEAw30KI4CPLSQ1DGFoD53LVqgTceOxLf74s3CTTcjUT5+tGoipBrzJcOQ/6eo8fEAKh53Yr5vWTlCaUqgO8nWHuvXz98NaUYqcskC4gnC38krhIRIjS/DBNRuXQHsePLsuLADBTwiO+KeeWXjgdvftnoMrF0NPzRo/eB8jOyFbkdOQzrEuspVBU/lu/D+bm59RLz9xWw
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2299.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(396003)(346002)(136003)(366004)(53546011)(71200400001)(45080400002)(966005)(6506007)(66556008)(76116006)(66946007)(7696005)(66616009)(86362001)(478600001)(38100700001)(55016002)(2906002)(8936002)(9686003)(33656002)(186003)(99936003)(110136005)(4326008)(316002)(83380400001)(54906003)(5660300002)(30864003)(26005)(64756008)(66476007)(107886003)(66446008)(8676002)(52536014)(491001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: X1n744pG7cA23C1j+6Vf54/Gt58p4Ts+nBZRjoL+7dtZR3qC4tPA/pfUmgwGvLMYmTGxwVYVnFTryYP/tnvmg5QRUA/wez1iCtCRsHPP+CCdYHVwzyzwpuw3bHhrcOzvRtDxOjRDNJOQ3Yw0KDtAKHdAyfgX7lZWeiUm6CGZ+KWmzTXS/NrYZASfeKahXgcM3qi0MESj0xaCsDyazHJH3UNSTY9C4CUYl+aBh3yorJR8MNZxOQKhiSCRZyAqRmGeeeLRrx+cq4sEim8/VS1gYQTnKcVXH8RnuIjwVWYsS4JeyBbrXK8FUoV3rG4jCk3avZOUxR2L2JEgW5BQX6afSmyMyTB0YNAK8rTgkGlTWjQd58Vul1PTl08hdQoRnTmnYbOVUEQgILcHqA1YHvrXqnCds8ZRHjsOiUpYzZF/eR2jRpgVEJAfoN0mRM9f6QkWoppQilTXozp9ye7jSMBKLtKkPkeTWGjOtAeUZcqfUr62Rgyqt4Kv63wOkVB7Vt3v7AR7+BKwMst6xxh3dH1UsdjHbqc5zS5roeJsCOQ82Q9ckofhkz5vQbBi3dR9cLUJV/XDQaZ1Q1OLesb8OYc5oEz4YfRe9KObvsH+o4qiXwa3pVD0PbW9l4LPlyQMA9CTRb6ODrfS05MZ17we9fuvaeyXlWpCBtu2VwfAE6oqF/OM8gKyTQEzW9ZcJzn7sbnNaEQfz8mq4pBMuEvQwRwEFrL2KpACR0vVejKE0Zsji8dGYamFZVakrwHLMtCb4sPpTWZTNLJ1grqqlIbfrWsAFvsXxVQjlaXlvhHWoIaSFyk900vclFMANwMEvpxMCg6Ac8uU6SlakCgBOOPNoxNzeKXigTpAWL4/kFg4bIOEaKsfkzR8CwAOI+2nGEoJ0RLPZXiIggJyGiOa9borKA+EZ2MF9k+g4ozFXz9Kni7AQEXfep6bSozNB83dGVGEPkrnlt25wDv25BoE4e6R5p2FipVFvi6pzjvj+CUk/l/V6qvoqLVjn+cJIrAod7UcFtaY6Y/I0l83jIBIHBgP3LACwZSOXnJM8kvnZndaQSnAHG2V3KX6LnxNMQUZRKoRv7xHh6M8OzlOkuyOsRLEpBlxM/UqDf+JjSXJp++MULdE8NGga4QVZJ1/3xlYVdt0w8C3+LWuHH579JtWCjWP4xlE5K29/ljpk8zWjhnihGQJ99ZTGt0dvrmaZ7wmZ42aiZ9hMQE4ejLw5QN0Q3zUQIW9ur6We1uRUjoop5mrpAAqfoU6u948bjOwxU8XD09nlIOccSekqW4icix01UBt6IaZmnU/itHw4hLrgc9MwkeMeOgyC7YF2Vmy3gBfbWxifp6k
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0289_01D72152.8020FF40"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2299.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47139b6b-582e-459e-66d1-08d8ef6141b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2021 07:40:26.4903 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Di4kR9jGpxX2GUB9l0Mq//1gcBDAhLZSUzwbZSDdm5oRhn0qdrmS0h2Y/JPgkQvrql9CpyWplu6qR1U60nsiFb1MUPbMCRpC8h7dt1c9aHTdrIatAlgwVxaUKDFOTeBm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2300
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/HZxP0cHecfWMuflmDEHwiO7a9xg>
Subject: Re: [tcpm] [EXTERNAL] Re: Hystart and delay jitter
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, 25 Mar 2021 07:40:36 -0000

Hi Christian, Mirja, Praveen, Neil + others

We use an a proprietary 5G simulator in our work that simulates the protocol stack down to the physical layer. In addition we of course have the real gear set up in a number of labs where we can try out different combinations of UE (phones) and base stations.

I am not sure about the capabilities of other open source simulators like NS3, NS3 appears to have an LTE module at least. I don't know how well it models reality however.

More inline 

/Ingemar

> -----Original Message-----
> From: Christian Huitema <huitema@huitema.net>
> Sent: den 22 mars 2021 17:19
> To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>; Ingemar
> Johansson S <ingemar.s.johansson@ericsson.com>; Praveen
> Balasubramanian <pravb@microsoft.com>;
> ncardwell=40google.com@dmarc.ietf.org <ncardwell@google.com>
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] [EXTERNAL] Re: Hystart and delay jitter
> 
> Back to Ingemar's point about delay measurement. In wireless networks, we
> should expect conditions to change when the device moves from cell to cell,
> when the number of devices in the cell changes, or even when the client
> stays in the same cell and moves closer or farther to the base station. In Wi-Fi
> network, I remember presentations showing that the quality of the radio
> signal could change radically if the device just moved a couple feet, maybe
> because it would then catch different reflections on walls of the signals sent
> by the base station. Conditions could also change if the device is rotated and
> the alignment of the device's antenna with the base station changes. Or if a
> big two-legged of water moves between device and base station, whether it
> is a big two-legged body or a smaller four-legged body with whiskers.
> 
> The congestion control algorithms that we currently use are not specifically
> designed for such changes in network conditions. They make hypotheses
> about min-rtt, max queue sizes, relation between rtt and congestion, or
> relative stability of the bottleneck bandwidth. As Ingemar points out, these
> hypotheses are not true in wireless networks.
[IJ] Agree, one easy to do mistake is to do a first 3-WHS ping measurement and try to assess path characteristics. DRX (a power saving feature in cell phones) can inflate this initial RTT. And it can well look completely different, seen from the server or client side. DRX can also kick in occasionally if traffic is sparse, which may make RTT spike even though it is not actually congestion. The latter is one good argument for ECN/L4S.

> 
> If I look at simulations in classic papers, I almost always see networks made of
> static links, with fixed bandwidth and fixed delays. Such simulations are not
> going to point out the issues with wireless networks. Are there available link
> models that incorporate the typical behaviors of wireless networks? Better
> simulations would make the problems obvious, and researchers would
> probably invent some clever way of dealing with that. And if such simulation
> models were widely known, peer-reviewers would have something to say
> about papers based on fixed link simulations.
> 
> Ingemar, Mirja, can you point us to such to simulation models for wireless
> segments?
> 
> -- Christian Huitema
> 
> On 3/22/2021 8:17 AM, Mirja Kuehlewind wrote:
> > Sorry, I was confused and thought this was a comment on the Cubic work.
> Would be really good to mention and discuss this in HyStart++ draft. Happy to
> discuss more if needed!
> >
> >
> > On 22.03.21, 16:12, "tcpm on behalf of Mirja Kuehlewind" <tcpm-
> bounces@ietf.org on behalf of
> mirja.kuehlewind=40ericsson.com@dmarc.ietf.org> wrote:
> >
> >      Yes, we also reported on some problems/bugs in HyStart in maprg two
> meetings back:
> >
> >
> > https://datatracker.ietf.org/meeting/interim-2020-maprg-01/materials/s
> > lides-interim-2020-maprg-01-sessa-behavior-of-tcp-cubic-in-low-latency
> > -mobile-radio-networks-00
> >
> >      This problem, where Slow Start is left wrongly and much too early, is
> particularly bad in combination with the TCP friendly region in Cubic.
> However, the actually problems lies in HyStart which is not covered in the
> Cubic RFC/bis-draft.
> >
> >
> >      On 19.03.21, 10:16, "tcpm on behalf of Ingemar Johansson S" <tcpm-
> bounces@ietf.org on behalf of
> ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> >
> >          Hi
> >
> >          My finding is that it is a bit problematic to rely on RTT estimates for
> path
> >          capacity especially with cellular access . It was summarized in section 4
> in
> >          https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02 and also
> >          presented in
> >
> > https://www.ietf.org/proceedings/96/slides/slides-96-iccrg-1.pdf
> >
> >          Regards
> >          Ingemar
> >
> >          > -----Original Message-----
> >          > From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Praveen
> >          > Balasubramanian
> >          > Sent: den 18 mars 2021 23:37
> >          > To: ncardwell=40google.com@dmarc.ietf.org; Christian Huitema
> >          > <huitema@huitema.net>
> >          > Cc: tcpm@ietf.org
> >          > Subject: Re: [tcpm] [EXTERNAL] Re: Hystart and delay jitter
> >          >
> >          > Thanks Christian for the suggestions! We will include a discussion on
> >          jitter in
> >          > the next draft update and also experiment with the min of max
> function.
> >          >
> >          > -----Original Message-----
> >          > From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
> >          > Sent: Friday, March 12, 2021 2:18 PM
> >          > To: Christian Huitema <huitema@huitema.net>
> >          > Cc: tcpm@ietf.org Extensions <tcpm@ietf.org>
> >          > Subject: [EXTERNAL] Re: [tcpm] Hystart and delay jitter
> >          >
> >          > On Fri, Mar 12, 2021 at 4:29 PM Christian Huitema
> <huitema@huitema.net>
> >          > wrote:
> >          > >
> >          > > Back in November 2019, when adding Cubic and Hystart to my
> >          > > implementation of QUIC, I noticed that Hystart was sensitive to
> delay
> >          > > jitter. Hystart detects the buildup of queues by monitoring the RTT.
> >          > > Some links experience delay jitter, caused for example by access
> >          > > protocol for shared radio links or possibly by link-local ARQ
> protocols.
> >          > > The delay jitter can cause Hystart to make the wrong decision, in
> two
> >          ways:
> >          > >
> >          > > 1) Delay jitter during a previous period could cause some packets to
> >          > > be delivered "faster than usual", causing Hystart to under-estimate
> >          > > the min RTT for that period.
> >          > >
> >          > > 2) Delay jitter during the currently measured period can cause
> packets
> >          > > to be delivered "slower than usual",  causing Hystart to over-
> estimate
> >          > > the min RTT for that period.
> >          > >
> >          > > The combination of these two issues may cause Hystart to make
> the
> >          > > wrong decisions, and exit slow start at levels well below link
> capacity.
> >          >
> >          > Yes, we have found in both our production experience and
> controlled
> >          > experiments that the Hystart-Delay algorithm is very susceptible to
> >          spurious
> >          > triggering from jitter, particularly in LTE and wifi paths.
> >          >
> >          > We discussed this a bit in Spring 2017 in the comparison of BBR's
> >          bandwidth-
> >          > based mechanism for exiting startup, vs Hystart-Delay's delay-based
> >          > mechanism:
> >          >   https://protect2.fireeye.com/v1/url?k=6c35f204-33aecb47-
> 6c35b29f-
> >          > 861fcb972bfc-c8f94340e007b7bd&q=1&e=fd13218f-2e70-4b39-a879-
> >          >
> e9b53c01447d&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com
> >          >
> %2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fproceedings%25
> >          > 2F98%252Fslides%252Fslides-98-iccrg-an-update-on-bbr-congestion-
> control-
> >          >
> 00.pdf%2523page%253D8%26amp%3Bdata%3D04%257C01%257Cpravb%2540
> >          >
> microsoft.com%257Cbc3399870c0d4105299408d8e5a4cbaa%257C72f988bf86f
> >          >
> 141af91ab2d7cd011db47%257C1%257C0%257C637511843745826011%257CUn
> >          >
> known%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> >          >
> iI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3D6SQWDb1
> >          >
> mFH0cgrayEwiRYeccYvP0dv%252BAJ1eokyJF%252BKs%253D%26amp%3Brese
> >          > rved%3D0
> >          >
> >          > > The draft-ietf-tcpm-hystartplusplus-01 does have some protection
> >          > > against the second issue, because currentRoundMinRTT is
> computed on at
> >          > > least N_RTT_SAMPLE. If that number is large enough, computing
> the min
> >          > > over N samples should filter out "slower than usual" anomalies.
> >          > > However, the draft does not include a protection against "faster
> than
> >          > usual"
> >          > > anomalies happening in the previous period. In my
> implementation, I
> >          > > protected against that by computing a "min of max" function:
> compute a
> >          > > rolling "MAX over N_RTT_SAMPLE", then compute the MIN value
> of that
> >          > > during the reference period, and use that to set the reference
> value
> >          > > "lastRoundMinRTT".
> >          > >
> >          > > I think it would be good to add a discussion of the effect of jitter
> >          > > to the hystart++ draft. In addition, we may also want to mention
> >          > > timestamps. The jitter on RTT may be caused by jitter on either
> >          > > direction of transmission -- data path or ACK path. The effect of
> >          > > jitter on the ACK path can be minimized if time stamps can be used
> to
> >          > > monitor the variation of one-way delays. This is not discussed in
> the
> >          > > current draft. Maybe it should be.
> >          >
> >          > A discussion of the effect of jitter sounds like a great idea.
> >          >
> >          > neal
> >          >
> >          > _______________________________________________
> >          > tcpm mailing list
> >          > tcpm@ietf.org
> >          > https://protect2.fireeye.com/v1/url?k=032901f3-5cb238b0-
> 03294168-
> >          > 861fcb972bfc-7a6ccb41bd90a846&q=1&e=fd13218f-2e70-4b39-a879-
> >          >
> e9b53c01447d&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com
> >          >
> %2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flis
> >          >
> tinfo%252Ftcpm%26amp%3Bdata%3D04%257C01%257Cpravb%2540microsof
> >          >
> t.com%257Cbc3399870c0d4105299408d8e5a4cbaa%257C72f988bf86f141af91a
> >          >
> b2d7cd011db47%257C1%257C0%257C637511843745826011%257CUnknown%
> >          >
> 257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> >          >
> WwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3Doqte6wCaTBUvrw
> >          >
> gXVRMcD13YgtspMJyIWMMLlwNuYdY%253D%26amp%3Breserved%3D0
> >          >
> >          > _______________________________________________
> >          > 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
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm