IETF Logo Mail Archive

ack delay in rx packets

Subodh Iyengar <subodh@fb.com> Wed, 25 April 2018 15:08 UTC

Return-Path: <prvs=7653103cd5=subodh@fb.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6404D124239 for <quic@ietfa.amsl.com>; Wed, 25 Apr 2018 08:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=jVh7HQJ2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TljIzR2F
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 jtP5O6gbvvw0 for <quic@ietfa.amsl.com>; Wed, 25 Apr 2018 08:08:01 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 E151E124205 for <quic@ietf.org>; Wed, 25 Apr 2018 08:08:01 -0700 (PDT)
Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3PF2gWM015781 for <quic@ietf.org>; Wed, 25 Apr 2018 08:08:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=Rtmr/qtRhJ6HNg0GWJpUtB7QvLzGd3znq3HU4FdcaEA=; b=jVh7HQJ2w5A3q8HQPgHNjR5g1KvH1YaYqyngwCQ1fXQJZUkMP1KhohU8FUC0vxEQnoIC USAw4q5EVQNkpPMHsowPLNsftaTOcz9mhjRKRMpCZyiCFcrlEmMi4wFIq+4NiUnHfKOz 0SFna5yAaEJnJgIw21s7mjegHD9oBtMDrpc=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hjrjx8h6s-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for <quic@ietf.org>; Wed, 25 Apr 2018 08:08:01 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Apr 2018 08:08:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Rtmr/qtRhJ6HNg0GWJpUtB7QvLzGd3znq3HU4FdcaEA=; b=TljIzR2FSWzvCQpHMkxRe4CCaFBKQQDWpXkuSILNZoAsKOdZ0JL0V0QbY4jLZGSrGDG2JOZz2PvBw7z8UE6Z6zBG+q1BJ0ucHYmU70Rjh2bM6rhN5eP6OELoBq2kGhrR5ajJAWuGRauatw43C7EUwm+a8ibdDVLXDbyjn+uDW3Q=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1423.namprd15.prod.outlook.com (10.173.234.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Wed, 25 Apr 2018 15:07:58 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::4569:2fbb:3aab:6126%17]) with mapi id 15.20.0696.020; Wed, 25 Apr 2018 15:07:58 +0000
From: Subodh Iyengar <subodh@fb.com>
To: "quic@ietf.org" <quic@ietf.org>
Subject: ack delay in rx packets
Thread-Topic: ack delay in rx packets
Thread-Index: AQHT3KYtFrc5wMFDcECav0DMEKPj+Q==
Date: Wed, 25 Apr 2018 15:07:58 +0000
Message-ID: <MWHPR15MB1821770E698C99AAD160864EB68F0@MWHPR15MB1821.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c090:180::1:1f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1423; 7:vvKjcOkhN8dszJLiwIegvqtw7p/aKaGnCL9AFy4T/Vlk1v1FOSXU082FkQoOXucXj+XdWljqzxUZEkOKpAyyr5sm8lb1TiM7dDsJwDMNUGbQ5dyUZjvqYQkLwRa19h5gOkhWfvINBxy+yalRnrUvasyGMxTb1mN9Hd9BRTU6qdFZSx1Wfx4hKOQ51ljenFcYSPZMeB1H0aY7I46yVx8fmAjuu4Wt6XpFVkepqquuTbjKUrqP7542OjMp94D9KUPe; 20:E0w/vu5xOv+bYVMgj+diFpIuf24J5RcAKcxoPpgxFhVMQWkfuIDXGM4+U7Qlsiewc64sgFj1Ru7FyTTT/jkBvchvnNFzE798gYumDHSfZRseV2HlMF5Ua2FCx/Nm1QpQoJ9a58pkgI439tbCkMAXbvnclIuxHbPTcWwdxjdTguE=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1423;
x-ms-traffictypediagnostic: MWHPR15MB1423:
x-microsoft-antispam-prvs: <MWHPR15MB1423357344B3ADF1A783EB54B68F0@MWHPR15MB1423.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231232)(11241501184)(944501410)(52105095)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR15MB1423; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1423;
x-forefront-prvs: 06530126A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(39380400002)(346002)(376002)(396003)(199004)(189003)(186003)(3280700002)(3660700001)(6606003)(2906002)(19627405001)(7736002)(6916009)(6506007)(8676002)(5660300001)(102836004)(5250100002)(2501003)(2351001)(97736004)(86362001)(74316002)(55016002)(68736007)(9686003)(5640700003)(54896002)(6436002)(53936002)(2900100001)(105586002)(478600001)(33656002)(106356001)(25786009)(476003)(486006)(46003)(6116002)(81166006)(316002)(99286004)(81156014)(7696005)(8936002)(14454004)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1423; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: IPqonCryyF26mJalmGGAOuG4TFnCdulq0xhOOJn090QSATuyDWu+AqKVmK++vtP73f2dwItIwQIxyXY+g8XXwzPxhxTJj7SOeLDPQC8v0RW8/PBiNS7SvF4scTjzb6HqFR/rvyJwLxnZGgkfd5gBTuRecN5B81/1yvhoAbdFIYlGKiJcUsiqN1o0DMQNzdPG
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1821770E698C99AAD160864EB68F0MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 9bb66bec-56a9-4263-4fde-08d5aabe54e4
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bb66bec-56a9-4263-4fde-08d5aabe54e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 15:07:58.6456 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1423
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-25_04:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/hwpSeZt-rFjzrluAgMDRM5k-SQI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2018 15:08:03 -0000

We ran into very common cases where we might have all our data to send already outstanding, so when a TLP and RTO alarm fires, we have no new data to send, so we resend data that was in previous packets.


In the time that the RTO fires, we might not have received any new packets, however want to send ACKs in this new packet as well. Since no new packets were received, this ACK will have the same largest acked as the previous packet.


One question came up as to what the ack delay of an ACK in such a rx packet should be. We could technically set it to the time since receipt of the packet, however with the new max_ack_delay computations, adding this might screw up our estimate of the normal ack delay, so I don't really want to do that. Is there a better option here, or does max_ack_delay not cover this case?


Subodh

v2.23.0 | Report a Bug | By Email