Re: What CSRs Do

Frode Kileng <frodek@tele.no> Tue, 19 November 2019 03:51 UTC

Return-Path: <frodek@tele.no>
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 20659120048 for <quic@ietfa.amsl.com>; Mon, 18 Nov 2019 19:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=tele.no
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 yTNOcktnTdJj for <quic@ietfa.amsl.com>; Mon, 18 Nov 2019 19:51:23 -0800 (PST)
Received: from gorgon.tele.no (gorgon.tele.no [IPv6:2001:700:800::70]) (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 C5272120044 for <quic@ietf.org>; Mon, 18 Nov 2019 19:51:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tele.no; s=20180731; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=TCitX3tS9l8iiOBgDiFQHGfxzhK14IjThgnRjgpUcyo=; b=aXJ7CAXBEqpfxzteTbix6d+/jX hinpjtqcIzvVBd9MOb90Ic6E5z4ozvP/4FpIVuMwnTDeiLYs4Y36pNFUnDki8MJzVi8liRqRdCuYL 1cV1SGtiMieTh20iEyw5S5KGw0UcktKKBB+mcLbQ1yemhBvQ7G9+HEdfw01p4HQmT7Xnd+OZ4/BHf mH0jTYmc8oDol+KAZUG/sQqEAhSyUVUUl/NfkpuHtSCL6ZsxgDhQDIlk0SRi0dOhU8CVauXZJFmyx 2qvOga/lww7w6kkJ79pncTQkzZoAU7agDre8NF16b5eE9H2QRWAQxIghqXQaZnU5l9y7S6UsSd781 YqtFngSQ==;
Received: from pilt1.tele.no ([2001:700:800::20] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.92) (envelope-from <frodek@tele.no>) id 1iWuXt-0004Ss-PW; Tue, 19 Nov 2019 04:51:18 +0100
Subject: Re: What CSRs Do
To: "Border, John" <John.Border@hughes.com>, "quic@ietf.org" <quic@ietf.org>
References: <BL0PR11MB3394D769128DEFEEFBC3CA71904C0@BL0PR11MB3394.namprd11.prod.outlook.com>
From: Frode Kileng <frodek@tele.no>
Message-ID: <0cf4d3ad-0f64-0ae4-2d95-77a39f40639d@tele.no>
Date: Tue, 19 Nov 2019 04:51:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <BL0PR11MB3394D769128DEFEEFBC3CA71904C0@BL0PR11MB3394.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/gpQDSrFrXZ1RoGjLzfMEnhsIufY>
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 03:51:25 -0000

On 19/11/2019 04:34, Border, John wrote:
>
>      I agree that it is too late to solve problems like 
> troubleshooting packet loss for v1.  Plus, we want a good solution 
> (which takes time).  But, we need to solve this problem or it will 
> impact QUICv1 deployment…
>
>      When a customer calls reporting that an application does not 
> work, the Customer Service Representative is trained to do whatever it 
> takes to fix the problem as quickly as possible.  Time on the phone 
> equals money.  And, unhappy customers equal churn.  There is a lot of 
> anecdotal learning involved with the troubleshooting process. If the 
> CSRs learn that disabling QUIC fixes the problem (because the 
> application falls back to TCP), eventually this will become the first 
> thing that is tried every time. Eventually, their supervisors will 
> push for disabling it across the board.  Once disabled, it is a lot of 
> work to get it reenabled.
>
I do think this exemplifies that some network operators have operational 
practices they want to preserve and requests "packet loss" signal 
support in v1. Other operators use alternative operational practices. 
Should the WG  make efforts to contribute to preserving current 
practices of some network operators?

Frode