IETF Logo Mail Archive

RE: Special TCPM meeting on draft-ietf-quic-recovery

Praveen Balasubramanian <pravb@microsoft.com> Tue, 06 November 2018 02:18 UTC

Return-Path: <pravb@microsoft.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 EF6B112F295 for <quic@ietfa.amsl.com>; Mon, 5 Nov 2018 18:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level:
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vOxMhDrQPCcL for <quic@ietfa.amsl.com>; Mon, 5 Nov 2018 18:18:44 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0105.outbound.protection.outlook.com [104.47.42.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E301294D0 for <quic@ietf.org>; Mon, 5 Nov 2018 18:18:44 -0800 (PST)
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=4qZJamyyU0OaSVpVUFoIqltPYMyE4EFHKAvh8u8FR0o=; b=h0SgDP0Gkp31uGTvpzppwDDqhwSQx3m5O8TwJP297vNN+A6SX8F5vJYo1Tccr+2Yy5g7RB9ARRmSYFZg0Z7x2O1LhhdFceTr9sF1FI3ugxiFR83u/Ciqodd8D51JgpVOwtPrjsSeAi/7ddMn3kcmlbrGO9bIeSBiMqQW7RUuS+U=
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0908.namprd21.prod.outlook.com (52.132.152.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.7; Tue, 6 Nov 2018 02:18:43 +0000
Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a%2]) with mapi id 15.20.1339.006; Tue, 6 Nov 2018 02:18:42 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Jana Iyengar <jri.ietf@gmail.com>, QUIC WG <quic@ietf.org>, Ian Swett <ianswett@google.com>
CC: Matt Olson <maolson@microsoft.com>
Subject: RE: Special TCPM meeting on draft-ietf-quic-recovery
Thread-Topic: Special TCPM meeting on draft-ietf-quic-recovery
Thread-Index: AQHUdECt9DEgqy6Sck+PiUV4zlmPwaVCAdXw
Date: Tue, 06 Nov 2018 02:18:41 +0000
Message-ID: <MW2PR2101MB1049C5E616EC3ED28F85395BB6CB0@MW2PR2101MB1049.namprd21.prod.outlook.com>
References: <CACpbDccH=5HCYmxfW-ffoEv97GiuFfbBVSSQMot0gaZy2c86ag@mail.gmail.com>
In-Reply-To: <CACpbDccH=5HCYmxfW-ffoEv97GiuFfbBVSSQMot0gaZy2c86ag@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:1:809d:901d:48f:b8f0]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MW2PR2101MB0908; 6:yPDNFiZ5wIs+LNXEbROM/LLR2//dUd39+KgAX3fKXVJ4pki+6TGs7Odg4VarvVXdbB0eU0YMyknsexBFZtidP4WiQ7ywmWo/19afJzQrSLas60VUZRlmcZugzc0MsTxWLXk3GTRiBmiXMrBn7QIEzGyHsBDiDkacabl4GfzhCFqutHiCqZKf9hVPlBDYbAkscmBpcPKl1310H/QG6/SFKYikGOaDpXnLqQkL045o4JX7SEesRzTTL8SRIrn7ymX8pLd+Q5TIedPOfi9I1Z2oVqA+KuhANc64nleh6qNxozbt/weVFOo3hCZA3vJ8M8wQ+muKlpxXQgE+wshKY2y4hd5hb+aihLM5ZF9tLfVZHtX8PPDIdUANMosqWkyqJvYD7C+rcHUxlQZt1GadsGLLVHsKTcflbQ62FJGfp9D9W0+qR4FJWaT5UkrdBwyV0NK+kPlhJu0N9Z2buUIOKRJIhw==; 5:wfGGnhTR2Y9OkY7JenwrVMKiW0cVZcNaS0pfYikuBN8414x0rTtbJSXKUkMUbKKeCUXV+Ked9zg3RSRF9949q4f9c4ZjQkbvyVKYdSvBYEfiLsQBqM1P4CzxevFCL4RJEd3HYuM3ecBJhUdauLGx1ectsSeex1Rgz5N3d6op2xA=; 7:VXr6wOSa7sDpPWb5U43lUUMNiq3ixDczhSW+qBQA9M9bSkztBrSgHNLQc7qwbtZlnTk66cJ0yj/yTwb3788613rjOAivQbmPdpe3GJ2r5MPhXk5S+kMpIpq1WMWLcRgAP9cHa3qOqigFoe/paqQOZw==
x-ms-office365-filtering-correlation-id: 54f80fe9-69d4-490c-e1ec-08d6438e2c17
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR2101MB0908;
x-ms-traffictypediagnostic: MW2PR2101MB0908:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <MW2PR2101MB090819ED60E995686A2C263FB6CB0@MW2PR2101MB0908.namprd21.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(8220035)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231382)(944501410)(52105095)(2018427008)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:MW2PR2101MB0908; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB0908;
x-forefront-prvs: 0848C1A6AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(39860400002)(376002)(346002)(189003)(199004)(186003)(22452003)(11346002)(7696005)(46003)(486006)(476003)(446003)(81156014)(8676002)(81166006)(76176011)(229853002)(10290500003)(71190400001)(5660300001)(25786009)(7736002)(53546011)(10090500001)(106356001)(105586002)(102836004)(74316002)(6506007)(71200400001)(4326008)(55016002)(33656002)(6246003)(2906002)(107886003)(86362001)(86612001)(478600001)(316002)(2900100001)(8990500004)(790700001)(6116002)(39060400002)(68736007)(110136005)(8936002)(53936002)(99286004)(256004)(9686003)(14454004)(6306002)(54896002)(97736004)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0908; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: RSQjtIjen+WwZoptx2NOqkjdnzIYAAD0b3/04iF/KpLACVuR+WYRv1p5ulWn6mT2adslWvh53YB8GquDD4KC28zBx3NZutro/hRdvlmthRbPW0r3yWng51H3nVGj+rlzGt7j2ZmA0rt4/MeuVlCENOXNemGH9TNbtaVayqa2EtfqaAWO0II/zuUPJRFuTA22GxijUafuvOGNYS1iX5/DWmpIqGanyCC6actddfO7COHMnEbjTQlB6R950MZtvOViQ7PdkPB2gzwfqq8tNTVRyyzM0Vy4gz6y5vhwHDmSZZyMlhPV/gwtd1a2R3sV+RgWGolFvh7gG358RSKfgp2I9EusVUkh/QYrY8h3SYjkLjw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB1049C5E616EC3ED28F85395BB6CB0MW2PR2101MB1049_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 54f80fe9-69d4-490c-e1ec-08d6438e2c17
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 02:18:41.8269 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0908
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pw1dR5Nhp9kDVX9ueHOQxYLvH0A>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 06 Nov 2018 02:18:47 -0000

Some differences from TCP that are worth discussing in this meeting:

  1.  Loss recovery epoch. QUIC may reduce cwnd several times on successive losses whereas TCP will keep cwnd constant until (longer) recovery exit or RTO.
  2.  Cwnd not reduced until an RTO is confirmed. In app send limited case, inflight could be very small compared to cwnd. So in QUIC there is potential to send a burst out after a long idle period (with outstanding data) where TCP wouldn’t. The draft claims this is okay to do because RTO may have been a result of RTT increase instead of loss. Is there data to suggest on which side we should err? i.e. data on what are the chances that an RTO is due to an RTT increase versus loss.
  3.  Min timeout for Crypto = 100 msec in absence of RTT samples. I believe the TCP RFC requires a minimum of 1 second in this case.

Another difference is kMinimumWindow = 2 versus 1 in TCP. Ian has said he will do an experiment to test IW = 1 or 2 and then decide the next steps, so IMO no discussion needed in this meeting.

Some more feedback on the draft (not necessarily as a comparison to TCP):

  1.  kUsingTimeLossDetection variable seems superfluous. All it seems to do is control RACK versus ER. It’s not even controlling FACK. Why not always do time based detection including FACK and TLP, and remove ER from the spec? Time based loss detection subsumes ER.
  2.  Immediate ACK on receiving CE = 1. This doesn’t work for DCTCP where ACK should be edge triggered (CE 0 to 1 or 1 to 0 transitions). So this is dependent on congestion control algorithm.

From: QUIC <quic-bounces@ietf.org> On Behalf Of Jana Iyengar
Sent: Sunday, November 4, 2018 5:17 AM
To: QUIC WG <quic@ietf.org>
Subject: Special TCPM meeting on draft-ietf-quic-recovery

PSA: For those not paying attention to the TCPM mailing list, the second TCPM session (Tues, 11:20-12:20, Chitlada 1) is dedicated to a discussion of QUIC loss detection and congestion control (draft-ietf-quic-recovery).

v2.23.0 | Report a Bug | By Email