Re: What CSRs Do

"Lubashev, Igor" <ilubashe@akamai.com> Tue, 19 November 2019 06:26 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 5EAC2120872 for <quic@ietfa.amsl.com>; Mon, 18 Nov 2019 22:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] 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 hxUh7BSmr8R9 for <quic@ietfa.amsl.com>; Mon, 18 Nov 2019 22:26:11 -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 1F0D6120834 for <quic@ietf.org>; Mon, 18 Nov 2019 22:25:59 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAJ6PSI7007189; Tue, 19 Nov 2019 06:25:55 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=2wvM+kD2Qz0s80aNk2IZ03DENgqj5h+glbkEPG/yOBk=; b=kdoI4ScFopP5SJdCvhheZDNLIW2Z1HLAIGzaQvGnRiUPFIGrwZggHDuspHQhFWo7C9Ln 8h/vjZPR0nirHfuqm/PZaK2dyGtCKvYJbngQJntNH5/YvY/aQ4mUPzCgRvGvxpIbx4Dq /wHGps7WlDCktsx474FGdhaD3jejqinRHn7OUx0h2xF9dyW8PSVpdYWOuqZl9hde8tvQ /bwirylFQJC/U2cvXumtEvbSyBpzrcSItk80r0gocGg97rxzkR7WCT7ri1dn1fD7S5DQ p97tXljtBW89EFo0bduYOj3nt3SV4sUwWmWzT+deh9l6UU/jQhqtmkOfTOQE2w6jcklF UQ==
Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2wafywc2an-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 06:25:54 +0000
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAJ6HF3A016534; Tue, 19 Nov 2019 01:25:54 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint7.akamai.com with ESMTP id 2wadb3r4e5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 01:25:53 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 00:25:52 -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 00:25:52 -0600
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Frode Kileng <frodeki@gmail.com>, "quic@ietf.org" <quic@ietf.org>
Subject: Re: What CSRs Do
Thread-Topic: What CSRs Do
Thread-Index: AdWeiLnP74voAASmTy29ATmkahTsZQANieYAAAFSQgAAAxM6gP//nbXW
Date: Tue, 19 Nov 2019 06:25:51 +0000
Message-ID: <1574144751435.15844@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>
In-Reply-To: <4003626d-8966-6772-7df0-e76549320430@gmail.com>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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=443 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911190057
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 priorityscore=1501 malwarescore=0 bulkscore=0 spamscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1011 mlxscore=0 mlxlogscore=415 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911190058
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ngnZBUVA9-pWBVmI7gL-WXR4g3I>
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 06:26:13 -0000

On Tue, Nov 19, 2019 at 12:57 AM, Frode Kileng <frodeki@gmail.com> wrote:
> On 19/11/2019 05:29, Willy Tarreau wrote:
>>
>> The only known alternative is to claim "we have no loss here" and point the
>> finger at the next step in the chain operated by someone else.
>
> What additional value can "loss bit(s)" provide beyond confirming that
> the source is within your network domain or somewhere else, i.e.
> information that is available from other "loss sources".
> How would network operators use this loss bit(s) signal when providing such
> "excellent customer support" when the problem source is external?

This is assuming there is a robust set of "other 'loss source'" available. This is far from reality for the vast majority of cases.

Also, the loss bits(s) would allow one to determine whether the loss is upstream or downstream.  That would allow you to know "whom do you call".  I.e. is the loss in your transit or peer? Is it in the user's own home WiFi network?  Or is it really in your network?

In general, it is important to keep in mind that we live in the world as it "is" and not in a world as it "should be".  I know little of ISP tech support business, but if ISPs says they have no other tools, I believe that they have no other tools currently. We can to encourage change, but if you push too hard, the reality has a way of pushing back.

> frodek

- Igor