IETF Logo Mail Archive

RE: Q and L loss bits: which is which?

"Lubashev, Igor" <ilubashe@akamai.com> Wed, 20 November 2019 00:37 UTC

Return-Path: <ilubashe@akamai.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 F132D120861 for <quic@ietfa.amsl.com>; Tue, 19 Nov 2019 16:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 TfnToefvi8KW for <quic@ietfa.amsl.com>; Tue, 19 Nov 2019 16:37:05 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 6AC2212018B for <quic@ietf.org>; Tue, 19 Nov 2019 16:37:05 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAK0Zoeq020886; Wed, 20 Nov 2019 00:37:04 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=5vrlzAmMmaiGgGXGz2BmSdKCmaBwf6/gEljxuloGmQs=; b=Uz6yTT51TiXe96T9E5eqcvV0E23QBnhecHemfXLXI11RnGfh2lamsG5Xn30u+e4d8kqC 9hhu8iJx2I7Mw8eHfLK/qXbu9B2R3OfKr/fL9KSrr2/ITyKxxAd1c9K022iA9xqNBv38 AvsIGDndtYqGBic+xOSXMyet8j8fyQrP/Xo5L66lpII0kS2Xp8/D7JedyvpZ/qD2oRC2 MTB2XWSOaSYfAjRUMsZXTEP7llqhhZLiMTYTrzx/Gq1D5ZLSLe4cTZMnKrpGC4HMIJOo xNu1HeebcG4Jvhtj3LhBKoZQwcQlYZlz6MrM0fQcjHadHPo08mXA6XA5HFsxp0AmXkAZ BQ==
Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2wafwvg0my-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 00:37:04 +0000
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAK0WKlU023834; Tue, 19 Nov 2019 19:37:02 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 2wadb1s1hd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 19:37:02 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 18:37:01 -0600
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1473.005; Tue, 19 Nov 2019 18:37:01 -0600
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Christian Huitema <huitema@huitema.net>, "Brian Trammell (IETF)" <ietf@trammell.ch>
CC: IETF QUIC WG <quic@ietf.org>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>
Subject: RE: Q and L loss bits: which is which?
Thread-Topic: Q and L loss bits: which is which?
Thread-Index: AQHVnuYxGYRqnRW1T0W5CpBoQ1gaSaeS98cAgAAFaICAAEgOgIAAQQmA//+iQwCAAG3AAIAAAoOA//+dbSA=
Date: Wed, 20 Nov 2019 00:37:01 +0000
Message-ID: <d699f1998e8a44109c5513f6e8a4fe55@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <EFE60BCA-89EE-4A78-8E5B-EB8B8ED25DD9@trammell.ch> <9F90F822-7B26-4B59-9F6E-F43D7935867E@huitema.net>
In-Reply-To: <9F90F822-7B26-4B59-9F6E-F43D7935867E@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.216.50]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=701 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911200004
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-19_08:2019-11-15,2019-11-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 clxscore=1011 mlxlogscore=671 impostorscore=0 suspectscore=0 bulkscore=0 malwarescore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200003
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/a17u7-Zm99M0dJ0TqpLxqkG7iC0>
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: Wed, 20 Nov 2019 00:37:07 -0000

> On Wed, Nov 20, 2019 at 8:25 AM, Christian Huitema <huitema@huitema.net> wrote:
>
> OK, but if I determine that a loss is spurious I revert the congestion control
> state to what it would be if the loss did not happen.

Ok, I think there is a better middle ground.  If the counter is > 0, sure, decrement it (since the loss has not yet been reported).  But if the counter is already 0, do not let it go negative, because then you would not be able to report an actual future loss event (and an actual future congestion controller response).

- Igor

v2.23.0 | Report a Bug | By Email