IETF Logo Mail Archive

RE: What CSRs Do

"Lubashev, Igor" <ilubashe@akamai.com> Tue, 19 November 2019 07:03 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 3DF81120BA7 for <quic@ietfa.amsl.com>; Mon, 18 Nov 2019 23:03:09 -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 ylSJ8cmvKwym for <quic@ietfa.amsl.com>; Mon, 18 Nov 2019 23:03:03 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 94058120927 for <quic@ietf.org>; Mon, 18 Nov 2019 23:03:03 -0800 (PST)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAJ71ONN012128; Tue, 19 Nov 2019 07:03:00 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+122sFy13GyP78ObSf1/6808AJIsfC/9W1eBs31KK0I=; b=Bzr4RYLkr5PCZ0OC8hitmHxetsFCr+iCKJgwLpMOFTqbZLuO0QaoVfANH7gpC6mPTCE6 K3v5WvuIwr5yqIwc2PAD/ngPT9M7/gaZP7nP622vdy3SLwiXPfXgfywJkTHGMe2vpY8Z gU87hjEw5UB+5IuG1c/bvhJK7Ew8vNOW9WQTBIwxUl0JQQ+DDllRFwn4axpwEhDy6Eip rZGsvg41mxrWUyPohzz6SIQIasGia6y9YXn4IYv4O5wHej/sKpwTLjQAA05KEwIAg8hQ hOcTSXaX13rBnwku7RzTAdjtCRmyVlSfU4PkMSMCLnbgzlsIegi3We+ehbVOct6D5Yrg qA==
Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wag31km25-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 07:02:59 +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 xAJ72RF9013275; Tue, 19 Nov 2019 02:02:59 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 2wadb1a43f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 02:02:59 -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 01:02:58 -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 01:02:58 -0600
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Frode Kileng <frodek@tele.no>, "quic@ietf.org" <quic@ietf.org>
Subject: RE: What CSRs Do
Thread-Topic: What CSRs Do
Thread-Index: AdWeiLnP74voAASmTy29ATmkahTsZQANieYAAAFSQgAAAxM6gP//nbXWgABu3gCAAGD/EA==
Date: Tue, 19 Nov 2019 07:02:57 +0000
Message-ID: <c73b86c40c574ad099d7245a2b5712da@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <BL0PR11MB3394D769128DEFEEFBC3CA71904C0@BL0PR11MB3394.namprd11.prod.outlook.com> <0cf4d3ad-0f64-0ae4-2d95-77a39f40639d@tele.no> <20191119042904.GC5602@1wt.eu> <4003626d-8966-6772-7df0-e76549320430@gmail.com> <1574144751435.15844@akamai.com> <bc0cf83f-16d6-3200-5d6e-091311ccf9a7@tele.no>
In-Reply-To: <bc0cf83f-16d6-3200-5d6e-091311ccf9a7@tele.no>
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.218.207]
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_01:, , 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=381 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911190065
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-19_01:2019-11-15,2019-11-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=352 adultscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1011 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911190064
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8be6keIfFatHm27bc8HHokMNIiU>
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, 19 Nov 2019 07:03:12 -0000

> On Tue, Nov 19, 2019 at 2:42 PM, Frode Kileng <frodek@tele.no> wrote:
> 
> On 19/11/2019 07:25, Lubashev, Igor wrote:
> >
> > This is assuming there is a robust set of "other 'loss source'" available. This is
> far from reality for the vast majority of cases.
> 
> So then there's two alternatives: a) Standardize a "loss-signal" option in QUIC
> and hope this is implemented and supported. b) Network operators lacking a
> "robust set of other loss sources" obtain such sources.

I do not think these are conflicting alternatives.  I am sure vendors will try to invent new tools, which is great.

As for loss-signal (as well as delay signal), these are definitely "experimental" features. There are many features that IETF standardized and never got widespread adoption. The benefit of QUIC is that it looks poised for a quick protocol evolution. If a feature gains widespread support, it would remain; if not, it would not make a future QUIC version and the bits occupied by loss- and delay- bits would be reused for something else.

> frodek

- Igor

v2.23.0 | Report a Bug | By Email