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

Yi Huang <huanyi@microsoft.com> Wed, 17 April 2019 22:09 UTC

Return-Path: <huanyi@microsoft.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 B1D331201B1 for <tcpm@ietfa.amsl.com>; Wed, 17 Apr 2019 15:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=microsoft.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 S3kMU1pouBBV for <tcpm@ietfa.amsl.com>; Wed, 17 Apr 2019 15:09:09 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740125.outbound.protection.outlook.com [40.107.74.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C2B120112 for <tcpm@ietf.org>; Wed, 17 Apr 2019 15:09:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=Avl5HE1XsM7E8Q4dsd2bwuAXucqwOL63tOU/Tw1SieOehYcVdTn0qYhbESchz7S3uXSS7xhSjtuye3cwhXywy4j86KrwS71fJYSEPHuyGjCYAgJlmcScZI+aHr9LsdlQ3sqCOZT8R+QStVnPspEuEzDxQZ5v+ie+s7wp0QjAYwf++8lN728zdkKt3qDfa9QYIU0d4JpIAW8YtBTxaaLyUfWbIXF18+HZ7peVGB3c9Un9ThBMxo+5zaXYXyoYLvNhHkOgjbheGdY2yn3c6vkZHnlzTHKiQAn76iH3TfICbPufczp+zpfJFwmi010q507P6oFu4qzhPcy44AxuFWRGOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tYoFJCY5h3kvQGS8tjl+bCI3lIOJrkTHzUE8RMp9Uh8=; b=YFhiEqkAKpENxVGNxT9izD8LTpn3Gj/1GwX3JUS7NKhmgTpvVooP6mA6zSI+fUYJHDUO6zxfdR8PLlfEczez8a2lEC4e5TF+RueBt1nNPHegUamv2J7dA1fXnJqhkrJ50OGBHIkKT4EX7FwLM0xdjBWCAEEsCed66SOPlOBsakL27lQFVSe3yb1haZIhRf25KPmtMhTix6Zp7onQgan0OCs/cqVmxe5UgP0lQFgz1+CeAHXpMACHZr4yyQVVIqTknyCeE4dB2vMhpHx4kUjqUtx7Q4/J5juorItjETK7UfCEhgeVj4wSks0fG87/wSqhIzdDzDEMftwoyw5dKZc5Uw==
ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tYoFJCY5h3kvQGS8tjl+bCI3lIOJrkTHzUE8RMp9Uh8=; b=Wj2UjaX3Wd7/iC82bHFZdGtiulJR14kelYuaHYQKHWDz84Zq0KZwFqNAbQzSRrVgqKWGj8tJfnPg7JlP0f3ygubRiUi0/VQbNIVCBaaEvpyrk9L2t3p28cf6Mk0n5T9BJa2H8IksLnkInJYffanhSVGbTi/lVNwBzDUVXs0G7K4=
Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (52.132.24.13) by BL0PR2101MB1012.namprd21.prod.outlook.com (52.132.24.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.6; Wed, 17 Apr 2019 22:09:03 +0000
Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9%8]) with mapi id 15.20.1835.000; Wed, 17 Apr 2019 22:09:03 +0000
From: Yi Huang <huanyi@microsoft.com>
To: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>, hiren panchasara <hiren@strugglingcoder.info>
CC: "tcpm@ietf.org" <tcpm@ietf.org>, Matt Olson <maolson@microsoft.com>, "draft-cheng-tcpm-rack@ietf.org" <draft-cheng-tcpm-rack@ietf.org>, Priyaranjan Jha <priyarjha@google.com>, Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>
Thread-Topic: [tcpm] A question about PTO/RTO rescheduling in RACK draft
Thread-Index: AdT0v450DAV7LlJPShaJ9NxD6aYmRAAibyEAAADFGxAAAZ2MAAACXLAAAAMODIA=
Date: Wed, 17 Apr 2019 22:09:03 +0000
Message-ID: <BL0PR2101MB1043291C3F10700EA22B778BC3250@BL0PR2101MB1043.namprd21.prod.outlook.com>
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>
In-Reply-To: <CADVnQym8cSACWmbbOSugb-QRcxpuaYTVKGPD=XX5i0AQH8m-JQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-04-17T22:09:02.2131489Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=339615d5-ed45-455b-ad6f-e9230ed65cec; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com;
x-originating-ip: [2001:4898:80e8:a:90dd:d90c:8727:9001]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 73a0d452-f96d-4e41-8bcd-08d6c3814d87
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR2101MB1012;
x-ms-traffictypediagnostic: BL0PR2101MB1012:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BL0PR2101MB1012A992400E37DC8A2C54A4C3250@BL0PR2101MB1012.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(366004)(39860400002)(199004)(189003)(14444005)(25786009)(256004)(97736004)(55016002)(316002)(110136005)(22452003)(71200400001)(54906003)(8990500004)(6116002)(74316002)(790700001)(102836004)(186003)(10290500003)(71190400001)(7736002)(14454004)(2906002)(53546011)(6506007)(10090500001)(478600001)(33656002)(93886005)(9686003)(5660300002)(6246003)(4326008)(7696005)(11346002)(236005)(446003)(46003)(76176011)(81166006)(68736007)(86612001)(81156014)(6306002)(476003)(606006)(486006)(8676002)(54896002)(6436002)(99286004)(53936002)(9326002)(86362001)(229853002)(52536014)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1012; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DcifIVfihVcpu4L52ePgCl5panZyHj7EWf2U7JOFeZfPz6ddyB0ZhKNhrvI3200DWMOlxhf9EhaZO8ulnTPRQ0PJUtHYbUFRgGkG6qdNKG9lQnntSIsKo2hIr5ldKdAoySc7LLV3pysYWjbcX8LGo2adz3PYtGGYJbzmdw2BrRAar8belGtkaBA3Eq6Zp8ocy4Q3r2zpzHGsIO98ogv9sTB82NoIDGzxL3g/+Ax9g0KvHuZEIUZVwxjM1Havrb43k2/mld+c+1kedJLboKI3V9p0Nx/llozYchQgPKZM94MQBU4qSnQ0UnP3mBWoj4eysCtx58eZdEBGHuex+IrKCE1q/9lQpc5IoayTfqf9lMYHk1v18l2A+ou/7nmjgl9DM9nWTrwmuwx/2YXPaxHRYKXdHYcMsNPzPZZriF9WTJ0=
Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1043291C3F10700EA22B778BC3250BL0PR2101MB1043_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 73a0d452-f96d-4e41-8bcd-08d6c3814d87
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 22:09:03.6661 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1012
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/KJ6poI_Qx2TcTWjB_iSAtMPsaRY>
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: Wed, 17 Apr 2019 22:09:13 -0000

Hi Neal,

Thanks for your quick response and also thanks Hiren for the help. It’s very clear to me now.

Yi

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Wednesday, April 17, 2019 1:30 PM
To: hiren panchasara <hiren@strugglingcoder.info>
Cc: tcpm@ietf.org; Matt Olson <maolson@microsoft.com>om>; draft-cheng-tcpm-rack@ietf.org; Priyaranjan Jha <priyarjha@google.com>om>; Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>
Subject: Re: [tcpm] A question about PTO/RTO rescheduling in RACK draft

Hi Yi and Hiren,

Thank you for raising this question and the continued discussion.

I think there are a few concrete mechanisms that kick into play in the kind of scenario Yi lays out.

(1) The TLP is scheduled at the min of the "native" TLP time and the "native" RTO time, as laid out in section 6.5.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tcpm-rack-04%23section-6.5.1&data=02%7C01%7Chuanyi%40microsoft.com%7Cd36a239568784d5233d908d6c3737cb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911298117752987&sdata=qlPq%2FDtmZYp4zumBJZPDq%2FNX3vFumJB3qzT4ZzHYmiM%3D&reserved=0>amp;reserved=0>.:


   TLP_timeout():

  ...

       If Now() + PTO > TCP_RTO_expire():

           PTO = TCP_RTO_expire() - Now()

   This keeps the TLP (PTO) from being pushed past the time at which an RTO previously would have fired.

(2) After the TLP probe is sent, an RTO timer is scheduled and fires. The intent is to not get stuck in cycles of repeated TLPs.

To illustrate more concretely, below is a (passing) packetdrill script illustrating/documenting the Linux TCP behavior in this kind of scenario, showing the points at which a loss probe and timeout happen.

We will need to update the draft to make these aspects more clear. Thank you for raising this!

neal

------------------
// Test for TLP with an app that makes periodic small writes.
`nstat > /dev/null`

// Establish a connection..
    0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
   +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
   +0 bind(3, ..., ...) = 0
   +0 listen(3, 1) = 0

   +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
   +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
  +.1 < . 1:1(0) ack 1 win 257
   +0 accept(3, ..., ...) = 4

// Small write of 2*MSS.
   +0 write(4, ..., 2000) = 2000
   +0 > P. 1:2001(2000) ack 1
   +0 %{ assert tcpi_ca_state == TCP_CA_Open }%
// TLP is scheduled 200ms later, but app writes again before that.

// Small write of 2*MSS, which pushes back TLP timer.
+.150 write(4, ..., 2000) = 2000
   +0 > P. 2001:4001(2000) ack 1
   +0 %{ assert tcpi_ca_state == TCP_CA_Open }%

// Loss probe is a retransmission, scheduled at a time
// calculated by the RTO formula, 300ms after the
// first packet we sent.
+.150 > P. 3001:4001(1000) ack 1
   +0 %{ assert tcpi_ca_state == TCP_CA_Open }%
   +0 `nstat -a -z | grep LossProbes`

// Small write of 2*MSS.
+.150 write(4, ..., 2000) = 2000
   +0 > P. 4001:6001(2000) ack 1
   +0 %{ assert tcpi_ca_state == TCP_CA_Open }%

// RTO timer fires.
+.210 > . 1:1001(1000) ack 1
   +0 %{ assert tcpi_ca_state == TCP_CA_Loss }%
   +0 `nstat -a -z | grep TCPTimeouts`